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@xxxxxxxxxx> wrote: > >> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <mvicomoya@xxxxxxxxxx> wrote: > >>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <hoegsberg@xxxxxxxxx> 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@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
