On 17 July 2012 01:57, Olivier Galibert <<a href="mailto:galibert@pobox.com" target="_blank">galibert@pobox.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Mon, Jul 16, 2012 at 08:43:17PM -0700, Paul Berry wrote: </div><div class="im">> 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. </div>Oh, I remember why I did that in the first place. All the front/back piglit tests only write the appropriate color slot and not the other one. The language is annoying: The following built-in vertex output variables are available, but deprecated. A particular one should be written to if any functionality in a corresponding fragment shader or fixed pipeline uses it or state derived from it. Otherwise, behavior is undefined. out vec4 gl_FrontColor; out vec4 gl_BackColor; out vec4 gl_FrontSecondaryColor; out vec4 gl_BackSecondaryColor; [...] One could argue that you don't "use" gl_FrontColor if all your polygons are back-facing. Dunno. Do you consider all of the twoside piglit tests buggy? We can fix *that*. OG. </blockquote></div> You have a good point about the piglit tests. It's weird that they don't set gl_FrontColor, but I can't bring myself to consider it a bug. Sigh, I was really hoping we could consider it undefined to write to gl_BackColor and not gl_FrontColor, but I guess it's reasonable for someone to expect that if they only write to gl_BackColor, and they only render backfacing polygons, they should get a sensible value in the fragment shader. If possible, I would still like to think of a way to address this situation that (a) doesn't require modifying both fragment shader back-ends and the SF program, and (b) helps all Mesa drivers, not just Intel Gen4-5. Especially because I suspect we may have bugs in Gen6-7 related to this situation. Would you be happy with one of the following two alternatives? 1. In the GLSL front-end, if we detect that a vertex shader writes to gl_BackColor but not gl_FrontColor, then automatically insert "gl_FrontColor = 0;" into the shader. This will guarantee that whenever gl_BackColor is written, gl_FrontColor is too. 2. In the function brw_compute_vue_map(), assign a VUE slot for VERT_RESULT_COL0 whenever *either* VERT_RESULT_COL0 or VERT_RESULT_BFC0 is used. This will guarantee that we always have a VUE slot available for front color, so we don't have to be as tricky in the FS and SF code. Note that alternative 2 leaves the contents of gl_FrontColor undefined if the vertex shader doesn't write to it. Although I appreciate what you're saying about security leaks due to reads out of place, I think that in this case the security risk is negligible, since the garbage value that winds up in gl_FrontColor will just be a value out of some random register in the vertex shader, not a random value out of memory and not a value belonging to some other process. This morning I'll try to ask some other Intel folks for their opinion on the subject.