Clash Royale CLAN TAG#URR8PPP

Issue with simple atomic counter test in OpenGL compute shader

I've been trying to wrap my head around memory synchronization and coherency by trying trivial examples.

In this, I'm dispatching a compute shader with 8x8x1 size work groups. The number of work groups is sufficient to cover the screen, which is 720x480.

Compute shader code:

#version 450 core

layout (local_size_x = 8, local_size_y = 8, local_size_z = 1) in;

layout (binding = 0, rgba8) uniform image2D u_fboImg;

layout (binding = 0, offset = 0) uniform atomic_uint u_counters[100];

void main()


This is what I get: (The heights of the jagged bars are different each time, but on average about that height)

This is what I would expect, and is the result of hard coding the for loop to go to 400.

Strangely enough, if I decrease the number of work groups in the dispatch, say by halving the x value (would now only cover half the screen), the bars get bigger:

Finally to prove there isn't some other nonsense going on, here i'm just coloring based on local invocation id:

*Edit: Forgot to mention the dispatch is followed immediately by glMemoryBarrier(GL_ALL_BARRIER_BITS);

glMemoryBarrier(GL_ALL_BARRIER_BITS);

ATOMIC_COUNTER_BUFFER_SIZE

GL_MAX_ATOMIC_COUNTER_BUFFER_SIZE

1 Answer
1

Unless otherwise stated, all shader invocations for a particular shader stage, including the compute shader stage, execute independently of one another, in an order which is undefined. And calling memoryBarrier does not change this fact. This means that, when the stuff after the memoryBarrier is called, there is no guarantee that the value from the atomic counter has been incremented by all of the shader invocations that will eventually do so.

memoryBarrier

memoryBarrier

So what you're seeing is exactly what one would expect to see: the invocations writing somewhat random values, depending on the implementation-dependent order that the invocations just so happen to be executed in.

What you're wanting to do is execute all of the atomic increments for all invocations, then read those values and draw stuff based on what you read. Your code as written cannot do that.

While compute shaders do have some ability to manipulate the order of execution of invocations, this only works for invocations within the same work group (this is in fact why work groups exist). That is, you can have invocations ordered to a degree in a work group, but never between work groups.

The simple fix for this is to turn it into 2 compute shader dispatch operations. The first does all of the incrementing. The second will read the values and write the results to the image.

More clever solutions would involve employing work groups. That is, group your work so that whatever would have incremented the same atomic counter will execute within the same work group. This way, you don't even need atomic counters; you just use shared variables (which can perform atomic operations). You call barrier() after you do all of the incrementing of the shared variable; that ensures that all invocations have executed at least that far before any invocation continues past that point. So all of the incrementing is done.

barrier()

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.