Position: Directly ingest SPIR-V, and not a human-writable shading language about gpuweb HOT 5 CLOSED

Not ingesting SPIR-V by default will make the web slower, one of the most painful parts of video-game development is the shader compilation

We actually have to kickoff compilation in multiple threads and how the CPU for a number of seconds to get all of the shaders in the scene to compile and optimize.

Some platforms (Mali) didn't use to do optimization to save on load times and power-usage, that ended up with sub-optimal framerates and mobile developers such as Aras P. had to write their own optimizers to make sure that the shipped shaders actually received optimization on mobile!

from gpuweb.

Today I saw a warning on the OpenGL wiki:

Warning: Implementations sometimes get the std140 layout wrong for vec3 components. You are advised to manually pad your structures/arrays out and avoid using vec3 at all.

which made me think of another way in which SPIR-V is more simply specified: SPIR-V has no such concept as memory layout algorithms (std140/std430) - the offsets are explicitly specified for every member (OpMemberDecorate _ _ Offset _, etc.) The overlap rules are validatable offline (and are no more complex than the layout(offset=x) overlap rules in GLSL).

from gpuweb.

I think SPIR-V is the only formally specified binary shader language.

HLSL does not have a thorough and formal specification.

You will be open to less bugs and issues, especially security bugs when using a binary intermediate representation for which there are multiple compilers available including cross-compilers.

You need an AST CFG anyway to reason about a shader's security, frankly I think it would be far easier to transform a SPIR-V shader's AST CFG to prevent out-of-bounds reads and writes for robustness.

HLSL to SPIR-V compilation is currently badly broken ( by ShaderConductor, SPIRV-Cross does a better job), ask any graphics developer who's looked into it.

The WebGPU working group is expected to own specification, conformance, and development of HLSL or an evolution thereof.

Lawsuits anyone?

from gpuweb.

One thing we didn't really discuss above: we also think that the WebGPU group should bless HLSL and fully maintain a complete development path to enable development with HLSL. We will revise the document to express this more clearly.

from gpuweb.

Revision posted. Changes marked with [R2].

from gpuweb.