PDA

View Full Version : Question about the "atomic counters"



l_belev
02-19-2012, 12:05 PM
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?

Alfonse Reinheart
02-19-2012, 12:10 PM
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.

l_belev
02-19-2012, 12:38 PM
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.

aqnuep
02-19-2012, 08:46 PM
Some vendors (actually one for sure) has special hardware for shader_atomic_counters that is about 10 times faster than image atomics.

Alfonse Reinheart
02-19-2012, 08:51 PM
i still would leave them as extension and keep the core spec more forward-looking and clean.

This assumes that they're a technological stop-gap rather than a limited alternative that can be made more performant due to those limitations.