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.
WebGPU, like WebGL, is a decade behind the native APIs it is based on.
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.
I haven't used either in a while, what is missing from GLSL?
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.
Will this help games be more compatible with the proton layer on Linux or is this not related?
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:
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...
This is really good news!
Cinematic crossovers have gone too far
Hopefully this isn’t actually Third SPIR-V Dialect
Good. Now if Windows would adopt Vulkan as the graphics API of the future.
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.
That's not really the same as being supported by Windows. I think that's 3rd party support and not built into the OS.
what do you mean when you say "built into the os"? d3d12 is just an api. the d3d runtime is user-space, both the UMD that wraps it and the KMD are supplied by the hardware vendor. In the end, both a d3d app and a vulkan app end up talking to the very same KMD. See here for reference:
https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
D3D is clearly more integrated into the OS than Vulkan is.
Most importantly, Windows includes a software D3D renderer (WARP) so apps can depend on it always being present (even if the performance isn’t spectacular). There are lots of situations where Vulkan isn’t present on Windows, for example a Remote Desktop/terminal server session, or machines with old/low-end video cards. These might not be important for AAA games, but for normal applications they are.
Another example: Windows doesn’t include the Vulkan loader (vulkan-1.dll), apps need to bundle/install that.
Oh, I was under the impression that Direct X 12 was built-in for Windows like Metal is on Apple.
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).
I haven't laid my hands on any ARM windows devices so I wouldn't be able to tell you. I'd be somewhat surprised if the newer snapdragon stuff doesn't have vulkan support because qcom supports vulkan first-class on its gpus. in fact, on newer android devices OpenGL support might already be implemented on top of vulkan, but don't quote me on that.
LunarG released a native ARM version of the Vulkan SDK shortly after the Snapdragon X machines launched so presumably it works on those.
edit: yup https://vulkan.gpuinfo.org/listreports.php?devicename=Micros...
If you're talking about replacing d3d12, that actually is a terrible idea.
Why do you say that?
I say this because vulkan is hamstrung by being an "open API" intended to run on a very wide range of devices including mobiles. this has major repercussions, like the awkward descriptor set binding model (whereas d3d12's descriptor heaps are both easier to deal with and map better to the actual hardware that d3d12 is intended to run on, see e.g. https://www.gfxstrand.net/faith/blog/2022/08/descriptors-are...). overall d3d has the benefit of a narrower scope.
Another problem with being an open API is that (and this is my own speculation) it's easier for IHVs to collaborate with just Microsoft to move faster and hammer out the APIs for upcoming novel features like work graphs for example, vs bringing it into the public working group and "showing their cards" so to speak. This is probably why vk gets all new shiny stuff like rtrt, mesh shaders etc. only after it has been in d3d for a while.
One could argue this is all solvable by "just" adding a torrent of extensions to vulkan but it's really not clear to me what that path offers vs d3d.
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.
SPIR-V is not an alternative to HLSL. It's an intermediary format that you compile HLSL (or GLSL) to.
Reinvention of the wheel and tax on supporting "yet another thing" for developers who need to deal with it.
Same reason standards have some value.
It's Vulkan that was reinventing the DX12 wheel wasn't it though?
Vulkan is based on Mantle, which predates the release of DX12 by about 2 years.
DX12 is proprietary. Vulkan is not.
It should.