| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | REOPENED |
| Assignee | dri-devel@lists.freedesktop.org | iive@yahoo.com |
| Resolution | FIXED | --- |
| CC | iive@yahoo.com |
Comment # 34
on bug 86720
from iive@yahoo.com
Created attachment 125183 [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 Shader Backend is not fixed and it is triggered by other more complicated shaders. For example: https://bugs.freedesktop.org/show_bug.cgi?id=94900 I had locally reverted the unroll workaround in order to obtain the form that 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_HINT` to 32, instead of 255. The buggy shader is the vertex shader of call 1024042 in the trace. When using `R600_DEBUG=ps,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=sbsafemath`. 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 register, so it is possible that the instruction that increments it is somehow "optimized" out.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
