I just read the new additions to GLSL 4.2. One thing i don’t understand is what is the point of the new atomic_uint opaque type.
Unless i miss something, functionality-wise they seem to be a strict sub-set of the new image opaque types. Images have atomic functions too and everything that can be done with atomic counters can also be done with images.
At first I thought the atomic counters might be older, so they are here just for compatibility, but then i saw both were introduced in 4.2.
Then I thought the counters might be simpler to work with and require now API-side setup, but then i saw they require one to create and bind buffers from the API side just as as with uimageBuffer.
Does anyone know why do we need separate atomic counters apart from the images?
Because some hardware has less expensive, built-in hardware for doing small-scale atomic stuff. shader_atomic_counters is designed to express the limitations of that hardware.
In short: if what you want to do can be done with shader_atomic_counters, then use that.
That had crossed my mind, but then I don’t understand how such specialized hardware can be faster when it still needs to access the video memory (the bound buffer). Maybe a specialized hardware which works with some (limited in number) special on-chip registers could be faster. But then how would these registers relate to buffer objects.
At any rate, even if there is really point in the separate counters, i still would leave them as extension and keep the core spec more forward-looking and clean.