OpenGL 2.0 - Out To Save Programmable Graphics

Functionality, Continued

• With the ability to get control of memory management if they want it, applications will then be able to adopt and dynamically change a policy. However, the application developers will have to incorporate usage hints for each object and communicate to OpenGL what the application knows about the data usage pattern. This will result in a true, "use once, use many times, write only, bind data asynchronously." It will also provide a unifying mechanism for all objects (e.g., textures, display lists, vertex arrays, images, pixel buffers and shaders). There's no distinction between textures, display list, vertex array memory, etc., and this does not prevent OpenGL implementations from having these object specific pools. Alternatively, an application can still let OpenGL manage memory; it's just another policy.
• 
  OpenGL 2.0 will use a pinned policy where the application gets control so that OpenGL will not move, copy, pack, or delete an object, once data is loaded. The object is pinned down in high performance graphics memory, which lets the application be responsible for storing or deleting objects, or for initiating a packing operation. The new organization is more efficient, as illustrated by the following diagram.
  

• Asynchronous OpenGL. By adding asynchronous operations to Open GL, OpenGL 2.0 will offer better parallelism and synchronization capabilities. OpenGL traditionally worries about how and where - not when. There has been a long-standing need for better mechanisms that know and control when things happen. Parallelism allows for work to continue, while something is finishing. For example, clear depth buffer while waiting for a swap.
• 
  OpenGL needs a generalized and unified synchronization mechanism that will eliminate the need for each extension to invent its own mechanism. This will: solve short-term problems such as parallel image download; enable more sophisticated use of timing control in the future; enable application to dictate the timing policy; control when things are going to happen; and allow parallel execution of longer OpenGL operations. These long operations can "run in the cracks" with respect to main rendering, which will provide better replacements for flush and finish.
  The net result will be that OpenGL (2.0) will have generalized time control capabilities that will improve parallelism and control of operation timing.
• GLsync. GLsync is a new OpenGL data type that will provide a unified synchronization mechanism. It can be viewed as a handle. Today, OpenGL provides allocate and de-allocate functions, but no application-managed ID space. In the new version, a thread can wait on a GLsync using OpenGL wait function. The graphics driver can unblock a thread waiting on a GLsync. Glsync can be used very broadly for things like: rendering fences; asynchronous data binding; event notification (e.g., vertical blank); triggered swap completion; and new things not thought of yet ... It will also provide optional integration into underlying operating system synchronization primitive.
• 
  Rendering a fence synchronizes a thread to a stream of rendering commands; it's a superset of the "Finish:" functionality. "Finish" requires stalls of host thread where no new rendering can be issued. OpenGL will be able to use Glsync for such notifications. A thread can issue fence, issue more commands, then wait on GLsync. A "wait" will unblock when the rendering preceding the fence is finished. This allows parallelism that Finish did not.