   DirectX9/10 multithread question...
  I've created in these months a multithreaded game engine for my projects, it works by dividing the work between several task, each task with a certain objective. (Draw, Update, Audio + Core (Core is the main loop) + the ones defined by the specific project)My question is...I've set the MULTITHREAD flag in DirectX9, what does this flag assure (cause the MSDN is not that clear)? I mean, i know that all draws must be executed on the same thread, but can the VertexBuffer/IndexBuffer/Texture update happen on thread different from the draw one?   
  If you set that flag in D3D9 or D3D10, then the device will enter a critical section every time you call one of its methods (or a method on any objects created by the device, like a texture or vertex buffer).  This makes it safe for you to do whatever you want from multiple threads, but it will end up serializing all of your API calls which will kill performance.For this reason it's generally best practice to have only one thread deal with Direct3D stuff, and then let other worker threads synchronize and communicate with that thread.  So for example if you wanted to to do background loading of textures, you would have a worker thread do all of the file I/O and preprocessing of the texture data (scaling, mipmaps, format conversion, compression, etc.).  It would then hand off the raw data to the Direct3D thread, which handle the relatively simple task of creating a texture and filling it with the raw data.D3D11 actually has *real* multithreading capabilities, in fact there are D3D11 drivers for D3D10 hardware available if you're registered developer with Nvidia/ATI.[Edited by - MJP on May 4, 2009 5:42:10 PM];Quote:Original post by MJPIf you set that flag in D3D9 or D3D10, then the device will enter a critical section every time you call one of its methods (or a method on any objects created by the device, like a texture or vertex buffer).  This makes it safe for you to do whatever you want from multiple threads, but it will end up serializing all of your API calls which will kill performance.For this reason it's generally best practice to have only one thread deal with Direct3D stuff, and then let other worker threads synchronize and communicate with that thread.  So for example if you wanted to to do background loading of textures, you would have a worker thread do all of the file I/O and preprocessing of the texture data (scaling, mipmaps, format conversion, compression, etc.).  It would then hand off the raw data to the Direct3D thread, which handle the relatively simple task of creating a texture and filling it with the raw data.D3D11 actually has *real* multithreading capabilities, in fact there are D3D11 drivers for D3D10 hardware available if you're registered developer with Nvidia/ATI.Ok, basically the same way i'm actually doing things, using only the draw thread to do any kind of DirectX call. So no change and i'll wait for D3D11, thanks. :D   ;  For DX9:If you have a multithreaded device, you can do whatever you like on multiple threads. You can update a texture from one thread, and draw in another. However, you'll still cause a stall if the GPU needs a resource that is locked by your application.You can make draw calls from any thread, but there's some functions that must be called from the same thread that is processing window messages, such as CreateDevice(), Reset(), TestCooperativeLevel() and the final Release() on the device.Without the multithreaded flag, all of your D3D calls must come from the thread that processes your window messages.   