Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Data writing behavior to UAVs without atomics?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 DementedCarrot   Members   -  Reputation: 589

Like
0Likes
Like

Posted 30 August 2013 - 03:57 PM

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.


Edited by DementedCarrot, 30 August 2013 - 04:25 PM.


Sponsor:

#2 MJP   Moderators   -  Reputation: 11781

Like
2Likes
Like

Posted 03 September 2013 - 12:17 AM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS