Sign in to follow this  

Direct3D11 Multithreading

This topic is 815 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

The device can be used by any thread. Feel free to load textures/models etc on any or all threads.

Contexts can only be used by one thread (at a time), but you can create as many (deferred) contexts as you need.

When you've finished submitting draw calls to a deferred context, you can call FinishCommandList to turn it into a ID3D11CommandList. You can then hand this over to your "main" thread (the one that owns the immediate context), and it can call ExecuteCommandList to send those commands to the GPU.

tl;dr-
Main thread owns "immediate context" and submits command lists.
Worker threads own "deferred contexts" and create command lists.
Every thread can use the device.

 

From what I know, you use threads to do work in parallel to load as many resources as possible at a time. But In std::threads, to make it work properly, I've to use thread.join() with mainthread for the mainthread to wait for that thread to finish the execution. Doesn't this completely destroy the purpose of threads? This is just like calling functions then.

Edited by newtechnology

Share this post


Link to post
Share on other sites

From what I know, you use threads to do work in parallel to load as many resources as possible at a time. But In std::threads, to make it work properly, I've to use thread.join() with mainthread for the mainthread to wait for that thread to finish the execution. Doesn't this completely destroy the purpose of threads? This is just like calling functions then.


No, because you can launch multiple threads and then join on all of them. This means you can have X functions executing in parallel. This is often called a fork-join model.

That said, use a thread pool and a job system instead of spinning up a new thread for every function call. Threads are heinously expensive to spin up and tear down on many platforms, and they're still somewhat expensive everywhere else. The job system can still be used in a fork-join for simplicity, of course.

Share this post


Link to post
Share on other sites
Yeah don't use fork-join in a game engine, it's not suitable.

Probably best to implement a threading system and apply it to some of your own code as a learning exercise before applying it to the D3D API.

The job model is very popular in game engines these days:
http://fabiensanglard.net/doom3_bfg/threading.php

Or alternatively, check out Intel TBB.

Share this post


Link to post
Share on other sites

As @MJP said you are unlikely to gain much performance using deferred contexts with D3D11 *unless* you are doing a lot of CPU intensive work that for whatever reason you cannot separate from your rendering logic *and* can actually be parallelised.

 

I've got a C#/SharpDX example https://github.com/spazzarama/Direct3D-Rendering-Cookbook/tree/master/Ch10_01DeferredRendering. You may need to take a good look at the code to work out how to drive it as it is assumed you are reading the book at the same time.

Edited by spazzarama

Share this post


Link to post
Share on other sites

This topic is 815 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