Use of immediate context with multithreaded rendering

Started by
3 comments, last by kubera 11 years, 2 months ago

I have decided to rewrite my entire engine to take advantage of scalable multithreading using Intel Threading Building Blocks (TBB) to handle the actual threading part. This also means rewriting my rendering code to take advantage of the multithreading features of D3D11. My original thoughts were to do something along these lines:

1. Create immediate context

2. Create a deferred context for each rendering "task" (terrain, buildings, shading, user interface, etc...)

3. Generate command lists on each deferred context in parallel (TBB handles dispatching these "tasks" to different threads)

4. Execute all command lists on the immediate context.

This seemed like a solid idea until I came across http://www.tecgraf.puc-rio.br/~abraposo/pubs/SBGames2011/SBGames2011_Tutorial.pdf while doing some random searching today. The illustration on the bottom right of page 2 contradicts my idea of leaving the immediate context as a mere "command list executer" by using the immediate context to execute draw commands and then executing the command lists of the deferred contexts once finidhed drawing.

I am hoping that someone with experience rendering multithreaded in D3D11 will tell me if my idea to do all drawing on the deferred contexts is flawed, or if these are simply two ways of accomplishing the same goal.

Thanks in advance.

Advertisement

You don't have to issue Draw commands on the immediate context if you don't want to, the diagram is just showing that it's possible to do it.

MJP is exactly right - you are allowed to do extra stuff on the immediate context if you want to, but you aren't required to. So you are left with the choice of how to design your system, and as with so many design decisions, there are lots of variables to consider.

I have done some work with using the immediate context as the command list executer (like your description above) and I have found mixed results. In general there is a huge amount of variation in performance gains from multithreading compared to singlethreading, so it really depends on what you are rendering, what you are doing between draw calls, and what hardware you are running on.

My advice would be to design your systems to be flexible and customizable, so that you can profile and select the appropriate solution. In fact, if you can do that at runtime it would be even better!

Thanks for the answers.

The fact that the immediate context can be used in this way leaves the door open for a runtime switch. That is a really good idea! I will definitely add that option.

One separate rendering thread would be enough as a worker.

Having more threads implicitly created by TBB are not critical for efficiency, maybe.

http://xboxforums.create.msdn.com/forums/t/109327.aspx

This topic is closed to new replies.

Advertisement