I think the new append/consume types for structured buffers and byte buffers are very cool.  However, I do have a question about something.

It looks like the AppendByteAddressBuffer type has an IncrementCounter method, which I like.  This way, I know exactly how many items are in the buffer at the time of insertion.  However, for AppendStructuredBuffer, the counter is hidden and the Append method does not return anything (such as the total number of items in the buffer).

I can't really append something and then call GetDimensions, as a parallel copy of the shader could be inserting something before I call GetDimensions in the other copy, which would result in a potentially incorrect count.  Wouldn't it be better to also have an IncrementCounter method on the structured buffer type so the programmer knows exactly how many items are in it at the time of insertion?  Or does the byte address buffer type use an atomic operation on an integer, while the structured buffer type uses a special instruction that HW people can optimize for?

Thanks,
Seth

Wouldn't it also work to just have the programmer maintain their own counter (atomic operations) and use the RWStructuredBuffer/RWByteAddressBuffer types?  This reduces HLSL types and is also more flexible than only being able to append or consume, but not both in one pass (not that this would necessarily be useful).

In the August SDK, we added IncrementCounter/DecrementCounter to RWStructuredBuffer, though you can only call one on a given resource. I don't recall, but I believe we may have removed the counter from raw buffers as well (RWByteAddressBuffer). Note that using this on a regular structured buffer can induce a performance penalty, because the driver won't be able to reorder the buffer behind your back, so if order doesn't matter, make sure to continue using Append/ConsumeStructuredBuffers.

OK, cool.  One more question --

Are the Append/Consume buffer types guaranteed to be tightly packed?  i.e., can I append structs into an AppendStructuredBuffer in one pass, then bind this same buffer as a regular StructuredBuffer in another pass and index it?  Judging by the reference device, this seems to work fine, but I want to make sure this isn't by some fluke.

I don't believe that they are guaranteed to be tightly packed, only that when consumed you'll get them all. Perhaps when the view as a regular structured buffer is made it will perform a compaction, but I'm not sure.

Is there a d3d11.chm that is more up to date than the one in the March 2009 SDK?

If I may piggyback on this thread... Is there any way to read and Append buffer's counter from the CPU, outside of HLSL?  For example, can I run a kernel that generates a variable amount of output into an Append buffer, and then map the buffer on the CPU and read its contents (including the number of elements written)?  Or is the only valid use case of an Append buffer to remap it to a Consume buffer in a different kernel and process it as part of a separate Compute task?

From someone on the runtime team:

Yes, you can use CopyStructureCount to copy the value to any buffer that you can then get back to the CPU and read the value of.  (CopyStructureCount is also useful to get the count values into a buffer to be used as Dispatch/Draw*Indirect calls)