On Thu, May 14, 2020 at 1:24 AM Gerd Hoffmann <> 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
>
