[Mesa-dev] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux