[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [RFC PATCH v2 1/2] virtio-gpu: add resource create blob
On Thu, May 14, 2020 at 1:24 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > > > Cool. I left out SCANOUT_FLUSH in v3 since AFAICT we'll only have one > > blob resource per scanout, and that blob resource will encompass the > > entire window (since we set_scanout when display parameters change). > > And to update the scanout blob resource, we can just call > > RESOURCE_FLUSH. > > Hmm, right, using the SET_SCANOUT parameters in case of BLOB resources > should work. Ok, so removing SCANOUT_FLUSH makes sense. > > > Though SCANOUT_FLUSH does make sense if you want multiple blob > > resources per scanout surface, so if there's a desire for some > > additional functionality, LMK. > > Other way around: one big framebuffer/resource backing multiple > scanouts. > > xorg used to handle multihead setups that way, but these days it is > rather uncommon. Typically userspace creates one drm framebuffer > per drm crtc. So, yes, I guess we don't have to worry much. > > > Also, TRANSFER_BLOB is also another maintenance vs. future proofing > > tradeoff -- for example, emulated coherent memory[1] (for platforms > > without the host-visible region or external memory extensions or > > shared guest) may benefit from such an API. However, the > > implementation of that doesn't exist and may not for a while (focusing > > on true zero copy for now), and the virglrenderer impl of the > > hypercall will likely just be a stub for now. So if that's > > undesirable, LMK. > > Implies the linux kernel can't use blob resources for dumb BOs in > case shared memory isn't available, v3 only allows VIRTIO_GPU_BLOB_MEM_GUEST for dumb blob resources, which implies we won't really use TRANSFER_BLOB. Currently, the path seems to be: SET_SCANOUT TRANSFER_TO_HOST_2D --> copies from iovecs to host private resource RESOURCE_FLUSH_BLOB --> copies from host private resource to framebuffer A theoretical display update path would be for dumb BOs without shared mappings would be: SET_SCANOUT_BLOB RESOURCE_FLUSH_BLOB --> copies from iovecs to framebuffer That should work with crosvm, you might want to verify if it's doable with QEMU. QEMU seems to have multiple dumb display paths -- qemu_spice_display_update, sdl2_2d_update. One possiblity is to only use dumb blob resources in virtio-gpu kms when shared guest is available rather than refactoring that code, or maybe you have something else in mind? > same goes for dma-buf imports (inside the guest). dma-buf import from another virtio driver is very interesting, but we'll probably need a some import UUID hypercall for that? Maybe a bit too expansive for F_RESOURCE_BLOB at this point. Though TRANSFER_BLOB can be useful. I can see the following use cases: - implementing guest kernel dma-buf mmap and synchronization (begin_cpu_access/end_cpu_access). Currently, it doesn't work but no guest user-space relies on it, so no one has noticed/complained. - emulated coherent memory It sounds like you think TRANSFER_BLOB is worth the maintenance vs. future proofing tradeoff, which is fair. I just want to make sure we're all on the same page in terms of use cases. > > cheers, > Gerd >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]