Once again, ATI and NVIDIA joined forces to present a full-day tutorial covering the latest and greatest happeneings in OpenGL. Unfortunately I was only able to attend the first half, but the first several sessions covered a number of vital developments that will greatly impact the future of OpenGL.

Changing of the Guard

The ARB is now working to transition the management of OpenGL to the Khronos Group by the end of the year. The Khronos Group manages a number of open, royalty-free standards, including OpenGL ES, which has quickly become the dominant 3D API for mobile devices. Having Khronos manage OpenGL will remove some artificial walls between the evolution of OpenGL and OpenGL ES, and will likely result in OpenGL being updated more quickly and marketed more successfully.

OpenGL on Windows Vista

Last SIGGRAPH, alarms were raised when it was learned that OpenGL support on Windows Vista would come with some limitations that were considered unacceptable by many. Developers and hardware vendors were asked to contact Microsoft and ask them to provide a path for IHVs to support OpenGL as a first-class citizen on Vista. As of the February Vista beta, this has now been done. See here for details.

OpenGL 2.1

The next update to OpenGL is on track to be released at SIGGRAPH 2006. The ARB is currently hammering out the details of several candidate features that may be included in 2.1. Anything not currently under consideration will not be included. The features being discussed are as follows:

• Pixelbuffer Objects, based on ARB_pixelbuffer_object. These work much like VBOs, using the same basic APIs, but work with image data instead.
• The OpenGL Shading Language will be updated to 1.20. New shaders will have to use #version 120 to take advantage of these changes. You'll be able to link shaders with shared versions, so it won't be necessary to rewrite existing shaders.
  • New texture functions based on ATI_shader_texture_lod will allow you to sample from a specific level, or sample passing an explicit derivative.
  • Built-in fragment special variables based on OpenGL ES 2.0 point sprites will be added for use when point sprites are enabled.
  • A new centroid qualifier will allow you to control where a texel is sampled when it's not fully covered by the fragment.
  • The update will also include some minor changes, some of which will be backward incompatable:
    • Names will be more C++ like. A name will hide names of all types (functions, variables, structures). You'll also be able to declare names within a scope, with the exceptions that local function declarations are not allowed, and you cannot redeclare within a scope. The built-in functions are considered to be in a sort of "outermost" scope. If you redeclare them, you'll hide all functions using that name (e.g. redeclaring texture2D will hide all texture2D functions, regardless of the signature).
    • Function signature matching will change such that the compiler will first try to find an exact match, then it'll try limited implicit contructors (i.e. int gets promoted to float, ivec3 to vec3, etc.). Multiple implicit matches will result in an error.
    • Arrays are now first class citizens. You'll be able to use equality, inequality, and assignment operators as long as they are explicitly sized, as well as use array constructors.
    • Non-square matrices will be permitted, and new outerProduct() and transpose() functions and constructors will be added to support them.
• Float buffers as per the current ARB extension. The only likely change is that if you try to create a floating point buffer and they aren't supported, the call will fail rather than falling back to an integer format.
• Support for sRGB textures. This would allow these textures to be used with correct filtering.
• ARB_synch_object derived from GL_NV_fence - but allowing sharing and using separated objects - and GL2_async_core - but a subset, with an eye to a later superset.
• They are working on an ARB_framebuffer_object, which will merge (with some changes) EXT_framebuffer_object, EXT_framebuffer_multisample, and EXT_framebuffer_blit. EXT_packed_depth_stencil will remain a separate extension. Mixed size and format attachments will be allowed, and R and RG formats will be added (L, and LA may be added as well). ARB_fbo_simple, EXT_framebuffer_format, and EXT_immutable_objects are some extensions that have been proposed to address format compatability, but nothing has been decided yet.

Other news

The ARB recognizes that they need to do more than just write a spec. To make OpenGL successful, they are going to be putting more effort into:

• Documentation
• Examples
• Courses
• Tools and utilities
• Conformance tests
• Marketing
• Cross standard collaboration

OpenGL: What's Next

ATI and NVIDIA have been working together for more than six months on a proposal to change the direction of OpenGL. Much of that time has been spent talking to developers to find out what they want from OpenGL, and this was the first time they presented what they want to propose publicly.

Disclaimer: All of this information is pre-workgroup; none of it has been officially proposed to the ARB yet.

OpenGL has matured over 13+ years. It's not always representative of hardware anymore, but it is fully backwards compatible (unlike other graphics APIs), which has obvious pros and cons. Significant new hardware functionality is on the way, and programmability is just the start. OpenGL needs to be market and timeline driven to provide only what is needed in a timely manner.

There has been talk for a few years of creating a version of OpenGL that doesn't maintain backward compatability, and it has been suggested that this might happen with OpenGL 3.0. But developers and IHVs have indicated that there is too much out there depending on existing functionality to make a fully clean break.

The proposal being worked on would divide OpenGL two profiles. The first, dubbed OpenGL Lean and Mean (or OpenGL LM) is the core API that is the right hardware abstraction, providing optimal performance. There would also be a full OpenGL profile that supports all existing functionality, as well as the LM profile. Once this division is made, most future efforts would be put into the LM profile.

Even in OpenGL 2.0, there are some features that are actually implemented in software layers on top of key core hardware functionality. With LM, this software layering would be removed. This would result in better drivers (since they would be considerably simplified), clear fast paths, and new features wouldn't have to make compromises to work with aging interfaces. With the full profile, anything that isn't in LM would be implemented as software layers. The following sections discuss the various stages of the pipeline and which features at each stage would be implemented in hardware and which would be implemented in software layers.

Drawing Geometry

What features to consider layering:

• Immediate mode
• Current vertex state
• Non-VBO vertex arrays
• Vertex array enables (with shaders, this should be automatic)
• glArrayElement()
• glInterleavedArrays()
• glRect()
• Display lists

Removing these would reduce the number of ways to get data to OpenGL, which would simplify drivers and hardware. VBOs would be the preferred method for transferring data.

They'd like to add:

• Geometry instancing
• Geometry-only display lists (for small static data, for instance) (no GL_COMPILE_AND_EXECUTE, since it's very problematic to implement efficiently)
• Arrays activated based on vertex shader usage

State Objects

They'd like to add new objects that encapsulate OpenGL state, so that you can switch between sets of GL state in one call. This could be a replacement for push/pop attributes. This would work very efficiently with VBOs in a way similar to display lists.

Vertex Processing

What features to consider layering:

• All fixed-function vertex processing (since IHVs no longer make fixed-function hardware anyway)
  • Lighting, materials, and flat shading
  • Texture coordinate generation
  • Vertex and normal transformation
  • Point size distance attenuation
• Built-in values in GLSL

GLSL enhancements

• Integer Support
  Full 32 bit integers full bit-wise integer ops integer texure lookups integer vertex attributes
  
  
• Offline compile (already in OpenGL ES)
  • Enables layering, faster startup, (limited) IP protection
  • Binary shader interface
  • Intermediate language interface
    
    
• Vertex position invariance across shaders (replaces ftransform())
• Enhanced interpolant control
  • Flat/smooth
  • center/centroid
  • perspective correct, or not
    
    
• Vertex ID (what vertex item am I?)
  
  
• Binding texture object IDs to samplers (skip texture image unit)

Rasterizing primitives

What features to consider layering: ARB imaging subset, since it isn't really being used. Most of this functionality can be done in fragment shaders anyway.

They'd like to add having coverage values accessible in the fragment shader

Fragment Processing

What features to consider layering:

• texture environments and functions
• color sum
• fog

What they'd like to add

• seamless cub map neighborhoods
• texture arrays (aka stacks)
• texture filter shaders

Changing the Object Model

In the current object model, teh application supplies an unsigned int "name", or requests one generated by OpenGL. When this object is used, the implementation does a lookup in a hash table to find the actual object. The object is then bound to edit or use it. Objects can be shared among contexts.

The problems with this model include:

• The cost for doing lookup can be 3-5% of driver overhead
• The binding process can cause application bugs because of the indirect reference
• It's actually too flexible, in that it's difficult for the driver to optimize because it can't predict what you're doing.
• There are some grey areas in behavior, such as reusing an existing name

They'd like to introduce a new object model that would improve performance, be easier to use (intuitive, fewer function calls), and easier to implement for IHVs (removing guesswork and race conditions) which will benefit developers with more optimized drivers.

Proposal:

• Object ID is a pointer instead of an uint (typedef void* GLobject)
• Object IDs are always generated by implementation
• Object manipulators take an explicit parameter (no more binding)
• Objects are immutable

Tradeoffs:

• Performance benefit for well-behaved apps (no more lookups)
• More expensive to create an object since the implementation has to allocate the pointer - but usage will be faster and has a bigger overall performance impact
• No more orphaining
• Easier to manipulate, but also easier to crash

Debugging support:

• Implementation may support a "debug mode" where object IDs are cached
• Implementation gives feedback on misued of objects (invalid object ID, incorrect type)

Immutable objects

• Object structure fixed at creation time (the data itself can be changed)
• Removes guesswork since structure is static
• Removes dangerous race conditions when an object is shared between contexts
• Simpler to optimize driver due to less overhead
• Encourages better application code with less state thrashing

New sharing model:

• Large objects (texture images, buffer objects, probrams) are always shared among contexts
• Small objects (state objects, possibly FBOs) are context-locked

Example: Texture image objects

• Encapsulate texture size, shape, and format
• No editable parameters
• glTexParameter() moves to GLSL shader
• No incomplete textures
• No glBindTexture() required, since the structure cannot be edited. New APIs will be needed for specifying the content.

Backward compatiblity

• New object may be "bound" to a legacy object
• New object behaves identically to old except for mutability

Sampler / parameter objects

• Context-locked object holds parameter state. These objects will be mutable since they are unshared.
• Bind image object diretly to sampler
• Bind sampler object to shader, or bind separate objects to shader

Benefits to other object types

• Buffer object size and usage
  • Resizes are messy
  • Redefining usage may force promotion
  • Enforces application behavior
• Framebuffer object attachments/formats
  • Avoids completeness check
  • Moves all guesswork to creation time
• Program objects
  • TBD

Texture Shaders

What features to consider layering:

• Texture filter state
• Texture wrap modes
• TExture comparision modes
• sRGB

Instead, have texture shaders in OpenGL LM

Sample Shader

What features to consider layering:

• Depth test
• Stencil test
• Blend

Instead, have sample shaders in OpenGL LM

Primitive Shader

Also called geometry shader, this is a new pipeline stage between vertex shader and rasterization.

Usability enhancements

• Better error handling
  • Callback mechanism
  • More error codes
  • More general glInfoLog() for all GL state - human readable
• Emphasis on tools

Misc

Consider layering

• Color index rendering
• accumulation buffer
• Evaluators
• Selection
• Feedback
• Multiple paths for specifying pixels/texesl

What will stay

• FBOs
• PBOs

Q&A

They want to make these changes as soon as possible, initially via extensions (so as hardware supports each, it can be immediately released), and then formally deprecate legacy functionality with 3.0.