JAJasper_·Jan 12, 2020
Let me offer a rebuttal to that page.
> 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 i
Read the rest
t. 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.