<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 12 December 2014 at 15:30, 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 03:11:02PM +0000, Daniel Stone wrote:<br>> On 12 December 2014 at 14:56, Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>><br>
> wrote:<br>> Having them separated is still kinda nice though, for the same rationale as<br>
> the EGLImage import extension having them as hints. If your hardware<br>
> doesn't support the tiling/compression format you use, then you're going to<br>
> be showing absolute garbage. But if it doesn't support your exact<br>
> chroma-siting or YUV range request, it'll still be totally viewable, just<br>
> not entirely perfect. So I don't see the logic in failing these.<br>
<br>
</div></div>Well, it will look nasty when switching between GL and display<br>
composition the GL path does the right thing an display path doesn't/<br>
And we already have that problem with the fuzzy alignment/scaling<br>
restriction stuff. So I think we will want some kind of strict flag<br>
somewhere to allow the user to specify that they'd rather fail the whole<br>
thing and fall back to GL rather than annoy the user.<br></blockquote><div><br></div><div>If you're doing it through GL, you've already lost. Either you're doing some magic behind the user's back to bind multi-planar dmabuf-EGLImages to TEXTURE_2D with RGB sampling, or you're binding to TEXTURE_EXTERNAL_OES, which forces you to use linear/nearest filtering. Even if you do use TEXTURE_2D binding, the EGLImage import spec does exactly the same as what's suggested here, and treats them as hints, which the implementation can use or ignore. So far I don't know of any implementation which doesn't ignore them.</div><div><br></div><div>FWIW, i965 completely disallows multi-planar EGLImage imports in the first place. Mali as shipped on ChromeOS forces you to use TEXTURE_EXTERNAL_OES. Soooo ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But for some simpler cases like Xv it would seem perfectly OK to use the<br>
less strict rules. Well, unless someone implements Xv in a way that can<br>
also transparently switch between display planes and GL/software rendering.</blockquote><div><br></div><div>Well sure, if you absolutely want to ensure it works, you're going to need some kind of query. Maybe, if the range/chroma-siting ones were part of a bitmask, you could steal the top bit to mark that the hints are actually requirements, and to fail if you can't respect the hints.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">> Well, you don't have to solve literally everything at once. Just having a<br>
> list of formats which could possibly be supported if you did the right<br>
> thing, would be a hell of a lot better than punting to userspace, which<br>
> either a) has to have hardware-specific knowledge in every component<br>
> (compositor, media library, etc etc), or b) brute-force it. The lack of any<br>
> format query in EGLImage dmabuf import is a serious, serious, serious, pain<br>
> when trying to do generic userspace (e.g. compositor feeds GStreamer a list<br>
> of formats which are supported by the hardware). I get that there are<br>
> combinations that could fail, but that's true of everything. At least<br>
> narrowing down the problem space a bit is an enormous help.<br>
<br>
</div></div>We alredy have a list of supported formats. The problem is when specific<br>
formats impose additonal constraints (eg. more restricted scaling factor<br>
limits).</blockquote><div><br></div><div>Where's the list of supported formats in this proposal? It just adds a modifier: there's no way to determine which modifiers are supported by a specific plane, which is what I really need to know. Right now, the only way is just brute-forcing your way through every single combination until you find one which succeeds.</div><div><br></div><div>Like I said, I completely get that there are going to be specific/weird/arbitrary restrictions. There already are, such as scaling factors, maximum one non-primary plane per scanline, global bandwidth limits, etc etc. Those are not something KMS has ever attempted to solve, and I'm not suggesting that the modifier mechanism attempts to solve them.</div><div><br></div><div>Cheers,</div><div>Daniel </div></div></div></div>