<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 12 December 2014 at 14:56, Ville Syrjälä <span dir="ltr"><<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Fri, Dec 12, 2014 at 08:50:18AM -0500, Rob Clark wrote:<span style="color:rgb(34,34,34)"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><span style="color:rgb(34,34,34)">> It does make me briefly think of just letting us set properties on fb</span><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> objects :-P (but maybe that is a bit overkill)<br>
<br>
</span>Yeah I had the same idea at some point. But then I decided that we could<br>
just have these as properties on the plane.</blockquote><div><br></div><div>Mm, it does seem a bit weird. Yes, they are relative to how the plane interprets things, but then again so is the format surely. Not to mention another thing to go wrong, if someone forgets to set and/or clear it when changing the plane. Keeping it in the fb eliminates that possibility.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> I suppose the semi-custom plane property approach is a bit easier to<br>
> extend-as-we-go, and we already have a mechanism so userspace can<br>
> query about what is actually supported.  But this does feel a bit more<br>
> like attributes of the fb.  I'm interested if anyone has particularly<br>
> good arguments one way or another.<br>
<br>
</span>I guess we could have just specified offset/size/stride as part of the<br>
fb and let pixel format and such as properties. That would be a fairly<br>
natural line IMO since it would be enough data to do a blit, but not<br>
enough to actually interpret the pixel data. But we already went beyond<br>
that with pixel formats. So I'm not sure how far we want to go.<br>
<br>
Also all this chroma siting and colorspace stuff definitely runs into<br>
hardware specific limitations so having some way to tell userspace what<br>
is possible would be nice as you said. Properties seem a decent match for<br>
that.</blockquote><div><br></div><div>Yeah, that's a good idea actually, especially since different planes do have different capabilities.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">
> > It might be useful to make the interpretation modifiers bitmaskable, so they<br>
> > can be combined (e.g. wide-range/unclamped YUV | whatever chroma siting),<br>
> > but I can't think of a usecase for combining multiple layout modifiers (e.g.<br>
> > this tiling | that compression).<br>><br>
> Yeah, I think the vendor-range part of the token, the vendor would<br>
> probably want to define as a bitmask or set of bitfields so that they<br>
> could have things like tiled+compressed<br>
><br>
> (otoh, if you try to organize it too nicely now, eventually enough hw<br>
> generations in the future that scheme will break down.. so maybe a big<br>
> switch of #define cases is better than trying to interpret the<br>
> modifier token)<br></div></div></blockquote><div><br></div><div>Having them separated is still kinda nice though, for the same rationale as the EGLImage import extension having them as hints. If your hardware doesn't support the tiling/compression format you use, then you're going to be showing absolute garbage. But if it doesn't support your exact chroma-siting or YUV range request, it'll still be totally viewable, just not entirely perfect. So I don't see the logic in failing these.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">> >> 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?<br>
> ><br>
> ><br>
> > Yeah, I'd second all of danvet's comments here, as well as adding a new<br>
> > ADDFB2_MODIFIERS cap + query for supported modifiers. Makes life much easier<br>
> > for generic userspace.<br>
><br>
> I've locally made a few tweaks (64b and move some stuff to drm_fourcc.h)..<br>
><br>
> I was kicking around the idea of letting plane specify an array of<br>
> supported format modifiers, and adding this to getplane ioctl, as an<br>
> alternative to a cap.  That plus wiring up some checking to disallow<br>
> addfb2 for a format + modifiers not supported by at least one plane.<br>
> Although some hw could only support certain tiling patterns for<br>
> certain layers of an fb (ie. luma vs chroma).  So I may scrap that<br>
> idea and just go back to cap.<br>
<br>
</div></div>Indeed the format specific limitations are problem. Properties can't<br>
handle that. We'd need to have some kind of caps for each plane+format<br>
combination if we want to deal with that. But I don't think we can<br>
still make it handle all the hw limitations, so I'm not sure it's worth<br>
going down this path.</blockquote><div><br></div><div>Well, you don't have to solve literally everything at once. Just having a list of formats which could possibly be supported if you did the right thing, would be a hell of a lot better than punting to userspace, which either a) has to have hardware-specific knowledge in every component (compositor, media library, etc etc), or b) brute-force it. The lack of any format query in EGLImage dmabuf import is a serious, serious, serious, pain when trying to do generic userspace (e.g. compositor feeds GStreamer a list of formats which are supported by the hardware). I get that there are combinations that could fail, but that's true of everything. At least narrowing down the problem space a bit is an enormous help.</div><div><br></div><div>Cheers,</div><div>Daniel </div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 December 2014 at 14:56, Ville Syrjälä <span dir="ltr"><<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Dec 12, 2014 at 08:50:18AM -0500, Rob Clark wrote:<br>
> On Fri, Dec 12, 2014 at 6:27 AM, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
> > Hey,<br>
> ><br>
> > On 10 December 2014 at 17:17, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>
> >><br>
> >> 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>
> ><br>
> ><br>
> > Cool, thanks a lot for looking at this! My one comment is that we could<br>
> > maybe go even further: keep the current modifier as a strict pixel-layout<br>
> > modifier (e.g. tiled, compressed - anything that affects how you actually<br>
> > determine pixel location), and then support an extra (perhaps<br>
> > non-vendor-namespaced) argument for optional pixel _interpretation_<br>
> > modifiers, e.g. the hints in EGL_EXT_image_dma_buf_import. V4L2 is starting<br>
> > to properly attack things like chroma siting, and being able to specify<br>
> > narrow/wide YUV range is pretty important for STB/DTV in particular. And<br>
> > they're actually starting to move to KMS, too ...<br>
><br>
> Up until now I had sort of thought of things like YUV range as plane<br>
> properties which could be updated (potentially on flip as part of<br>
> atomic ioctl).  But they are also additional metadata about how to<br>
> properly interpret the pixel data contained in the buffer.<br>
><br>
> I guess chroma siting and YUV range would at least be one value that<br>
> applies across all the bos/planes of the fb, rather than per plane?<br>
<br>
</div></div>There is the DV case where the chroma is sampled at different points for<br>
Cb and Cr. So we could in theory specify chroma siting per-plane. But it<br>
seems to me that it'd be enough to have it for the entire fb. I had some<br>
ideas posted years ago. Here's [1] one at least.<br>
<br>
[1] <a href="http://lists.freedesktop.org/archives/dri-devel/2011-November/016379.html" target="_blank">http://lists.freedesktop.org/archives/dri-devel/2011-November/016379.html</a><br>
<span class=""><br>
><br>
> It does make me briefly think of just letting us set properties on fb<br>
> objects :-P (but maybe that is a bit overkill)<br>
<br>
</span>Yeah I had the same idea at some point. But then I decided that we could<br>
just have these as properties on the plane.<br>
<span class=""><br>
><br>
> I suppose the semi-custom plane property approach is a bit easier to<br>
> extend-as-we-go, and we already have a mechanism so userspace can<br>
> query about what is actually supported.  But this does feel a bit more<br>
> like attributes of the fb.  I'm interested if anyone has particularly<br>
> good arguments one way or another.<br>
<br>
</span>I guess we could have just specified offset/size/stride as part of the<br>
fb and let pixel format and such as properties. That would be a fairly<br>
natural line IMO since it would be enough data to do a blit, but not<br>
enough to actually interpret the pixel data. But we already went beyond<br>
that with pixel formats. So I'm not sure how far we want to go.<br>
<br>
Also all this chroma siting and colorspace stuff definitely runs into<br>
hardware specific limitations so having some way to tell userspace what<br>
is possible would be nice as you said. Properties seem a decent match for<br>
that.<br>
<div><div class="h5"><br>
><br>
> > It might be useful to make the interpretation modifiers bitmaskable, so they<br>
> > can be combined (e.g. wide-range/unclamped YUV | whatever chroma siting),<br>
> > but I can't think of a usecase for combining multiple layout modifiers (e.g.<br>
> > this tiling | that compression).<br>
> ><br>
><br>
> Yeah, I think the vendor-range part of the token, the vendor would<br>
> probably want to define as a bitmask or set of bitfields so that they<br>
> could have things like tiled+compressed<br>
><br>
> (otoh, if you try to organize it too nicely now, eventually enough hw<br>
> generations in the future that scheme will break down.. so maybe a big<br>
> switch of #define cases is better than trying to interpret the<br>
> modifier token)<br>
><br>
> >><br>
> >> 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?<br>
> ><br>
> ><br>
> > Yeah, I'd second all of danvet's comments here, as well as adding a new<br>
> > ADDFB2_MODIFIERS cap + query for supported modifiers. Makes life much easier<br>
> > for generic userspace.<br>
><br>
> I've locally made a few tweaks (64b and move some stuff to drm_fourcc.h)..<br>
><br>
> I was kicking around the idea of letting plane specify an array of<br>
> supported format modifiers, and adding this to getplane ioctl, as an<br>
> alternative to a cap.  That plus wiring up some checking to disallow<br>
> addfb2 for a format + modifiers not supported by at least one plane.<br>
> Although some hw could only support certain tiling patterns for<br>
> certain layers of an fb (ie. luma vs chroma).  So I may scrap that<br>
> idea and just go back to cap.<br>
<br>
</div></div>Indeed the format specific limitations are problem. Properties can't<br>
handle that. We'd need to have some kind of caps for each plane+format<br>
combination if we want to deal with that. But I don't think we can<br>
still make it handle all the hw limitations, so I'm not sure it's worth<br>
going down this path.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Ville Syrjälä<br>
Intel OTC<br>
</font></span></blockquote></div></div>