Hi,

The primary differences are what the compiler/driver can't do in each scenario.

1) no memory accesses may be moved across this barrier, essentially this means that until you hit the barrier, there is no guarantee that what you wrote to memory will be visible to other threads
2) similar to 1, but this is a threading barrier as well, all threads must hit this statement before any can continue
3) no UAV accesses may be moved across this barrier
4) 3 + threading barrier
5) no accesses to group shared memory may be moved across this barrier
6) 5 + threading barrier

1, 3, and 5 really aren't all that interesting by themselves, because without a thread sync barrier, there is no guarantee that whoever wrote the data you'd like to see will have written it yet. So these are mostly to help you work around compiler/driver bugs that don't recognize a dependency and are ordering your memory accesses incorrectly.

Thanks for the clarification, John. Still, there remains some doubts in it.

Yes, but you have to remember that it goes both ways. There is no guarantee that anything you wrote to shared memory will be visible to other threads, and there is no guarantee that you'll be able to see anything another thread wrote or has yet to write.

If you don't use these calls at all, then you're specifying that all of your threads are independent of each other and don't need to share data. This doesn't mean you need to put them after every write to shared memory, though. Generally the programs we see have various phases, where threads act individually, then synchronize with each other, and then continue individually again.

The only device memory that can be both read and written (required for these synchronization primitives to be necessary) is memory in a UAV. I don't believe we have any mechanism for the GPU to explicitly use a system memory surface as a writeable surface, though in certain cases, system memory may be treated as device memory (such as in some integrated parts).

Thanks a lot John, for all the clarifiactions. :)

The granularity is 4-bytes, HLSL doesn't currently directly expose anything smaller than this (though you can obviously use bitwise operations to insert/extract a byte from a 4-byte block).

As for your second question, there are no lock concepts. Locks are a very bad model when you start to have many hundreds of threads trying to access the lock simultaneously (1000x slowdown is not unlikely). Instead, your algorithm should organize the threads in such a way that they can do their writes without stepping on each other, or make use of the interlocked intrinsics to calculate a spot that will not step on any other threads (for example, incrementing an integer that reserves a unique spot for your data).

Okey, so there is no locking done by DirectX itself. The programmer should be aware of this fact and write the code accordingly, got it. 

We considered adding language support for critical sections, but again you can run into the 1000x slowdown case, so we decided against it. If it really is something that you only want one thread to do, then we suggest using the if( threadid == N ) trick.

Okey. I'll do that.