<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 21, 2017 at 12:36 AM, Daniel Vetter <span dir="ltr"><<a href="mailto:daniel@ffwll.ch" target="_blank">daniel@ffwll.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Dec 21, 2017 at 9:06 AM, James Jones <<a href="mailto:jajones@nvidia.com">jajones@nvidia.com</a>> wrote:<br>
> However, making some assumptions, I suspect it's probably going to come down<br>
> to yes we can fit what we need in some number of bits marginally less than<br>
> 56 now, with the current use cases and hardware, but we're very concerned<br>
> about extensibility given the number has only ever grown in our HW, is<br>
> uncomfortably close to the limit if it isn't over it already, and it's been<br>
> demonstrated it takes a monumental effort to change the mechanism if it<br>
> isn't extensible.  While it's hard to change the mechanism one more time<br>
> now, better to change it to something truly extensible now because it will<br>
> be much, much harder to make such a change ~5 years from now in a world<br>
> where it's baked in to pervasively deployed Wayland and X protocol, the EGL<br>
> and Vulkan extensions have been defined for a few years and in use by apps<br>
> besides Wayland, and the allocator stuff is deployed on ~5 operating systems<br>
> that have some derivative version of DRM modifiers to support it and a bunch<br>
> of funky embedded apps using it.  Further, we're volunteering to handle the<br>
> bulk of the effort needed to make the change now, so I hope architectural<br>
> correctness and maintainability can be the primary points of debate.<br>
<br>
</span>I think that's already happened. So no matter what we do, we're going<br>
to live with an ecosystem that uses modifiers all over the place in 5<br>
years. Even if it's not fully pervasive we will have to keep the<br>
support around for 10 years (at least on the kernel side).<br>
<br>
So the option is between reving the entire ecosystem now, or reving it<br>
in a few years when the current scheme has run out of steam for good.<br>
And I much prefer the 2nd option for the simple reason that by then<br>
the magic 8ball has gained another 5 years of clarity for looking into<br>
the future.<br>
<br>
I think in the interim figuring out how to expose kms capabilities<br>
better (and necessarily standardizing at least some of them which<br>
matter at the compositor level, like size limits of framebuffers)<br>
feels like the place to push the ecosystem forward. </blockquote><div><br></div><div>I agree and let me elaborate a bit. The problem we're seeing isn't that we need more that 2^56 modifiers for a future GPU. The problem is that flags like USE_SCANOUT (which your allocator proposal essentially keeps) is inadequate. The available tiling and compression formats vary with which (in KMS terms) CRTC you want to use, which plane you're on whether you want rotation or no and how much you want to scale etc. It's not realistic to think that we could model this in a centralized allocator library that's detached from the display driver. To be fair, this is not a point about blobs vs modifiers, it's saying that the use flags don't belong in the allocator, they belong in the APIs that will be using the buffer - and not as literal use flags, but as a way to discover supported modifiers for a given use case.</div><div><br></div><div>Kristian</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In some way<br>
Miguel's proposal looks a bit backwards, since it adds the pitch<br>
capabilities to addfb, but at addfb time you've allocated everything<br>
already, so way too late to fix things up. With modifiers we've added<br>
a very simple per-plane property to list which modifiers can be<br>
combined with which pixel formats. Tiny start, but obviously very far<br>
from all that we'll need.<br>
<div class="HOEnZb"><div class="h5">-Daniel<br>
--<br>
Daniel Vetter<br>
Software Engineer, Intel Corporation<br>
<a href="tel:%2B41%20%280%29%2079%20365%2057%2048" value="+41793655748">+41 (0) 79 365 57 48</a> - <a href="http://blog.ffwll.ch" rel="noreferrer" target="_blank">http://blog.ffwll.ch</a><br>
</div></div></blockquote></div><br></div></div>