Open TobTobXX opened 2 years ago
Thanks for filing!
This is ultimately an issue on our end, as this is valid wgsl, but the HLSL compiler isn't happy with the output.
That being said the loop on line 209 indexes the vector out of bounds, it indexes it at 1, 2, 3, 4 and 4 isn't a in-bounds index into a vec4. If you were to keep those in bounds, it should compile.
Yes, it compiles now. Sorry for the inconvenience. I didn't catch it because I guess Vulkan just ignores it...
(at least now someone searching for it should find this ;) )
Could we get a reduced version of the test case here?
Here's the loop @cwfitzgerald called out at line 209:
for (var i = 1; i < 5; i=i+1) {
let this_dist = distance(cubic_bezier(curve, roots_n[i]), p);
// And accept any smaller distance
dist = min(dist, this_dist);
}
This could be a problem for us. roots_n[i]
is a dynamic access, and it's apparently only because the HLSL compiler is unrolling the loop that it recognizes that this expression will definitely perform an out-of-bounds access. We don't want to have to do this level of analysis in Naga.
If that's what's going on, then Naga may just have to accept that HLSL will reject shaders that we pass, because it analyzes them more thoroughly.
@TobTobXX Would you be able to put together a reduced version of the test case, based on the loop at line 209?
I think a simple example would be an explicit vector_4[4]
. I think this might be a limitation in DXBC or FXC where it doesn't allow non-constant indexing into vectors.
I think a simple example would be an explicit
vector_4[4]
. I think this might be a limitation in DXBC or FXC where it doesn't allow non-constant indexing into vectors.
We already detect this:
fn f(v: vec4<f32>) -> f32 {
return v[4];
}
That elicits:
error: Index 4 is out of bounds for expression [1]
Could not parse WGSL
But, for example, Naga validates this and I suspect the HLSL compiler will reject it:
fn f(v: vec4<f32>) -> f32 {
var sum: f32 = 0.0;
for (var i = 1; i <= 4; i = i + 1) {
sum = sum + v[i];
}
return sum;
}
Yes, as @jimblandy has guessed, this shader does work on Linux, but doesn't on Windows (tested):
let foo = vec4<f32>(0.1, 0.2, 0.3, -0.6);
[[stage(vertex)]]
fn vs_main(
[[builtin(vertex_index)]] in_vertex_index: u32,
) -> [[builtin(position)]] vec4<f32> {
let x = f32(1 - i32(in_vertex_index)) * 0.5;
let y = f32(i32(in_vertex_index & 1u) * 2 - 1) * 0.5;
return vec4<f32>(x, y, 0.0, 1.0);
}
[[stage(fragment)]]
fn fs_main() -> [[location(0)]] vec4<f32> {
var sum = 0.0;
// Note the off-by-one error
for (var i = 0; i < 5; i=i+1) {
sum = sum + foo[i];
}
return vec4<f32>(1.0, sum, 1.0, 1.0);
}
Unless @kvark has some clever way out for us, I think that leaves us at
If that's what's going on, then Naga may just have to accept that HLSL will reject shaders that we pass, because it analyzes them more thoroughly
This only seems to be an issue with FXC. DXC seems to compile it just fine. See https://shader-playground.timjones.io/70cb272b067ff17ae1ab1dc6ee12a513 I also found this related issue https://github.com/microsoft/DirectXShaderCompiler/issues/1879#issuecomment-463415562
I think a simple example would be an explicit
vector_4[4]
. I think this might be a limitation in DXBC or FXC where it doesn't allow non-constant indexing into vectors.We already detect this:
fn f(v: vec4<f32>) -> f32 { return v[4]; }
That elicits:
error: Index 4 is out of bounds for expression [1] Could not parse WGSL
@jimblandy according to the WGSL spec this should work though.
Implementing the OOB behavior above would fix the issue.
Implementing the OOB behavior above would fix the issue.
The OOB behavior is already implemented, actually. We're just being over-eager about detecting errors at compile time.
So, solving both gfx-rs/wgpu#4389 and gfx-rs/wgpu#4390 should hopefully fix this issue.
Hi there, I wrote this wgpu application on Linux (Wayland) and it worked just fine. Now that someone wanted to compile it on Windows, it doesn't work:
noisy log output
``` 2022-04-27T15:20:32.196Z WARN [wgpu_hal::dx12::instance] Unable to enable D3D12 debug interface: 0x887A002D 2022-04-27T15:20:32.197Z WARN [wgpu_hal::dx12::instance] Unable to enable DXGI debug interface: 0x887A002D 2022-04-27T15:21:29.310Z WARN [wgpu_hal::dx12::device] Naga generated shader for "fs_main" at Fragment: struct NagaConstants { int base_vertex; int base_instance; uint other; }; ConstantBufferHere's the important part (I think, line breaks and indentation mine):
This is the shader I used: shader.wgsl (pls don't laugh. I know these aglorithms can be done better, but I had to do it without copy-pasting.)
And this is a link to the project source. It's just standart
cargo run
, in case anyone wants to try: sources.tar.gz.Is there a way to work around this?