Good morning. My name is John Rosascco. I'm a member of the Apple OpenGL engineering team, and I'm here to talk to you this morning about the state of OpenGL on OS X. In this session, if you'll indulge me for a minute, I'm going to cover what OpenGL is in a slide or two.

And I know that's a little elementary for most of the crowd here, but I think it helps to kind of ground us in a minute before we go into the rest of the presentation. I'll also talk about OpenGL's role on OS X. We'll go through some of the new features and things that have happened in the specification and in Apple's implementation of the specification since WWDC '05. We'll talk about what's new in OpenGL for Leopard.

We'll go through some architecture slides, some of which, if you've attended previous WWDCs, you may have seen before, but we'll have some new stuff in there for you as well. We'll go through some of the new extension examples and we'll kind of roll that together with best practices and basically how to make the best out of modern OpenGL specification and the features that have been enabled in OS X.

So what is OpenGL? Fundamentally, it's a specification. And that specification describes a software interface to graphics hardware. The OpenGL specification, currently version 2.0, has been developed by the OpenGL Architecture Review Board, otherwise known as the ARB.

So what does OpenGL do? Fundamentally, it takes a few inputs. It applies, and those inputs are pixels and vertices.

Then some visual operation is applied to that data, and it produces pixels or fragments out. And really, if you take a look at it, back at Apple, we have the OpenGL machine printed out on the wall by our group, and it's about five feet wide and four feet high. This thing has, you know, it's basically describing a state machine, which is kind of feathered in here, that has an innumerable number of states, it seems like, at times.

But it's often good to just reflect back and say, what is it that this thing is doing, and where are we in those three states? Are we here at the input stage, where we're modifying this data? Are we in a kind of transformation stage, or are we in the output stage, you know, kind of the rasterization end of the pipeline? So OpenGL's role on OS X, I think it's pretty fair to say, is very unique industry-wide.

And its uniqueness is really rooted in the fact that there are application dependencies and API and framework dependencies because the Mac OS X user experience is so intimately tied with this kind of visual experience, all the way back to the genie effects you see when you close windows and all the compositing and transparency that's been, you know, now most folks are familiar with as far as OS X is concerned. You know, the heart of all that is OpenGL's processing that visual information.

So, as far as OpenGL being Grand Central Station, I alluded to some application dependencies earlier. You know, one of the most fundamental application dependencies is the Quartz Windows Server itself and all the windowing operations that are basically controlling the desktop and the OS X user experience. The other application dependencies, like iLife and iWork, represent a very broad base of Apple's, you know, basically their customer or their clientele that are using the platform. So, obviously, iLife and iWork is a big part of the OS X user experience. There's also the professional applications like Final Cut Pro and Logic and Shake, you know, for music and digital compositing.

And video editing. Those all also depend fundamentally on OpenGL as well. And there are also the API dependencies, some of them of which you may have seen in this session, such as Core Image or Core Video and the new Core Animation. These all depend on OpenGL as well as Quartz Composer.

So, new things since WWDC '05. We've been very busy. And one of the biggest new things is OpenGL 2.0, and I'll talk a little bit more about that later. GLSL. As of the last WWDC '05, we did have GLSL support, but it was only in software. Since that time, we have given GLSL full hardware support. The introduction of framebuffer objects at that time in the Mac OS X OpenGL implementation of OpenGL. Also, pixel buffer objects. For the first time, stereo and window on the platform.

And processing, we've added a feature for processing unit determination based on the enabled state for your application. We also added an extension for our Vertex and Fragment program that allows batching of program parameters and a lot more efficient kind of uses of the API so that you're not just hammering on the API to send these parameters into your shaders.

We've added an extension called Apple Flush Buffer Range for partial flushing of VBOs and more efficient use of the bus. We've added Intel GPU support, so that's kind of a big departure, or not big departure, but a big addition, because adding a driver is kind of a big deal on the platform. Obviously, not only is the GPU support there, but the OpenGL implementation has had to do a lot for CPU support for the Intel platform as well.

There's a lot of optimized paths, and when it comes to OpenGL development, there's no room for messing around or dropping megabytes per second on the floor when you're trying to move two or three gigabytes a second. So obviously, we've got to make the most advantage of the CPU that we have at our disposal.

So for Leopard, what do we have new? OpenGL 2.1 will be available in Leopard. And GLSL version 1.20 of the language spec, that GLSL 1.20 is available in the developer seed that you've gotten, or the Leopard preview DVD that you've gotten here at the conference. So that's ready to go. You can find out a lot more about the GLSL, modern GLSL usage and examples by attending Nick Burns' session, number 216.

We'll also add support for OpenGL ES 2.0 in Leopard timeframe. 64-bit support, a big one to make your application 64-bit ready. We have multi-threaded our GL engine and our command stream for processing. The pervasiveness of multi-core systems was just too tempting not to make that change, that transition. We'll have a new major version rev of OpenGL Profiler available in Leopard. And we're going to have some to-be-announced shader tools.

So this is probably one of my favorite things that's happened since the last WWDC '05, which is that our group has done a lot of work on updating the documentation so that you can get the most out of your application on OS X. This documentation is really superb. They had a lot of engineering support working with technical publications on this.

Very well illustrated, great examples, really great coverage and continuity across the platform. So I really encourage you to take a look at this. It was updated recently, June 28th. So I hope you find it as interesting and kind of compelling as I did when I first took a look at it.

So, on to architecture. As far as the architecture on OS X, I alluded to some of the diagrams you may have seen in previous years. OS X has some really unique challenges when it comes to architecting an OpenGL implementation. If you consider that you have a system that is capable of driving multiple displays using multiple heterogeneous devices from various different graphics vendors, that means that this one device may be driven by logic that was written in part by Apple and part by NVIDIA. This display over here is driven, again, in part by Apple, but by ATI or Intel. Then you take your application.

You have an extended desktop across those two devices. You move it from a GPU that has capabilities of, say, the ATI X1900 over to something with the capabilities of one of the older NVIDIA parts, for instance. You lose a tremendous amount of functionality as far as the GPU is concerned.

If there's a bunch of state that's not supported in hardware, obviously the implementation has to do something smart with all that state. It has to move it across. Basically, seamlessly. Make your application do what we call a renderer switch when you move it across. For these reasons, it's kind of why the OS X combination of OpenGL is quite unique. We'll describe the framework interface and the driver model.

So on the top of this diagram, you see your application. And on the left side, you'll see the windowing interfaces to OpenGL. There are three of those available on OS X. One is Glut. And you can see kind of the dependency chain for Glut. Glut depends on NSOpenGL view. So essentially, Glut is a kind of Cocoa-based, results in having sort of a Cocoa-based application.

Over to the right of that, you see AGL. And AGL is for carbon-based GL applications on OS X. Underneath Glut is NSOpenGL app kit slash Cocoa, if you want to put another slash on there. And always remembering that, you know, the app kit code and functionality is not interchangeable with AGL. So those are two paradigms you never mix. And similarly, because Glut is derived from NSOpenGL, you do not mix that with AGL as well. So underneath that, of course, is driving through the state to the OpenGL engine and drivers that ultimately control the hardware.

So as far as the driver model, we talked about the application and the framework interface. You may have heard in some of the State of the Union sessions some of the work about the OpenGL engine, and this is effectively another logical module. One of the kind of configure application, it's a modular implementation, so you're really just trying to wire together these different elements in a manner that makes the most sense logically.

Some of this wiring happens kind of beneath the covers for you, but ultimately you control this by choosing pixel formats and some of the state that you've set up in your application and so forth. So you have the GL engine kind of command stream, which then drives the commands into the driver layer beneath it, and we have our new Intel.

So you have the driver plug-in there in blue on the right, the previous three were at the last WWDC. And ultimately, once the driver state has been set, that drives the commands through to the hardware. So that's it for architecture. And after a little water, we'll go into features.

So, new features for OpenGL and Mac OS X. OpenGL 2.0. Now... If you consider, most of you are probably quite aware that when OpenGL makes a revision, a minor revision number is usually pretty significant. In OpenGL's case, a major revision number, therefore, is even that much more so. What makes OpenGL 2.0 much more significant than the 1.x series is the introduction of the GL shading language. That, of course, is the descendant of the arb-vertex-in-fragment program method.

The Mac OS X is a new feature that allows you to create your own custom Mac OS X.