Jump to content
  • Advertisement
Sign in to follow this  
Bejan0303

multithreading software renderer

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

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
"it can only be 'current' in one thread at a time."

What does 'current' mean in this case?

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!