During Metal Shading Language's development, there were multiple opportunities to engage for Apple to open up their shading language toolchain, and make MSL a standard that would be respected by multiple people. They ignored that advice, and now lots of people grumble about writing MSL. It is, in many people's eyes, a quite decent shading language, but it's "different enough" and for a niche enough platform (in the games world) that it pays the price heavily. Tooling is pretty abysmal, and GPU debugging in Xcode is not the greatest experience.
Now, with that said, Apple did not propose MSL to the WebGPU working group either. Apple originally proposed a hilariously underspecified fork of HLSL called WHLSL which had three goals: 1. Be a safe shading language for the web, 2. Be compatible with existing HLSL content, 3. Add pointers.
Nobody ever justified the existence of that last one to me or the rest of the group, other than making the Metal implementation slightly easier for Safari, since Metal's binding model is based on pointers, and coincidentally, the Safari pre-release only supported binding pointers, and not the standard HLSL way of doing things. But still, the WHLSL proposal was interesting to a lot of people because HLSL seemed like a good language to start from.
After a lot of debate, Apple secretly went back to the drawing board, and released a revised version of the language, WSL, which dropped the goal of HLSL compatibility but still has pointers for some reason. Nobody has ever explained why it has pointers, despite everyone continuing to ask. The goals are still there if you want to read them [0].
Thanks for the summary. It highlights how "collaboration" from Apple's perspective works. Throwing something over the fence, and then going back to discuss things in secret.
The track record of industry GPU language development is very poor (arguably even disastrous).
I worry that we now just count on nice languages / compilers magically appearing deus ex machina, and we end up not having any. Big multiplatform frameworks like Unity will just put a SPIR-V backend on their existing tooling.
The rest of us will be stuck with POC-quality GLSL transpiler tools, without the browser devtools and other tooling support that we slowly got over the ~10 years of WebGL history.
(I'm not saying GLSL is that excellent, just that could be heading backwards from current almost-good-enough GLSL implementation quality in WebGL.)
Metal Shading Language is a C++ dialect. HLSL is as much of a C dialect as GLSL is. And I would argue that C++ provides no benefits over C for shading languages.
Moved but remained proprietary. So the problem is not solved. Language shouldn't be proprietary to begin with. It's an obsolete and invalid practice from the last century.
Apparently not, given the monthly occurrence of FOSS projects that decide to go dual license, or even back to proprietary, because this century practice doesn't cover their existence and life responsibilities.
For languages? That's a dead end really. That's why whatever Apple will produce will also be dead, as long it's proprietary. Apple is stuck in that mentality and has hard time getting out of it.
It kind of has, if Khronos never provides anything better, as it has been proven before, hardly anyone will step up to improve it, until the standard starts being put aside in preference to proprietary middleware or competing APIs.
There is nothing wrong per se with SPIR-V to provide anything much better. What you said has indeed nothing to do with the intermediate language itself.
It's relevant to what you choose to use as the standard. A language can be fine on its own terms, but also you should only install it with a layer on top and not by itself.
Yeah, around 500 boilerplate lines of code to draw a triangle on Vulkan, plus having to going hunting for features that every graphics application requires and all other APIs provide on their SDKs.
With Khronos APIs, every newbie graphics developer learns to build their engine from day one.
But for bug reports, debugging and fixing bugs in the shader compiler, validation layers, etc they are pretty responsive to issue reports and pull requests.
