mesa: bff0d87668538196a2d3ef1400382e4deb0e0435 (master) $ ./bin/shader_runner tests/shaders/glsl-fs-frontfacing.shader_test -auto Probe color at (0,0) Expected: 0.000000 1.000000 0.000000 0.000000 Observed: 0.000000 0.501961 0.501961 0.000000 Probe color at (249,0) Expected: 0.000000 1.000000 0.000000 0.000000 Observed: 0.000000 0.501961 0.501961 0.000000 PIGLIT: {'result': 'fail' } 2d15f4746ba4c5d0146912550442b96386e4a32d is the first bad commit commit 2d15f4746ba4c5d0146912550442b96386e4a32d Author: Zack Rusin <zackr@vmware.com> Date: Fri Aug 2 15:50:16 2013 -0400 llvmpipe: make the front-face behavior match the gallium spec The spec says that front-face is true if the value is >0 and false if it's <0. To make sure that we follow the spec, lets just subtract 0.5 from our value (llvmpipe did 1 for frontface and 0 otherwise), which will get us a positive num for frontface and negative for backface. Signed-off-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> :040000 040000 2ada90b3a1da549c955add2ee247bf564f4964b8 f47d0cb938eee9fb413f71518c6afa1ad9fce5b9 M src bisect run success
Looks like the gallium docs and the "old" tgsi_semantic_face value don't quite agree with what glsl actually wants: The shader does this: void main() { gl_FragColor = vec4(0.0, float(gl_FrontFacing), 1.0 - float(gl_FrontFacing), 0.0); } And it gets translated to: FRAG PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1 DCL IN[0], FACE, CONSTANT DCL OUT[0], COLOR DCL TEMP[0] DCL TEMP[1..2], LOCAL IMM[0] FLT32 { 0.0000, 1.0000, 0.0000, 0.0000} 0: MOV_SAT TEMP[0], IN[0] 1: MOV TEMP[1].xw, IMM[0].xxxx 2: AND TEMP[2].x, TEMP[0].xxxx, IMM[0].yyyy 3: MOV TEMP[1].y, TEMP[2].xxxx 4: AND TEMP[2].x, TEMP[0].xxxx, IMM[0].yyyy 5: ADD TEMP[2].x, IMM[0].yyyy, -TEMP[2].xxxx 6: MOV TEMP[1].z, TEMP[2].xxxx 7: MOV OUT[0], TEMP[1] 8: END OUT[0].x = 0.000000 OUT[0].w = 0.000000 That is pretty strange but it looks like it would work (thanks to the mov_sat) if - backside value is 0.0 or smaller - frontside value is 1.0 or larger Might be best to go back and just generate 1.0 for front again to avoid trouble - -1.0 instead of 0.0 for back should be just fine. glsl translation is really relying on undocumented behavior here though, and the lax definition in gallium (saying it must be positive or negative) was intentional (matching old specs). Not sure though if things would work as well if that face would be used differently (i.e. as a bool/int).
mesa: fc25956badb8e1932cc19d8c97b4be16e92dfc65 (master 10.2.0-devel) glsl-fs-frontfacing is passing on llvmpipe now.
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.