Bug 32395 - [glsl] Incorrect code generation for shadow2DProj() with bias
Summary: [glsl] Incorrect code generation for shadow2DProj() with bias
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: 7.10
Hardware: All All
: medium normal
Assignee: Ian Romanick
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-14 09:36 UTC by Brian Paul
Modified: 2011-04-11 19:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Brian Paul 2010-12-14 09:36:54 UTC
The piglit glsl-fs-shadow2dproj-bias.shader_test uses the following texture function:

 	gl_FragColor = shadow2DProj(tex, vec4(texcoords.xyy, 2.0), 1.0);

Note that 3rd component of the texture coordinate is the depth value which will be compared to the texture sample.  According to the GL spec, is must be divided by the W component (2.0 in this case) just like the S, T coords.

The generated code does this, but the 3rd component gets clobbered by an errant MOV instruction (at line 5):

  0: (assign (constant bool (1)) (w) (var_ref vec_ctor@0x949390)  (constant float (2.000000)) ) 
     MOV TEMP[1].w, CONST[1].xxxx;
  1: (assign (constant bool (1)) (xyz) (var_ref vec_ctor@0x949390)  (swiz xyy (var_ref texcoords@0xa2d390) )) 
     MOV TEMP[1].xyz, INPUT[14].xyyx;
  2: (txb (var_ref tex@0xb37b00)  (swiz xy (var_ref vec_ctor@0x949390) ) (0 0 0) (constant float (2.000000))  (swiz z (var_ref vec_ctor@0x949390) ) (constant float (1.000000)) )
     MOV TEMP[2], TEMP[1].xyyy;
  3: RCP TEMP[2].w, CONST[1].xxxx;
  4: MUL TEMP[2].xyz, TEMP[2], TEMP[2].wwww;
  5: MOV TEMP[2].z, TEMP[1].zzzz;

Here, instruction 5 is overwriting TEMP[2].z.  We want to keep the .z value that resulted from instruction 4. I don't know where the MOV instruction is coming from.


  6: MOV TEMP[2].w, CONST[1].yyyy;
  7: TXB TEMP[3], TEMP[2], texture[0], 2D SHADOW;
  8: (assign (constant bool (1)) (xyzw) (var_ref gl_FragColor@0xa2cf10)  (txb (var_ref tex@0xb37b00)  (swiz xy (var_ref vec_ctor@0x949390) ) (0 0 0) (constant float (2.000000))  (swiz z (var_ref vec_ctor@0x949390) ) (constant float (1.000000)) )) 
     MOV OUTPUT[2], TEMP[3];
  9: END
Comment 1 Ian Romanick 2011-04-05 11:31:24 UTC
Fixed on master.

commit 9996a86085edb2bdbcb165d985203ee8ce6a9b22
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Apr 4 13:35:26 2011 -0700

    ir_to_mesa: Handle shadow compare w/projection and LOD bias correctly
    
    The code would previously handle the projection, then swizzle the
    shadow comparitor into place.  However, when the projection is done
    "by hand," as in the TXB case, the unprojected shadow comparitor would
    over-write the projected shadow comparitor.
    
    Shadow comparison with projection and LOD is an extremely rare case in
    real application code, so it shouldn't matter that we don't handle
    that case with the greatest efficiency.
    
    NOTE: This is a candidate for the stable branches.
    
    Reviewed-by: Brian Paul <brianp@vmware.com>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=32395
Comment 2 Brian Paul 2011-04-05 16:33:05 UTC
Verified fixed in master (tested with softpipe, llvmpipe, swrast).
Were you going to cherry-pick this to 7.10?
Comment 3 Ian Romanick 2011-04-11 19:14:00 UTC
Fixed in 7.10 by f890661.


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.