[Mesa-dev] [Intel-gfx] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.
Olivier Galibert
galibert at pobox.com
Tue Jul 17 01:33:52 PDT 2012
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.
More information about the mesa-dev
mailing list