SL and OS X Leopard: OpenGL improvements

I was reading this at apple insider:


Can anyone at LL comment about the upcoming Leopard and SL performance on it? Will this enable SL to take advantage of both cores on dual core Macs?

Oooooh, sounds good.

Sorry, that's the most intelligent thing that I can manage, as I know nothing about this sort of graphical jiggery-pokery.

If SL works with it (which it sounds like any OpenGL app should) then this will be awesome indeed as it will be like running on multiple cores without LL having to do anything. Though I'd still like to see SL to use threading anyway, it ought to be a big boost for us on Macs

I was under the impression that Tiger already ran a lot of CPU-based processing in another thread. If not, I don't understand the performance difference between single- and dual- core Mac minis on straight-line graphics tasks.

It does for the GUI, but for general OpenGL apps the limitation is dependant on the application itself, if the app splits OpenGL handling into a separate thread then it won't see much if any improvement. But SL which doesn't seem to do this would have all it's OpenGL commands offloaded to run in parallel automatically.

You're maybe thinking of Quartz2D and Quartz2DExtreme, CoreImage and things like that? These are APIs or OSX GUI enhancements designed to do this rather than general improvements to OpenGL itself. This new development will automatically make all OpenGL apps multi-core aware

OH OH OH!
That is GOOD news!

Excuse me now. I must go to the back yard and tie a goat to tree to attract Leopards.

No, I'm referring to benchmark differences of straight OpenGL benchmarks between the original Core Solo and Core Duo Mac Minis with otherwise identical specs. I remember being quite surprised when benchmarks where Apple's OpenGL emulation had to pick up the slack from the GMA950 were significantly better on the Core Duo. Is it possible Apple made these special cases in the OpenGL support for the GMA950 chipset?

I'm so tired at looking at my CPU Menu Meter and seeing only one core being used (and pegged at that) when running SL.

/me does happy dance!

Hmm, which applications? There may be other aspects involved, or the apps themselves have been optimised to use multiple threads already. If it's a benchmarking tool in particular then I'd expect it to have been coded specifically to split off into threads itself.

OpenGL 2 compliance in itself is going to be an incredible speed boost because it will allow developers to leverage a lot of new hardware features through a standardized API. Most of these hardware features involve ways of offloading processing and storage to the GPU and avoiding having to schlep data back and forth thru the AGP bus. Version 1.5 already introduced VBOs and Array Index Buffer Objects which allow apps to basically upload gemometry data to GPU memory once and have the GPU processes it from ultrafast vram rather than pump it through the relatively narrow AGP bus every frame. The version 2 specification expands this model with the Pixel Buffer Object which basically will allow such nifty things as rendering directly to a texture, texture manipulation, blurring the distinction between vertex data and pixel data -- all totally on the GPU. All of this has been available on Windows (damn it) for quite a while through DirectX. I'm really looking forward to seeing it on the Mac.

Another great improvement is LLVM (nothing to do with Linden Labs despite the LL) and JIT compiling for the programmable pipeline. Older GPUs had fixed pipelines meaning that if a hardware vendor didn't provide a certain feature, developers would have to do it in software on the CPU. But the current batch of GPUs have a programmable pipeline. Basically this means that you can write programs that get uploaded to the GPU which tell the GPU how to process vertex and pixel data -- you might have heard the phrases "vertex shader" and "pixel shaders", this is what these phrases refer to. The language is powerful enough to program the GPU to do all kinds of cool stuff like toon-shading, shadow casting, motion blur, antialiasing, bump-mapping, reflection mapping, high-dynamic range lighting ... all the stuff a game needs for increased realism. And again, all within the GPU, freeing up the CPU to do other stuff.

But guess what, the programs that get uploaded have to be compiled, optimized and uploaded. Often several times per frame because not every surface is rendered with the same programs. This is where the new developments in Leopard come into play. LLVM and JIT are very low-level libraries which compile vertex and shader programs into highly optimized bytecode for upload to the GPU. This is the kind of stuff that will benefit greatly from multiprocessing. A graphics app has to handle a lot: IO (UI, network, file), scene management, physics, bone and skin deformation, particles, audio (which is also often offloaded to dedicated hardware) -- all of which has to be done for EACH frame. But really, all of that is completely independent of surface characteristics. Therefore, vertex and pixel shading can pretty much run in a completely separate thread without too many synchronization problems.

BUT, just because these features are available in the 2.0 API doesn't necessarily mean that ALL apps will benefit. IF SL has been designed around the buffer object paradigm, IF it makes extensive use of vertex and pixel shaders, perhaps then we'll see a big difference. However, ask yourself the following. Does SL make extensive use of dynamic, or procedural textures? Does SL have many different kinds of shading styles, like environment mapping, reflection, dynamic bumpmapping, toon-shading? Does it have tons of special effects like motion blur, antialiasing, full frame filters? Is there a lot of complex yet static geometry? Will LL incorporate such features in the future?

Frankly: the most complex graphics feature I see is multi-texturing which is basically the layering of multiple texures on a surface, introduced into OpenGL in version 1.3 (eons ago). OpenGL supports 8 layers. In SL I count 5: skin, tattoo, undershirt, shirt, jacket. Maybe 6 if you include gloves. But that's only on AVs. You can't even layer textures on prims.

Do we want all these things? Yes. But there are other things that are in more need of attention: stability, bandwidth, massive concurrency, security, overwhelmed customer service, an incomplete physics engine, a clunky UI, a painfully limited scripting system, and a seriously tragically rediculously quadraplegic modelling paradigm.