[D3D] How about a render thread

[chronozphere]

Hi all. :)

I consider to add a second thread to my engine wich will render the scene, while the other is executing the gamelogic, physics, building matrices etc.. :)

But i wonder whether this is worthwile or not.
Of course it will be much faster on Hyperthreading or Dual-Core CPU's. but do i get a speed increase when working on an older machine. :?
Is D3D fully thread-proof??
Is it hard to design a system wich maintains the resources and tells a thread whether it has acces or not??

Does anyone have build a multithreading engine, if so... were there many problems?.. is it time consuming to get it working correctly?.. are such engines bug-sensitive??

Thanx in advance 8)

[cronodragon]

I have a multi-threading engine in Delphi. In an earlier version, I used to have several threads for each task, but now I only have 2. Ofcourse there is the main thread of the application, and I have 1 for the game loop (reading input, rendering, logic, etc), and another is for loading resources, just that.

The problem with more thread is that it wastes a lot of CPU and is very easy to produce a critical error. Also it adds tons of memory. For example, I had to save current work for other threads to use it until the next work was finished. If that work means vertex buffers, textures, and other huge data, then it becomes a big problem.

Also debugging is hard, very hard. Sometimes you get errors that never happen while debugging!!! And there is also the synchronization problem. Sometimes I had to waste lots of time wating for another thread to synchronize... if you have to do that, there is no advantage on using threads, even on multithreading systems.

I think, instead of multithreading, a good technique are breakeable loops. I mean, if your have to generate something in a loop, just set how much time you want to spend on it, break it when the time is over, and in the next cycle of the engine re-take the loop at the last step. That's much easier to debug, and you can balance the processing to your needs... indeed I'm going to check if I can replace the resource loading thread for this method :D

[chronozphere]

So building a multi-threaded engine isn't always the best/fastest way to preformance :?.
3 Threads is very impressive :o But i didn't think you chose the easy way. I am looking for an easier way.:)

if i want to implement multi-threading. I wouldn't use 3 threads, but just one main and one render thread.
Does it really to be that difficult?? :?

What is the best way to divide tasks between threads??

[savage]

And then you need to start thinking multi-processor as well.

[cronodragon]

Multithreading in Delphi is very easy, just inherit the TThread class, and override the Execute method. Making the code is just like making any other code. Use Resume to start the execution. The problems start when you exchange information with other objects, and it gets worst when they are in different threads.

Many books I have read say something like "oh, by the way, you can use multithreading and make your games even better!". Then why are they keeping with the old fashioned game loop?? Just because it's optimal. The same happens with event driven phylosophies.

My own conclusion is that multithreading is not something that you just add and everything gets enhanced. It's just a solution for certain problems that can't be addressed in another way. For example, to deal with blocking sockets or reading from slow storage devices.