> First, SPIR-V was not written with security as a first principle, and it’s unclear whether it can be modified to satisfy the security requirements of the web.
At the time of this post's authoring, Google already had a set of SPIR-V restrictions to make it suitable for the web [0]. The only response from Apple I heard was "it doesn't have tests", but, again, it had more than WSL at the time [1].
> Forking the SPIR-V language means developers would have to recompile their shaders, possibly being forced to rewrite their source code anyway.
They might have to rewrite some small portions of their shader code to target WebGPU, or run some preprocessing tools to validate it. I don't think this was ever a problem. This is basically saying "if they have to change it anyway, why not rewrite it in an entirely new language", but most realistic shader code would be unaffected.
> Additionally, browsers would still be unable to trust incoming bytecode, and would be required to validate programs to make sure they are not doing anything insecure.
Browsers need to validate WSL/WHLSL too for things like out-of-bounds array accesses.
> And since Windows and macOS/iOS don’t support Vulkan, the incoming SPIR-V would still need to be translated/compiled into another language.
This is also true for WSL/WHLSL. But SPIR-V has a leg up here, as existing community cross-compile tools like SPIRV-Cross exist [2].
The argument that we have against WSL/WHLSL is that we do not trust the developers of these specifications to correctly understand the GPU programming environment, and involving IHVs in WSL/WHLSL's design is a waste of time, when they have already produced SPIR-V over many years.
Regardless of the advantages of SPIR-V as an intermediate format, it's kind of unfortunate for step one of using WebGPU to be "choose a shader compiler and integrate it into your build system" (or alternately delivering a shader compiler on every page load).
That seems like a big usability regression over WebGL. It would sure be nice if there was some human readable format that was guaranteed to be available, even if all it did was compile to SPIR-V and submit it to a lower level API. Maybe that's too hard to specify adequately.
I'd personally be completely satisfied if they decided to compromise on letting you use either WSL/whatever-shader-language and SPIR-V. I just want to be able to use SPIR-V because I'm tired of high level shader language lock-in preventing me from:
1. using existing libraries written in other languages
2. using features that the graphics hardware has supported for years simply because the language/API has been abandoned
I agree that it could be convenient to have a readily available human writable shader language, but don't think it should replace SPIR-V. WSL could be that language for all I care. It already compiles to SPIR-V.
Yeah that seems like it would be ideal since it would satisfy both use cases.
I’m just using OpenGL right now and hoping to port to WebGPU (and the corresponding native libraries) when it comes out. If the performance is adequate maybe I’ll skip porting to Vulkan altogether.
So to dynamically load shaders I’d prefer not to have to ship a separate shader compiler on every platform. I also worry that a separate shader compiler implementation (used mostly offline) might not have as good portability/security/performance as something that’s part of a web standard and implemented directly by browser vendors, although that’s not guaranteed I guess.
Of course this doesn’t matter to game engines that always compile shaders up front and already support SPIR-V. But a lot of existing WebGL code isn’t like that. The rest of the API doesn’t look too complex, so if there was an easy way to input shaders (of course in addition to SPIR-V) I think it would go a long way to making it a total replacement for existing WebGL code.
> First, SPIR-V was not written with security as a first principle, and it’s unclear whether it can be modified to satisfy the security requirements of the web.
At the time of this post's authoring, Google already had a set of SPIR-V restrictions to make it suitable for the web [0]. The only response from Apple I heard was "it doesn't have tests", but, again, it had more than WSL at the time [1].
[0] https://github.com/gpuweb/spirv-execution-env/blob/master/ex... [1] https://github.com/KhronosGroup/SPIRV-Tools/blob/master/test...
> Forking the SPIR-V language means developers would have to recompile their shaders, possibly being forced to rewrite their source code anyway.
They might have to rewrite some small portions of their shader code to target WebGPU, or run some preprocessing tools to validate it. I don't think this was ever a problem. This is basically saying "if they have to change it anyway, why not rewrite it in an entirely new language", but most realistic shader code would be unaffected.
> Additionally, browsers would still be unable to trust incoming bytecode, and would be required to validate programs to make sure they are not doing anything insecure.
Browsers need to validate WSL/WHLSL too for things like out-of-bounds array accesses.
> And since Windows and macOS/iOS don’t support Vulkan, the incoming SPIR-V would still need to be translated/compiled into another language.
This is also true for WSL/WHLSL. But SPIR-V has a leg up here, as existing community cross-compile tools like SPIRV-Cross exist [2].
[2] https://github.com/KhronosGroup/SPIRV-Cross/
The argument that we have against WSL/WHLSL is that we do not trust the developers of these specifications to correctly understand the GPU programming environment, and involving IHVs in WSL/WHLSL's design is a waste of time, when they have already produced SPIR-V over many years.