Jump to content
  • Advertisement
Sign in to follow this  
maya18222

DX11 Dx11 Multi-threading

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

I understand that that calls such as setting state and making drawcalls have CPU overhead in that the CPU has to send the call down to the GPU and cannot continue until the call is complete. It is my understanding that these calls get stored into a CommandList at the Driver level which the user is abstracted from.

When using the multi-threaded api, you're essentially doing the same thing that the driver does, only from multiple threads. If each thread builds a commandlist and then these are processed by the immediate context one after another, why is it faster?

I guess what Im asking, is that in the end the the commandlists have to be stacked up and processed linearly by the immediate context, so where are the costs being reduced?

Share this post


Link to post
Share on other sites
Advertisement
Firstly the CPU doesn't have to wait till the draw call is completed by the GPU. In fact the GPU can be executing draw calls the CPU issued a couple of frames ago.

The basic idea of the optimization is that each draw call involves some CPU work to translate what you want done into a series of GPU commands which are stored in memory. These commands are specific to the GPU hardware. Once the command buffer is built the GPU should be able to execute it without any help from the CPU.

It's only a benefit if you're CPU bound, and aren't using the threads for other tasks.

Share this post


Link to post
Share on other sites
You also have to consider the fact that most implementations don't *ONLY* submit draw calls during their rendering code. There is usually some math done or whatever other logic that is performed on a particular rendering path. When you do it in parallel then you are amortizing those additional CPU instructions, which gives you some benefit.

In general though, I think the topic that Adam_42 mentioned are the primary benefactor of using the multithreaded rendering...

Share this post


Link to post
Share on other sites
Sorry, I didn't mean wait for the draw call to complete, I meant wait for the driver to add it to the Commandlist. I wasn't aware that these CPU calls had translate the DirectX draw call into a series of GPU commands, but I guess it makes complete sense seeing as there is more than one API, and each one will have its own interface or different ways of doing things.

I still find it odd that doing this parallel provides such a gain in performance. I've read about people going from a 50ms frame time down to a 30ms, which is a huge increase. Those CPU translation calls must be doing a lot of work I guess.

When I submit a number of calls to an immediate context, such

SetVShader()
SetPShader()
SetVBuffer()
Draw()

SetVShader()
SetPShader()
SetVBuffer()
Draw()

SetVShader()
SetPShader()
SetVBuffer()
Draw()
Present()

When exactly does the commandList get executed?
Could work be being added to the commandlist and it already executing calls that were previously added?

Share this post


Link to post
Share on other sites
In a multi-threaded app, since the GPU is able render your scene at the same time as the CPU is doing some calculations, could this sometimes cause inaccuracy for calculations that need to be "in sync" with the scene?

Share this post


Link to post
Share on other sites
There's a whole lot of overhead involved in issuing D3D calls. There's multiple DLL's involved (which is slow), there are user-mode to kernel-mode transitions (which are slow), there is validation performed by the D3D runtime, and after that the driver may have to do a non-trivial amount of work to further validate data and convert it to native GPU commands. There are a whole lot of games out there then spend a good portion of their CPU frame time just submittng D3D calls.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!