-
Notifications
You must be signed in to change notification settings - Fork 909
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[naga] Permit only structs as binding array elements. #6333
[naga] Permit only structs as binding array elements. #6333
Conversation
Require `T` to be a struct in `binding_array<T, ...>`; do not permit arrays. In gfx-rs#5428, the validator was changed to accept binding array types that the SPIR-V backend couldn't properly emit. Specifically, the validator was changed to accept `binding_array<array<T>>`, but the SPIR-V backend wasn't changed to wrap the binding array elements in a SPIR-V struct type, as Vulkan requires. So the type would be accepted by the validator, and then rejected by the backend.
Document and refactor `naga::back::spv::BlockContext::write_runtime_array_length`. Don't try to handle finding the length of a particular element of a `binding_array<array<T>>`. The SPIR-V backend doesn't wrap that type correctly anyway; gfx-rs#6333 changes the validator to forbid such types. Instead, assume that the elements of a `binding_array<T>` are always structs whose final members may be a runtime-sized array. Pull out consistency checks after the analysis of the array expression, so that we always carry out all the checks regardless of what path we took to produce the information.
Document and refactor `naga::back::spv::BlockContext::write_runtime_array_length`. Don't try to handle finding the length of a particular element of a `binding_array<array<T>>`. The SPIR-V backend doesn't wrap that type correctly anyway; gfx-rs#6333 changes the validator to forbid such types. Instead, assume that the elements of a `binding_array<T>` are always structs whose final members may be a runtime-sized array. Pull out consistency checks after the analysis of the array expression, so that we always carry out all the checks regardless of what path we took to produce the information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
question: Are there plans in the future to relax this restriction, since the OP implies it's possible?
Wait, so can you no longer do |
Document and refactor `naga::back::spv::BlockContext::write_runtime_array_length`. Don't try to handle finding the length of a particular element of a `binding_array<array<T>>`. The SPIR-V backend doesn't wrap that type correctly anyway; gfx-rs#6333 changes the validator to forbid such types. Instead, assume that the elements of a `binding_array<T>` are always structs whose final members may be a runtime-sized array. Pull out consistency checks after the analysis of the array expression, so that we always carry out all the checks regardless of what path we took to produce the information.
Document and refactor `naga::back::spv::BlockContext::write_runtime_array_length`. Don't try to handle finding the length of a particular element of a `binding_array<array<T>>`. The SPIR-V backend doesn't wrap that type correctly anyway; gfx-rs#6333 changes the validator to forbid such types. Instead, assume that the elements of a `binding_array<T>` are always structs whose final members may be a runtime-sized array. Pull out consistency checks after the analysis of the array expression, so that we always carry out all the checks regardless of what path we took to produce the information.
Document and refactor `naga::back::spv::BlockContext::write_runtime_array_length`. Don't try to handle finding the length of a particular element of a `binding_array<array<T>>`. The SPIR-V backend doesn't wrap that type correctly anyway; gfx-rs#6333 changes the validator to forbid such types. Instead, assume that the elements of a `binding_array<T>` are always structs whose final members may be a runtime-sized array. Pull out consistency checks after the analysis of the array expression, so that we always carry out all the checks regardless of what path we took to produce the information.
@JMS55 wrote:
I'm confused. That has never worked: $ cat in.wgsl
@group(0) @binding(0)
var<storage> a: binding_array<array<u32>>;
fn f(i: i32, j: i32) -> u32 {
return a[i][j];
}
$ naga in.wgsl out.spv
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.11s
Running `/home/jimb/rust/wgpu/target/debug/naga in.wgsl out.spv`
$ spirv-val out.spv
error: line 16: Block decoration on target <id> '4[%_runtimearr_uint]' must be a structure type
OpDecorate %_runtimearr_uint Block
$ As the commit message and PR message explains, Naga fails to wrap the And this restriction is easy to work around: just put the runtime-sized array in a struct in the WGSL: $ cat fixed.wgsl
struct S {
arr: array<u32>,
}
@group(0) @binding(0)
var<storage> a: binding_array<S>;
fn f(i: i32, j: i32) -> u32 {
return a[i].arr[j];
}
$ naga fixed.wgsl fixed.spv
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.11s
Running `/home/jimb/rust/wgpu/target/debug/naga fixed.wgsl fixed.spv`
$ spirv-val fixed.spv
$ |
Oh I see, yeah wrapping it in a struct is what I was doing. Didn't realize that still worked, thanks! |
Document and refactor `naga::back::spv::BlockContext::write_runtime_array_length`. Don't try to handle finding the length of a particular element of a `binding_array<array<T>>`. The SPIR-V backend doesn't wrap that type correctly anyway; #6333 changes the validator to forbid such types. Instead, assume that the elements of a `binding_array<T>` are always structs whose final members may be a runtime-sized array. Pull out consistency checks after the analysis of the array expression, so that we always carry out all the checks regardless of what path we took to produce the information.
Require
T
to be a struct inbinding_array<T, ...>
; do not permit arrays.In #5428, the validator was changed to accept binding array types that the SPIR-V backend couldn't properly emit. Specifically, the validator was changed to accept
binding_array<array<T>>
, but the SPIR-V backend wasn't changed to wrap the binding array elements in a SPIR-V struct type, as Vulkan requires. So the type would be accepted by the validator, and then rejected by the backend.