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

[Marek Olšák]

I don't remember implementing anything in the GLSL linker for colors
not to be counted against the maximum varying count limit.

R500 supports GL_ARB_color_buffer_float, but not GL3.0. R300 and R500
have special slots for colors.

Marek

On Wed, Sep 18, 2013 at 10:30 PM, Paul Berry <stereotype441 at gmail.com> wrote:
> 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.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>