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


  Hi,

> > So add a note that this is for future planar format support?
> > Or do we want add planar formats now?
> 
> No YUV support for now.  I was mostly thinking about compressed
> standard formats (AB24, AR24) with a header + data plane
> (I915_FORMAT_MOD_Y_TILED_CCS etc.).  The modifier can be queried from
> virglrenderer in the distant future to avoid modifiers in the guest
> (which is another can of worms).  Will write a note about that.

Ok, good.

> > Also: should resource_id an array too?  So we have the option to store
> > each plane in a different resource (simliar to drm_framebuffer in the
> > linux kernel)?
> 
> It's a cost vs. level of future-proofing tradeoff.
> 
> Pros:
> + To mirror the KMS/wayland APIs, a resource_id array +
> VIRTIO_GPU_CMD_SET_SCANOUT_BLOBS makes sense.
> Cons
> - The trend seems to be one buffer.  I've only encountered disjoint
> YUV images on deprecated platforms, and reviewing the modifiers in
> <drm_fourcc.h> seem to be one buffer too.

Ok.  I guess it makes sense to stick to one buffer then.  An API which
isn't used in practice is a maintenance burden we better avoid ...

take care,
  Gerd



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