[Mesa-dev] [PATCH] mesa: add const flags to skip MaxVarying and MaxUniform linker checks

[Ian Romanick]

On 12/10/2011 11:37 PM, Marek Olšák wrote:
> On Sat, Dec 10, 2011 at 8:19 PM, Ian Romanick<idr at freedesktop.org>  wrote:
>>
>> This may not be necessary in the short term.  I think r300 is
>> under-reporting it's capabilities.  See
>> https://bugs.freedesktop.org/show_bug.cgi?id=34201#c9
>
> The problem is st/mesa is under-reporting its capabilities, because
> when I was writing that code, I thought color varyings just don't
> belong to the max varying limit. The color varyings shouldn't be
> considered a generic varying resource (at least internally in Mesa),
> because there may have different precision. They don't have to be
> float when clamped, and they don't have to be exactly 32-bit float
> when not clamped (r300 is an example of such a behavior).

Before fairly recent versions of OpenGL, there was no requirement that 
varyings be full single-precision.  I didn't think that r300 used full 
single-precision for anything.  Like I mentioned in the bug report, 
other drivers for that hardware report 40 varying floats.

> I see this solution:
>
> We don't need exact GL limits in gl_constants, only the limits which
> make sense for drivers, like Gallium has. So we'd have something like
> MaxGenericVaryings and glGet*(GL_MAX_VARYING_FLOATS) would return
> MaxGenericVaryings*4+8. Then the linker wouldn't count the color
> varyings in the number of used varying components. How does it sound?

Hardware is increasingly moving towards not having "special" varyings. 
All of Intel's i965-class hardware works that way, and I'm pretty sure 
NVIDIA hardware is the same way.  It seems like not counting the colors 
leads to a cascade of special-cases in each driver.

Imagine the case where someone writes a shader that uses 40 float 
varying components for non-builtin varyings.  Then what? 
GL_MAX_VARYING_FLOATS said it was ok, but the linker sees a different 
limit.  Then what?  If the link fails (either from the linker or the 
driver), the app developer will (rightfully!) report a bug or rage quit.

Assuming that all hardware can do unclamped colors, it seems like 
counting them as generic varyings is the right choice.

If there is some hardware that can't do unclamped colors, they shouldn't 
include them in the generic varying count, and we'll have to put 
something special in to (not) count them.