| name | wgsl-no-u16-u8-types |
| description | WGSL has no u16 or u8 types. Compact Rust structs with u16/u8 fields must NOT be mirrored with those types in WGSL — use u32 and pack/unpack manually, or fall back to f32. WGSL compilation panics with 'no definition in scope for identifier: u16' |
WGSL — no u16 or u8 types
WGSL does not have u16, u8, i16, or i8 types. The integer types are:
i32, u32, bool. The float types are: f32, f16 (requires enable f16;).
When Rust defines a compact struct with u16 or u8 fields (e.g. for
f16-packed storage buffers), do NOT create a matching WGSL struct with
those types. The shader compilation will panic:
Shader parsing error: no definition in scope for identifier: `u16`
Correct approaches:
-
Keep f32 in WGSL, use compact types only on the Rust side. The WGSL
struct continues to use f32 fields; the Rust side packs/unpacks f16
values into u16 fields. WGSL never sees the compact types.
-
Use enable f16; and WGSL f16 type. If the adapter supports
SHADER_F16, the WGSL struct can use f16 fields (2 bytes each).
The stride shrinks but f16 arithmetic is limited.
-
Pack into u32 manually. Store multiple u16 values in a single u32
field and unpack with bitwise operations in the shader.
The footgun: During the CellReservoirSlotF16 implementation, the WGSL
struct was written with target_pdf_f16: u16 and total_weight_f16: u16
because the Rust struct uses u16. WGSL rejected this. The fix was to
remove the F16 variant from all three WGSL files (cell_cull, cell_update,
stratum_probe_trace) and keep the Rust side only — the WGSL path continues
to use the f32 CellReservoirSlot until the compact storage path is
activated with proper enable f16; support.
Verification: If cargo build passes but the bench panics at shader
compilation with no definition in scope for identifier, search the WGSL
files for u8, u16, i8, or i16 in struct or variable declarations.
