Mutexes for sharing resources

Started by
6 comments, last by SoldierOfLight 8 years ago

I'm trying to share resources across different command queues. Obviously I want to keep the sharing to a minimum but at some point something needs to be shared. Afaik there's no mutex object in dx12, but does using fences work? Here's my current plan that seems to work, but I'm wondering if it could be better or what other people do. I want the compute queue to run as fast as possible, and as many times as it can, but I also want the draw queue to stop it when drawing needs to happen.

F0 <- 1

F1 <- 0

Compute loop:

* queue->Set F1 = 1

* queue->Wait for F0 == 1

* Exec command list

* queue->Set F1 = 0
Draw loop:
* cpu->Set F0 = 0, this should stop new computes from starting
* queue->Wait for F1 == 0, this should wait until the currently executing compute command list is finished
* Exec command list, compute queue should not be executing anything at this point
* queue->Set F0 = 1, compute queue can run again
I'm pretty sure there's a deadlock in there somewhere but whatever.
Should/could I do this with one fence instead of two? If I have a bunch of command lists pending inside the compute queue, I want the draw queue to take priority so that I can stack a bunch of stuff into compute but maintain priority for drawing. Obviously this will fall apart if a compute command list takes too long and the draw queue waits for it, so I want compute command lists to be pretty fast relative to draws.
I think setting the queue priority would let me do this -- i.e. if two command queues are waiting on the same fence, the one with higher priority should get it? But all the documentation says is

The priority for the command queue, as a D3D12_COMMAND_QUEUE_PRIORITY enumeration constant to select normal or high priority

so idk :(.
Advertisement

You should use fences for multiple queue synchronization on GPU.

Conceptually, I suggest something like this:


commandQueue1->ExecuteCommandLists(...);
// Insert a fence.
{fence, value} = commandQueue1->Signal(fence, value);
// Do some work...
// The next execution of commandQueue2 needs the results of commandQueue1.
commandQueue2->Wait(fence, value);
// The following execution will not happen until the fence is reached.
commandQueue2->ExecuteCommandLists(...);

Why would you down vote somebody for attempting to give an honest answer to your question, even if you disagree with it? You just said "I don't know the answer, but I know that's not it and you're wrong. Piss off mate". That's what you just said.

Why would you down vote somebody for attempting to give an honest answer to your question, even if you disagree with it? You just said "I don't know the answer, but I know that's not it and you're wrong. Piss off mate". That's what you just said.

I'm not saying that the downvote was justified, however let's not start an unnecessary heated discussion, let's wait for Dingleberry to respond.

FastCall22: "I want to make the distinction that my laptop is a whore-box that connects to different network"

Blog about... stuff (GDNet, WordPress): www.gamedev.net/blog/1882-the-cuboid-zone/, cuboidzone.wordpress.com/

I don't want to talk about up/downvoting at all, unless you're talking about compute shader vote functions. I didn't tell anyone to piss off, they simply didn't read my post.

Have you looked at the nBodyGravity sample? I think this does exactly what you're trying to do: simulate as frequently as possible and every now and then render the results into the swapchain buffer. It uses multiple threads as well as multiple queues.

I need to go over it again, but why are multiple threads necessary? In this case the threads don't seem to be performing a whole lot of work -- I understand it's a sample, but even then the situation seems to be a lot of compute work vs not too much time to assemble the compute command list. Wouldn't it be fine for the main thread to synchronize both command queues?

They aren't particularly necessary, it's just an example of using two independent workloads with non-symmetric sync points, on both the CPU and the GPU. It's basically showing "if you would synchronize two threads on the CPU this way, here's how you would synchronize two queues on the GPU."

This topic is closed to new replies.

Advertisement