OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

The OpenGL Pipeline Newsletter - Volume 001

Table of Contents
Previous article: Free OpenGL Debug Tools for Academic Users
Next article: New Texture Functions with Awkward Names to Avoid Ugly Artifacts

Superbuffers Working Group Update

As you might have heard, the scope of the Superbuffers Working Group has broadened considerably.  After we finished the EXT_framebuffer_object extension, which you all know and love (I hope!), we started working on adding some missing functionality.  Some of you expressed interest in features like rendering to one and two component render targets, as well as being able to mix attachments of different dimensions and even different formats.  But most importantly, you wanted to be able to find out how to set up a framebuffer object that is guaranteed to be supported by the OpenGL implementation your application is running on.  In other words, how can you set up a framebuffer object so that the dreaded GL_FRAMEBUFFER_UNSUPPORTED

error will not occur?  We worked on a solution for this, but started to realize that this was really hard due to some choices we made in EXT_framebuffer_object.  Looking ever deeper, we realized that the current object model in OpenGL is, in large part, to blame for this.  As a result, we are now working on a new object model for OpenGL.  You might have seen the presentation at GDC.  A summary is described here: http://www.gamedev.net/columns/events/gdc2006/article.asp?id=233

The goals of the new object model are several.  First, we want to provide top rendering performance.  The current object model has performance cost associated with a name lookup every time an object name is passed to the OpenGL driver.  This cost is only going to increase due to the widening gap between CPU and GPU performance.  Second, there is a performance cost every time you make a draw call l (

glBegin, glDrawArrays, etc.).  The OpenGL driver needs to perform a non-trivial amount of validation work before starting to draw.  This is especially important if the draw call only consists of a few primitives.  Third, we want to eliminate difficult race conditions which arise when sharing objects across multiple OpenGL contexts.  For example, what happens when you change the filter mode of a texture object in one context while also using that texture object in another context?  Last, but not least, we want to make the new object model simpler to use.  State-based errors are a pain to deal with. Say, for example, that one part of your code calls glActiveTexture

, another part of your code binds a texture object, and a third part of your code sets the filter mode for that texture object—at least, you hope.  The active texture state might not be what you wanted it to be at that time.  We’re going to change this model of binding objects just to set a parameter.  In the new object model, any command that sets a parameter of an object will take a handle to that object.  No more confusion!  Furthermore, object creation will, if successful, always return a handle to the newly created object.  The application can no longer make up a name for an object.  This is a key component of the new object model, and will help us achieve the goals just outlined.

We will be posting updates to www.opengl.org whenever we have something to share.  Watch that space!

Barthold Lichtenbelt, NVIDIA
Superbuffers Working Group Chair


About OpenGL