Created attachment 108602 [details] log when the test fails Hi again guys. I've been getting some very weird piglit crashes, including one lockup, which I haven't yet been able to bisect. Anyway, here's one I've been able to bisect. The test spec/glsl-1.50/execution/geometry/max-input-components fails before commit 54de7099115502c561f5f51095e08dc0a52c71b7, and always crashes on commits after. I have attached the piglit result logs from both versions. I'm not sure if the LLVM Register Spilling spam is relating to my other problems, or not. Let me know if you need any more information. Thanks, sarnex
Created attachment 108603 [details] log when the test crashes
Created attachment 108612 [details] radeonsi: If compiling the vertex or geometry shader fails, skip the draw Does this patch fix the crash?
Created attachment 108624 [details] patch crash (In reply to Michel Dänzer from comment #2) > Created attachment 108612 [details] > radeonsi: If compiling the vertex or geometry shader fails, skip the draw > > Does this patch fix the crash? Hi Michel, Unfortunately, it appears the patch has no effect. But, after updating my mesa to today's version, the test crashes very quickly, when it used to take over 3 minutes to fail or crash. Maybe this is related to the other llvm change? I attached a log. Thanks, sarnex
Can you run the test in gdb and attach a backtrace? From the logs you attached, the command line for running the test on your system is: /usr/local/lib/piglit/bin/shader_runner /usr/local/bin/../lib/piglit/tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test -auto
Created attachment 108646 [details] backtrace (In reply to Michel Dänzer from comment #4) > Can you run the test in gdb and attach a backtrace? From the logs you > attached, the command line for running the test on your system is: > > /usr/local/lib/piglit/bin/shader_runner > /usr/local/bin/../lib/piglit/tests/spec/glsl-1.50/execution/geometry/max- > input-components.shader_test -auto Hi Michel, I compiled LLVM3.5 debug and Mesa debug, so hopefully there is enough information here. The backtrace is attached. Thanks, sarnex
(In reply to sarnex from comment #5) > I compiled LLVM3.5 debug and Mesa debug, so hopefully there is enough > information here. The backtrace is attached. That's a crash in LLVM. Does that also happen with Mesa commit 54de7099115502c561f5f51095e08dc0a52c71b7? If not, can you test my patch on top of that?
Created attachment 108669 [details] second bt (In reply to Michel Dänzer from comment #6) > (In reply to sarnex from comment #5) > > I compiled LLVM3.5 debug and Mesa debug, so hopefully there is enough > > information here. The backtrace is attached. > > That's a crash in LLVM. Does that also happen with Mesa commit > 54de7099115502c561f5f51095e08dc0a52c71b7? If not, can you test my patch on > top of that? Nope, it's a different crash. I incorrectly assumed it would be the same crash since on latest git vs the first commit where it crashes. Backtrace attached. Thanks and sorry for the confusion. Sarnex
(In reply to Michel Dänzer from comment #6) > (In reply to sarnex from comment #5) > > I compiled LLVM3.5 debug and Mesa debug, so hopefully there is enough > > information here. The backtrace is attached. > > That's a crash in LLVM. Does that also happen with Mesa commit > 54de7099115502c561f5f51095e08dc0a52c71b7? If not, can you test my patch on > top of that? Whoops, I forgot about your patch. It doesn't apply against commit 54de7099115502c561f5f51095e08dc0a52c71b7. If you get a chance could you update it, because I'd likely break everything trying to manually apply. Thanks again, sarnex
I think there are 2 ways to fix this and we should do both: 1) Fix VGPR register spilling caused by indirect addressing into lots of registers. LLVM crashes when it attempts to do that. Those registers are just copies of shader inputs and outputs. 2) Step A) Implement indirect addressing for VS outputs before GS and GS inputs. This means that we cannot store outputs at the end of shaders (using emit_epilogue), but we must store them when they occur as a destination register (using emit_store). (BTW my tessellation branch contains modifications to emit_store that make it easier to re-implement it for shaders that use store instructions for outputs) Step B) glsl_to_tgsi and/or some passes of the GLSL compiler may need to be modified not to move ins/outs into temporaries. I think the only pass that does that is the varying packing. The pass should be disabled or rewritten, because its current implementation isn't gonna fly with our hardware and is often the cause of unnecessary register spilling.
Quite old bug. Can no longer be reproduced with mesa-git (51dc5e3df38), llvm-git (6f7f2057b76) and piglit-git (9cc5b2169). Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.