Jump to content
  • Advertisement
Sign in to follow this  
Pyrogame

DX11 [Solved] Multi-Threading SlimDX DX11 Radeon Win7 Crash

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

Hi, I write an engine for a game in C# using SlimDX (like many other developers here too ^^). One of the features is multi-threading. I do this using the deferred context of the DX11-API. Each of my threads collects the calls in its deferred context, then the deferred context is executed on this thread. Because the device is synchronized (I'm not using singlethreaded flag!), all the threads can execute their calls itself on the device. I do not need a 3rd thread, which gets the calls and puts them to the device (because this would be singlethreaded rendering!). All is working well. Now, I have a new test code for the engine, which renders parallel in 2 threads into two Win7-windows. First I created the two windows, then I created two threads, which do the DoEvents()-stuf for each window. Then on each window I created a render target. Two other rendering threads renders parallel to this two render targets. In the first few seconds, it seams that all is ok. But then the application crashes. For some reason the GUI of my Win7 gets errors too. You can see, that the window-vertices (I mean the real gui-elements in Win7) becomes crazy, or the textures becomes streched. If I create the device in SlimDX with the debug option, then the application says, there is an internal error of an external component, and that's all. On a REF device, in 90% of the tries, the GUI of Win7 becomes instable and crashes the device driver, which, after a few seconds, resets. I'm using the newest Radeon on my 5870. Has someone the problem too? Or maybe I'm wrong assuming, that I can use two threads accessing the immediate-context on the DX device simultanously (which should be synchronized internally and executed successive). [Edited by - Pyrogame on March 8, 2010 2:43:40 AM]

Share this post


Link to post
Share on other sites
Advertisement
You're misunderstanding how the multithreading functionality works. The point isn't to allow to have two threads using the device simultaneously, the point is to have multiple threads building up portions of a command list so that your main rendering thread can combine the portions into one big command list that can be submitted to the GPU. You're incorrect when you say that this would be like single-threaded rendering...using a deferred context allows you to spread the overhead of building the command list over multiple threads. The final part where you combine command lists is relatively cheap.

Ultimately your deferred contexts need to be serialized into a single command list. This is because the GPU only reads one command at a time, so you need to make sure that the command lists from your deferred contexts are combined in the order needed for the GPU to properly draw your scene.

If you want to support multiple output windows, you need to do it the old-fashioned way: create a swap chain for each window, render each view seperately, and present with the corresponding swap chain.

Share this post


Link to post
Share on other sites
Thank you for you comment MJP. I figured it out (with your help), why my way didn't work.

In my opinion, the deferred contexts are only simple software lists. So it shouldn't matter, how the lists are pushed to the immediate contexts. If you use a 3rd thread, you automatically serializes the lists. And this was my problem: the synchronized executing of the command lists. Because I render all my stuff in renderings threads, it doesn't matter, that this threads waits for the (synchronized) immediate context to push their commands. In my opinion, this is faster, than using a 3rd thread.

Now, instead of using a 3rd thread, I simply synchronize my immediate context like this:

for every rendering thread:
render to deferred context
build the command list
lock (immediateContext) {
immediateContext.ExecuteCommandList(commandList, false);
}
dispose the command list


Only the immediate contexts has to be synchronized. Other things, like the device itself are already synchronized by SlimDX or DX. And this was something, I misunderstud in the DX-API :) Now, all the threads render, render, render, and if one of them becomes ready, it renders to the device. Only, if two threads finishes the work simultanously, one of them has to wait for the other to execute the command list. This should be more efficient than using a third thread, which implies synchronized passing of command list from the rendering threads to this 3rd thread, etc.

Thank you for your help :)

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!