Format layout qualifiers on image function parameters? about glsl

[realazthat]

As suggested in the original post, one horrible solution is to use GL_EXT_shader_image_load_formatted, then run your script through glslangValidator to convert it to SPV, then run spirv-opt with --inline-entry-points-exhaustive, which inlines everything. Then either load the SPV in vulkan or opengl (if implementation supports it) or, alternatively, use spirv-cross to convert it back to glsl, and then load it as normal. I've gotten most of such a pipeline working, though I can't say it will work for everyone or on all hardware. I also was simultaneously doing other horrible hacks, so take this all with a grain of salt until you try it and it works in all contexts.

[graphitemaster]

Adding +1, it's been five years and it's still not possible to pass images around to functions.

[StilesCrisis]

Just adding my +1 here. This seems like a very serious functionality gap in the language.

[DethRaid]

Was a resolution reached for this? It's been four years and being able to pass a storage image to a function would make my code so much better

[Raikiri]

in vulkan 1.1.121.2 this code:

layout(binding = 0, r32f) uniform image2D testImage;
float Func(image2D image)
{
  return imageLoad(image, ivec2(0, 0)).r;
}
void main()
{
  float test = Func(testImage);
}

gives this error:

'format' : image formats must match

Why is it happening? Is there a workaround to pass image2D argument to a function?

[realazthat]

Why is it happening? Is there a workaround to pass image2D argument to a function?

There is no way, it's mostly hardware limitation.

How is this sort of thing a hardware limitation, when - at least my understanding is - everything is basically inlined before being executed on the hardware, and if you manually inline this, it is valid?

[spencerkohan]

Has there been any progress on this? I'm running into this exact issue today.

[johnkslang]

It seems like we should allow format qualifiers on function parameters, so that loads can be supported.

I think that's the right answer, and possibly to warn (or error) at the GLSL level if the argument type does not match the parameter type, including the format.

See KhronosGroup/glslang#1720 for a recent complaint about this.

[ianromanick]

We discussed on the call today that there was a very old bug (11466) about this issue. My recollection was that the driver was supposed to do whatever specialization of functions was necessary to make it work. Since most functions would be inlined, this would be trivial. It seems like the version of the shader with just g() should just work. SPIR-V makes things a bit more complicated.

[NeilMonday]

On AMD, the example compute shader above compiles with no errors.

[jeffbolznv]

FWIW, the original issue was reported to me by an internal Vulkan developer. We should definitely answer the question for both GL and Vulkan, and as Ian says it is probably harder with SPIR-V.

[pdaniell-nv]

Since we can't bugfix the current GLSL/ESSL specs for this, I think we need an extension so applications that want to use format qualifiers on function parameters know that it's supported by the implementation. If that makes sense we need a volunteer to create the extension.

[johnkslang]

Glslang is updated now to give an error if formats do not match between calling argument and formal parameter (unless the formal parameter is writeonly and at least one of caller/callee has an unknown format).

[Raikiri]

I saw a whole bunch of changes and discussions around this topic as it keeps popping up for the past 3 years whenever anybody attempts to pass a readwrite texture into a function. Is there any way (even a workaround) to do this as of today?

I changed my mind about that question. I suppose that is language and/or compiler problem. At least, for Vulkan API, due SPIR-V. About OpenGL or OpenGL ES, I currently have no idea...

[M-Gjerde]

+1