wgsl-bindgen
🚀 Generate typesafe Rust bindings from WGSL shaders for wgpu
wgsl_bindgen transforms your WGSL shader development workflow by automatically generating Rust types, constants, and boilerplate code that perfectly match your shaders. Powered by naga-oil, it integrates seamlessly into your build process to catch shader-related errors at compile time rather than runtime.
🎯 Why wgsl_bindgen?
Before: Manual, error-prone shader bindings
// ❌ Easy to make mistakes - no compile-time verification
let bind_group = device.create_bind_group;
After: Typesafe, auto-generated bindings
// ✅ Compile-time safety - generated from your actual shaders
let bind_group = from_bindings;
bind_group.set; // Simple, safe usage
✨ Key Benefits
- 🛡️ Type Safety: Catch shader binding mismatches at compile time
- 🔄 Automatic Sync: Changes to WGSL automatically update Rust bindings
- 📝 Reduced Boilerplate: Generate tedious wgpu setup code automatically
- 🎮 Shader-First Workflow: Design in WGSL, get Rust bindings for free
- 🔧 Flexible: Works with bytemuck, encase, serde, and custom types
- ⚡ Fast: Build-time generation with intelligent caching
Features
General:
- Generates either new or enum-like short constructors to ease creating the generated types, especially ones that require to be padded when using with bytemuck.
- More strongly typed bind group and bindings initialization
- Generate your own binding entries for non-wgpu types. This is a work in progress feature to target other non-wgpu frameworks.
Shader Handling:
-
Supports import syntax and many more features from naga oil flavour.
-
Add shader defines dynamically when using either
WgslShaderSourceType::EmbedWithNagaOilComposerorWgslShaderSourceType::HardCodedFilePathWithNagaOilComposersource output type.The
WgslShaderSourceType::HardCodedFilePathWithNagaOilComposercould be used for hot reloading. -
Shader registry utility to dynamically call
create_shadervariants depending on the variant. This is useful when trying to keep cache of entry to shader modules. Also remember to add shader defines to accomodate for different permutation of the shader modules. -
Ability to add additional scan directories for shader imports when defining the workflow.
Type Handling:
- BYO - Bring Your Own Types for Wgsl matrix, vector types. Bindgen will automatically include assertions to test alignment and sizes for your types at compile time.
- Override generated struct types either entirely or just particular field of struct from your crate, which is handy for small primitive types. You can also use this to overcome the limitation of uniform buffer type restrictions in wgsl.
- Rust structs for vertex, storage, and uniform buffers.
- Either use encase or bytemuck derives, and optionally serde for generated structs.
- Const validation of WGSL memory layout for provided vector and matrix types and generated structs when using bytemuck
- Override the alignment for the struct generated. This also affects the size of the struct generated.
🚀 Quick Start
1. Add to your Cargo.toml
[]
= "0.19"
[]
= "25"
= { = "1.0", = ["derive"] }
# Optional: for additional features
# encase = "0.8"
# serde = { version = "1.0", features = ["derive"] }
2. Create your WGSL shader (shaders/my_shader.wgsl)
struct Uniforms {
transform: mat4x4<f32>,
time: f32,
}
struct VertexInput {
@location(0) position: vec3<f32>,
@location(1) uv: vec2<f32>,
}
struct VertexOutput {
@builtin(position) clip_position: vec4<f32>,
@location(0) uv: vec2<f32>,
}
@group(0) @binding(0) var<uniform> uniforms: Uniforms;
@group(0) @binding(1) var my_texture: texture_2d<f32>;
@group(0) @binding(2) var my_sampler: sampler;
@vertex
fn vs_main(input: VertexInput) -> VertexOutput {
var output: VertexOutput;
output.clip_position = uniforms.transform * vec4<f32>(input.position, 1.0);
output.uv = input.uv;
return output;
}
@fragment
fn fs_main(input: VertexOutput) -> @location(0) vec4<f32> {
return textureSample(my_texture, my_sampler, input.uv);
}
3. Set up build script (build.rs)
use ;
4. Use the generated bindings
// Include the generated bindings
use my_shader;
🎉 That's it! Your shader bindings are now fully type-safe and will automatically update when you modify your WGSL files.
📚 See the example project for a complete working demo with multiple shaders, including advanced features like texture arrays and overlay rendering.
🔧 Advanced Configuration
Serialization Strategies
Choose how your WGSL types are serialized to Rust:
// For zero-copy, compile-time verified layouts (recommended)
.serialization_strategy
// For runtime padding/alignment handling
.serialization_strategy
Type Mapping
Use your preferred math library:
// glam (recommended for games)
.type_map
// nalgebra (recommended for scientific computing)
.type_map
// Use built-in Rust arrays (no external dependencies)
.type_map
Custom Types
Override specific types or structs:
.override_struct_field_type
.add_override_struct_mapping
Shader Source Options
Control how shaders are embedded:
// Embed shader source directly (recommended for most cases)
.shader_source_type
// Use file paths for hot-reloading during development
.shader_source_type
// Use naga-oil composer for advanced import features
.shader_source_type
Wgsl Import Resolution
wgsl_bindgen uses a specific strategy to resolve the import paths in your WGSL source code. This process is handled by the ModulePathResolver::generate_possible_paths function.
Consider the following directory structure:
/my_project
├── src
│ ├── shaders
│ │ ├── main.wgsl
│ │ ├── utils
│ │ │ ├── math.wgsl
│ ├── main.rs
├── Cargo.toml
And the following import statement in main.wgsl:
import utils::math;
Here's how wgsl_bindgen resolves the import path:
- The function first checks if the import module name (
utils::math) starts with the module prefix. If a module prefix is set and matches, it removes the prefix and treats the rest of the import module name as a relative path from the entry source directory converting the double semicolor::to forward slash/from the directory of the current source file (src/shaders). - If the import module name does not start with the module prefix, it treats the entire import module name as a relative path from the directory of the current source file. In this case, it will look for
utils/math.wgslin the same directory asmain.wgsl. - The function then returns a set of possible import paths. The actual file that the import statement refers to is the first file in this set that exists. In this case, it would successfully find and import
src/shaders/utils/math.wgsl. - If not, the second possible path it would have tried would be
src/shaders/utils.wgsltreatingmathas an item withinutils.wgslhad it existed.
This strategy allows wgsl_bindgen to handle a variety of import statement formats and directory structures, providing flexibility in how you organize your WGSL source files.
Memory Layout
WGSL structs have different memory layout requirements than Rust structs or standard layout algorithms like repr(C) or repr(packed). Matching the expected layout to share data between the CPU and GPU can be tedious and error prone. wgsl_bindgen offers options to add derives for encase to handle padding and alignment at runtime or bytemuck for enforcing padding and alignment at compile time.
When deriving bytemuck, wgsl_bindgen will use naga's layout calculations to add const assertions to ensure that all fields of host-shareable types (structs for uniform and storage buffers) have the correct offset, size, and alignment expected by WGSL.
Bind Groups
wgpu uses resource bindings organized into bind groups to define global shader resources like textures and buffers. Shaders can have many resource bindings organized into up to 4 bind groups. wgsl_bindgen will generate types and functions for initializing and setting these bind groups in a more typesafe way. Adding, removing, or changing bind groups in the WGSl shader will typically result in a compile error instead of a runtime error when compiling the code without updating the code for creating or using these bind groups.
While bind groups can easily be set all at once using the set_bind_groups function, it's recommended to organize bindings into bindgroups based on their update frequency. Bind group 0 will change the least frequently like per frame resources with bind group 3 changing most frequently like per draw resources. Bind groups can be set individually using their set(render_pass) method. This can provide a small performance improvement for scenes with many draw calls. See descriptor table frequency (DX12) and descriptor set frequency (Vulkan) for details.
Organizing bind groups in this way can also help to better organize rendering resources in application code instead of redundantly storing all resources with each object. The BindGroup0 may only need to be stored once while WgpuBindGroup3 may be stored for each mesh in the scene. Note that bind groups store references to their underlying resource bindings, so it is not necessary to recreate a bind group if the only the uniform or storage buffer contents change. Avoid creating new bind groups during rendering if possible for best performance.
🔍 Best Practices
Performance Tips
-
Organize bind groups by update frequency:
// Bind group 0: Per-frame data (transforms, time) // Bind group 1: Per-material data (textures, material properties) // Bind group 2: Per-object data (model matrices, instance data) -
Use RenderBundles for static geometry:
let render_bundle = device.create_render_bundle_encoder; bind_group.set; render_bundle.draw; let bundle = render_bundle.finish; -
Prefer bytemuck for zero-copy performance:
.serialization_strategy
Development Workflow
- Start with your WGSL shaders - design your rendering pipeline in the shader language
- Configure wgsl_bindgen - set up your build script with appropriate options
- Use generated types - let the compiler guide you to correct usage
- Iterate safely - modify shaders and let Rust catch any breaking changes
Common Patterns
// Generated structs work seamlessly with wgpu
let vertices = vec!;
// Update uniforms safely with type checking
let uniforms = new;
queue.write_buffer;
⚠️ Current Limitations
- Some advanced WGSL features may not be fully supported yet - please file an issue for missing features
- Vertex attributes currently assume standard float types rather than normalized integer formats
- All textures are assumed to be filterable (can be resolved with
TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES) - Generated code prioritizes safety and convenience over maximum performance (you can optimize specific hotspots manually when needed)
🤝 Contributing
We welcome contributions! Please see our contribution guidelines for details on:
- Reporting bugs and requesting features
- Setting up the development environment
- Running tests and adding new test cases
- Code style and documentation standards
📄 License
This project is licensed under the MIT License - see the LICENSE file for details.
🙏 Acknowledgments
- naga-oil - WGSL import system and preprocessing
- wgpu - WebGPU implementation for Rust
- naga - Shader translation and validation
- wgsl_to_wgpu - Original inspiration
- The WebGPU working group for the WGSL specification
Differences from the wgsl_to_wgpu fork.
- Supports WGSL import syntax and many more features from naga oil flavour.
- You can only choose either bytemuck or encase for serialization
- Bytemuck mode supports Runtime-Sized-Array as generic const array in rust.
- Bytemuck mode correctly adds padding for mat3x3, vec3, whereas original would fail at compile assertions. (The fork was mostly born out of reason to use bytemuck and ensure it works in all cases instead of refusing certain types.)
- User can provide their own wgsl type mappings using
quotelibrary - Expect small api surface breaking change.
Publishing Crates
The provided example project outputs the generated bindings to the src/ directory for documentation purposes.
This approach is also fine for applications. Published crates should follow the recommendations for build scripts in the Cargo Book.
use ;
use ;
// src/build.rs
The generated code will need to be included in one of the normal source files. This includes adding any nested modules as needed.
// src/lib.rs