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

[Rob Clark]

On Thu, Dec 21, 2017 at 3: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.

Drive by comment (and disclaimer, haven't had chance to read rest of
thread yet), but I think there is a reasonable path to increase the
modifier space to something like 2^^568 (minus the cases were
modifiers[0]==modifiers[1]==modifiers[2]==modifiers[3]).. (Yeah, yeah,
 I'm sure there is a 640k should be enough joke here somewhere)

Fortunately currently modifiers array is at end of 'struct
drm_mode_fb_cmd2', so there maybe some other options to extend it as
well.  Possibly reserving the modifier value ~0 now might be a good
idea.

It does seem like, if possible, starting out with modifiers for now at
the kernel interface would make life easier, vs trying to reinvent
both kernel and userspace APIs at the same time.  Userspace APIs are
easier to change or throw away.  Presumably by the time we get to the
point of changing kernel uabi, we are already using, and pretty happy
with, serialized liballoc data over the wire in userspace so it is
only a matter of changing the kernel interface.

The downside of this is needing a per-driver userspace bit to map
liballoc to modifiers.  We kinda have this already in mesa, even for
the modesetting-only drivers that can be paired with a render-only
driver.

BR,
-R

> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev