<div dir="ltr">On 18 September 2013 13:04, 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 09/13/2013 01:45 PM, Paul Berry wrote:<br>
> On 11 September 2013 16:28, Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a><br>
</div><div class="im">> <mailto:<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>>> wrote:<br>
> Another question which we haven't really addressed is how Mesa's front<br>
> end linker should check these limits, given the fact that some<br>
> implementations have dedicated locations for certain shader<br>
> inputs/outputs.  I have a few ideas about this, but it's probably<br>
> something that we should save for a future patch series.<br>
<br>
</div>Maybe the 39th time will be the charm. :(  The last time this came up<br>
was w.r.t. gl_Color and gl_SecondaryColor.  Most (all?) SM2 hardware<br>
(i915, r300, and probably others) have special slots that can be used<br>
for *clamped* fragment shader inputs.  So, gl_Color can use those slots<br>
if the API setting of CLAMP_VERTEX_COLOR is TRUE.  This control is added<br>
by the GL_ARB_color_buffer_float extension and OpenGL 3.0<br></blockquote><div><br></div><div>So i915, r300, and others even support GL_ARB_color_buffer_float/GL3.0?  <br></div><div><br>If so that's a bit of a difficult wrinkle because that means we can't determine at link time whether the shader will fit in the available slots.  Given that these older hardware models are frequently pretty tightly constrained on their number of varyings, and the fact that most apps probably leave vertex color clamping on, it's probably best to do the link error checking under the assumption that the special slots can be used.  Kind of lame since it means that a shader tha linked without error might not be guaranteed to execute correctly in all GL states, but I'm guessin for these older pieces of hardware that's the least of our worries :)<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think we need a flag for each special variable that says whether or<br>
not it is counted.  I think Marek implemented something like this for<br>
gl_Color.<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">Yeah, that seems reasonable.  I was thinking along similar lines.  We could have bitfields called something like ctx->Const.DedicatedFsInputs and ctx->Const.DedicatedVsOutputs.  The convention would be: set the bit if your hardware has a dedicated slot for the given input/output (and therefore it doesn't need to be counted).  That way a default value of 0 would correspond to the conservative assumption that there are no dedicated slots at all.<br>
</div></div>