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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
