The urge to write a gallium-like layer for Vulkan intensifies...

[gfxstrand@social.treehouse.systems]

The urge to write a gallium-like layer for Vulkan intensifies...

[gfxstrand@social.treehouse.systems]

A bit more on this...

One of the problems I keep running into when trying to do common Vulkan stuff in Mesa is that all the common code is optional. About the only thing that isn't optional is the dispatch layer that handles Get*ProcAddress(). This means that, while I can implement something in the common layer, if a driver isn't using that component for some reason, they don't get the benefit.

The second issue is a layering problem. While the dispatch tables allow common code to call back into the driver, the common code is first and foremost a client of the driver, not the other way around. This means that I can't just add a bit of code and then start flipping on features like you can in gallium. Even if I do add it to common code, all the feature bits and all the format bits are all handled by the drivers.

Also, there's no truly common compiler code so if something requires both API side stuff and compiler stuff, there's no way to do the compiler stuff in common and mandate it. And even if we did, since all the API-side stuff is optional, there's a chance a driver will get the compiler half but not the API half.

[gfxstrand@social.treehouse.systems]

This came up this last week as I was hooking up 64-bit vertex attributes for NVK and looking at how it's handled in RADV today.

This is a feature that should be trivial to implement entirely in common code. On the compiler side, you bitcast double to uvec2 and dvec2 to uvec4. For dvec3 and dvec4, you split them into a uvec4 and a uvec2 or another uvec4, respectively. NIR already has all the code to do this.

Then, on the API side, we could just translate between the Vulkan descriptions of vertex attributes to one that's similarly split. So we'd replace VK_FORMAT_R64_UINT with VK_FORMAT_R32G32_UINT, etc. In the 384 and 512-bit cases, we'd provide two vertex attributes, with the correct respective formats and the top half offset by 16B. This is easy to do in Vulkan because dvec3/4 attributes are already required to consume 2 locations so we don't even have to renumber them.

[gfxstrand@social.treehouse.systems]

And I could do this. I could do it today. It'd take me an hour or so to type up. The problem is that not everyone uses the common state tracking code and so I can't actually ensure they get the translation. I can provide it but I'd have to hide it behind an enable bit, which only gets set by drivers that use all the necessary common pieces and want the features.

[gfxstrand@social.treehouse.systems]

But it's not really ideal.

In an ideal world, I'd be able to tweak the compiler bits, add the API translation, and then flip the feature on across the entire Mesa stack. Boom! 64-bit vertex attributes for everyone!

[karolherbst@chaos.social]

@gfxstrand the good thing about gallium: you can do common code changes and boom it works

the bad thing about gallium: you have to do common code changes and boom it breaks every driver.