I took a brief look to this one. Two quick notes.

(In reply to Mark Janes from comment #0)

> Failed to compile compute shader: 0:9(8): error: unrecognized layout
> identifier `size4x32'

<skip>

> uniform cs_uniform_block {
> 	uniform vec4 cs_test;
> };
> layout(size4x32) uniform image2D tex;

Using "layout(rgba32f)" gets the shader being compiled without problem, and the subtest passing (the test itself still fails). After a skim reading on EXT_shader_image_load_store and ARB_shader_image_load_store (the latter depends on the former), that layout should be allowed, and it is also more general (for example, using rgba32i fails due a format mismatch). So I suspect that this is a bug on the implementation for those extensions. The problem was hidden until now because this shader needed compute shader.

Using glslangValidator with that shader also prints a "unrecognized layout identifier". Having said so, it prints several other errors.

NVIDIA proprietary drivers handle that shader without problems (as pointed on the commit log of those tests)

Will keep investigating to check if the problem is in the shader. In that case, the bug would be on the piglit test.

> subroutine vec4 com_offset();
> subroutine uniform com_offset COMPUTE;
> subroutine (com_offset) vec4 css() { return vec4(1, 0, 0, 0); }
> void main() {
> 	imageStore(tex, ivec2(0.0), cs_test + COMPUTE());
> }


Second note: piglit.spec.arb_program_interface_query.arb_program_interface_query-resource-location is affected by the same problem, that got also fixed by changing size4x32 for rgba32f.

(In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #1)
> I took a brief look to this one. Two quick notes.
> 
> (In reply to Mark Janes from comment #0)
> 
> > Failed to compile compute shader: 0:9(8): error: unrecognized layout
> > identifier `size4x32'
> 
> <skip>
> 
> > uniform cs_uniform_block {
> > 	uniform vec4 cs_test;
> > };
> > layout(size4x32) uniform image2D tex;
> 
> Using "layout(rgba32f)" gets the shader being compiled without problem, and
> the subtest passing (the test itself still fails). After a skim reading on
> EXT_shader_image_load_store and ARB_shader_image_load_store (the latter
> depends on the former), that layout should be allowed, and it is also more
> general (for example, using rgba32i fails due a format mismatch). So I
> suspect that this is a bug on the implementation for those extensions. The
> problem was hidden until now because this shader needed compute shader.
> 
> Using glslangValidator with that shader also prints a "unrecognized layout
> identifier". Having said so, it prints several other errors.
> 
> NVIDIA proprietary drivers handle that shader without problems (as pointed
> on the commit log of those tests)
> 
> Will keep investigating to check if the problem is in the shader. In that
> case, the bug would be on the piglit test.

Ok, after a more deep reading on the spec, from ARB_shader_image_load_store spec:

    "(0) How does this extension differ from the similar
        EXT_shader_image_load_store?

      RESOLVED:  The functionality provided by this extension is very similar
      to that provided by EXT_shader_image_load_stores.  There are some
      functional differences.

        * "size" layout qualifiers replaced with "format" qualifiers."

So, layout(size4x32) was valid for EXT_shader_image_load_store but not for ARB_shader_image_load_store.

About why this doesn't fail on NVIDIA drivers, at the same spec:
"Dependencies on EXT_shader_image_load_store

    Both this extension and EXT_shader_image_load_store provide nearly the
    identical functionality.

    If both extensions are enabled in the shading language, the "size*" layout
    qualifiers are treated as format qualifiers, and are mapped to equivalent
    format qualifiers in the table below, according to the type of image
    variable. "

So I understand that if both extensions are enabled, size* is still allowed, but mapped to the format qualifiers. NVIDIA supports both extensions while hsw/i965 only the ARB one, explaining the difference between both.

So. I think that the way to solve this would be change the layout at the test, to one using the format qualifier, as is the one required by the ARB version of the extension.

(In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #2)

> So. I think that the way to solve this would be change the layout at the
> test, to one using the format qualifier, as is the one required by the ARB
> version of the extension.

Patch sent to piglit:
https://patchwork.freedesktop.org/patch/73278/

Note that the test itself still fails after this patch. But fixes the bug in any case, as the problem reported is about a shader compile error.

Also moving the bug to piglit.

(In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #3)
> (In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #2)
> 
> > So. I think that the way to solve this would be change the layout at the
> > test, to one using the format qualifier, as is the one required by the ARB
> > version of the extension.
> 
> Patch sent to piglit:
> https://patchwork.freedesktop.org/patch/73278/

Patch reviewed and pushed:

commit b7a65af75afb3664a1e908b09c8a39fa4490c2cc
Author: Alejandro Piñeiro <apinheiro@igalia.com>
Date:   Thu Feb 11 12:04:40 2016 +0100

    program_interface_query: use format layout qualifiers instead of size* layout qualifiers
    
    From ARB_shader_image_load_store spec:
    
    "    (0) How does this extension differ from the similar
            EXT_shader_image_load_store?
    
          RESOLVED:  The functionality provided by this extension is very similar
          to that provided by EXT_shader_image_load_stores.  There are some
          functional differences.
    
            * "size" layout qualifiers replaced with "format" qualifiers.
    
            * Image loads aren't restricted to "1x8", "1x16", "1x32", "2x32", and
              "4x32" formats.  Instead, each supported image format has a layout
              qualifier, and values loaded from images are converted to an
              vec4/ivec4/uvec4 representation appropriate for the image format."
    
    size4x32 was valid for EXT_shader_image_load_store. That explains
    why this test works properly on proprietary NVIDIA drivers, as
    both extensions are supported.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93336
    Reviewed-by: Tapani Pälli <tapani.palli@intel.com>


Closing bug.