[RFC] drm: add support for tiled/compressed/etc modifier in addfb2

Daniel Stone daniel at fooishbar.org
Fri Dec 12 03:27:48 PST 2014


Hey,

On 10 December 2014 at 17:17, Rob Clark <robdclark at gmail.com> wrote:
>
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats.  Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specific
> gem-create ioctl to pass around these extra flags.
>
> The proposal is to add a per-plane format modifier.  This allows to, if
> necessary, use different tiling patters for sub-sampled planes, etc.
> The format modifiers are added at the end of the ioctl struct, so for
> legacy userspace it will be zero padded.
>

Cool, thanks a lot for looking at this! My one comment is that we could
maybe go even further: keep the current modifier as a strict pixel-layout
modifier (e.g. tiled, compressed - anything that affects how you actually
determine pixel location), and then support an extra (perhaps
non-vendor-namespaced) argument for optional pixel _interpretation_
modifiers, e.g. the hints in EGL_EXT_image_dma_buf_import. V4L2 is starting
to properly attack things like chroma siting, and being able to specify
narrow/wide YUV range is pretty important for STB/DTV in particular. And
they're actually starting to move to KMS, too ...

It might be useful to make the interpretation modifiers bitmaskable, so
they can be combined (e.g. wide-range/unclamped YUV | whatever chroma
siting), but I can't think of a usecase for combining multiple layout
modifiers (e.g. this tiling | that compression).


> TODO how best to deal with assignment of modifier token values?  The
> rough idea was to namespace things with an 8bit vendor-id, and then
> beyond that it is treated as an opaque value.  But that was a relatively
> arbitrary choice.  There are cases where same tiling pattern and/or
> compression is supported by various different vendors.  So we should
> standardize to use the vendor-id and value of the first one who
> documents the format?


Yeah, I'd second all of danvet's comments here, as well as adding a new
ADDFB2_MODIFIERS cap + query for supported modifiers. Makes life much
easier for generic userspace.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/f28f729d/attachment-0001.html>


More information about the dri-devel mailing list