Passing an image to a function causing a spirv-val validation error "type does not match function parameter type"

[nicovize]

Hello,

I get the following error from spirv-val when I try to pass an image to a function :

error: line 24: OpFunctionCall Argument '15[%TestRWTex]'s type does not match Function '8[%ptr_UniformConstant_7]'s parameter type.
%16 = OpFunctionCall %void %f_I21 %TestRWTex

Here is the minimal compute shader that causes the problem from the validator (this compiles fine, however) :

#version 450

layout (binding=0, rgba32f)  uniform image2D TestRWTex;

void f(image2D rwTexture)
{
}

void main()
{
    f(TestRWTex);
}

I used the following command line to get the error :

glslangValidator -o image_passed_to_function.spv -V --target-env vulkan1.1 image_passed_to_function.comp
spirv-val image_passed_to_function.spv

I'm not sure if there is a workaround, as declaring a "uniform image2D" in nested function scope is not allowed in GLSL, it seems.

glslangvalidator version infos (version from 1.1.101.0 Vulkan SDK) :

Glslang Version: 7.11.3113
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos. 11.3113
GLSL Version: 4.60 glslang Khronos. 11.3113
SPIR-V Version 0x00010300, Revision 6
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 7
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100

best regards,

[johnkslang]

I think this is a problem with GLSL itself, which Khronos is currently looking into.

The types don't match, because one has the layout rgba32f and the other does not, yet GLSL seems to require it on the global (unless it is writeonly) and generally does not allow qualifiers on the function parameter (though perhaps it should for this purpose).

Given your variable name, I doubt it helps, but the following works:

#version 450

writeonly layout (binding=0)  uniform image2D TestRWTex;

void f(writeonly image2D rwTexture)
{
}

void main()
{
    f(TestRWTex);
}

[johnkslang]

See KhronosGroup/GLSL#57.

This is pending an extension that enables the use of the qualifiers needed.

In the meantime, I'll see if glslang should be issuing an error for this at the GLSL level.

[nicovize]

Hi John,
Thanks for sharing this info!
This is great that an extension is coming to handle this case.
If the issue can be resolved at GLSL level, still better :)
best regards