cancel
Showing results for 
Search instead for 
Did you mean: 

OpenGL & Vulkan

Journeyman III
Journeyman III

imageAtomicAdd on R16I textures

Jump to solution

In my application I use single-channel signed integer texture of the format R16I to store data. Attempting to use imageAtomicAdd() on the image the texture is bound to fails, with debug output as:

Compute shader failed to compile with the following errors:

ERROR: 0:23: error(#370) Missing or invalid layout qualifier for image variable

ERROR: error(#273) 1 compilation errors.  No code generated

(Apologies, I don't know how to format text as code here).

Changing the format in the layout() to r32i or removing the imageAtomicAdd() use results in a successful compilation.

As far as I can read in the OpenGL specification, there is no restriction on imageAtomicAdd() (or any other image functions) based on format.

Basic test shader:

#version 430 core

layout(binding = 1, r16i) uniform iimage2D sampleTexture; //fail

//layout(binding =1, r32i) uniform iimage2D sampleTexture; //success

void main(void){

ivec2 pix = ivec2(gl_GlobalInvocationID.xy);

  imageAtomicAdd(sampleTexture, pix, 1); //if this is commented out/removed, success

}

0 Kudos
Reply
1 Solution

Accepted Solutions
Staff
Staff

Re: imageAtomicAdd on R16I textures

Jump to solution

peppercat wrote:



As far as I can read in the OpenGL specification, there is no restriction on imageAtomicAdd() (or any other image functions) based on format.



Referring to the latest GLSL specification, version 4.50, revision 5 (although this language has always existed), section 8.12, bottom of page 175, it says:

Atomic memory operations are supported on only a subset of all image variable types; image must be either:

• a signed integer image variable (type starts “iimage”) and a format qualifier of r32i, used with a data argument of type int, or

• an unsigned image variable (type starts “uimage”) and a format qualifier of r32ui, used with a data argument of type uint.

Image atomics are only accepted on integer image types with a format qualifier of r32i or r32ui.

Cheers,

Graham

View solution in original post

0 Kudos
Reply
3 Replies
Staff
Staff

Re: imageAtomicAdd on R16I textures

Jump to solution

I'll pass on to the OpenGL team.

For the "how do I format code..."

When you reply, toward the upper right of the Reply box you should see "Use Advanced Editor." Click that.

You now have real formatting options, like ability to pick a font.

What I would so is copy and paste the code in place, select it, and apply Courier.

#version 430 core

layout(binding = 1, r16i) uniform iimage2D sampleTexture; //fail

//layout(binding =1, r32i) uniform iimage2D sampleTexture; //success

void main(void){

ivec2 pix = ivec2(gl_GlobalInvocationID.xy);

  imageAtomicAdd(sampleTexture, pix, 1); //if this is commented out/removed, success

}

(I have to go see if there's any way to create a code "style" and make this happen a bit more easily. Probably not, but what the hey... I can dream)

Staff
Staff

Re: imageAtomicAdd on R16I textures

Jump to solution

peppercat wrote:



As far as I can read in the OpenGL specification, there is no restriction on imageAtomicAdd() (or any other image functions) based on format.



Referring to the latest GLSL specification, version 4.50, revision 5 (although this language has always existed), section 8.12, bottom of page 175, it says:

Atomic memory operations are supported on only a subset of all image variable types; image must be either:

• a signed integer image variable (type starts “iimage”) and a format qualifier of r32i, used with a data argument of type int, or

• an unsigned image variable (type starts “uimage”) and a format qualifier of r32ui, used with a data argument of type uint.

Image atomics are only accepted on integer image types with a format qualifier of r32i or r32ui.

Cheers,

Graham

View solution in original post

0 Kudos
Reply
Journeyman III
Journeyman III

Re: imageAtomicAdd on R16I textures

Jump to solution

Oh wow, I didn't even think of reading the GLSL spec.

Thank you very much for the clarification.

0 Kudos
Reply