The OpenGL Pipeline Newsletter Volume 004
Spring 2007
Table of Contents - All Volumes
Climbing OpenGL Longs Peak, Camp 3: An OpenGL ARB Progress Update
Since the last edition of OpenGL Pipeline we’ve increased our efforts even more. We held a face-to-face meeting in March and another face-to-face meeting at the end of May. Currently we’re on track to meet face-to-face six times this year, instead of the usual four! The ARB recognizes it is extremely important to get OpenGL Longs Peak and Mount Evans done. We also still meet by phone five times per week. This is a big commitment from our members, and I’m very happy and proud to see the graphics industry working together to make OpenGL the best graphics platform! Read on →
Shaders Go Mobile: Announcing OpenGL ES 2.0
It’s here at last! At the Game Developers Conference in March, the OpenGL ES Working Group announced the release of OpenGL ES 2.0, the newest version of OpenGL for mobile devices. OpenGL ES 2.0 brings shader-based rendering to cell phones, set-top boxes, and other embedded platforms. The new specification has been three years in the making – work actually started before the release of our last major release, OpenGL ES 1.1. Read on →
Longs Peak Update: Buffer Object Improvements
Longs Peak offers a number of enhancements to the buffer object API to help streamline application execution. Applications that are able to leverage these new features may derive a considerable performance benefit. In particular they can boost the performance of applications that have a lot of dynamic data flow in the form of write-once/draw-once streamed batches, procedurally generated geometry, or frequent intra-frame edits to buffer object contents. Read on →
Another Object Lesson
The OpenGL Longs Peak object model is substantially defined now, and we have a good notion of what a Longs Peak program will look like at a high level. Many smaller details are still being filled in, but after reading this article you should understand Longs Peak in considerable detail. Read on →
Transforming OpenGL Debugging to a “White Box” Model
The OpenGL API is designed to maximize graphics performance. It is not designed for ease of debugging. When a developer works on top of OpenGL, he sees the graphics system as a "black box;" the program issues thousands of API calls into it and "magically" an image comes out of the system. But, what happens when something goes wrong? How does the developer locate the OpenGL calls that caused the problem? Read on →
Editor: Benj Lipchak, AMD
Web Layout: James Riordon, Khronos Webmaster
Contributors:
- Barthold Lichtenbelt, NVIDIA
- Tom Olson, Texas Instruments
- T. Hunter, Object Model Technical SubGroup Contributor
- Jon Leech, OpenGL Spec Editor
- Yaki Tebeka, Graphic Remedy