https://bugs.freedesktop.org/show_bug.cgi?id=67692
--- Comment #1 from Roland Scheidegger <srol...@vmware.com> ---
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).
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
