Romulus 2

 
x You are here: Home > Guides > Future Look: OpenGL 2.0



 

xRobert Richmond

Future Look: OpenGL 2.0

April 2002

Page Four

Contents
Page One: Introduction Page Three: OpenGL 2.0 Envisioned
Page Two: OpenGL 1.3 Limitations Page Four: OpenGL 2.0 Explained

OpenGL 2.0 Explained

The 3DLabs approach is to first extend software through utilization of certain OpenGL 2 standards, then gradually move code towards a "pure" OpenGL 2.0 environment. However, unlike DirectX 8, all OpenGL rendering conventions should be available for those seeking a pure OGL implementation at release, instead of staggering the releases in various subset revisions. As stressed earlier, the ultimate final goal is to reach a streamlined programming interface which offers hardware independency.

Each of the programmable processor pipelines (software and/or hardware) essentially eliminate and/or replace a significant portion of current OpenGL conventions. The programmable vertex processor replaces the current options for transform, lighting, normalization, texture coordinate generation and fog rendering. The fragment processor replaces the current operations for smooth shading, texture access, texture application, alpha testing and pixel transfers. The pack/unpack processor included capabilities for flexible pixel formatting during memory move operations to create a coherent and consistent stream of pixel data to the rendering pipeline. The clear benefits of these programmable options are increased performance and image quality by removing the dependence upon fixed functions of static T&L pipeline routines. The associated rendering conventions for each of these advanced routines will be unified through a comprehensive C-based programming language with special detail added for vector and matrix processing operations.

3Dlabs also suggests a new data buffer mechanism needs to be utilized for enhancement of the programmable rendering interface. The buffer would be used to enable multiple-pass fragment programs with full stream processing support. Usage examples include multiple outputs from a single fragment routine, intermediate result storage, multi-spectral imaging, and acceleration of back-end rendering by reducing the time needed for read-back of floating-point images by the host bus. Additionally, the buffer space would be accessible through either spatial or FIFO memory operations.

Today's OpenGL 1.3 provides no real direct control over when or where objects are stored or deleted within the memory address range. OGL 1.3 also provides no direct control over memory copies or address fragmentation. 3Dlabs plans to implement a new management routine to allow for improved timing control over memory operations. The OGL 2.0 proposal sets policies and priorities for all datasets with timing estimates provided for each task. Additionally, all pinned policy operations allow the application to control memory store/delete and packing operations.

Final Thoughts

OpenGL 2.0 is still in its development infancy, though 3Dlabs does offer some insight into the new features needed for this aging standard to maintain acceptance within the graphics marketplace. As noted earlier, the concepts and ideas presented here are only preliminary at best. 3Dlabs has issued no formal proposals to the industry, though it has engaged in much discussion about the possibility of a new OpenGL standard. The information gathered for this article was obtained through various discussion overviews published by 3DLabs and associated companies. Still, it appears 3DLabs and other developers are steadily moving forward with development of a new and exciting OpenGL standard that strives to offer the best compatibility with sustained performance across the widest variety of hardware configurations available.

   

Back to Top

   

Copyright © 1999-2002 Romulus 2. All rights reserved. Legal Notice / Privacy Policy.