Bug 42966

confirm this on i965.

(In reply to comment #1)
> confirm this on i965.

This test has never passed on i965, so I don't see how it's a regression there.  In fact, it used to crash inside the driver, but not it terminates with an error.  This shader uses 4097 uniform components, but the i965 driver only supports 4096 ('glxinfo -l | grep GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB' confirms this).

(In reply to comment #0)
> mesa: 79653c12d6da4d89aaa73e4e8260a84d91f93593 (master)
> 
> Run piglit glsl-fs-uniform-array-6 on swrast, softpipe, or llvmpipe. The test
> now fails but previously passed.

What does 'glxinfo -l | grep GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB' show on these drivers?  If the value is less than 4097, this test *should* fail.  From the text of the test:

/* Test that we can access a dynamically indexed array element of a
 * very large fragment shader uniform array.  Note that this array is
 * much larger than the minimum MAX_FRAGMENT_UNIFORM_COMPONENTS, so a
 * driver may just reject this shader.
 */

(In reply to comment #2)
> What does 'glxinfo -l | grep GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB' show on
> these drivers? 

mesa: a43908fe62c39b84f014ddf2bee15cd07a77fc0d (master)

swrast:
$ glxinfo -l | grep GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB
Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_COLOR_MATRIX_STACK_DEPTH)
Mesa: User error: GL_INVALID_ENUM in glGetConvolutionParameteriv
        GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB = 16384

softpipe:
$ glxinfo -l | grep GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB
Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_COLOR_MATRIX_STACK_DEPTH)
Mesa: User error: GL_INVALID_ENUM in glGetConvolutionParameteriv
        GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB = 16384

llvmpipe:
$ glxinfo -l | grep GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB
Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_COLOR_MATRIX_STACK_DEPTH)
Mesa: User error: GL_INVALID_ENUM in glGetConvolutionParameteriv
        GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB = 16384

This case used to crash on i965 indeed, pass on i915. It fails on i965 and i915 since Ian's commit.

I just posted a patch to the mesa-dev mailing list that should fix this issue.  I tested with softpipe.

http://lists.freedesktop.org/archives/mesa-dev/2011-November/014913.html

(In reply to comment #5)
> I just posted a patch to the mesa-dev mailing list that should fix this issue. 
> I tested with softpipe.
> 
> http://lists.freedesktop.org/archives/mesa-dev/2011-November/014913.html

Tested-by: Vinson Lee <vlee@vmware.com>

I applied the above patch to mesa master 0fe14178dbd5b350082a06c7488b6077362a85e3.

piglit glsl-fs-uniform-array-6 passes on swrast, softpipe, and llvmpipe.

There looks to be two extra print statements now though.

$ ./bin/shader_runner tests/shaders/glsl-fs-uniform-array-6.shader_test -auto
i: 1
arg: 4096
PIGLIT: {'result': 'pass' }

Fixed by the following commit in Mesa master:

commit 151867b422d07b9e5845e95c2ebc30567809edc5
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Nov 21 11:42:37 2011 -0800

    linker: Remove erroneous multiply by 4 in uniform usage calculation

    The old count_uniform_size::num_shader_uniforms was actually
    calculating the number of components used.  Multiplying by 4 when
    setting gl_shader::num_uniform_components caused us to count 4x as
    many uniform components as were actually used.

    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42930
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42966
    Acked-by: Marek Olšák <maraeo@gmail.com>
    Tested-by: Vinson Lee <vlee@vmware.com>
    Tested-by: Pavel Ondračka <pavel.ondracka@email.cz>
    Reviewed-and-tested-by: Kenneth Graunke <kenneth@whitecape.org>

mesa: 24d25b55bf511493e70600cc7c49c0a0e6fc7a32 (master)

Verified fixed.