http://developer.apple.com/technotes/tn2006/tn2085.html

Doesn't mention that it's too buggy to actually use on 10.4.8

Maybe this is a silly question, but I'm not one to shy away from a silly question...

It seems to say that the only case where performance will really increase is when you're limited by CPU speed, but is that really the bottleneck with most OpenGL applications? It's been a while since I used OpenGL heavily, but I don't seem to recall the bottleneck being my CPU speed but rather my fill rate and graphics card... so really, how useful is this?

Useful enough that World of Warcraft is claiming an 80% (or something like that) performance improvement from it

Your mileage may vary.

This functionality works best for applications that are already well-written (using all the asynchronous fast paths correctly) but have so much CPU work (either of their own, or inside OpenGL) that the GPU is starved. By moving OpenGL CPU work (error checking, command submission etc) to a second CPU core, more time on the first core is available for the application. In other words, it will appear to your application that calls to OpenGL "return sooner". Really, the same work is still happening, it is just being processed on another core.

If your bottleneck is not the CPU (you are bound by fill rate, or bus bandwidth, or worst case disk access) then this won't do much for you.

Also, you should first tune your application to run asynchronously. If you have even one glGet inside your draw loop, that will become a synchronization point (so, always compile out glGetError with #if DEBUG or similar.)

WoW does see a real-world frame rate improvement of over 80% (i.e. spinning around on a mountain out in the wilderness with all detail cranked to max) on a beefy Mac Pro system. This improvement is very real, and it is in addition to other improvements realized via APPLE_flush_buffer_range. However, multithreaded OpenGL is not a magic bullet. Your application does need to be well-written, and be doing significant amounts of CPU work in order to realize benefit.

So, it might not help your application. But there are more CPU-bound OpenGL apps out that than you might think.

Does anyone have any ideas as to why Apple aren't supporting this on Multi-Core / Multi-Processor PPC systems? My G5 has just as many Core's as a MacPro and is less than a year old, yet it seems Apple has decided to forget about me yet again.

Firstly I had no graphics card upgrade option (until ATI announced the X1900 G5 Edition) and now this. If Apple are determined to obsolete PPC based Macs so quickly in order to encourage me to switch to Intel, all they are likely to do is push me away.

I don't know from a technological standpoint, but from a logical standpoint it would make sense that they continue to pressure forward and not waste too many resources on past products if the cost/benefit ratio isn't there -- which it rarely ever is. Apple maintains products for years, but they cease developing for them once they're out the door. All tech companies are like that.

As for the lack of video card upgrade options? The general rule is that you don't upgrade video cards in Macs, because it usually isn't cost effective. Look at the cost of the video card you might want, and consider the money saved from not buying it as money off your next Mac

It's not like it's making your computer obsolete. You can still run OpenGL on it, you just don't get the speed bump.

Would this help/backfire/not work/not make a difference for the GMA 950, which does T&L on the CPU?

My expectation is that the GMA 950 (on dual-core systems) will see the largest gains from this... but I don't actually know for sure