| Summary: | [glsl] Incorrect code generation for shadow2DProj() with bias | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Brian Paul <brianp> |
| Component: | glsl-compiler | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 7.10 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
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 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. |
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.
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