No surprise here, given the extent HLSL is already the de facto shading language for Vulkan.
Khronos already mentioned in a couple of conferences that there will be no further work improving GLSL, and given DirectX weight in the industry, HLSL kind of took over.
Additionally for the NVidia fans, it might be that Slang also gets a place in the Vulkan ecosystem, discussions are ongoing, as revealed on SIGGRAPH sessions.
My understanding was that dxc lacked support for compiling various HLSL features to SPIR-V (hence SM7 now), so there are still a bunch of Vulkan-focused projects like Godot which only support GLSL.
But yes, the games industry has been almost entirely HLSL since forever, and this is going to help remove the final obstacles.
What about WGSL though, the shader language of WebGPU? WebGPU is kind of Vulkan lite, but unlike with Vulkan, Apple is on board and actually the reason why WGSL exists as yet another shading language.
What about it? Nobody wanted WGSL, it's just an artifact of having to appease Apple during WebGPUs development as you say. I don't see why it would be adopted for anything else.
The old WebGPU meeting notes have some choice quotes from (IIRC) Unity and Adobe engineers literally begging the committee not to invent a new shader language.
The native WebGPU libraries accept SPIRV as input, and they offer libraries to convert WGSL to SPIRV and back. E.g. WGSL is only needed when running WebGPU in browsers, but even there it can be code-generated from other shading languages by going through SPIRV (but tbh, I actually like WGSL, it's simple and straightforward).
WGSL was a mistake and hopefully they get rid of it, it negatively impacts WebGPU's adoption, at least it did for me, the syntax is one of the worst ever created, just horrible
> Khronos already mentioned in a couple of conferences that there will be no further work improving GLSL
Unfortunately, HLSL isn’t an open standard like GLSL. Is it Khronos's intention to focus solely on SPIR-V moving forward, leaving the choice of higher-level shader languages up to application developers?
There's likely to be very little funding for GLSL moving forward, and I would expect no major spec updates ever again, but vendors will probably keep publishing extensions for new GPU features and fixing things up. GLSL still has a fairly large user base. Whether SPIR-V is going to be the only Khronos shading language (or whatever you want to call it) moving forward, that's hard to say. Nvidia is pushing for Slang as a Khronos standard at the moment. Not sure if anyone's biting.
Yes, they officially stated at Vulkanised, SIGGRAPH among other places, that there is no budget for GLSL improvements, and also they aren't programming language experts anyway.
It is up to the community to come up with alternative, and the game development community is mostly HLSL.
In theory if DirectX games start passing shaders to the driver in SPIR-V, the same format Vulkan uses, then yes it should make Protons job easier. Translating the current DXIL format to SPIR-V is apparently non-trivial to say the least:
C based, no support for modular programming, everything needs to be a giant include, no one is adding features to it as Khronos isn't assigned any budget to it.
HLSL has evolved to be C++ like, including lightweight templates, mesh shaders and work graphs, has module support via libraries, is continuously being improved on each DirectX release.
I wouldn't expect being able to load a D3D12 SPIRV blob into Vulkan or OpenGL anyway though, just because the 'input semantics' are very different (and I think that's also the main difference between GL and Vulkan SPIRV blobs). But AFAIK SPIRV is extensible for this type of differences without rendering existing SPIRV tools completely useless.
I think you’re kind of missing what I was getting at: today, tools which produce SPIR-V for OpenCL cannot be used to produce SPIR-V for Vulkan shaders, and vice versa. MLIR is a possible way out of the mess, but I am not hopeful that the future looks less messy, at least for some years, and it may not have enough incentive to even be feasible to improve.
What's wrong with d3d12? It works perfectly fine for what it does. In my experience it causes a lot less issues than Vulkan. And it's not really due to windows not supporting Vulkan correctly, since my experience with Vulkan has mostly been on Linux.
I don't dislike Vulkan either, it's just that I don't see the point of replacing something that works pretty well.
Adopting Vulkan doesn't mean removing Direct X 12. Just like adopting spirv doesn't mean removing hlsl. No one said anything about getting rid of anything.
It's mostly on us, the developers.
Vulkan is fully supported on windows.
I would say that if you want to have multi-platform support just use Vulkan.
Covers most of the platforms(especially if you include MoltenVK)[0].
Though, for games, if you want to support Xbox, that usually throws a curveball into API choice planning. As that might be more important of a target than Linux/Android/Mac/iOS(maybe even combined) for your game. So if you already have to support DX for that..
vulkan is already supported on windows as a first-class citizen by all major IHVs. I am not sure what this "adoption" you speak would entail. If you're talking about replacing d3d12, that actually is a terrible idea.
Does that support extend to ARM? Not sure if it's still the case, but I recall that early Windows on ARM devices didn't have native Vulkan (and I believe OpenGL was translated to DirectX via ANGLE).
But are you saying that compared to DX or just in general?
We're talking here about potential DX replacement, not about design in general and the bulk of it is very similar for both APIs.
There are some small quirks from Vulkan being made to be easily extensible which in the end I consider worth it.
I personally like how consistent the API is in both patterns and naming. After using it for a while, it's easy to infer what function will do from the name, how it will handle memory, and what you'll need to do with that object after the fact.
Readit News
Khronos already mentioned in a couple of conferences that there will be no further work improving GLSL, and given DirectX weight in the industry, HLSL kind of took over.
Additionally for the NVidia fans, it might be that Slang also gets a place in the Vulkan ecosystem, discussions are ongoing, as revealed on SIGGRAPH sessions.
But yes, the games industry has been almost entirely HLSL since forever, and this is going to help remove the final obstacles.
Though I would still like to see if slang can succeed and I am always a bit afraid of Microsoft just dropping the ball somewhere.
The old WebGPU meeting notes have some choice quotes from (IIRC) Unity and Adobe engineers literally begging the committee not to invent a new shader language.
No one asked for a new Rust like shading language that they have to rewrite their shaders on.
Also contrary to FOSS circles, most studios don't really care about Web 3D, hence why streaming is such a thing for them.
There have been HLSL to SPIR-V compilers for several years now, this is Microsoft own official compiler getting SPIR-V backend as well.
Unfortunately, HLSL isn’t an open standard like GLSL. Is it Khronos's intention to focus solely on SPIR-V moving forward, leaving the choice of higher-level shader languages up to application developers?
It is up to the community to come up with alternative, and the game development community is mostly HLSL.
https://themaister.net/blog/2021/09/05/my-personal-hell-of-t...
https://themaister.net/blog/2021/10/03/my-personal-hell-of-t...
https://themaister.net/blog/2021/11/07/my-personal-hell-of-t...
https://themaister.net/blog/2022/04/11/my-personal-hell-of-t...
https://themaister.net/blog/2022/04/24/my-personal-hell-of-t...
HLSL has evolved to be C++ like, including lightweight templates, mesh shaders and work graphs, has module support via libraries, is continuously being improved on each DirectX release.
Given the culture around memes, attribution feels somehow weird.
I don't dislike Vulkan either, it's just that I don't see the point of replacing something that works pretty well.
Same reason standards have some value.
I would say that if you want to have multi-platform support just use Vulkan. Covers most of the platforms(especially if you include MoltenVK)[0].
Though, for games, if you want to support Xbox, that usually throws a curveball into API choice planning. As that might be more important of a target than Linux/Android/Mac/iOS(maybe even combined) for your game. So if you already have to support DX for that..
[0] https://www.vulkan.org/porting
If and only if the GPU vendor supports it (they do for now). Windows itself fully supports only DX
> Though, for games, if you want to support Xbox, that usually throws a curveball into API choice
As does Playstation. Very few develop with Vulkan for Playstation as GDN (or whatever the name of the native framework is) is the main choice.
And on mobile, well, you need to support Metal.
Why do you say that?
Vulkan is not a well designed API. It's so complicated, verbose, and error prone. It's pretty bad.
We're talking here about potential DX replacement, not about design in general and the bulk of it is very similar for both APIs.
There are some small quirks from Vulkan being made to be easily extensible which in the end I consider worth it.
I personally like how consistent the API is in both patterns and naming. After using it for a while, it's easy to infer what function will do from the name, how it will handle memory, and what you'll need to do with that object after the fact.
I find documentation better than the DX one.
What are your biggest problems with it?
What are the parts that you consider objectively better in D3D12 compared to Vulkan?
Dead Comment