[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #19 from Timothy Arceri--- Ok here is a piglit test for the original GLSL IR bug: https://patchwork.freedesktop.org/patch/213332/ The NIR bug is a little harder to test reliably for since it depends on the order in which optimisations are called so I just going to leave it for now. Anyway this bug should now be fixed with the following commits: commit 56b867395dee1a48594b27987d3bf68a4e745dda Author: Timothy Arceri Date: Mon Mar 26 10:31:26 2018 +1100 glsl: fix infinite loop caused by bug in loop unrolling pass Just checking for 2 jumps is not enough to be sure we can do a complex loop unroll. We need to make sure we also have also found 2 loop terminators. Without this we were attempting to unroll a loop where the second jump was nested inside multiple ifs which loop analysis is unable to detect as a terminator. We ended up splicing out the first terminator but failed to actually unroll the loop, this resulted in the creation of a possible infinite loop. Fixes: 646621c66da9 "glsl: make loop unrolling more like the nir unrolling path" Tested-by: Gert Wollny Reviewed-by: Ian Romanick Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105670 commit 629ee690addad9b3dc8f68cfff5ae09858f31caf Author: Timothy Arceri Date: Mon Mar 26 11:41:51 2018 +1100 nir: fix crash in loop unroll corner case When an if nesting inside anouther if is optimised away we can end up with a loop terminator and following block that looks like this: if ssa_596 { block block_5: /* preds: block_4 */ vec1 32 ssa_601 = load_const (0x /* -nan */) break /* succs: block_8 */ } else { block block_6: /* preds: block_4 */ /* succs: block_7 */ } block block_7: /* preds: block_6 */ vec1 32 ssa_602 = phi block_6: ssa_552 vec1 32 ssa_603 = phi block_6: ssa_553 vec1 32 ssa_604 = iadd ssa_551, ssa_66 The problem is the phis. Loop unrolling expects the last block in the loop to be empty once we splice the instructions in the last block into the continue branch. The problem is we cant move phis so here we lower the phis to regs when preparing the loop for unrolling. As it could be possible to have multiple additional blocks/ifs following the terminator we just convert all phis at the top level of the loop body for simplicity. We also add some comments to loop_prepare_for_unroll() while we are here. Fixes: 51daccb289eb "nir: add a loop unrolling pass" Reviewed-by: Jason Ekstrand Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105670 -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 i...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from i...@yahoo.com --- Both fixes has been committed to git master, so I can close this bug. https://cgit.freedesktop.org/mesa/mesa/commit/?id=56b867395dee1a48594b27987d3bf68a4e745dda https://cgit.freedesktop.org/mesa/mesa/commit/?id=629ee690addad9b3dc8f68cfff5ae09858f31caf (In reply to Timothy Arceri from comment #17) > We still need to create a piglit test for this but here is the fix for NIR > also: > Don't forget to do that. > It seems once the loop in unrolled NIR then optimises this whole shader down > to: > > vec4 32 ssa_0 = load_const (0x /* 0.00 */, 0x /* > 0.00 */, 0x /* 0.00 */, 0x /* 0.00 */) > intrinsic store_var (ssa_0) (ps_out) (15) /* wrmask=xyzw */ > /* succs: block_0 */ > block block_0: Is that correct? It doesn't look correct. Have you found more bugs that need fixing? -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #17 from Timothy Arceri--- We still need to create a piglit test for this but here is the fix for NIR also: https://patchwork.freedesktop.org/patch/212882/ It seems once the loop in unrolled NIR then optimises this whole shader down to: vec4 32 ssa_0 = load_const (0x /* 0.00 */, 0x /* 0.00 */, 0x /* 0.00 */, 0x /* 0.00 */) intrinsic store_var (ssa_0) (ps_out) (15) /* wrmask=xyzw */ /* succs: block_0 */ block block_0: -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #16 from i...@yahoo.com --- (In reply to Timothy Arceri from comment #15) > Here is a fix for drivers that use GLSL IR loop unrolling. I'm still looking > into NIR unrolling it seems there is a different bug in that pass. > > https://patchwork.freedesktop.org/patch/212881/ I can confirm that this patch fixes the bug for me. Thank you for reacting so quickly to it. Is NIR unrolling bug triggered by the same shader/trace? If so, I should not close this bug until it is fixed too. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #15 from Timothy Arceri--- Here is a fix for drivers that use GLSL IR loop unrolling. I'm still looking into NIR unrolling it seems there is a different bug in that pass. https://patchwork.freedesktop.org/patch/212881/ -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #14 from almos--- (In reply to Roland Scheidegger from comment #5) > (In reply to almos from comment #4) > > The problem is not loop unrolling. The problem is that userspace code can > > hang the GPU unrecoverably, and thus bringing down the entire system. > > > > BTW I can confirm this on Pitcairn with radeon drm in linux 4.15. > > There isn't much you can do about shaders not terminating (loop limiting in > llvmpipe is quite a hack, you could legitimately have a loop which has more > iterations). You can detect the stall and kill the process that sent the drawing command. > > But yes, gpu reset actually working reliably would be nice. I haven't really > seen it succeed lately neither (but it can happen...). It wouldn't be nice. It's essential. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #13 from Gert Wollny--- The GLSL spec says that "negative zeros are generated as dictated by IEEE" and that "==" returns the correct result, which I'd assume means (0.0 == -0.0) is true. In any case, I don't see how this is relevant for this bug. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #12 from i...@yahoo.com --- (In reply to Gert Wollny from comment #11) > The if statement can be be true because > which means at this point R3.w can be zero. But that's the point in my initial question. When R3.w=0.0, will "if(+0.0 != -0.0)" be true of false, because float points do have 2 different zeroes - positive and negative one, and both zero floats do have different binary representation aka +0.0 = 0x; -0.0 = 0x8000. My question is more of the lines: are shader float point operations always IEEE complaint, and is it guaranteed that (+0.0 == -0.0) is true for all their implementations. (For example, SSE float operations sometimes deviate from IEEE for speed reasons.) -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #11 from Gert Wollny--- The if statement can be be true because tmp0.w = (R3.w >= 0.0 ? abs(ps_lc18.w) : abs(ps_lc18.y)); with ps_lc18.y = -1 and ps_lc18.w = 0.0, and then R3.w = (tmp0.w); R3.w = (R5.w * R3.w); which means at this point R3.w can be zero. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #10 from i...@yahoo.com --- (In reply to Gert Wollny from comment #9) > Actually, > if (R3.w != -R3.w) > will never fail, because R3.w = R0.w = (ps_lc17.y) = 1.0; You are correct for the "if" with the "break". However my question still stands for the other "if (R3.w != -R3.w)" right before the "break" one. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #9 from Gert Wollny--- Actually, if (R3.w != -R3.w) will never fail, because R3.w = R0.w = (ps_lc17.y) = 1.0; The compiler should optimize this away, and in my attempts to create a piglit it always did so far. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #8 from i...@yahoo.com --- Created attachment 138335 --> https://bugs.freedesktop.org/attachment.cgi?id=138335=edit Fragment/Pixel Shader generated by Wine3.3, extracted from lookup of #55251 op in the trace. It's quite simple to use qapitrace to get all needed information. Just go to op#55251, right click and select "lookup", it would start `glretrace` and dump all information about current state, including the shaders, textures etc. On unrelated to this bug note, this condition looks really fishy to me: if (R3.w != -R3.w) break; Will this condition ever fail? If variables were two's complement integers, the above line would have been false if `R3.w==0` (or INT_MIN). However with float numbers we can have separate +0.0 and -0.0, just like we have +inf and -inf. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #7 from Gert Wollny--- I tried to create a piglit, but so far i failed. So here is a dumped down version of the loop contained in the relevant shader: const vec4 ps_lc21 = vec4(5.e-01, -5.e-01, 0.e+00, 0.e+00); const vec4 ps_lc20 = vec4(1.e+00, 3.92156886e-03, 1.53787005e-05, 2.0003e-01); const vec4 ps_lc19 = vec4(3.3013e-01, -1.7002e-01, 4.e+00, 1.0001e-01); const vec4 ps_lc18 = vec4(2.e+00, -1.e+00, 1.0005e-03, 0.e+00); const vec4 ps_lc17 = vec4(-5.e-01, 1.e+00, 2.e+00, -9.9978e-03); R0.w = (ps_lc17.y); for (tmpInt0 = 0; tmpInt0 < 4; tmpInt0++) { R6.xyz = ((R5.xyz * ps_lc20.www) + R6.xyz); R9.xyzw = (textureLod(ps_sampler4, R6.xy, R6.w).xyzw); R3.w = ((R9.w * ps_lc20.y) + R9.z); R5.w = ((R3.w * -ps_c[11].y) + ps_in[7].z); tmp0.w = (R5.w >= 0.0 ? abs(ps_lc18.w) : abs(ps_lc18.y)); R5.w = (tmp0.w); R3.w = ((R3.w * ps_c[11].y) + -R6.z); tmp0.w = (R3.w >= 0.0 ? abs(ps_lc18.w) : abs(ps_lc18.y)); R3.w = (tmp0.w); R3.w = (R5.w * R3.w); if (R3.w != -R3.w) { R8.xy = (R6.xy); R3.w = (R0.w); if (R3.w != -R3.w) break; } } the working TGSI looks like this: IMM[0] FLT32 {2.,-1., 1., 0.0010} IMM[1] FLT32 {0.3300,-0.1700,-0.,-1.} IMM[2] FLT32 { -0.5000, 0., 0.1000,-2.} IMM[3] FLT32 {1., 0.0039, 0.,-0.0100} IMM[4] FLT32 { -0.5000, 1.,-0.0100, 0.} IMM[5] FLT32 { -1., 0., 4., 0.5000} IMM[6] FLT32 {0.5000,-0.5000, 0.2000, 0.} IMM[7] INT32 {0, 4, 1, 0} ... 218 MOV TEMP[2].w, IMM[0]. 219 MOV TEMP[8].x, IMM[7]. 220: BGNLOOP 221: ISGE TEMP[13].x, TEMP[8]., IMM[7]. 222: UIF TEMP[13]. 223: BRK 224: ENDIF 225: MAD TEMP[14].xyz, TEMP[11].xyzz, IMM[6]., TEMP[14].xyzz 226: MOV TEMP[13].xy, TEMP[14].xyyy 227: MOV TEMP[13].w, TEMP[14]. 228: TXL TEMP[13], TEMP[13], SAMP[4], 2D 229: MOV TEMP[15], TEMP[13] 230: MAD TEMP[13].x, TEMP[13]., IMM[3]., TEMP[13]. 231: MAD TEMP[15].x, TEMP[13]., -CONST[0][11]., TEMP[1]. 232: FSGE TEMP[15].x, TEMP[15]., IMM[2]. 233: UIF TEMP[15]. 234: MOV TEMP[9].x, IMM[2]. 235: ELSE 236: MOV TEMP[9].x, IMM[0]. 237: ENDIF 238: MOV TEMP[11].w, TEMP[9]. 239: MAD TEMP[13].x, TEMP[13]., CONST[0][11]., -TEMP[14]. 240: FSGE TEMP[13].x, TEMP[13]., IMM[2]. 241: UIF TEMP[13]. 242: MOV TEMP[12].x, IMM[2]. 243: ELSE 244: MOV TEMP[12].x, IMM[0]. 245: ENDIF 246: MOV TEMP[6].w, TEMP[12]. 247: MUL TEMP[6].x, TEMP[9]., TEMP[12]. 248: MOV TEMP[7].w, TEMP[6]. 249: FSNE TEMP[6].x, TEMP[6]., -TEMP[6]. 250: UIF TEMP[6]. 251: MOV TEMP[4].xy, TEMP[14].xyxx 252: MOV TEMP[7].w, TEMP[2]. 253: FSNE TEMP[6].x, TEMP[2]., -TEMP[2]. 254: UIF TEMP[6]. 255: BRK 256: ENDIF 257: ENDIF 258: UADD TEMP[8].x, TEMP[8]., IMM[7]. 259: ENDLOOP -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #6 from Timothy Arceri--- (In reply to Gert Wollny from comment #2) > I can confirm this on Radeon 6870 HD. > > I was able to track the issue to the series beginning with > >ab23b759f24 glsl: don't drop instructions from unreachable >terminators continue branch > > The first time around I had a few difficulties get the correct patch, it > seems to be either 646621c66da9 or 7a7fb90af75. In any case, yes it is > related to loop unrolling. > > The original TGSI goes like > > BGNLOOP > ISGE TEMP[13].x, TEMP[8]., IMM[7]. > UIF TEMP[13]. > BRK > ENDIF > ... > ENDLOOP > > and with the series in question applied it is > > BGNLOOP > ISLT TEMP[13].x, TEMP[8]., IMM[7]. > UIF TEMP[13]. > ... > ENDI > ENDLOOP > > This UIF should have an else path with the BRK to resemble the original > code. > (There are more BRK statements in the LOOP but they are the same in both > versions. > > Regarding bisecting this, after a failure one usually must reboot the > system, otherwise the graphics card is in a bad state. But given the nature > of the bug one should also be able to reproduce the endless loop with > LIBGL_ALWAYS_SOFTWARE=1 thereby not clobbering the hardware. Thanks for tracking down the problem. Do you think you would be able to create a piglit test to reproduce the bug? Or failing that can you copy the full glsl loop an attach it to the bug so that I can attempt to recreate the issue in piglit. Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #5 from Roland Scheidegger--- (In reply to almos from comment #4) > The problem is not loop unrolling. The problem is that userspace code can > hang the GPU unrecoverably, and thus bringing down the entire system. > > BTW I can confirm this on Pitcairn with radeon drm in linux 4.15. There isn't much you can do about shaders not terminating (loop limiting in llvmpipe is quite a hack, you could legitimately have a loop which has more iterations). But yes, gpu reset actually working reliably would be nice. I haven't really seen it succeed lately neither (but it can happen...). I disagree that loop unrolling isn't a problem. Clearly there's two problems: - loop unrolling shouldn't turn perfectly fine loops into loops which don't terminate, this is what this bug is about. - gpu reset should work reliably -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #4 from almos--- The problem is not loop unrolling. The problem is that userspace code can hang the GPU unrecoverably, and thus bringing down the entire system. BTW I can confirm this on Pitcairn with radeon drm in linux 4.15. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #3 from Roland Scheidegger--- (In reply to Gert Wollny from comment #2) > Regarding bisecting this, after a failure one usually must reboot the > system, otherwise the graphics card is in a bad state. But given the nature > of the bug one should also be able to reproduce the endless loop with > LIBGL_ALWAYS_SOFTWARE=1 thereby not clobbering the hardware. Just to avoid any confusion, llvmpipe won't show an infinite loop, since it uses a loop limiter on all loops (might still take quite some time, though). But of course you can still see the bogus tgsi. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #2 from Gert Wollny--- I can confirm this on Radeon 6870 HD. I was able to track the issue to the series beginning with ab23b759f24 glsl: don't drop instructions from unreachable terminators continue branch The first time around I had a few difficulties get the correct patch, it seems to be either 646621c66da9 or 7a7fb90af75. In any case, yes it is related to loop unrolling. The original TGSI goes like BGNLOOP ISGE TEMP[13].x, TEMP[8]., IMM[7]. UIF TEMP[13]. BRK ENDIF ... ENDLOOP and with the series in question applied it is BGNLOOP ISLT TEMP[13].x, TEMP[8]., IMM[7]. UIF TEMP[13]. ... ENDI ENDLOOP This UIF should have an else path with the BRK to resemble the original code. (There are more BRK statements in the LOOP but they are the same in both versions. Regarding bisecting this, after a failure one usually must reboot the system, otherwise the graphics card is in a bad state. But given the nature of the bug one should also be able to reproduce the endless loop with LIBGL_ALWAYS_SOFTWARE=1 thereby not clobbering the hardware. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 --- Comment #1 from Tapani Pälli--- Could be related to loop unrolling (?) While playing back trace on i965 I saw this: --- 8< --- glretrace: ../src/compiler/nir/nir_opt_loop_unroll.c:414: complex_unroll: Assertion `unroll_loc->type == nir_cf_node_block && exec_list_is_empty(_cf_node_as_block(unroll_loc)->instr_list)' failed. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105670] [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later
https://bugs.freedesktop.org/show_bug.cgi?id=105670 Bug ID: 105670 Summary: [regression][hang] Trine1EE hangs GPU after loading screen on Mesa3D-17.3 and later Product: Mesa Version: 17.3 Hardware: Other OS: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: glsl-compiler Assignee: mesa-dev@lists.freedesktop.org Reporter: i...@yahoo.com QA Contact: intel-3d-b...@lists.freedesktop.org The game is Trine1 Enchanted Edition, running under Wine-3.3. The game works fine with Mesa-17.2.0, but with Mesa-17.3.0 hangs right after the loading screen. The hang is soft, the driver tries to reset itself each 10 seconds and turns off my monitor. I am able to switch to text console (kms one) and kill the Xorg server, then reboot the machine. The kernel driver refuses to accept any new commands. Using software render I was able to capture a small apitrace (90MB compressed) that successfully reproduces the issue. It could be found here: https://drive.google.com/open?id=1RNKExfdBXUCN7SIhcrdiMwsvwIoCVMTg By using the qapitrace lookup, I managed to locate the exact operation that hangs. Not surprising, it is a draw operation: #55251 - works #55252 - hangs I tried to git bisect between 17.2.0 and 17.3.0, but I only managed to narrow it down to few steps: git bisect good 375c4868efa3cf549699557989c8f5c08c0710f0 git bisect bad 09f6bd5ef27c1b16b1468441b070b60c2d57523d The rest of my bisect log is full of skips, because I cannot find a commit that would work at all. All of them fail to run even `glxgears`, some crash, other give asserts in R600 code, in xmlconfig etc... My hardware is AMD Radeon HD5670 Redwood Evergreen (R600 driver). Using "R600_DEBUG=nosb" does not workaround the issue. Also the bug is reproducible on AMD RX480, running latest mesa3d master, llvm-svn 7.0.0svn_r328112 and experimental kernel. -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev