Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
Yeah, this one's gonna hit Phoronix... When we started writing Vulkan drivers back in the day, there was this notion that Vulkan was a low-level API that directly targets hardware. Vulkan drivers were these super thin things that just blasted packets straight into the hardware. What little code was common was small and pretty easy to just copy+paste around. It was a nice thought... What's happened in the intervening 8 years is that Vulkan has grown. A lot. We already have several places where we're doing significant layering. It started with sharing the WSI code and some Python for generating dispatch tables. Later we added common synchronization code and a few vkFoo2 wrappers. Then render passes and... https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024 That's been my project the last couple weeks: A common VkPipeline implementation built on top of an ESO-like interface. The big deviation this MR makes from prior art is that I make no attempt at pretending it's a layered implementation. The vtable for shader objects looks like ESO but takes its own path when it's useful to do so. For instance, shader creation always consumes NIR and a handful of lowering passes are run for you. It's no st_glsl_to_nir but it is a bit opinionated. Also, a few of the bits that are missing from ESO such as robustness have been added to the interface. In my mind, this marks a pretty fundamental shift in how the Vulkan runtime works, at least in my mind. Previously, everything was designed to be a toolbox where you can kind of pick and choose what you want to use. Also, everything at least tried to act like a layer where you still implemented Vulkan but you could leave out bits like render passes if you implemented the new thing and were okay with the layer. With the ESO code, you implement something that isn't Vulkan entrypoints and the actual entrypoints live in the runtime. This lets us expand and adjust the interface as needed for our purposes as well as sanitize certain things even in the modern API. The result is that NVK is starting to feel like a gallium driver. 🙃 So here's the question: do we like this? Do we want to push in this direction? Should we start making more things work more this way? I'm not looking for MRs just yet nor do I have more reworks directly planned. I'm more looking for thoughts and opinions as to how the various Vulkan driver teams feel about this. We'll leave the detailed planning for the Mesa issue tracker. It's worth noting that, even though I said we've tried to keep things layerish, there are other parts of the runtime that look like this. The synchronization code is a good example. The vk_sync interface is pretty significantly different from the Vulkan objects it's used to implement. That's worked out pretty well, IMO. With as complicated as something like pipelines or synchronization are, trying to keep the illusion of a layer just isn't practical. So, do we like this? Should we be pushing more towards drivers being a backed of the runtime instead of a user of it? Now, before anyone asks, no, I don't really want to build a multi-API abstraction with a Vulkan state tracker. If we were doing this 5 years ago and Zink didn't already exist, one might be able to make an argument for pushing in that direction. However, that would add a huge amount of weight to the project and make it even harder to develop the runtime than it already is and for little benefit at this point. Here's a few other constraints on what I'm thinking: 1. I want it to still be possible for drivers to implement an extension without piles of runtime plumbing or even bypass the runtime on occasion as needed. 2. I don't want to recreate the gallium cap disaster drivers should know exactly what they're advertising. We may want to have some internal features or properties that are used by the runtime to make decisions but they'll be in addition to the features and properties in Vulkan. 3. We've got some meta stuff already but we probably want more. However, I don't want to force meta on folks who don't want it. The big thing here is that if we do this, I'm going to need help. I'm happy to do a lot of the architectural work but drivers are going to have to keep up with the changes and I can't take on the burden of moving 8 different drivers forward. I can answer questions and maybe help out a bit but the refactoring is going to be too much for one person, even if that person is me. Thoughts? ~Faith
Re: Mesa >= 23.3.x and python 2.6 ...
On Thu, Jan 18, 2024 at 10:22 AM Stefan Dirsch wrote: > I noticed that with version 23.3.x Mesa no longer can be built with python > 2.6. It still worked with Mesa 23.2.1. For anyone who got this far and was completely incredulous... this (and the subject) is typo'd -- the problem is about Python 3.6, not 2.6.
Re: Mesa >= 23.3.x and python 2.6 ...
On Fri, Jan 19, 2024 at 12:35:58PM -0500, Matt Turner wrote: > On Thu, Jan 18, 2024 at 10:22 AM Stefan Dirsch wrote: > > I noticed that with version 23.3.x Mesa no longer can be built with python > > 2.6. It still worked with Mesa 23.2.1. > > For anyone who got this far and was completely incredulous... this > (and the subject) is typo'd -- the problem is about Python 3.6, not > 2.6. I'm pretty sure you were the first and only one. :-( I've corrected it in the body by doing a reply to my own message, but how do I correct a typo in the subject ... I'll try to send the message again with also the correct subject. Then I'll be blamed for bringing up the same topic twice and spamming the list. Sigh. Thanks for having a look at the message nevertheless! Thanks, Stefan Public Key available -- Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.deGermany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Re: Mesa >= 23.3.x and python 2.6 ...
On 2024-01-18 04:37:52, Stefan Dirsch wrote:
> Hi
>
> I noticed that with version 23.3.x Mesa no longer can be built with python
> 2.6. It still worked with Mesa 23.2.1.
As mentioned in other emails, this was typo where 3.6 was intended.
>
> It fails with
>
> [ 95s] Traceback (most recent call last):
> [ 95s] File "../src/intel/genxml/gen_bits_header.py", line 23, in
> [ 95s] import intel_genxml
> [ 95s] File
> "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_
> genxml.py", line 5
> [ 95s] from __future__ import annotations
> [ 95s] ^
> [ 95s] SyntaxError: future feature annotations is not defined
>
I guess this code first appeared in Dylan's:
4fd2e15855d ("intel/genxml: add type annotations to gen_sort_tags.py")
and then became part of the standard tests a few commits later in:
1f0a0a46d97 ("meson: run genxml sort tests")
back in Oct 2022. So, I guess at that point 'ninja test' would have
failed with Python 3.6.
Then, I suppose I propagated this to being used on every build in:
0495f952d48 ("intel/genxml: Add genxml_import.py script")
in Sept 2023.
Maybe Dylan knows how we might make this compatible with Python 3.6,
assuming we want to. :)
https://devguide.python.org/versions/
-Jordan
Re: Mesa >= 23.3.x no longer supporting python 3.6 ...
On Thu, Jan 18, 2024 at 01:37:52PM +0100, Stefan Dirsch wrote: > Hi > > I noticed that with version 23.3.x Mesa no longer can be built with python > 2.6. It still worked with Mesa 23.2.1. Of course I've meant python 3.6. Sorry for the confusion! > It fails with > > [ 95s] Traceback (most recent call last): > [ 95s] File "../src/intel/genxml/gen_bits_header.py", line 23, in > [ 95s] import intel_genxml > [ 95s] File > "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_ > genxml.py", line 5 > [ 95s] from __future__ import annotations > [ 95s] ^ > [ 95s] SyntaxError: future feature annotations is not defined > > When removing __future__ line like this > > --- mesa-23.3.3/src/intel/genxml/intel_genxml.py.orig 2024-01-12 > 10:26:26.314070540 +0100 > +++ mesa-23.3.3/src/intel/genxml/intel_genxml.py2024-01-12 > 10:26:38.682317490 +0100 > @@ -2,7 +2,6 @@ > # Copyright © 2019, 2022 Intel Corporation > # SPDX-License-Identifier: MIT > > -from __future__ import annotations > from collections import OrderedDict > import copy > import io > > this results in the following failure. > > [ 113s] Traceback (most recent call last): > [ 113s] File "../src/intel/genxml/gen_bits_header.py", line 23, in > [ 113s] import intel_genxml > [ 113s] File > "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_ > genxml.py", line 51, in > [ 113s] def add_struct_refs(items: typing.OrderedDict[str, bool], node: > et. > Element) -> None: > [ 113s] AttributeError: module 'typing' has no attribute 'OrderedDict' > > I'm wondering if Mesa developers are interested in still supporting python > 3.6? > > Unfortunately currently it's not an option for SUSE's enterprise product to > update to a newer python (would be probably 3.12) (due to many customers still > relying on python 3.6 and we lack the ressources of adding and maintaining a > (full!) second python development stack). :-( > > If the answer to the question above is a no. :-( How hard would it be to > adjust the code to python 3.6? Any suggestions to how it could be done? Or is > there any other workaround available? > > I had a quick look between 23.2.1 and 23.3.3 and I've seen that > > from __future__ import annotations > > and > > typing.OrderedDict > > have already been used in 23.2.1 (although it was in gen_sort_tags.py and > now has been moved to new intel_genxml.py). So not sure why this fails now > or was working before ... > > Any help here would be appreciated. SUSE is definitely interested in shipping > the latest Mesa with our latest enterprise product. Thanks, Stefan Public Key available -- Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.deGermany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Re: Mesa >= 23.3.x and python 2.6 ...
Hi Jordan
Thanks for digging into this!
On Fri, Jan 19, 2024 at 12:10:37PM -0800, Jordan Justen wrote:
> On 2024-01-18 04:37:52, Stefan Dirsch wrote:
> > Hi
> >
> > I noticed that with version 23.3.x Mesa no longer can be built with python
> > 2.6. It still worked with Mesa 23.2.1.
>
> As mentioned in other emails, this was typo where 3.6 was intended.
>
> >
> > It fails with
> >
> > [ 95s] Traceback (most recent call last):
> > [ 95s] File "../src/intel/genxml/gen_bits_header.py", line 23, in
> >
> > [ 95s] import intel_genxml
> > [ 95s] File
> > "/home/abuild/rpmbuild/BUILD/mesa-23.3.3/src/intel/genxml/intel_
> > genxml.py", line 5
> > [ 95s] from __future__ import annotations
> > [ 95s] ^
> > [ 95s] SyntaxError: future feature annotations is not defined
> >
>
> I guess this code first appeared in Dylan's:
>
> 4fd2e15855d ("intel/genxml: add type annotations to gen_sort_tags.py")
>
> and then became part of the standard tests a few commits later in:
>
> 1f0a0a46d97 ("meson: run genxml sort tests")
>
> back in Oct 2022. So, I guess at that point 'ninja test' would have
> failed with Python 3.6.
>
> Then, I suppose I propagated this to being used on every build in:
>
> 0495f952d48 ("intel/genxml: Add genxml_import.py script")
>
> in Sept 2023.
Thanks. This explains why I've found this code already in older releases, but
it didn't fail for me yet. You said tests. Is this just a test, I could
disable (as dirty hack)? I was assuming it would generate code ...
> Maybe Dylan knows how we might make this compatible with Python 3.6,
> assuming we want to. :)
>
> https://devguide.python.org/versions/
Yes, I know. It's EOL since a long time now ... sigh
Thanks,
Stefan
Public Key available
--
Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH
Tel: 0911-740 53 0Frankenstraße 146
FAX: 0911-740 53 479 D-90461 Nürnberg
http://www.suse.deGermany
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)
Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
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. 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. 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. 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. Mike On Fri, Jan 19, 2024, 4:02 PM Faith Ekstrand wrote: > Yeah, this one's gonna hit Phoronix... > > When we started writing Vulkan drivers back in the day, there was this > notion that Vulkan was a low-level API that directly targets hardware. > Vulkan drivers were these super thin things that just blasted packets > straight into the hardware. What little code was common was small and > pretty easy to just copy+paste around. It was a nice thought... > > What's happened in the intervening 8 years is that Vulkan has grown. A lot. > > We already have several places where we're doing significant layering. > It started with sharing the WSI code and some Python for generating > dispatch tables. Later we added common synchronization code and a few > vkFoo2 wrappers. Then render passes and... > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024 > > That's been my project the last couple weeks: A common VkPipeline > implementation built on top of an ESO-like interface. The big > deviation this MR makes from prior art is that I make no attempt at > pretending it's a layered implementation. The vtable for shader > objects looks like ESO but takes its own path when it's useful to do > so. For instance, shader creation always consumes NIR and a handful of > lowering passes are run for you. It's no st_glsl_to_nir but it is a > bit opinionated. Also, a few of the bits that are missing from ESO > such as robustness have been added to the interface. > > In my mind, this marks a pretty fundamental shift in how the Vulkan > runtime works, at least in my mind. Previously, everything was > designed to be a toolbox where you can kind of pick and choose what > you want to use. Also, everything at least tried to act like a layer > where you still implemented Vulkan but you could leave out bits like > render passes if you implemented the new thing and were okay with the > layer. With the ESO code, you implement something that isn't Vulkan > entrypoints and the actual entrypoints live in the runtime. This lets > us expand and adjust the interface as needed for our purposes as well > as sanitize certain things even in the modern API. > > The result is that NVK is starting to feel like a gallium driver. 🙃 > > So here's the question: do we like this? Do we want to push in this > direction? Should we start making more things work more this way? I'm > not looking for MRs just yet nor do I have more reworks directly > planned. I'm more looking for thoughts and opinions as to how the > various Vulkan driver teams feel about this. We'll leave the detailed > planning for the Mesa issue tracker. > > It's worth noting that, even though I said we've tried to keep things > layerish, there are other parts of the runtime that look like this. > The synchronization code is a good example. The vk_sync interface is > pretty significantly different from the Vulkan objects it's used to > implement. That's worked out pretty well, IMO. With as complicated as > something like pipelines or synchronization are, trying to keep the > illusion of a layer just isn't practical. > > So, do we like this? Should we be pushing more towards drivers being a > backed of the runtime instead of a user of it? > > Now, before anyone asks, no, I don't really want to build a multi-API > abstraction with a Vulkan state tracker. If we were doing this 5 years > ago and Zink didn't already exist, one might be able to make an > argument for pushing in that direction. However, that would add a huge > amount of weight to the project and make it even harder to develop the > runtime than it already is and for little benefit at this point. > > Here's a few other constraints on what I'm thinking: > > 1. I want it to still be possible for drivers to implement an > extension without piles of runtime plumbing or even bypass the runtime > on occasion as needed. > > 2. I don't want to recreate the gallium cap disaster drivers should > know exactly what they're advertising. We may want to have some > internal features or properties that are used by the runtime to make > decisions but they'll be in addition to the features and properties in > Vulkan. > > 3. We've got some meta stuff already but we probably want more. > However, I don't want to force
Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
On 2024/01/20 2:01, Faith Ekstrand wrote: We already have several places where we're doing significant layering. It started with sharing the WSI code I wish that it be possible to compile WSI implementation as separate Vulkan layer *.so module instead of hardcoding and duplicating it to each driver. It will make Vulkan driver more platform-independent and provide proper separation.
