<div dir="ltr">Hey,<div class="gmail_extra"><br><div class="gmail_quote">On 10 December 2014 at 17:17, Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In DRM/KMS we are lacking a good way to deal with tiled/compressed<br>
formats.  Especially in the case of dmabuf/prime buffer sharing, where<br>
we cannot always rely on under-the-hood flags passed to driver specific<br>
gem-create ioctl to pass around these extra flags.<br>
<br>
The proposal is to add a per-plane format modifier.  This allows to, if<br>
necessary, use different tiling patters for sub-sampled planes, etc.<br>
The format modifiers are added at the end of the ioctl struct, so for<br>
legacy userspace it will be zero padded.<br></blockquote><div><br></div><div>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 ...</div><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
TODO how best to deal with assignment of modifier token values?  The<br>
rough idea was to namespace things with an 8bit vendor-id, and then<br>
beyond that it is treated as an opaque value.  But that was a relatively<br>
arbitrary choice.  There are cases where same tiling pattern and/or<br>
compression is supported by various different vendors.  So we should<br>
standardize to use the vendor-id and value of the first one who<br>
documents the format?</blockquote><div><br></div><div>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.</div><div> <br></div><div>Cheers,</div><div>Daniel</div></div></div></div>