<p>Will having all invocations incrementing the same atomic counter be slower than not doing that? Sure. How much slower? That depends on many factors, but it's hardly going to be a crippling performance issue.</p>
<p>The whole point of atomic memory operations is that there is some hardware mechanism that allows them to work reasonably efficiently. Not as efficiently as bumping a local variable of course, but they shouldn't be assumed to cause a massive performance penalty.</p>
<p>On some hardware, atomic counter operations aren't even memory operations. AMD implements them as specialized hardware within their shader system, such that atomic counter operations don't touch actual memory storage until after the rendering process that uses them is complete.</p>
<p>Obviously, the best thing you can do is profile on your hardware-of-choice, but failing that, I would see no reason not to use this mechanism as you see fit.</p>

CC BY-SA 4.0
2020-07-18T00:13:41.083Z
I've had similar things cripple performance on CPUs so I would not bet on it not being a crippling performance issue. Especially as GPUs have so many more cores all fighting for the same memory location. With that said, you're right that the best thing to do is measure it.
Olivier
CC BY-SA 4.0
2020-07-19T13:54:01.387Z
@Olivier: And yet, there are many algorithms and rendering patterns that do this all the time. Linked-list-based order independent transparency is ultimately based on everyone bumping the same atomic counter to get unique locations for their list nodes. That seems to work adequately performance-wise. Also, atomic counters can be specialized hardware; on AMD platforms, they're something that lives inside the rendering context, not a memory location. I'm not saying that it's cheap, but it shouldn't be looked on as an a priori show-stopper.
Nicol Bolas
CC BY-SA 4.0
2020-07-17T17:54:20.457Z
2020-07-19T13:55:58.750Z
2020-07-19T13:55:58.750Z
Nicol Bolas
<p>is it worse to do for each invocation an atomicAdd on the same memory location than doing for each invocation an atomicAdd to a unique memory location? (I know, atomicAdd does not make sense when each invocation writes to another location... but this is theoretically)</p>
<p>I am asking, because I wrote the marching cubes algorithm and while creating the mesh I additionally want to calculate the center of mass as well.</p>
<p>I am doing this by having four integers in the SSBO (centerX, centerY, centerZ and countTriangles)
each of these 4 integers will be increased by the atomicAdd function within the GeometryShader.
When everything is done, I only need to divide the centerX/Y/Z variable by countTriangles and I am done.</p>
<p>if these atomics on one memory location would slow down my shader, I would outsource it to another maybe CPU function.</p>
<p>Thanks in advance</p>

<opengl><glsl>
Does atomic functions on same memory location cause an performance issue?
Thomas
# Does atomic functions on same memory location cause an performance issue?

(Asked by: username_0 on 2020-07-17)

is it worse to do for each invocation an atomicAdd on the same memory location than doing for each invocation an atomicAdd to a unique memory location? (I know, atomicAdd does not make sense when each invocation writes to another location... but this is theoretically)

I am asking, because I wrote the marching cubes algorithm and while creating the mesh I additionally want to calculate the center of mass as well.

I am doing this by having four integers in the SSBO (centerX, centerY, centerZ and countTriangles)
each of these 4 integers will be increased by the atomicAdd function within the GeometryShader.
When everything is done, I only need to divide the centerX/Y/Z variable by countTriangles and I am done.

if these atomics on one memory location would slow down my shader, I would outsource it to another maybe CPU function.

Thanks in advance

**Tags:** opengl, glsl


---

## 1 answers

### Answer by username_1 on 2020-07-17. Score: 2 | Accepted answer

Will having all invocations incrementing the same atomic counter be slower than not doing that? Sure. How much slower? That depends on many factors, but it's hardly going to be a crippling performance issue.

The whole point of atomic memory operations is that there is some hardware mechanism that allows them to work reasonably efficiently. Not as efficiently as bumping a local variable of course, but they shouldn't be assumed to cause a massive performance penalty.

On some hardware, atomic counter operations aren't even memory operations. AMD implements them as specialized hardware within their shader system, such that atomic counter operations don't touch actual memory storage until after the rendering process that uses them is complete.

Obviously, the best thing you can do is profile on your hardware-of-choice, but failing that, I would see no reason not to use this mechanism as you see fit.

> **Comments:**
> **username_2**: I've had similar things cripple performance on CPUs so I would not bet on it not being a crippling performance issue. Especially as GPUs have so many more cores all fighting for the same memory location. With that said, you're right that the best thing to do is measure it.  
> **username_1**: @username_2: And yet, there are many algorithms and rendering patterns that do this all the time. Linked-list-based order independent transparency is ultimately based on everyone bumping the same atomic counter to get unique locations for their list nodes. That seems to work adequately performance-wise. Also, atomic counters can be specialized hardware; on AMD platforms, they're something that lives inside the rendering context, not a memory location. I'm not saying that it's cheap, but it shouldn't be looked on as an a priori show-stopper.  

---

