webgpu-headers VS SPIRV-Tools

There's standardized C API which is both implemented by Dawn and wgpu.rs:

https://github.com/webgpu-native/webgpu-headers/blob/main/we...

...and this standardized API would also enable other independent native implementations.

There's even thought put into the API being extensible via 'struct chaining', this is how the native implementations also accept SPIRV shader bytecode instead of just WGSL shader source code.

The API definition exists:

https://github.com/webgpu-native/webgpu-headers/blob/main/we...

The next missing piece is a standard window system glue API for WASI though.

At first it was for only web, but browsers implement it using compiled code (C++/Rust) and you can use the implementation directly. Wgpu is for Firefox, Dawn is for Chrome. There is a C header for them: https://github.com/webgpu-native/webgpu-headers/blob/main/webgpu.h.

> Wgpu actually has C bindings to allow you to write C/C++ code with it, as well as use other languages that interface with C. That being said, wgpu is written in Rust, and it has some convenient Rust bindings that don't have to jump through any hoops. On top of that, I've been enjoying writing in Rust.

Why the bloat when this exist? https://github.com/webgpu-native/webgpu-headers

SPIR-V is an intermediate bytecode format. That bytecode is the data that you use in the Vulkan API, and under the hood your graphics drivers compile that bytecode into the device-specific native shader binary that runs on the graphics hardware.

Vulkan doesn't come with any tools to generate that bytecode though. Foreign shader language (like HLSL, GLSL, etc) to SPIR-V compilers exist, and various graphics toolchains can generate SPIR-V. https://github.com/KhronosGroup/SPIRV-Tools does have tools to validate and optimizing SPIR-V bytecode.

In that case, there is a linker in SPIR-V tools, though it doesn't use the syntax sugar for inlined functions like Metal3 does https://github.com/KhronosGroup/SPIRV-Tools, but again, that's kind of a higher level functionality

which is looking for https://github.com/KhronosGroup/SPIRV-Tools/releases/download/master-tot/SPIRV-Tools-master-osx-RelWithDebInfo.zip which yields a 404.

I would use SPIR-V Tools to disassemble the shader, and confirm that it's an issue in the on-disk shader binary. If you find that constant ID 9 on disk has size 4, then it's your shader loading that's going wrong; if it has size -1, then you need to look at why glslc has compiled your shader source with the wrong size.