Commen=
t # 34
on bug 86720<=
/a>
from iive@yahoo.com
Created attachment 125183<=
/a> [details]
EU4 shader #175 in TGSI , unoptmized disassembly, sbdump of all stages and
optimized disassembly
While the committed workaround does work for this case, the bug in R600 Sha=
der
Backend is not fixed and it is triggered by other more complicated shaders.=
For
example:
https://bugs.freedesktop.org/show_bug.c=
gi?id=3D94900
I had locally reverted the unroll workaround in order to obtain the form th=
at
triggers this bug. If you need to test the bug with this shader, then in
`r600_pipe.c:559` you have to set `PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HI=
NT`
to 32, instead of 255.
The buggy shader is the vertex shader of call 1024042 in the trace.
When using `R600_DEBUG=3Dps,vs`, the shader is under #175 .
Like in the other bugreport, this shader causes assertion failure in the
sb_checker (if mesa is compiled with debugging) and the bug is also
workarounded by `R600_DEBUG=3Dsbsafemath`.
This works because it disables the call to `fold_assoc()` in
`expr_handler::fold_alu_op2()` somewhere around `sb_expr.cpp:740`
In order to locate the bug, I've enabled the sbdump for all SB stages.
I'm also uploading a second log, with the "fold_assoc()" disabled=
, so a
side-by-side comparison of both logs could indicate how the function affects
the result through the different stages. (I recommend `diffuse` program.)
This shader is easier to analyze, because it contains just one loop with 4
iterations and no other conditional branches and jumps. The loop counter
register is used as index for memory access. The memory address calculations
might be involved in triggering the bug as `fold_assoc()` works on them.
The `sb_checker` complains about instructions that list the counter registe=
r,
so it is possible that the instruction that increments it is somehow
"optimized" out.