Compilation of the following fragment shader fails: uniform vec4 vecX, vecY; uniform int iter; void main() { for(;;) { bool b = (dot(gl_TexCoord[0], gl_TexCoord[0]) < 4.0); gl_FragColor.z = iter == 0 ? vecX.z - vecY.z : 15.0; if(b) break; gl_FragColor.x = 1.0; } } r300: Initial fragment program FRAG DCL IN[0], GENERIC[0], PERSPECTIVE DCL OUT[0], COLOR DCL CONST[0..2] DCL TEMP[0..2] IMM FLT32 { 4.0000, 0.0000, 15.0000, 1.0000} 0: BGNLOOP :16 1: DP4 TEMP[0].x, IN[0], IN[0] 2: SLT TEMP[1].x, TEMP[0].xxxx, IMM[0].xxxx 3: MOV TEMP[0].x, TEMP[1].xxxx 4: SEQ TEMP[1].x, CONST[0].xxxx, IMM[0].yyyy 5: IF TEMP[1].xxxx :8 6: ADD TEMP[1].x, CONST[2].zzzz, -CONST[1].zzzz 7: MOV TEMP[2].x, TEMP[1].xxxx 8: ELSE :10 9: MOV TEMP[2].x, IMM[0].zzzz 10: ENDIF 11: MOV OUT[0].z, TEMP[2].xxxx 12: IF TEMP[0].xxxx :14 13: BRK 14: ENDIF 15: MOV OUT[0].x, IMM[0].wwww 16: ENDLOOP :0 17: END Another example that fails is (maybe more common): uniform vec4 vecX, vecY; uniform int iter; void main() { for(;;) { gl_FragColor.z = vecX.z - vecY.z; if(dot(gl_TexCoord[0], gl_TexCoord[0]) < 4.0 && iter > 15) break; gl_FragColor.x = 1.0; } } r300: Initial fragment program FRAG DCL IN[0], GENERIC[0], PERSPECTIVE DCL OUT[0], COLOR DCL CONST[0..2] DCL TEMP[0..1] IMM FLT32 { 4.0000, 15.0000, 0.0000, 1.0000} 0: BGNLOOP :15 1: ADD TEMP[0].x, CONST[2].zzzz, -CONST[1].zzzz 2: MOV OUT[0].z, TEMP[0].xxxx 3: DP4 TEMP[0].x, IN[0], IN[0] 4: SLT TEMP[1].x, TEMP[0].xxxx, IMM[0].xxxx 5: IF TEMP[1].xxxx :8 6: SGT TEMP[0].x, CONST[0].xxxx, IMM[0].yyyy 7: MOV TEMP[1].x, TEMP[0].xxxx 8: ELSE :10 9: MOV TEMP[1].x, IMM[0].zzzz 10: ENDIF 11: IF TEMP[1].xxxx :13 12: BRK 13: ENDIF 14: MOV OUT[0].x, IMM[0].wwww 15: ENDLOOP :0 16: END The driver could cope with that by inserting something like CMP x, -x, 1, 0 before the IF.
Both shaders *should* fail to compile because you cannot say at compile time whether they will terminate or not. If a GPU gets stuck in an infinite loop, it's basically a hard lockup, and your monitor becomes unusable until you reset the machine. We can't allow that.
Created attachment 39022 [details] [review] Fix the compiler error This patch should fix the compiler error, but I'm seeing this shader render incorrectly, so this is still a bug.
(In reply to comment #1) > Both shaders *should* fail to compile because you cannot say at compile time > whether they will terminate or not. If a GPU gets stuck in an infinite loop, > it's basically a hard lockup, and your monitor becomes unusable until you reset > the machine. We can't allow that. It's not possible to have infinite loops, because the number of iterations is capped at 256.
(In reply to comment #3) > It's not possible to have infinite loops, because the number of iterations is > capped at 256. And what about jumps?
This shader uncovers a bug in the deadcode pass, so I'm reopening it.
(In reply to comment #4) > (In reply to comment #3) > > It's not possible to have infinite loops, because the number of iterations is > > capped at 256. > > And what about jumps? Jump instructions can be executed an infinite number of times, but the r300 compiler doesn't use them.
(In reply to comment #5) > This shader uncovers a bug in the deadcode pass, so I'm reopening it. It was actually a slight variation of this shader that was uncovering the bug in the deadcode pass. With the compiler error fixed this shader exhibits the same behavior as bug 30415. *** This bug has been marked as a duplicate of bug 30415 ***
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.