On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote:
Can you split this into three separate patches? That will make it easier
to troubleshoot in case we find bugs with these patches in the future.
I'm going to try.
Also, I'm not convinced that #3 is necessary. Is there something in the
spec that dictates this behaviour? My reading of the spec is that if the
vertex shader writes to gl_BackColor but not glFrontColor, then the
contents of gl_Color in the fragment shader is undefined.
Given the number of security issues/information leaks that happen due
to reads out of place, I'm always extremely wary of reads from
nowhere. So one pretty much has a choice between forcing a specific
value (like 0) or reading from someplace else that makes sense. In
that particular case I considered reading from the other color slot
the easy way out.
If we *do* decide that #3 is necessary, then I think a better way to
accomplish it is to handle it in the GLSL vertex shader front-end, by
replacing gl_BackColor with gl_FrontColor in cases where gl_FrontColor is
not written to. That way our special case code to handle this situation
would be in just one place, rather than in three places (both fragment
shader back-ends, and the SF program). Also then the fix would apply to
all hardware, not just Intel Gen4-5.
You'd have to switch off two-sided lighting too, but why not.
Finally, I couldn't figure out what you meant by the stray mov into
lalaland. Can you elaborate on which piece of code used to generate that
stray mov, and why it doesn't anymore? Thanks.
Looking at it again, I was wrong, it was protected.
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
