Sign in to follow this  

[D3D11] Append Buffers and Copy Structure Count

This topic is 2546 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have been building up a particle system using append and consume buffers where all of the particles are read out of a consume buffer, they get updated, and then appended to the output buffer. This is currently using a fixed number of particles for both dispatching the compute shader and drawing the results. Now I would like to get some indirect rendering up and running so that I can use variable numbers of particles.

In order to do this, I create two separate buffers for holding the arguments to the DispatchIndirect and the DrawInstancedIndirect respectively.

To start out, I initialize the args buffers with the appropriate fixed number of items to dispatch and draw respectively. The system is working properly, and the particles are updated in the compute shader and then rendered afterwards. There is a total of 512 particles currently.

However, once I start to use ID3D11DeviceContext::CopyStructureCount to get the current structure counts determined by the UAVs I start getting strange results. To try to understand what is going on, I created a separate staging buffer so that I could copy the structure count and then map it back to system memory for reading.

Before the compute shader is executed at all, I copy the structure count out of my UAVs and get the following:

UAV[0]: 0xbaadf00d
UAV[1]: 0xbaadf00d

Then, after executing the update compute shader I get the following:

UAV[0]: 0xfffc0200
UAV[1]: 0x00040000

I would expect UAV[1] to hold 0x00000200 and UAV[0] to have 0x00000000. At first I thought I must be botching something up, but after executing the rendering pass and coming back around to updating the system, I get the expected results on the second pass:

UAV[0]: 0x00000000
UAV[1]: 0x00000200

This cycle alternates every other frame - for some reason it seems that the whole setup is still working with all of the particles being updated and moving as intended, but then the counts don't seem to be coming out correctly only half of the time... I am using the reference device, so I don't expect any unusual behavior from the driver either...

Does anyone have a similar setup working? Or perhaps see some pattern in this data that would indicate what is going on? Thanks in advance for any help or suggestions!

Share this post


Link to post
Share on other sites
D'Oh! I figured out the "problem"...

When I switched to using the DispatchIndirect method, I went from using a single thread group of sized [512,1,1] to using a the same sized thread group, but the indirect dispatch arguments buffer is initialized to [512,1,1] size as well... that means that I was doing 512*512 threads per dispatch, which accounts for the wacky number results.

Sorry for the false alarm [grin]!

Share this post


Link to post
Share on other sites

This topic is 2546 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this