Hacker News Reader

Comment by kvark | Hacker News Reader

The article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works.

For shading languages, it's not clear to me why GLSL-to-SPIRV would be so slow. Would be great to hear back from Google. Side note: we are currently experimenting [1] with Rust-based SPIR-V generation, and the transformation is looking to be mostly trivial - there is no reason it should be slow.

A bigger question though that needs to be resolved is how to specialize SPIR-V shaders. Without this, there is no good alternative to text-based cut-and-paste that the blog argues to be the best approach.

[1] https://github.com/jrmuizel/glsl-to-spirv

View on HN

> The article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works.

The first thing you read is: "WebGPU is a new API being developed by Apple and others in the W3C which enables high-performance 3D graphics and data-parallel computation on the Web."

right?! short of listing all the browsers and renders out there I think they did ok.

> it's not clear to me why GLSL-to-SPIRV would be so slow. Would be great to hear back from Google.

Off the top of my head:

- glslang supports all previous GLSL versions and profiles, which adds many checks and corner cases throughout the code

- it's tricky to generate correct SPIR-V; for instance, it took me a while to properly understand the constraints around basic-block ordering

Disclaimer: I left Google in 2016 and haven't looked at glslang/shaderc since. I am only offering personal opinions here.

> A bigger question though that needs to be resolved is how to specialize SPIR-V shaders.

Is the OpSpecConstant family not enough? Those exist specifically for specialisation.

Specialization constants don’t seem to cut it for all the use cases. There’s variation beyond plugging in constants. Also some frameworks and engines give their clients the ability to provide shader snippets at runtime.

The answer to shader snippets in the SPIR-V world would be linking. I don't think that's well developed in the ecosystem if at all, but it's a perfectly natural extension.

My main problem with SPIR-V specialization today is that it doesn't affect the shader interface. For WebGPU, we don't want to validate presence of resources that the user doesn't need, we don't want to allocate registers for them in our pipeline layouts, etc. I think having this ability is critical.

Reply on news.ycombinator.com