OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[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
> 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:

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:

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]