On Wed 21 Feb 2018, Daniel Vetter wrote: > 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> Linux would eventually encounter big problems if the kernel and Vulkan disagreed on the fundamental, unspoken Theory of Modifiers. So your acked-by is definitely worth something here. Thanks for confirming. > > 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. Yep. I believe Jason Ekstrand has tentative plans for such a modifier that improves performance for interop in GL and Vulkan but the kernel and Intel display hw wouldn't understand: a modifier for CCS_E images that are fully compressed. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
