I think not specifying the shader language / byte-code makes at least sense for those native WebGPU implementation libraries (of course not for the WebGPU standard itself).
For instance, currently Dawn comes with a lot of code to translate and validate SPIRV to the underlying shader languages or byte-codes. When using Dawn as a native library to get a friendlier cross-platform API over Metal, Vulkan and D3D12, it might make sense to do the shader translation offline, and feed Dawn directly with Metal and D3D12 shader bytecode. The strict validation isn't really needed in such a use case, the shader translation doesn't need to happen at run time, and the executable can be a lot slimmer.
Ideally I'd like to see both in web backend, SPIRV as base, but also have a quasi-standard textual language (might be WHLSL, I don't care, but just don't offer WHLSL as the only way to get shaders into WebGPU).
Both D3D12 and Metal allow to either feed shader bytecode to the API, or translate from shader source during run time.
Dawn, used offline, will almost certainly accept SPIR-V. Even if the WebGPU WG chooses an alternate approach, Google plans to use this internally for other projects, and I expect SPIR-V will remain a supported shader ingestion format.
Genuine question from someone looking at toying with graphics programming who had never heard of WebGPU before today: does this mean I should hold off on learning WebGL? How different are the two?
Based on my interests, I tend to look at this in the opposite direction. Vulkan is the correct level of abstraction for an API targeting high performance utilization of CPU/GPU rendering/compute resources. But I don't do any web based programming (other than pushing results of large data formatting to simple forms for my office). I don't care what uses a front or back end dev finds simple or low-boiler-plate, I want maximum control with as much cross-platform portability as possible. But I do get that other developers want something different. So I'm all for Khronos staying away from WebGPU and focusing on the things I care about.
Yeah, there are both use cases. Having a low level, very flexible API and a higher level, more opinionated and probably easier to use API. Having only one doesn't cut it in my opinion. There must be two levels of use.
Agreed, although being able to use JavaScript already allows for more developer friendly approach than the bare bones C API.
Khronos doesn't seem interested into making Vulkan developer friendly, like Apple, Microsoft, Sony and Nintendo do with their APIs.
So it is either "build your own engine while searching for math, image loading, fonts and mesh libraries" or getting something like Unity/Unreal/Godot, which then again turns Vulkan into just yet another API to choose from thanks to being API agnostic.
The fact that WebGPU is being driven by browser engines, without Khronos contribution, is quite telling.
> The fact that WebGPU is being driven by browser engines, without Khronos contribution, is quite telling.
Officially, on paper, this is because Apple started the WG inside the W3C, since they have an ongoing legal battle with Khronos that makes them reluctant to choose them to host the WebGPU group (it was originally started there, and Apple said they couldn't do that). But some contributors from other companies have also been contributors to Khronos specifications, including Vulkan.
> Khronos doesn't seem interested into making Vulkan developer friendly, like Apple, Microsoft, Sony and Nintendo do with their APIs.
The thing that makes Vulkan more finnicky than the other options, currently, is the fact that it has to ship on mobile. And lots of mobile Android GPU vendors are basically awful. If you cut that restriction out, you can use a subset of Vulkan that is way more like than the others.
Regarding Android, from the point of view of a beginner (in low level 3D) getting into Vulkan, compare how to use MetalKit or DirectTK, versus the official NDK support for Vulkan.
You get told to clone a GitHub repo, compile shaderc, go to download LunarG SDK, and this is just the beginning.
Now you still need to go get GLM, DevIL, glTF loader, write code to loader shaders, and it is finally time for getting the first triangle ready.
Whereas you get all of that from a set of IDE templates, and integrated debugging tools.
So something like WebGPU, is pretty much welcomed.
The Android development experience is a piece of garbage, but that's not Khronos's fault necessarily.
> Now you still need to go get GLM, DevIL, glTF loader, write code to loader shaders, and it is finally time for getting the first triangle ready.
MetalKit is a higher-level scene graph toolkit. I don't really think it's appropriate for Khronos to specify a higher-level scene graph (remember VRML? OpenInventor?). DirectXTK is not that either, DirectXTK is effectively a bunch of helper-ish math stuff.
If you want a higher-level scene graph toolkit, there are plenty to choose from.
Neither ARB or Khronos had nothing to do with VRML, OpenInventor.
Yes I do believe that it is appropriate for Khronos to specify something, specially for beginners.
I did my first GL serious application porting a particles visualization engine from NeXTSTEP into Windows, ironically what is a basic feature in any modern graphics engine.
Yet, whatever is coming out of Khronos has already changed since then, other than now we have Khronos instead of ARB and get some PDFs with overview of APIs.
It appears there is a certain culture that every beginner has to through the same rite of passage to be worthy of using Khronos APIs.
It is like only IP would be standard, and after learning how to send an ICMP package, one would need to go out and get libraries for UDP, TCP, or do their own protocol on top of IP.
[1] https://gpuweb.github.io/gpuweb/#typedefdef-gpushadercode > Note: While the choice of shader language is undecided, GPUShaderModuleDescriptor will temporarily accept both text and binary input.