Open htrojan opened 2 years ago
This is likely a bug in naga (which wgpu uses for translating from glsl to spir-v). Did you try reproducing with just wgpu?
I'm not quite sure how to check that in pure wgpu without building too much stuff around it. What I tried is to use naga, let it parse the input and then output again as a fragment shader.
naga blur.frag output.frag
In the output, both for loops are present with variables i and j that are incremented within their respective loops. So I'm not quite sure what to make of that
Bevy version
0.8.1
[Optional] Relevant system information
What you did
Glsl fragment shaders ignore the outer loop when nesting for loops. Here is a minimal example of a nested for loop. What should have happened is, that the texture is averaged over a certain width. Instead only the height is averaged and the outer loop is completely ignored.
Interestingly, the code aboves seems to leave i=0 constant and does not iterate the outer loop at all, causing a constant shift of 4 pixels in x direction. Moreover, this code
causes a constant shift of 4 pixels in the opposite direction as the code above, while the y-direction averages correctly.
I do not know what module exactly is responsible for this, but I would assume something in the parsing of the GLSL shader is not working as expected.
Example output
This shows the first example. Only the y axis (the inner loop) is considered.
When using the second code example, all red rectangles gain a constant x offset Here the rectangle is not emitted from the sprite origin, but is offset to the right (the offset is 50 pixels, so more exaggerated than in the code fragment above)