Hi there,
I’m trying to use a compute shader to generate a generalized fibonacci seq as it is the simplest case where a subsequent pixel depends on the value of several that came before it (in a left to right fashion). For some reason I keep getting results that defy my understanding of atomic counters and I was wondering if folks here might be able to shed some light on the reasons I’m getting what comes back.
I’ve included the glsl code here, and I’m using a compute shader who’s dimensions are globally 1x1x1 and locally 64x1x1 which should be enough to cover my 25 pixel long texture output.
// Example Compute Shader
// uniform float exampleUniform;
layout (local_size_x = 64, local_size_y = 1) in;
layout (binding = 0) uniform atomic_uint wcount;
shared float numbers[20];
void main()
{
numbers[0]=5;
numbers[1]=7;
// attempt to ensure all invocations have this in their memory already
memoryBarrier();
barrier();
// get next numbers index to set
uint wid = atomicCounterIncrement(wcount) +2; // +2 because we already have some values
numbers[wid]=numbers[wid -1] + numbers[wid-2];
// write out values to texture to check success
memoryBarrier();
barrier();
imageStore(mTDComputeOutputs[0],ivec2(wid-2,0),vec4(numbers[wid],0,0,1));
}
which gives me this
My confusion is that it seems like an atomic counter should help me make sure that the invocation who has gotten the atomic first will use the pre existing values of 5 and 7 to write a new value of 12 into the shared memory array. Then the invocation who gets the atomic next will use the value 7 and the new value of 12 to write the value of 19 into the array. For some reason it seems like the invocations are getting the atomics and incrementing them before the shared memory has been updated by the previous one. This is too bad because it means there isn’t anything in the shared memory to make use of.
I feel like this is something I’m sure folks have worked around and I’m just a little bit puzzled. If anyone can help I’d be super grateful!
