Bugzilla – Bug 32395
[glsl] Incorrect code generation for shadow2DProj() with bias
Last modified: 2011-04-11 19:14:00 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.w, CONST.xxxx;
1: (assign (constant bool (1)) (xyz) (var_ref vec_ctor@0x949390) (swiz xyy (var_ref texcoords@0xa2d390) ))
MOV TEMP.xyz, INPUT.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, TEMP.xyyy;
3: RCP TEMP.w, CONST.xxxx;
4: MUL TEMP.xyz, TEMP, TEMP.wwww;
5: MOV TEMP.z, TEMP.zzzz;
Here, instruction 5 is overwriting TEMP.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.w, CONST.yyyy;
7: TXB TEMP, TEMP, texture, 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, TEMP;
Fixed on master.
Author: Ian Romanick <email@example.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 <firstname.lastname@example.org>
Verified fixed in master (tested with softpipe, llvmpipe, swrast).
Were you going to cherry-pick this to 7.10?
Fixed in 7.10 by f890661.