[Mesa-dev] [PATCH] glsl: disable resource checking in the linker until it's done right

[Ian Romanick]

On 11/22/2011 06:47 AM, Jose Fonseca wrote:
> ----- Original Message -----
>> NAK with extreme prejudice.  Technically speaking, these are app
>> bugs.
>>
>> I absolutely will not disable all correct behavior to work around
>> broken
>> apps.  The problem is the following shaders will correctly link, but
>> completely explode:
>>
>> uniform float array[1234];
>> uniform int i;
>> void main() {
>>       gl_FragColor = vec4(array[769] + array[i]);
>> }
>
> AFAICT, the spec is not clear to whether max uniforms applies to active uniforms, or declared uniforms.

The paragraph describing the GL_MAX_VERTEX_UNIFORM_COMPONENTS query is 
preceded and followed by paragraphs describing active uniforms.

     "A uniform is considered active if it is determined by the compiler
     and linker that the uniform will actually be accessed when the
     executable code is executed. In cases where the compiler and linker
     cannot make a conclusive determination, the uniform will be
     considered active.

     The amount of storage available for uniform variables accessed by
     a vertex shader is specified by the implementation dependent
     constant MAX VERTEX UNIFORM COMPONENTS. This value represents the
     number of individual floating-point, integer, or boolean values
     that can be held in uniform variable storage for a vertex shader."

It doesn't explicitly say that it's the count of active uniforms, but it 
does say it counts the storage used.  I think it's reasonable to infer 
that the active uniforms are the only ones using storage.  What it 
leaves ambiguous is whether the set of active uniforms is a superset of 
the storage requirement.

> Indeed for the example you give it is unrealistic for the app to expect this to be supported with a limited number of max uniforms.  But the examples that Marek pasted, it is not clear cut if this is an app bug, or a compiler limitation.
>
>> There's over a month before what is currently master will be
>> released.
>> People that don't like this bug can use a stable release.
>
> This will drive testers affected by this issue away from testing
> master. I thought that we all agreed that master should remain
> relatively stable all the time. No good comes from leaving things broken
> for our users like this for so long.

That's fair.  It's worth pointing out a couple things about this:

1. These patches sat on the mailing list for a week and received *zero* 
review comments from anyone outside Intel.

2. The actual bug was fixed by commit 151867b4 a week after that.

> I also think that something needs to be done to keep old behavior until GLSL compiler handles optimizes this particular case.  If not within GLSL itself, then in the components around it.