Hello all!
I was think about way to multithread game engines and rendering. I looked at various designs online and didn't really like any, none of them really multithread rendering because the render context etc. (Correct me if I'm wrong). I was wondering if a well designed and thoght out multithreaded software renderer would be comparable performance wise to its hardware accelerate cunter part. I doo understand that the gpu is specialize of these calculations, but I figured 8 good workers can probably produce more than 1 awesome worker. I try and do some research on the topic but couldn't find anything. I was considering testing the idea myself, but wated some input from people smarter and more experienced than myself first.

Bejan

A modern GPU is more like 1000 awesome workers than one awesome worker. Plus dedicated hardware to do various bits o f the rendering a general purpose CPU cannot get anywhere close to this performance.

What do you mean by "the render context etc." Do you mean that since you generally don't want to render things at different frame rates, multiple rendering threads will have to sync up per frame, thereby negating their threaded impact? I agree that this is an issue with multi-threaded rendering. The thing is, the modern GPU is incredibly powerful. The CPU is often the bottleneck nowadays when blasting triangles through the card. What a multi-threaded approach is useful for is setting up all your vertices / textures / etc. (through physics-based mesh placement, shader-driven texture filtering, etc.) to render your scene with. If your physics code runs on it's own thread (processor), and your large-scale-terrain engine runs on another (if the two things are separable), then you've basically doubled the potential framerate of your code by multi-threading it.

A multi-threaded rendering approach would be good for software rendering. Maybe ray tracing? An interesting thing about that approach is that, if you break a scene into 8 different segments, and each segement raytraces a portion of the scene, you're essentially implementing a parallel processor (like a GPU) through multi-threading!

Ah I see, I didn't realize it was so much better at its job. It just bothered me how I appears rendersing takes up the most cpu, but can't very well multithread it. Is there no good way to take adantage of the 4+ core on the cpu? Also then (not to sound ignorant) why do people still bother righting them? Just fun/learning experience?

Edit: I apologize funkymonkey I must have posted this initially around the same time as you and not seen your post. By rendering context I was referring to the inablilty to draw more then one triangle at once e.g. one thread attempts to draw its models, and the other thread tries to draw there's. At best I would think you would get triangles with vertices from both models. Even if the gpu and driver could differentiate the threads and keep the triangles correct, each thread would have to run the equivalent speed (I think this is what you were saying) which might not be so bad if the driver could keep everything straight I suppose. But with software rendering it would be designed around the idea of multithreading.

Even with the physics, ai, etc it seems like rendering takes most of the cpu time (~70% rendering, ~30% else) which can't be multithreaded, does that mean the only reasonable solutions are to just deal with the lack of balance, or do more physics, ai, whatevr else?

Thanks for the quick responses.

Bejan

[Edited by - Bejan0303 on December 5, 2010 12:54:03 PM]

The experts can correct me if I'm wrong, but I don't think rendering takes that much of the CPU time in a modern game/renderer, and if it does it's simply due to batching issues and state changes. Which should be correctable with smarter scene organization and/or a thread-safe rendering context (DX11) so you can have multiple threads submitting commands at the same time.

[Edited by - doesnotcompute on December 5, 2010 1:21:24 PM]

I'm no familiar with directx passed 9 really and hardly that I prefer opengl (not for any reason other than I learned it first it feels better to use) I'm not a fanatic about it either way. Does opengl havethe same ability in that regard?

Bejan

I don't think so... you could ask over at the opengl.org forums though.

Well that's annoying. I hope they are working on that. Well anyway. That's a lot guys, I just was curious about the idea. You know, think I could revolutionize the industry (jk). Thanks for the information.

Currently with OpenGL the context is bound to a single thread; you can move the context between threads but it can only be 'current' in one thread at a time.

With DX11 you can create 'deferred contexts' which allow you to build command lists on multiple threads; however the final submission to the graphics card can only be done via a single thread (however you could interleave this with your next frames update step).

"it can only be 'current' in one thread at a time."

What does 'current' mean in this case?