Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Use of immediate context with multithreaded rendering


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Deortuka   Members   -  Reputation: 493

Like
0Likes
Like

Posted 10 March 2013 - 05:34 PM

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.


Edited by Deortuka, 10 March 2013 - 05:37 PM.


Sponsor:

#2 MJP   Moderators   -  Reputation: 11736

Like
1Likes
Like

Posted 10 March 2013 - 06:16 PM

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.



#3 Jason Z   Crossbones+   -  Reputation: 5284

Like
1Likes
Like

Posted 10 March 2013 - 07:49 PM

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!



#4 Deortuka   Members   -  Reputation: 493

Like
0Likes
Like

Posted 11 March 2013 - 07:55 AM

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.



#5 kubera   Members   -  Reputation: 964

Like
0Likes
Like

Posted 11 March 2013 - 10:41 AM

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






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS