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


> 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.

> 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

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, same goes for dma-buf imports
(inside the guest).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]