<div dir="ltr">On 15 July 2013 15:50, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_extra"><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 07/12/2013 06:25 PM, Paul Berry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When the core profile is active, there is no fixed function fragment<br>
shader functionality.  However, we still need to generate a dummy<br>
fragment shader program in case the back-end expects it (e.g. to cover<br>
the case where GL_RASTERIZER_DISCARD is active and the client hasn't<br>
supplied a fragment shader).<br>
<br>
This patch makes the dummy fragment shader program do nothing when the<br>
core profile is active.  This will prevent breakages in later patches,<br>
when we stop exposing compatibility-only builtin variables in the core<br>
profile.<br>
</blockquote>
<br></div>
Does this have potential interactions with meta?</blockquote><div><br></div><div>Shoot, I bet it does.  That's a problem.<br><br>In addition, you and Chad brought up some other points in person yesterday, specifically regarding the questions:<br>
<br>(a) In a core context, is it legal to compile a GLSL 1.30 shader that tries to use compatibility-only features like gl_FrontColor or ftransform()?<br>(b) If so, are the results of running that shader well-defined?<br>
<br></div><div>Currently in Mesa, the answer to (a) is "yes", and the answer to (b) is "probably" (while coding, we have assumed that since we don't support compatibility contexts or the ARB_compatibility extension, so we haven't thought too carefully about the interaction between OpenGL 3.1+ and compatibility-only features; so there may well be bugs).  My patches would make the answer to (a) "no" (and then of course (b) becomes irrelevant).<br>
<br>IIRC, you thought that the spec definitively answered (a) with "yes" and (b) with "no" (which would make current Mesa behaviour correct), but we weren't able to find any text to back that up.<br>
<br>There were also some concerns that if if the Nvidia or AMD proprietary drivers answer either (a) or (b) with "yes", then Mesa may need to as well, to avoid breaking apps.  We haven't done any checking to see what those drivers do.<br>
<br></div><div>I don't think I have time to follow up on these questions right now--I'm too behind on geometry shaders.  So unless someone else wants to pick up the thread, I'll just archive the patches in a branch in the hopes that we'll have times to address them later.<br>
</div></div></div></div>