Bug 25579 - glsl compiled condition codes or temps seem wrong
Summary: glsl compiled condition codes or temps seem wrong
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-10 23:42 UTC by Andre Maasikas
Modified: 2009-12-11 08:45 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Andre Maasikas 2009-12-10 23:42:49 UTC
progs/vpglsl/vp-tris if.glsl has:

void main() {
    gl_FrontColor = gl_Color;
    gl_Position = gl_Vertex;
    if (gl_Position.x < 0.5)
        gl_FrontColor = vec4(1.0, 0.0, 0.0, 1.0);
}

This compiles to mesa_program:

# Vertex Program/Shader 3
  0: MOV OUTPUT[1], INPUT[3];
  1: MOV TEMP[0], INPUT[0];
  2: SLT.C TEMP[0].x, INPUT[0].xxxx, CONST[0].xxxx;
  3: IF (NE.xxxx); # (if false, goto 5);
  4:    MOV OUTPUT[1], CONST[1];
  5: ENDIF;
  6: MOV OUTPUT[0], TEMP[0];
  7: END

From what I understand TEMP[0].x is overwritten in 2: SLT.C
and this is then output as gl_position.x  - this is not what the shader
code above does.
Seems due to this it currently misrenders on r600 and also intel
also same thing with ifelse.glsl nestedifs.glsl ...
Comment 1 Brian Paul 2009-12-11 08:20:08 UTC
Fixed on the Mesa 7.6 branch with commit 5076a4f53a2f34cc9116b45951037f639885c7a1.

However, I think there's another bug related to this in Mesa 7.7 and later...
Comment 2 Brian Paul 2009-12-11 08:45:28 UTC
False alarm on the secondary bug.  The code was wrong (an extraneous loop in _mesa_remove_output_reads(), but the results were correct anyway.

Closing this bug.


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.