<div dir="auto">On one hand I think it's a great idea. Moving code out of drivers to common means fixing bugs helps everyone, and implementing new features is the same.<div dir="auto"><br></div><div dir="auto">On the other hand, everyone's already got code that works, which means both a lot of work to switch that code over to common and then the usual cycle of fixing regressions.</div><div dir="auto"><br></div><div dir="auto">Gallium is generally pretty great now, so my gut says a 'Zirkonium' common layer is eventually gonna be pretty good too, assuming it can provide the same sorts of efficiency gains; vulkan is a lot thinner than GL, which means CPU utilization becomes more noticable very easily.</div><div dir="auto"><br></div><div dir="auto">I'm not saying I'll dive in head first tomorrow, but generally speaking I think 10 years from now it'll be a nice thing to have.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Mike</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 19, 2024, 4:02 PM Faith Ekstrand <<a href="mailto:faith@gfxstrand.net">faith@gfxstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yeah, this one's gonna hit Phoronix...<br>
<br>
When we started writing Vulkan drivers back in the day, there was this<br>
notion that Vulkan was a low-level API that directly targets hardware.<br>
Vulkan drivers were these super thin things that just blasted packets<br>
straight into the hardware. What little code was common was small and<br>
pretty easy to just copy+paste around. It was a nice thought...<br>
<br>
What's happened in the intervening 8 years is that Vulkan has grown. A lot.<br>
<br>
We already have several places where we're doing significant layering.<br>
It started with sharing the WSI code and some Python for generating<br>
dispatch tables. Later we added common synchronization code and a few<br>
vkFoo2 wrappers. Then render passes and...<br>
<br>
<a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024</a><br>
<br>
That's been my project the last couple weeks: A common VkPipeline<br>
implementation built on top of an ESO-like interface. The big<br>
deviation this MR makes from prior art is that I make no attempt at<br>
pretending it's a layered implementation. The vtable for shader<br>
objects looks like ESO but takes its own path when it's useful to do<br>
so. For instance, shader creation always consumes NIR and a handful of<br>
lowering passes are run for you. It's no st_glsl_to_nir but it is a<br>
bit opinionated. Also, a few of the bits that are missing from ESO<br>
such as robustness have been added to the interface.<br>
<br>
In my mind, this marks a pretty fundamental shift in how the Vulkan<br>
runtime works, at least in my mind. Previously, everything was<br>
designed to be a toolbox where you can kind of pick and choose what<br>
you want to use. Also, everything at least tried to act like a layer<br>
where you still implemented Vulkan but you could leave out bits like<br>
render passes if you implemented the new thing and were okay with the<br>
layer. With the ESO code, you implement something that isn't Vulkan<br>
entrypoints and the actual entrypoints live in the runtime. This lets<br>
us expand and adjust the interface as needed for our purposes as well<br>
as sanitize certain things even in the modern API.<br>
<br>
The result is that NVK is starting to feel like a gallium driver. 🙃<br>
<br>
So here's the question: do we like this? Do we want to push in this<br>
direction? Should we start making more things work more this way? I'm<br>
not looking for MRs just yet nor do I have more reworks directly<br>
planned. I'm more looking for thoughts and opinions as to how the<br>
various Vulkan driver teams feel about this. We'll leave the detailed<br>
planning for the Mesa issue tracker.<br>
<br>
It's worth noting that, even though I said we've tried to keep things<br>
layerish, there are other parts of the runtime that look like this.<br>
The synchronization code is a good example. The vk_sync interface is<br>
pretty significantly different from the Vulkan objects it's used to<br>
implement. That's worked out pretty well, IMO. With as complicated as<br>
something like pipelines or synchronization are, trying to keep the<br>
illusion of a layer just isn't practical.<br>
<br>
So, do we like this? Should we be pushing more towards drivers being a<br>
backed of the runtime instead of a user of it?<br>
<br>
Now, before anyone asks, no, I don't really want to build a multi-API<br>
abstraction with a Vulkan state tracker. If we were doing this 5 years<br>
ago and Zink didn't already exist, one might be able to make an<br>
argument for pushing in that direction. However, that would add a huge<br>
amount of weight to the project and make it even harder to develop the<br>
runtime than it already is and for little benefit at this point.<br>
<br>
Here's a few other constraints on what I'm thinking:<br>
<br>
1. I want it to still be possible for drivers to implement an<br>
extension without piles of runtime plumbing or even bypass the runtime<br>
on occasion as needed.<br>
<br>
2. I don't want to recreate the gallium cap disaster drivers should<br>
know exactly what they're advertising. We may want to have some<br>
internal features or properties that are used by the runtime to make<br>
decisions but they'll be in addition to the features and properties in<br>
Vulkan.<br>
<br>
3. We've got some meta stuff already but we probably want more.<br>
However, I don't want to force meta on folks who don't want it.<br>
<br>
The big thing here is that if we do this, I'm going to need help. I'm<br>
happy to do a lot of the architectural work but drivers are going to<br>
have to keep up with the changes and I can't take on the burden of<br>
moving 8 different drivers forward. I can answer questions and maybe<br>
help out a bit but the refactoring is going to be too much for one<br>
person, even if that person is me.<br>
<br>
Thoughts?<br>
<br>
~Faith<br>
</blockquote></div>