Data writing behavior to UAVs without atomics?

Started by
0 comments, last by MJP 10 years, 7 months ago

I'm thinking about an occlusion system, and I'm wondering about the writing behavior to UAV's from a pixel shader.

I want to pass an integer ID to a pixel shader, before using that as an index to write a value into a UAV. I only care that a value has been written to it, and not what the value is (as long as it's non-zero).

I'm unsure about the threading implications. Assuming every value in the UAV is defaulted to 0, if a ton of different pixel shaders are setting a non-zero value to a position in the UAV what will happen?

Will it be set to the value, or will the writes interfere with each-other in some undefined way? Is the writing behavior guaranteed to be consistent among different DX11 capable GPU's?

Edit: Or are they all auto-atomic'd.

Advertisement

If multiple pixel shader invocations write a value to the same location of a texture, then all of the writes will happen by the time the draw/dispatch call finishes. However you will have no guarantee as to the order in which they occur, so one of the threads will "win" by being last to write its value. If all of the threads are writing the same value then this shouldn't matter, that value should be written to the texture and visible in any subsequent draw/dispatch calls. AFAIK this is guaranteed in D3D, although the public docs are notoriously vague about this sort of thing. The one place you could get into trouble is if you try to read from a location in memory that was written to earlier in the same shader. In such cases writes from one thread group aren't guaranteed to be visible to threads in other thread groups, unless you use globallycoherent to ensure that sync calls wait for pending writes to be finished and flushed across different GPU cores.

This topic is closed to new replies.

Advertisement