This may be a stupid question but I'm currently failing to see the purpose of the ConsumeStructuredBuffer if it is impossible to tell when it is empty.

The obvious use for such a buffer is to read in an arbitrary, unknown number of elements and process those in a shader. In order to make sure they are all processed, enough threads for a "maximum load" have to be used. So normally you'll end up with more threads than data to process. This is acceptable as long as you can tell those threads that there's nothing to do for them, but it seems it isn't possible to retrieve the internal counter of append/consume buffers on the GPU, or even to tell when they're empty. Sure, you can query the counter on the CPU and copy it into a cbuffer or similar but that pretty much takes away the whole point of having a supposedly CPU-independent data structure, doesn't it? And if I know the counter through such means as a constant, I wouldn't need the consume behaviour at all but could rather just step through each element as through a normal StructuredBuffer.

Surely I must be missing something here... or?

Yes, you are right in that, but I thought it would make sense that you should somehow be able to avoid situations where you run past the end of the buffer. The most reasonable would be if the Consume function used an out argument and returned a boolean indicating whether the call failed instead I guess, but alas it does nothing of the kind...

I don't know how it escaped me that I could copy the counter directly into another buffer; I've been putting it in a staging buffer and then updated it to other buffers from the CPU. That at least makes the whole approach a bit less contradictory.

The best you could do is call Consume, and check if the resulting structure is all 0's.

Is that really safe? I think MSDN said consuming past the end of a buffer results in undefined behaviour. Also the counter seems to be less than clever and will happily go into the negatives causing wrong size information if you start appending to the buffer again. But if that all-zeroes thing work I guess it could be used, I'll do some tests with that :)

The indirect argument buffer approach sounds interesting as well, I haven't looked into that much than reading some brief passage about it. Also is it recommended to dispense a number of threads per group or can you theoretically (and without loosing performance) have say lots of thread groups that contain just a single thread? I've always assumed that you shouldn't do this and your asterix part seems to suggest the same, but at the same time it doesn't seem the thread groups actually map directly to SIMD blocks on the GPU... or do they? But if that was the case they should be a lot more limited as to how many you can make use of than they now are?

It seems it does in fact return the full-zero thing for me as well, but as you say I don't know if that is safe to assume will be the case for any card. The counter approach does seem the most appropriate here, I'll try to switch to that and see how it fares. I guess the D3D11_BUFFER_UAV_FLAG_COUNTER cannot be combined with the D3D11_BUFFER_UAV_FLAG_APPEND flag? Actually I can just check that myself and if it doesn't I'll just use the IncrementCounter function for filling it out too.

Thanks for the threading explanation, I managed to track down some more detailed information from the "warp" keyword which I hadn't heard until now :)

Also I just found out you're on of the co-authors of the Practical Rendering with DirectX 11 book I've been referring a lot lately, so thanks a lot for that too!