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@google.com wrote:
On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico mvicomoya@nvidia.com wrote:
On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg hoegsberg@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@ffwll.ch
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.