Vulkan 1.1.81 Released, Deprecates VK_NV_glsl_shader

[phoronix]

Phoronix: Vulkan 1.1.81 Released, Deprecates VK_NV_glsl_shader

Vulkan 1.1.81 is now available as the latest minor update for this graphics/compute API...

http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.1.81-Released

[schmidtbag]

As far as I'm concerned, any brand-specific extensions ought to be depreciated, anyway.

[starshipeleven]

As far as I'm concerned, any brand-specific extensions ought to be depreciated, anyway.

It's a good thing you don't wield any significant power in multi-vendor API development.

Also, *deprecated

[FireBurn]

I think the 2nd last line doesn't read the way it's supposed to. "Since then..."

[schmidtbag]

It's a good thing you don't wield any significant power in multi-vendor API development.

I don't understand how that relates to what I said... I want an API to be as multi-vendor-friendly as possible. This extension Nvidia created would've been practical for other vendors, but they reserved it for themselves. All that does is cause fragmentation and clutter. So, why exactly is wanting Nvidia-specific (or any brand, not just Nvidia) extensions to be deprecated a bad thing?

[patrakov]

Out of interest - when was the first deprecation of any Vulkan extension?

[VikingGe]

All that does is cause fragmentation and clutter.

You don't seem to have any idea what vendor-specific extensions are for. There are multiple examples of vendor extensions being promoted to more generic EXT or KHR extensions, and some extensions are extremely hardware-specific and cannot be implemented by other vendors.

As for this one, of course I don't know the exact reason why it gets deprecated, but it's just not needed. Just use glslang directly if you need to compile GLSL shaders on the fly, or better yet, don't compile GLSL on the fly at all. So yes, it's a good thing that this one gets dropped, but because of what it does, not because it's a vendor extension.

There's actually a very simple solution to the "fragmentation and clutter" issue caused by vendor extensions: Don't use them.

[starshipeleven]

This extension Nvidia created would've been practical for other vendors, but they reserved it for themselves.

Which is where you are wrong, and why I said it's a good thing you don't have any power in it.

Vulkan exensions aren't private. Any vendor can support another vendor's extension if they so choose, there is no reservation. This is a way to have vendors promote their ideas independently and if everyone else likes it and supports it then the extension is promoted to generic standard and eventually becomes part of the next version of the spec.

There are some extensions that are hardware-specific and of course won't ever be used by other vendors, or even the same vendor in different generations of GPUs.

This is EXACTLY the same that happened with OpenGL, and also on each fucking article about Vulkan or OpenGL extensions added we get someone that thinks extensions are private and a bad thing and so on and so forth, and each time someone comes and explains that they are wrong.

[schmidtbag]

You don't seem to have any idea what vendor-specific extensions are for. There are multiple examples of vendor extensions being promoted to more generic EXT or KHR extensions, and some extensions are extremely hardware-specific and cannot be implemented by other vendors.

Pretty arrogant approach to my response, considering you sort of contradicted yourself:
1. If the extension can be made generic, why not just make it so from the very beginning? It's one thing if only one vendor supports an extension at first, but to make it vendor-specific is just an inefficient use of everyone's time, including the vendor who created it in the first place.
2. If it is "extremely hardware-specific and cannot be implemented by other vendors" (in other words, cannot be made generic), then what's the point of making it? Most software developers aren't going to use an extension that leaves out some of their userbase. This is why DX9 and OGL2 lived for so much longer than they should have - practically all hardware worth anyone's interest was compatible with those. So, it seems like a wasted effort to make an extension that can easily be predicted to go mostly unused.

As for this one, of course I don't know the exact reason why it gets deprecated, but it's just not needed. Just use glslang directly if you need to compile GLSL shaders on the fly, or better yet, don't compile GLSL on the fly at all. So yes, it's a good thing that this one gets dropped, but because of what it does, not because it's a vendor extension.

So despite your "this is all obvious" attitude, you admit to not knowing why it was deprecated...
Seeing as this extension was made early in Vulkan's development, this extension was once practical, and would've been to all vendors. But, as you pointed out, there's not really a reason to compile in GLSL on the fly anymore, and being vendor-specific further hinders its practicality to any real-world application, so I think it makes perfect sense why it was dropped.

There's actually a very simple solution to the "fragmentation and clutter" issue caused by vendor extensions: Don't use them.

That doesn't solve either of those problems... That's like someone saying "we need to do something about the Pacific Garbage Patch" and your response to that is "just stop making garbage" as though that will magically make the existing garbage go away. The clutter still exists - not using it doesn't inherently get rid of it.

[schmidtbag]

This is EXACTLY the same that happened with OpenGL, and also on each fucking article about Vulkan or OpenGL extensions added we get someone that thinks extensions are private and a bad thing and so on and so forth, and each time someone comes and explains that they are wrong.

I never said they were private or implied it. After all, both OpenGL and Vulkan are open-source. However, mind pointing out how many of Nvidia's extensions Intel and AMD have willingly supported in their closed-source drivers (or vise-versa, this isn't an Nvidia-specific thing) and were used in real-world applications? I exclude open-source drivers because they often make make more progress than the vendors have ever intended, usually due to volunteer or 3rd party devs (such as r600 heading toward complete OGL4 support).