[Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Daniel Vetter]

On Thu, Dec 21, 2017 at 9:06 AM, James Jones <jajones at nvidia.com> wrote:
> However, making some assumptions, I suspect it's probably going to come down
> to yes we can fit what we need in some number of bits marginally less than
> 56 now, with the current use cases and hardware, but we're very concerned
> about extensibility given the number has only ever grown in our HW, is
> uncomfortably close to the limit if it isn't over it already, and it's been
> demonstrated it takes a monumental effort to change the mechanism if it
> isn't extensible.  While it's hard to change the mechanism one more time
> now, better to change it to something truly extensible now because it will
> be much, much harder to make such a change ~5 years from now in a world
> where it's baked in to pervasively deployed Wayland and X protocol, the EGL
> and Vulkan extensions have been defined for a few years and in use by apps
> besides Wayland, and the allocator stuff is deployed on ~5 operating systems
> that have some derivative version of DRM modifiers to support it and a bunch
> of funky embedded apps using it.  Further, we're volunteering to handle the
> bulk of the effort needed to make the change now, so I hope architectural
> correctness and maintainability can be the primary points of debate.

I think that's already happened. So no matter what we do, we're going
to live with an ecosystem that uses modifiers all over the place in 5
years. Even if it's not fully pervasive we will have to keep the
support around for 10 years (at least on the kernel side).

So the option is between reving the entire ecosystem now, or reving it
in a few years when the current scheme has run out of steam for good.
And I much prefer the 2nd option for the simple reason that by then
the magic 8ball has gained another 5 years of clarity for looking into
the future.

I think in the interim figuring out how to expose kms capabilities
better (and necessarily standardizing at least some of them which
matter at the compositor level, like size limits of framebuffers)
feels like the place to push the ecosystem forward. In some way
Miguel's proposal looks a bit backwards, since it adds the pitch
capabilities to addfb, but at addfb time you've allocated everything
already, so way too late to fix things up. With modifiers we've added
a very simple per-plane property to list which modifiers can be
combined with which pixel formats. Tiny start, but obviously very far
from all that we'll need.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch