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

[Kristian Kristensen]

On Thu, Dec 21, 2017 at 12:36 AM, Daniel Vetter <daniel at ffwll.ch> wrote:

> 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.


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.

Kristian


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171221/9279807f/attachment-0001.html>