Vulkan 1.0.5 API Specification Released

[computerquip]

No I am not, but I'm not an expert either. Can you explain why you think what I said was silly?

Because there's no "proprietary implementation" to match. There's a specification.
EDIT: And really, the implementation is mostly done for all drivers. They've done it for over a decade in their OpenGL drivers. Alternatively, they can just use glslang to go from GLSL to Spir-V to their intermediary.

[M1kkko]

... Are you joking?

No I am not, but I'm not an expert either. Can you explain why you think what I said was silly?

[computerquip]

Doesn't this still mean that you, as someone writing let's say an open source Vulkan driver, have to compile the shaders at run time, in the driver, and try to match Nvidia's proprietary implementation? (Good luck with that)

... Are you joking?

[TheBuzzSaw]

Also, NVIDIA's crimes against humanity had nothing to do with extensions; it was the fact that NVIDIA would hard code against specific games.

When I would read NVIDIA drive release notes, I would see that game X runs 12% faster, game Y runs 22% faster, and game Z runs 15% faster. I never really dug far into it. I assumed that NVIDIA was running the game, studying API call patterns, and merely optimizing its driver against those patterns. That is totally fair game as far as I am concerned. If real games are commonly using D3D/GL a particular way, the driver can streamline that path.

But that's not what was happening. NVIDIA had a bunch of hard coded checks against whole applications/shaders and substituting code with its own re-implementation! In other words, rather than go to Gearbox and say "hey, your Borderland shaders could be better written this way", NVIDIA just quietly swaps the entire shader out for a better one it wrote. So, on the outside, it appears to the world that Borderlands just "runs better on NVIDIA", but the truth is AMD (or whatever other GPU) is literally running an outdated and suboptimal shader in the first place! "Oh, AMD sucks. They can't do anything right."

In short, all vendors create extensions for graphics APIs. That shouldn't upset anyone or be seen as "the first steps to anti-competitive behavior". NVIDIA simply needs to be called out on its attempts to cherry-pick bugs in other programs and create this illusion that NVIDIA's actual driver is "better at everything" when it actually isn't.

[M1kkko]

I agree with you that extensions often have a vendor lock-in effect and that this move may make some think that this one is official. However, it doesn't seem very dangerous (at least in comparison with other extensions from NVIDIA), because the GLSL shaders that it accepts must anyway adhere to the Vulkan version of GLSL

Doesn't this still mean that you, as someone writing let's say an open source Vulkan driver, have to compile the shaders at run time, in the driver, and try to match Nvidia's proprietary implementation? (Good luck with that)

[computerquip]

Why isn't it still in alpha, if it has to change every week, and isn't feature complete either?

They can't win regardless of what they do and you wouldn't be happy if they waited another 5 or 6 months to make the API more stable, not to mention that those changes perhaps wouldn't have been made if it hadn't gotten use from the public to begin with.

[computerquip]

And there we go, adding vendor specific stuff, thats the first step in order to Vulkan become what OpenGL is

This
The whole point of Vulkan was to design a new specification from the ground up without any legacy limitations.
Introducing glsl ruins the lean driver part of the clean design thing.

No, but that's the thing: Even if it's not a part of "core" Vulkan, some form of it is in the official released documentation of Vulkan. It's an extension that, I admit, is going to help a lot of early ports to Vulkan (though with minimal benefits) and while before it was strictly NVidia only, now that it's on the official documentation of the API (definition only or no), people are going to see that as "So everybody ships it, we're okay to use it"... and so everybody will have to ship it. AMD/Intel are basically forced to implement this now. Despite what somebody said earlier, extensions ARE part of why OpenGL was so fucked up. 90% of OpenGL problems were from vender-specific implementations... guess what's harder to implement to spec than core OpenGL? That's right, extensions which, afaik, were never bound to the (already not-very-strict) definitions/implementation rules as core OGL. When there's a lot of them, you're going to have problems in terms of not rending exactly the same as the implementation by the creator of the extensions.

Extensions are fine, but I really feel they should be sent to Khronos as a whole for review, then if accepted (changed or not) renamed to fit Vulkan instead of having a ton of "NV_" or "AMD_" etc etc extensions in the spec. It really gets annoying after a while. It could be like the browser --webkit- or --mozilla- flags, where if you're using "VK_NV_glsl_shader", you're using NVidia's specific implementation, but if you're using "VK_VE_glsl_shader", you're using the official, spec-compliant version. AMD/Intel wouldn't be forced to implement the _NV_ (nor NVidia _AMD_/_INTEL_) versions so less complaining from everybody, we get more strict extension definitions (less breakage overall). Win-win.

Extensions are optional. We see implementations differ in extension support all the time... For instance, Mesa doesn't support any binary formats or ARB_compatibility. AMD and Intel doesn't support NV_command_list. In addition, implementations are not "forced" to implement another vendors extensions. As a matter of fact, it's very rarely ever done. Instead, an extension specification for the specific vendor is often created, something in the middle is created and formatted into a EXT extension and eventually into an ARB extension if it gets enough support and Khronos sees it fit to approve.

We won't see an official extension for GLSL, we already have the appropriate and correct method of using GLSL via a Spir-V compiler. You can also compile GLSL into Spir-V yourself at runtime. NVidia is just making it easier by providing the interface in their driver. It will be slower than Spir-V -> Nvidia Intermediary Binary Format and it will come with its own attached problems.

Extensions aren't a reason why OpenGL was fucked up. OpenGL was fucked up because of abstract specification that let multiple methods of doing things differ in performance across vendors. It also had specification that went against an efficient multithreading application. It isn't ideal when you need control over the GPU rather than control over the driver that controls the GPU, which differs across implementations and GPU. I've never seen anyone complain about OpenGL extensions (aside from maybe loading them which LunarG SDK now abstracts for us). As a matter of fact, I'd say it's the only reason why OpenGL is still viable at all.

[kalrish]

No, but that's the thing: Even if it's not a part of "core" Vulkan, some form of it is in the official, released documentation of Vulkan. It's an extension that, I admit, is going to help a lot of early ports to Vulkan (though with minimal benefits) and while before it was strictly NVidia only, now that it's on the official documentation of the API (definition only or no), people are going to see that as "So everybody ships it, we're okay to use it"... and so everybody will have to ship it. AMD/Intel are basically forced to implement this now.

I agree with you that extensions often have a vendor lock-in effect and that this move may make some think that this one is official. However, it doesn't seem very dangerous (at least in comparison with other extensions from NVIDIA), because the GLSL shaders that it accepts must anyway adhere to the Vulkan version of GLSL:

Implementations that expose this function allow GLSL shaders […] as an alternative to SPIR-V shaders. […] the GLSL shaders must be authored to the GL_KHR_vulkan_glsl extension specification.

AFAIU, this means that freeing from this extension would mostly require changes to the build system.

That said, I don't see the point in this extension. Porting to Vulkan already requires bigger changes (also in the shader themselves) than merely compiling the shaders in a separate step. It seems like saving a few bucks in the glasses when building an expensive house (understandable if one does the same with many other small things, but still questionable).

[andrei_me]

Extensions are fine, but I really feel they should be sent to Khronos as a whole for review, then if accepted (changed or not) renamed to fit Vulkan instead of having a ton of "NV_" or "AMD_" etc etc extensions in the spec.

IIRC those acronyms serve the purpose to identify the company behind the original specification of the extension, not necessarily the implementation...

[Daktyl198]

EDIT: Nevermind, seems it's just about recognising the existence of the extension, not about incorporating it into Vulkan itself.

No, but that's the thing: Even if it's not a part of "core" Vulkan, some form of it is in the official, released documentation of Vulkan. It's an extension that, I admit, is going to help a lot of early ports to Vulkan (though with minimal benefits) and while before it was strictly NVidia only, now that it's on the official documentation of the API (definition only or no), people are going to see that as "So everybody ships it, we're okay to use it"... and so everybody will have to ship it. AMD/Intel are basically forced to implement this now.

Despite what somebody said earlier, extensions ARE part of why OpenGL was so fucked up. 90% of OpenGL problems were from vender-specific implementations... guess what's harder to implement to spec than core OpenGL? That's right, extensions which, afaik, were never bound to the (already not-very-strict) definitions/implementation rules as core OGL. When there's a lot of them, you're going to have problems in terms of not rending exactly the same as the implementation by the creator of the extensions.

Extensions are fine, but I really feel they should be sent to Khronos as a whole for review, then if accepted (changed or not) renamed to fit Vulkan instead of having a ton of "NV_" or "AMD_" etc etc extensions in the spec. It really gets annoying after a while. It could be like the browser --webkit- or --mozilla- flags, where if you're using "VK_NV_glsl_shader", you're using NVidia's specific implementation, but if you're using "VK_VE_glsl_shader", you're using the official, spec-compliant version. AMD/Intel wouldn't be forced to implement the _NV_ (nor NVidia _AMD_/_INTEL_) versions so less complaining from everybody, we get more strict extension definitions (less breakage overall). Win-win.