Bug 30416 - r300compiler: build_loop_info: expected conditional
Summary: r300compiler: build_loop_info: expected conditional
Status: RESOLVED DUPLICATE of bug 30415
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-28 02:42 UTC by Wiktor Janas
Modified: 2010-09-28 22:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Fix the compiler error (1.22 KB, patch)
2010-09-28 09:57 UTC, Tom Stellard
Details | Splinter Review

Description Wiktor Janas 2010-09-28 02:42:53 UTC
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.
Comment 1 Marek Olšák 2010-09-28 08:37:43 UTC
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.
Comment 2 Tom Stellard 2010-09-28 09:57:49 UTC
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.
Comment 3 Tom Stellard 2010-09-28 10:11:13 UTC
(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.
Comment 4 Marek Olšák 2010-09-28 10:18:18 UTC
(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?
Comment 5 Tom Stellard 2010-09-28 10:23:34 UTC
This shader uncovers a bug in the deadcode pass, so I'm reopening it.
Comment 6 Tom Stellard 2010-09-28 22:05:16 UTC
(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.
Comment 7 Tom Stellard 2010-09-28 22:10:47 UTC
(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.