1. create upload heap (D3D12_RESOURCE_STATE_GENERIC_READ state)

2. create default heap (D3D12_RESOURCE_STATE_COPY_DEST state)

3. fill upload heap with data

4. copy data from upload heap to default heap (UpdateSubresources(), give command list which creates the command, stores in command allocator)

5. transition default heap from copy dest state to vertex and constant buffer state (next command in command list after UpdateSubresources)

6. execute command list

7. update fence value

8. create signal "command" with command queue which updates the fence value on the gpu with new fence value

9. check fence value on gpu to make sure that signal command was executed, at that point you know the executed command list above has finished executing.

you have to update the fence value, otherwise you may end up trying to access that data in the default heap before its finished copying

So my question is really, do I have to do the fence on the Copy Queue, and then transition to D3D12_RESOURCE_STATE_VERTEX_AND_CONSTANT_BUFFER on the Direct Queue. Which it looks like I do.

That makes sense. A copy queue is an abstraction over a DMA controller, which really can't do anything useful besides memcpy... however, resource transitions are abstractions over cache invalidations, cache flushes, and data format/packing/pitch/swizzling transformations -- which a DMA unit might not be able to perform. So it makes sense that your "graphics" queue would wait for a signal that the DMA task has completed, and then perform these "transition" tasks itself.

Honestly i use a direct queue for everything including moving data to and from the GPU. The Present API only presents at multiples of the screen refresh rate (I haven't had luck getting unlocked fps yet), and i get 120 FPS whether i use a direct queue or a copy queue. Unless you are moving a lot of data to and from the GPU, i personally feel the copy queue just makes things more complex than they really need to be for how much performance gain you might get with it.

Anyway, If you are going to use a copy queue, you would still definitely have to use a fence like hodgman said, because again you need to make sure that the data has finished copying before using or modifying it (which includes changing its state, the GPU could actually physically move the data from what i understand when changing states, someone please correct me if i'm wrong about that though). Not that this bit is that helpful, but you can still use the data as vertex/index resources if you leave the default heap in a copy dest state. Of course the GPU can do optimizing for certain things depending on the state its in though, so you'll want to make sure it's in the proper state before you do anything with it.

yeah, thats a good point dingleberry, what i meant though was that my applications have not had to wait noticeably longer for the GPU to finish copying data from upload heaps to default heaps using only a direct command queue to do everything rather than using a direct queue along side a copy queue, so I personally have not seen or needed the benefit you might get from utilizing a copy queue. I mentioned the FPS because the fps cap is preventing me from seeing the actual difference if any between the performance of using a copy queue or not

I've only recently began working with the beautiful vs graphics debugger (god i love how convenient that thing is!). I didn't realize you could track times in it, so thanks for pointing that out!

Honestly i use a direct queue for everything including moving data to and from the GPU. The Present API only presents at multiples of the screen refresh rate (I haven't had luck getting unlocked fps yet), and i get 120 FPS whether i use a direct queue or a copy queue. Unless you are moving a lot of data to and from the GPU, i personally feel the copy queue just makes things more complex than they really need to be for how much performance gain you might get with it.