Multithreaded renderer

Hi boys and girls!

I would like to make advantage of hyperthreading capatibilities of modern Pentium CPUs in my OpenGL renderer and just need some ideas how to realize it.
I don’t want you to tell me how to program the “perfect” multithreaded renderer, but i need some ideas, thoughts, suggestions on this subject.
Tuts or tech papers would be nice, too. :wink:

Thx in advance, moebius

Easy: Don’t! :wink:

No, seriously, the renderer itself should not be multiple threads. That is, do not create multiple threads with one OpenGL context per thread bound to the same window at the same time.
In the end it’s one shared hardware resource doing the work.

Leave one thread for the OpenGL rendering and use other threads for parallel work for the next frame, like culling, physics, animation, texture loading, sound, whatever.

Search for multithreading in the “OpenGL on Windows” forum, there are answers to asychronous texture loading for example.

Thank you for your advice. I think I will forget about this idea and do it the way you said, binding the physics (and the sound, if I will ever create sth. like a sound engine) to different threads.

You can also offload some graphics related stuff like visibility testing onto other CPUs/threads but you need to pipeline it correctly, double buffer some information and don’t require high frequency low latency sync between threads.

I’m not very familiar with multithreading, as you might have seen, but for example the visibility tests: Isn’t it possible that the renderer will render sth. that isn’t visible anymore (the expensive, but not so bad case) or won’t render sth. that’s actually visible (the worse case) if the render-thread and the VisTest-thread are out of sync?

You have to make sure that the threads don’t get out of sync.

For example, have one thread that does visibility testing. This thread puts everything that has to be rendered into a queue. When it’s finished it sends the queue to the rendering thread and starts building the queue for the next frame while the rendering thread works on the queue for the current frame.

Okay, so I still have a speed improvement (in best case) because the vis test on the (n+1)th frame is done while the nth frame is rendered. I think I’ll have a try on this, thanks.