Vulkan 1.3.279 Brings New NVIDIA Extension Co-Engineered By Valve

[smitty3268]

It's not about them being available or not. It's about them being too many dude.

I'm confused why people think that's a problem.

The average dev falls into 3 categories:
* A random guy just playing around with stuff, that will likely only ever use baseline 1.3 and doesn't need to care or even know that extensions exist
* Someone working on a game that will be using a graphics engine to do all the underlying work for them
* A dev maintaining a graphics engine or translation layer, which wants as many little knobs to tweak as possible
* Am i missing a 4th category that cares about this for some reason?

I know "bloat" is a dirty word for people, but can you explain exactly why adding new extensions is bad or hurting the ecosystem?

It can make creating new Vulkan drivers harder, but that only really affects new hardware and if Vulkan support is required for the platforms they want to support they're going to create the drivers regardless.

[piotrj3]

Correct me if I am wrong, but my understanding is, that the most important client for Vulkan is Valve and Proton, making execution of DX12 on Linux a great experience. So as long as Proton does handle the extensions. it is a completely irrelevant how complex some feel it had become. Vulkan now runs on any platform and so DX12 runs on a lot of them too.

I call that a win.

The most important client for Vulkan is/will be android. Unreal, Unity, now godot all support Vulkan. O3DE doesn't even support dx11/opengl - it supports mobile platforms only by vulkan. Proton i would say is is fairly big one, but most developers seems to follow defaults of their game engine and that is DX11 or DX12... but in some titles it doesn't prevent you from running on vulkan.

[Daktyl198]

Vulkan is now "extension hell" in the same way OpenGL was. Its initial popularity is completely gone now. Games just stick to DX12. Once in a blue moon you see a Vulkan game. Graphics devs are kind of fed up with this.

Careful, every time I say this I get a thousand replies saying I'm an idiot and somehow this time it will be different.

[marlock]

I'm confused why people think that's a problem.

The average dev falls into 3 categories:
* A random guy just playing around with stuff, that will likely only ever use baseline 1.3 and doesn't need to care or even know that extensions exist
* Someone working on a game that will be using a graphics engine to do all the underlying work for them
* A dev maintaining a graphics engine or translation layer, which wants as many little knobs to tweak as possible
* Am i missing a 4th category that cares about this for some reason?

I know "bloat" is a dirty word for people, but can you explain exactly why adding new extensions is bad or hurting the ecosystem?

It can make creating new Vulkan drivers harder, but that only really affects new hardware and if Vulkan support is required for the platforms they want to support they're going to create the drivers regardless.

the 4th dev category is gpu driver devs...
...but they're on board (literally, lol!) with the extensions being introduced, and in fact contribute several of them

if anyone wants someone to "blame" that would be Microsoft, for maintaining DX12 instead of turning to Vulkan on the latest Xbox Series consoles, but i've seen a dev explain a couple things once that made me rest easier even about that

1) Vulkan development is slower, but more carefully thought out than DX12... if anyone is going to fall into a feature creep trap is probably DX12, which introduces features quickly and without giving everyone the opportunity to chime in and improve the design before it's set in stone

2) Vulkan vendor-specific extensions are a breeding ground... the good extensions become vendor-neutral... and the best battle-proven ones later enter a versioned core vulkan specification if needed

3) a bunch of extensions are higher abstraction built over the core vulkan specification functions, but could be executed through core functions with extra implementation efforts in the calling software

4) there is a delay but eventually everything new about DX12 is implemented as a superset feature in Vulkan, with greater flexibility and performance

5) Vulkan perf is actually better, and while often ignored, there are some game devs who think it worthwhile to add direct Vulkan support to their games despite already having DX12... this is no small sign

Even if most games use DX12, they run over Vulkan just fine, so DX12 can no longer act as the OS lock-in its predecessors once were

Vulkan is not going away... it's the most cross-platform thing ever... and even mandatory on Android for a while already (not that i like android, but it matters)

Outside gaming, Vulkan is only gaining ground and that also matters... a lot!

[Weasel]

I'm confused why people think that's a problem.

The average dev falls into 3 categories:
* A random guy just playing around with stuff, that will likely only ever use baseline 1.3 and doesn't need to care or even know that extensions exist
* Someone working on a game that will be using a graphics engine to do all the underlying work for them
* A dev maintaining a graphics engine or translation layer, which wants as many little knobs to tweak as possible
* Am i missing a 4th category that cares about this for some reason?

I know "bloat" is a dirty word for people, but can you explain exactly why adding new extensions is bad or hurting the ecosystem?

It can make creating new Vulkan drivers harder, but that only really affects new hardware and if Vulkan support is required for the platforms they want to support they're going to create the drivers regardless.

What part of "baseline" getting official extensions into it you don't get?

Your average dev has limited brain capacity. Having to remember all those freaking extensions, official or not, is what drives people away. It's called feature creep. OpenGL is similar of course, but everyone knows OpenGL is a bad graphics library, so why the fuck make Vulkan follow in its footsteps?

For graphics engine dev it is the same thing. Why the fuck would they learn a bloated/complicated as shit API like Vulkan instead of DX12?

[marlock]

I don't think you understand what Vulkan is. Its an OS independent hardware go between DX12 and the GPU, or OpenGL and the GPU, not really a framework directly for games. Think of it as an Open Hardware library that DX12 speaks to. It simplifies having to port games for many specific platforms. DX12 is comprised of mostly Vulkan. It simplified game development for PC and all consoles. There would be no DX12 without Vulkan. Every single current gen console game and pc game uses it when using DX12.

Good gods, dude, no!

Just because DX12 can be translated into Vulkan API calls by DXVK doesn't mean that DX12 is actually a piece of Vulkan...

GPU drivers on Windows implement DX12 directly, not over Vulkan, but alongside it.

Because Vulkan development is a bit slower one of its aims is to ensure new DX12 features are covered in some way in the Vulkan API to ensure such translation is always possible and as performant and straightforward as possible, but both have lives of their own.

DX12 is a proprietary graphics API by Microsoft for Windows and Xbox series consoles, wereas Vulkan is a cross-platform opensource API maintained by an industry-wide consortium: https://www.vulkan.org/

[mSparks]

Vulkan is now "extension hell" in the same way OpenGL was. Its initial popularity is completely gone now. Games just stick to DX12. Once in a blue moon you see a Vulkan game. Graphics devs are kind of fed up with this.

yeah, that nanite engine by those losers at unreal, its not sold a game with more than 120 million players for at least a few weaks, absolute failure.
meanwhile microsoft is dropping blockbusters like msfs2020 every other day.

rofl.

[ahrs]

Because Vulkan development is a bit slower one of its aims is to ensure new DX12 features are covered in some way in the Vulkan API to ensure such translation is always possible and as performant and straightforward as possible, but both have lives of their own.

I'm not even sure why people think this is a bad idea. If we want to encourage people to use the free and open alternative then surely it is in everyone's best interest that they make porting/translating code as easy as possible.

The alternative without creating extensions means creating more headaches. They're still going to implement the behaviour but in a hacky or buggy way that might have more performance issues, etc, when it could be done better in the graphics driver.

[mSparks]

I'm not even sure why people think this is a bad idea. If we want to encourage people to use the free and open alternative then surely it is in everyone's best interest that they make porting/translating code as easy as possible.

The alternative without creating extensions means creating more headaches. They're still going to implement the behaviour but in a hacky or buggy way that might have more performance issues, etc, when it could be done better in the graphics driver.

I think their problems with it are much simpler than that.
Certain contingent is mad that this is yet another meaningful investment by nvidia in Linux, that creates yet more unpaid work to do for the others to try and keep up.

If this was an AMD extension, we'd already be on page 30 full of screaming how great it is, even tho no one actually cares or would actually use it.

[marlock]

do you know what's even more obnoxious that amd/nvidia fanboyism? the anti nvidia/amd-fanboyism rage and indignation! especially in topics where fanboyism hasn't even shown up!

in a blog about linux and FOSS software development, when a company helps develop FOSS software and open APIs most of us are happy, no matter the vendor... it's pretty basic math

so this thread is not boiling up with anti-Nvidia feelings because it's a case where Nvidia did something pro-FOSS people consider positive... which is good, because we don't want to send them mixed signals

if anything it's a testament to Vulkan, Khronos.org and FOSS that Nvidia is even a part of a FOSS API development initiative nowadays, instead of just inventing yet another vendor-locked alternative (especially given how much they usually love vendor-locked stuff)

i for one am super glad there is a better FOSS driver for Nvidia GPUs in the oven, and that NVK is turning out as good as it is... every single time it wins against the current proprietary driver in a test is a good day, same as when RADV and ACO win against AMD's reference proprietary components and keeps the retrograde temptation of AMD going back to their own dark ages at bay

astonishing and rare as it is, sometimes competitors work together... or, more to the point, a development framework like khronos.org's industry-wide participative development makes them work begrudgingly towards a common goal, a step at a time

we may believe there's more begrudging or more happiness in the collaboration, but pragmatically it's collaboration nonetheless, and it moves us an inch further away from the barbwired walled gardens, regardless of which vendor did which lines of code

and i would be omiss to not acknowledge Valve's hand in yet another part of the Linux graphics API stack... they make a closed source software to sell mostly closed source games, yet it's undeniable how much they value FOSS as part of their strategy and push it forward by financing efforts across the stack, upstreaming as much of it as possible, etc

trivia:
several years ago some folks (presumably nvidia fanboys) in a steam for linux discussions forum complained that Valve didn't contribute to Nvidia GPUs on Linux, only to AMD's and this was unfair... to which the general reply was "if they also had an opensource driver..."
...
well, i'll be damned?! what a shocking plot twist now!