Precompiled shader blobs API

[stoyannk]

Some closed platforms like game consoles disallow shader compilation on the user machine. This makes the showing of arbitrary WebGL (so far) content extremely tough.
It would be great for the gpuweb API to allow the developer to use Blobs as pre-compiled shader code. Although not very web-y because the blobs will have to be platform-depndent, it will deal in a standard way a problem that otherwise is pretty much impossible to solve.

[thokra1]

Well, with something like SPIR-V, the IR is what you ship - independent of the target platform. The fact that you have to ship binaries for a specific platform is something that has historically complicated things and, IMHO, is not the right thing to strive for.

Also, there is some hope that at least for the PS4, Vulkan support might not be impossible to achieve (I know it technically isn't, but business and political decisions might still get in the way). Some individuals already had varying success in this endeavor. For Steam Boxes (which are simply Linux based and thus has no barriers for Vulkan support at all) and NVIDIA Shield (which is Android based and offers Vulkan Support on all , Vulkan support is not even in question.

So, my takeaway from these observations is: Don't make concessions due to proprietary platforms like the PS4. Use an IR that already works for most other recent platforms out there, like SPIR-V, and forget about pre-compiled, vendor-specific binaries. If the console at some point follow suit and adopt SPIR-V as a valid representation, there is nothing you have to changed in your pipeline and if they don't, we're at least not worse off than we are today.

[othermaciej]

I don't think we should support platform-specific shader binaries.

First, shipping platform-specific binary blobs undermines the universality of the web. The web is supposed to be cross-platform, and shipping platform-specific binaries undermines that.

Second, directly sending unverified shader binaries to the GPU is almost certainly unsafe from a security perspective. The validation problem will be hard enough for a platform-independent source or binary shader format.

BTW my current favorite suggestion for a shader format is WebAssembly (yes, really). It supports safety and efficient validation by design. And we know it can be compiled to a wide range of targets efficiently. On the other hand, validating SPIR-V is an unknown and likely tricky problem. But in any case, shaders will need to be cross-platform and validated.

[stoyannk]

I agree that the universality definitely suffers, however platforms will again be left out. There doesn't seem to be a lot interest from console developers in the web unfortunately, because they are the ones who would have the possibility to allow some form of shader processing.

WebAssembly is an interesting idea.

[Kangz]

The choice of a shading language can come pretty late in the specification of the API.

I'd like to complement @othermaciej's point of view with the fact that WebAssembly doesn't have any construct related to SIMD processing like in GPUs nor facilities for declaring shader stage input / output. SPIRV does however have a work in progress validator in SPIRV-Tools.

[othermaciej]

@Kangz "The choice of a shading language can come pretty late in the specification of the API." <-- strongly agree with this.

I don't have the expertise to know whether a GPU-independent shader format needs explicit SIMD constructs, or whether they are on the WebAssembly roadmap. Both things worth checking.

Finally, the SPIR-V validator is interesting. It says that it checks the validity criteria in the SPIR-V spec. Are those criteria sufficient to guarantee memory safety and other required security criteria for a web-facing format? Or is it more like a well-formedness constraint?

[Kangz]

WebAssembly has a "Long SIMD" post-MVP feature which mentions it might relate to GPU, but that's all I could find. Usually GPU shading languages look like "serial" languages but have additional feature to access the memory space shared between waves, do aggregate operations between waves (think all(), any()), etc.

AFAIK the SPIRV validator checks the well-formedness of the program and SPIRV doesn't have memory safety on its own. However all the memory accesses are done through builtin functions with (for example) the buffer as an opaque handle. It looks like it would be reasonably easy to make a transformation that would add bounds checking if the hardware doesn't support it natively.

[devshgraphicsprogramming]

You could contribute an extension to the SPIR-V specification and vulkan for robustness and memory safety.

[litherum]

The CG is proceeding without platform-dependent shader binaries, because of security. I’d like to close this issue.

[kainino0x]

We've discussed this in WebGL as well. It's still possible to partially deliver this by allowing applications to key by opaque handle (allowing them to control the caching of precompiled pipelines). However since the binary must always be compiled on the user machine, the benefits over automatic caching in the browser are fairly minimal.

[litherum]

Such handles should probably be fairly tightly scoped to JS objects that live in the page (e.g. we generally consider it a mistake that Blobs can’t get garbage collected because a URL somewhere might happen to reference them).

If they are literally represented as JS objects, then there’s no reason for JS to use them rather than a pipeline state object. Even if they’re not, if they are tightly scoped to the page, then the browser should be able to perform this optimization transparently under the hood, for all WebGPU content, rather than having this optimization be opt-in.

[magcius]

In WebGL land, since shader compilation takes a long time, it would be nice to know up-front whether a shader needs to be compiled explicitly or whether it is cached. But since there are multiple factors that affect shader compilation (current input layout is part of the shader signature, at least in ANGLE), that's more difficult.

I expect this to be less of an issue in WebGPU, but it would still be nice up-front to know whether a pipeline is cached or not.

[mixtur]

We've discussed this in WebGL as well. It's still possible to partially deliver this by allowing applications to key by opaque handle (allowing them to control the caching of precompiled pipelines). However since the binary must always be compiled on the user machine, the benefits over automatic caching in the browser are fairly minimal.

Come on. This is still useful. Yes, you won't benefit from it on the first load, but if what you are doing is something like Figma, or Sketchfab this might speedup initialization substantially. I am not even talking games.

[devshgraphicsprogramming]

We've discussed this in WebGL as well. It's still possible to partially deliver this by allowing applications to key by opaque handle (allowing them to control the caching of precompiled pipelines). However since the binary must always be compiled on the user machine, the benefits over automatic caching in the browser are fairly minimal.

Come on. This is still useful. Yes, you won't benefit from it on the first load, but if what you are doing is something like Figma, or Sketchfab this might speedup initialization substantially. I am not even talking games.

browser caches are so small they're better used for buffer data and texture data than compilation results of text based shaders

If you want faster shader loading, then come up with an fast to validate IL with small effective size, to complement WGSL (which shouldn't exist in my humble opinion).

[mixtur]

browser caches are so small they're better used for buffer data and texture data than compilation results of text based shaders

I think the opaque-handler approach would introduce another type of storage with it's own size-limits.

Another idea is to make browser cryptographically sign the precompiled binary, and then only accept stuff with verified signature. (Don't know how big overhead would be in that case)