Jump to content
  • Advertisement
turanszkij

DX12 WriteBufferImmediate use-cases

Recommended Posts

I am doing a DX12 graphics wrapper, and I would like to update constant buffers. I found the ID3D12GraphicsCommandList2::WriteBufferImmediate method, which is apparently available from a Windows 10 Creators update only. I couldn't really find any info about this (and couldn't try it yet), am I correct to assume this would be useful for writing to constant buffers without much need to do synchronization? It seems to me like this method copies data to the command list itself and then that data will be copied into the DEFAULT resource address which I provided? The only synchronization needed here would be transition barriers to COPY_DEST before WriteBufferImmediate() and back to GENERIC_READ afterwards? I could be totally off though, I'm still wrapping my head around a lot of things.

What other use cases would this method allow for?

Share this post


Link to post
Share on other sites
Advertisement

At a high level, no that is not its intended use. Using MODE_DEFAULT would (probably) cause the graphics pipeline to stall/drain every time you issue one of these writes, which would kill performance. Using either of the other modes could cause the writes to happen too soon (affecting draws already in flight) or too late (after all previous draws in flight are fully finished, not necessarily in time for the next one).

Its intended use is for checking progress of GPU execution, specifically when the GPU has faulted and the device has become removed. If you use WriteBufferImmediate to insert "breadcrumbs" at the top of pipe and bottom of pipe, and the GPU faults, you can inspect these breadcrumbs to see which workloads had started but not finished - i.e. which workloads could have possibly contributed to the fault.

Share this post


Link to post
Share on other sites

SoldierOfLight is correct that one of the main purposes of WriteBufferImmediate is to provide synchronized writes with work done in the pipeline using MARKER_IN and MARKER_OUT modes.  However, MODE_DEFAULT is not a synchronizing operation.  In fact, the purpose of MODE_DEFAULT is to enable quick, stochastic writes to buffer locations, such as updating a few constants.  This also eliminates the need for an upload-heap staging buffer for these cases. 

The buffer must be in either the COPY_DEST or COMMON state (will be promoted to COPY_DEST).  

We would love to hear your feedback on how this affects your application performance.  Also, let me know if you have any more questions.

Share this post


Link to post
Share on other sites

Right, to clarify, the barrier to COPY_DEST would cause the write to be serialized with the previous read operation. However, if you weren't previously reading from the resource in the command list, then yes, WriteBufferImmediate is an excellent replacement for CopyBufferRegion.

Share this post


Link to post
Share on other sites
On ‎05‎/‎12‎/‎2017 at 7:19 PM, SoldierOfLight said:

Right, to clarify, the barrier to COPY_DEST would cause the write to be serialized with the previous read operation. However, if you weren't previously reading from the resource in the command list, then yes, WriteBufferImmediate is an excellent replacement for CopyBufferRegion.

Right now I am using an upload heap allocator that the CPU writes and issues a CopyBufferRegion into a default heap resource. Each buffer has one default heap and the upload heap is a global heap used by all buffers. This way on each update I will have:

  1. allocate next chunk from upload heap
  2. memcpy into upload heap
  3. transition barrier from constant buffer to copy_dest
  4. CopyBufferRegion(default_heap, 0, upload_heap, upload_heap_offset, dataSize)
  5. transition back to constant buffer
  6. bind constant buffer to pixel shader

Do you think this would be acceptable/standard way of doing this? I could not test perf yet, I'm just setting everything up. Data seems correct in the debugger.

The WriteBufferImmediate would be nearly exactly the same, but I copy my constant buffer to the command list.

Share this post


Link to post
Share on other sites

What you've implemented is the D3D11 equivalent of UpdateSubresource on a default constant buffer. WriteBufferImmediate would be roughly the same thing. In my experience, most people prefer to implement the D3D11 equivalent of Map(DISCARD) on a dynamic constant buffer, which would mean just binding your upload heap directly to the pixel shader.

Share this post


Link to post
Share on other sites

Thanks for this, great information. 

12 hours ago, MJP said:

You'll also have to track your fence on the DIRECT queue  to know when to free your chunk from the UPLOAD heap.

I've been thinking about just leaving the fence and freeing the UPLOAD heaps on frame start. I have unique upload heaps per frame for double (or triple) buffering. I will have a fence only when there are no more frames available to be queued up which the GPU hasn't finished yet. 

Also very interesting way of using the copy queue, I will not get into that yet but seems like an interesting technique. I heard that the copy queue could be slower, but it would use different hardware units so utilization could be better. Could you compare this with different hardware vendors as well?

This also cleared up some confusion, thanks for this:

18 hours ago, SoldierOfLight said:

What you've implemented is the D3D11 equivalent of UpdateSubresource on a default constant buffer. WriteBufferImmediate would be roughly the same thing. In my experience, most people prefer to implement the D3D11 equivalent of Map(DISCARD) on a dynamic constant buffer, which would mean just binding your upload heap directly to the pixel shader.

I just thought that you can't bind an upload heap as shader resource. I guess this way you are creating constant buffer views for each allocation from the heap for binding to the descriptor tables? Does an UPLOAD heap which is shader visible need unmapping or can it also stay mapped forever?

Share this post


Link to post
Share on other sites
3 hours ago, turanszkij said:

I guess this way you are creating constant buffer views for each allocation from the heap for binding to the descriptor tables? Does an UPLOAD heap which is shader visible need unmapping or can it also stay mapped forever?

Yep, that's right, and no it doesn't need to be unmapped.

Share this post


Link to post
Share on other sites
11 hours ago, turanszkij said:

Also very interesting way of using the copy queue, I will not get into that yet but seems like an interesting technique. I heard that the copy queue could be slower, but it would use different hardware units so utilization could be better. Could you compare this with different hardware vendors as well?

I don't have any comprehensive numbers at the moment, so I'll have to try to set up a benchmark at some point. I would guess that the difference would be pretty minimal unless you're uploading a very large buffer. For me it was also somewhat convenient to use the COPY queue since I already had a system in place for initializing resources using the COPY queue, and the buffer updates go through the same system. The IHV's have recommended using the COPY queue for resource initialization, since the DMA units are optimized for pulling lots of data over the PCI-e bus without disrupting rendering too much (which is necessary in D3D11 games that stream in new textures while gameplay is going on).

Share this post


Link to post
Share on other sites

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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!