Multi-threaded OpenGL

How hard is it to write OpenGL code that is multi-threaded? I want to write C code that takes advantage of a second processor…how (non)-trivial is this?

The same as level of difficulty as writing any other multi-threaded program.

Multithreaded programs in general are pretty difficult to write, but that’s not a topic for here…

The particular caveat for OpenGL is that although you can make OpenGL calls from any thread, the current context is per-thread state, and you must not make OpenGL calls to the same context from two different threads simultaneously.

OS X will spin off some tasks into a seperate thread if a second processor exists, although I’m not certain of the granularity of this - whether it’s moving an entire app to a second processor, or moving particular tasks. I suspect that without special development, it’d be app-based.

What about writing one thread to calculate geometry, and another to render it to the GPU? That would avoid the context issue noted above, and allow you to maximise use of the dual processors. You could communicate between the threads using simple flags, to let the renderer know that the geometry is in a ‘renderable’ state.

If it turns out that your rendering code generally consists only of submitting a bunch of pointers to data blocks, then you’re better off using the second processor for other tasks (eg AI/physics for a game).

Originally posted by Gary Patterson:
OS X will spin off some tasks into a seperate thread if a second processor exists, although I’m not certain of the granularity of this - whether it’s moving an entire app to a second processor, or moving particular tasks. I suspect that without special development, it’d be app-based.

It will run threads on whichever processor is available. By default though, your program only has one thread, and in the case of an otherwise idle machine, the second processor is essentially idle.

Audio is one case where you do get to take advantage of the second processor essentially for free, since the audio processing will be done in another thread.

What about writing one thread to calculate geometry, and another to render it to the GPU? That would avoid the context issue noted above, and allow you to maximise use of the dual processors. You could communicate between the threads using simple flags, to let the renderer know that the geometry is in a ‘renderable’ state.

From what I understand, this is essentially what Q3A does, so it’s probably a good idea

If it turns out that your rendering code generally consists only of submitting a bunch of pointers to data blocks, then you’re better off using the second processor for other tasks (eg AI/physics for a game).

Just be careful not to get bogged down in the synchronization aspects. It’s very easy to lose all the advantages of multithreading by having over-communicative threads.

It’s also not a task for the weak-hearted… single-threaded development is /much/ easier. Don’t commit to a multithreaded design unless you’re really sure it’s worth 3-5x the development time for the extra few percent of performance…

[This message has been edited by OneSadCookie (edited 10-06-2003).]

Originally posted by Gary Patterson:
[b]OS X will spin off some tasks into a seperate thread if a second processor exists, although I’m not certain of the granularity of this - whether it’s moving an entire app to a second processor, or moving particular tasks. I suspect that without special development, it’d be app-based.
B]

I doubt even Apple would be so stupid as to make it “app based” as you suggest :smiley:
Actually the multi-threading in mac os is based on the BSD kernel’s implementation…it has nothing to do with any apple software.
Jasonk, if you want good answers to your questions, your better off asking this question in the Linux forum… they know what they are talking about there and the answers are directly applicable to what you’re using.
(Therefore the next question you should ask yourself is "why am I paying through the nose for a unix-variant software under Apple’s name when I can get the exact same underlying system for free, with Linux which has much better support? ")
By the way, OpenGL on the Mac is NOT re-entrant so it might not do you any good for you to have it multi-threaded.

Thanks everyone for your input. I was just curious because although I have not done any multi-threaded programming (and it doesn’t seem easy to learn) the OpenGL/C code that I’ve written flips back and forth between the two processors (at least according to CPU utilization by the CPU Monitor utility.) Neither processors gets to 100% or 0%. Each alternates between about 25% to 80% in rapid succession.

Threading on Mac OS X is actually based on Mach threads, which are nothing to do with BSD, though they may have use some of the higher-level code from BSD’s pthreads implementation…

Whilst it’s true that OpenGL is not reentrant on Mac OS X (nor on any other platform AFAIK), there are definite benefits to moving all your OpenGL calls into a secondary thread. Q3A gets nearly double the FPS on a dual-proc machine.

I still wouldn’t recommend it unless you really know what you’re doing…

As for flicking between the processors, that’s normal. The OS makes no distinction between them; it’s of no benefit for one program to stay on one CPU consistently. If your app were more CPU-intensive, you could get up to about 97-99% of one CPU, depending on what else your computer is doing.

Originally posted by OneSadCookie:
Threading on Mac OS X is actually based on Mach threads, which are nothing to do with BSD, though they may have use some of the higher-level code from BSD’s pthreads implementation…

That’s true but irrelavent to almost 100% of programmers. They don’t have to deal with mach threads directly… at all.

I don’t disagree with that, only with the statement that Mac OS X’s threading is based on BSD’s…

For a platform that no one seems to be making any new programs for, there sure is alot of activity here!
Is it really worth it writing software for macs nowadays?

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.