[Mesa-dev] [PATCH 11/17] mesa: Get GL_MAX_VARYING_FLOATS_ARB from VertexProgram.MaxOutputComponents

[Paul Berry]

On 18 September 2013 13:04, Ian Romanick <idr at freedesktop.org> wrote:

> On 09/13/2013 01:45 PM, Paul Berry wrote:
> > On 11 September 2013 16:28, Ian Romanick <idr at freedesktop.org
> > <mailto:idr at freedesktop.org>> wrote:
> > Another question which we haven't really addressed is how Mesa's front
> > end linker should check these limits, given the fact that some
> > implementations have dedicated locations for certain shader
> > inputs/outputs.  I have a few ideas about this, but it's probably
> > something that we should save for a future patch series.
>
> Maybe the 39th time will be the charm. :(  The last time this came up
> was w.r.t. gl_Color and gl_SecondaryColor.  Most (all?) SM2 hardware
> (i915, r300, and probably others) have special slots that can be used
> for *clamped* fragment shader inputs.  So, gl_Color can use those slots
> if the API setting of CLAMP_VERTEX_COLOR is TRUE.  This control is added
> by the GL_ARB_color_buffer_float extension and OpenGL 3.0
>

So i915, r300, and others even support GL_ARB_color_buffer_float/GL3.0?

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 :)


>
> I think we need a flag for each special variable that says whether or
> not it is counted.  I think Marek implemented something like this for
> gl_Color.
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130918/a2910b60/attachment.html>