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

[Daniel Vetter]

On Tue, Feb 20, 2018 at 10:14:47PM -0800, Chad Versace wrote:
> On Thu 21 Dec 2017, Daniel Vetter wrote:
> > On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <hoegsberg at google.com> wrote:
> >> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <mvicomoya at nvidia.com> wrote:
> >>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> >>>> I'd like to see concrete examples of actual display controllers
> >>>> supporting more format layouts than what can be specified with a 64
> >>>> bit modifier.
> >>>
> >>> The main problem is our tiling and other metadata parameters can't
> >>> generally fit in a modifier, so we find passing a blob of metadata a
> >>> more suitable mechanism.
> >>
> >> I understand that you may have n knobs with a total of more than a total of
> >> 56 bits that configure your tiling/swizzling for color buffers. What I don't
> >> buy is that you need all those combinations when passing buffers around
> >> between codecs, cameras and display controllers. Even if you're sharing
> >> between the same 3D drivers in different processes, I expect just locking
> >> down, say, 64 different combinations (you can add more over time) and
> >> assigning each a modifier would be sufficient. I doubt you'd extract
> >> meaningful performance gains from going all the way to a blob.
> 
> I agree with Kristian above. In my opinion, choosing to encode in
> modifiers a precise description of every possible tiling/compression
> layout is not technically incorrect, but I believe it misses the point.
> The intention behind modifiers is not to exhaustively describe all
> possibilites.
> 
> I summarized this opinion in VK_EXT_image_drm_format_modifier,
> where I wrote an "introdution to modifiers" section. Here's an excerpt:
> 
>     One goal of modifiers in the Linux ecosystem is to enumerate for each
>     vendor a reasonably sized set of tiling formats that are appropriate for
>     images shared across processes, APIs, and/or devices, where each
>     participating component may possibly be from different vendors.
>     A non-goal is to enumerate all tiling formats supported by all vendors.
>     Some tiling formats used internally by vendors are inappropriate for
>     sharing; no modifiers should be assigned to such tiling formats.

fwiw (since the source of truth wrt modifiers is the kernel's uapi
header):

Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>

I'm happy to merge modifier #define additions for pretty much anything
where there's a need for sharing across devices/drivers/apis, explicitly
including stuff that's only relevant for userspace and which the kernel
nevers sees (in e.g. a kms addfb2 call). Trying to preemptively enumerate
everything that's possible doesn't seem like a wise idea. But even then we
can probably spare the oddball vendor prefix is a driver team really
insists that this is what they want, best using some code that makes the
case for them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch