From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Galibert Subject: Re: [Intel-gfx] [PATCH 1/5] intel gen4/5: fix GL_VERTEX_PROGRAM_TWO_SIDE. Date: Tue, 17 Jul 2012 10:33:52 +0200 Message-ID: <20120717083352.GA360@dspnet.fr> References: <1341082215-22933-1-git-send-email-galibert@pobox.com> <1341082215-22933-2-git-send-email-galibert@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mesa-dev-bounces+gcvmd-mesa3d-493=gmane.org@lists.freedesktop.org Errors-To: mesa-dev-bounces+gcvmd-mesa3d-493=gmane.org@lists.freedesktop.org To: Paul Berry Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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.