Home > Articles > Programming > Graphic Programming

OpenGL Is Alive and Well: New Features, Capabilities, and Strengths for Modern Graphics

  • Print
  • + Share This
With new APIs, rendering effects, and other features changing the world of graphics, should you still care about OpenGL? Graham Sellers, lead author of OpenGL SuperBible, Seventh Edition, discusses why OpenGL is not only relevant, but offers updated features that rival some of the vaunted capabilities of newer technologies.
Like this article? We recommend

Over the last few months in 2015, we have heard a lot of talk about new APIs and how they enable new rendering effects and unprecedented performance. I am actually involved in the development of Vulkan, Khronos Group's new graphics and compute API. However, I believe there is still a place for the venerable OpenGL, which is why OpenGL SuperBible, Seventh Edition incorporates new features from OpenGL 4.5 and brings in discussion of extensions.

Some key topics addressed in this latest edition are part of what has become known as the "Approaching Zero Driver Overhead" (AZDO) suite of features:

  • Zero-copy features enabled by persistent mapped buffers
  • Arrayed indirect draws (multi-draw indirect, or MDI)
  • Sparse textures
  • Bindless textures
  • Advanced use of compute shaders

The book contains examples of the use of all of these features, some of which are available only on very recent hardware with up-to-date drivers that expose specific extensions. This marks a departure from the previous edition, in which I stayed away from extensions in order to ensure the widest possible user base for the code. Because these extensions have become more ubiquitous, I decided to showcase them. However, these features represent the cutting edge of graphics technology; at this point in 2015, OpenGL is the only way to get them.

Persistent Mapped Buffers

Possibly the most interesting of the new features introduced since OpenGL 4.3 is persistent mapped buffers, which were included with the GL_ARB_buffer_storage extension and are now part of OpenGL 4.4 and 4.5. In prior versions of OpenGL, it was an error to attempt to render from a buffer while that buffer was mapped. However, because the overhead is so great for a driver to attempt to figure out whether any mapped buffer might be used by a particular draw, it wasn't guaranteed that you'd actually see that error, and most drivers didn't do the check at all. Sometimes this kind of rendering would work, sometimes it would generate an error, and sometimes it wouldn't work but also wouldn't generate an error. OpenGL 4.4 made this use legal and well defined, so long as the application specifies its intention to use the buffer this way when it's allocated. This change allows an application to share a piece of memory between the CPU and GPU, and even deal with synchronization itself, which has implications for multithreading, fine-grained work generation, and efficient read-backs from the GPU to the CPU. Demonstrations of using persistent mapped buffers for shader parameters, vertex data, and texture data are included with the book's sample code in the pmbstreaming, ompparticles, and pmbfractal examples, respectively.

Multi-Draw Indirect (MDI) Functions

Another feature expanded in recent versions of OpenGL is the set of MDI functions, which allow a large list of parameters for draws to be placed in a buffer object and then sent to the GPU at once. (The sixth edition showed an example of this feature rendering an asteroid field.) In the original version of the function call, introduced in OpenGL 4.2, the number of draws in the buffer was passed as a parameter. This meant that if the draws were generated on the GPU, a roundtrip back to the CPU would be necessary–retrieving the value only to send it straight back to the GPU. GL_ARB_indirect_parameters added a feature to allow the draw count to be placed in a buffer as well. This change allows for using a shader or other GPU functionality to generate both a list of draws and the count, without CPU intervention. The seventh edition's cullindirect example demonstrates this feature.

Bindless Textures

Next, we come to bindless textures, an exciting new feature available only through the GL_ARB_bindless_texture extension. In traditional OpenGL, textures are bound to texture units, of which there are a finite number. While it's possible for an implementation to expose an arbitrarily large number of units, in practice most implementations expose only the minimum number required by the OpenGL specification. In GLSL shaders, textures are represented by sampler variables that normally refer to texture units and are declared as uniforms at global scope. Using bindless textures, the storage for a sampler variable becomes transparent as a 64-bit driver-supplied value, which can be passed to a shader in any manner the application chooses (such as inside a uniform block). The number of unique textures available to a single shader essentially becomes limited only by the resources available to the GPU. The bindlesstex example in the new book shows a simple demonstration of the feature.

Sparse Textures

Also extending OpenGL's texturing functionality are sparse textures, which are exposed by the GL_ARB_sparse_texture functionality. This extension separates the logical texture, its dimensions, format, and so on from the memory that backs it, allowing them to be allocated and managed separately. In addition, it allows a texture to be partially (sparsely) populated with memory. By using this feature, applications can create enormous textures that normally wouldn't fit into a graphics card's memory. Only the parts of the texture containing useful data are resident, allowing those parts to fit. This design makes more efficient use of video memory, reduces waste by not consuming memory for large parts of textures that are blank (for example, the gaps between segments in a texture atlas), and gives the application control over what's in video memory at any given time.

Direct State Access (DSA)

While that wraps up much of the AZDO feature set, OpenGL 4.4 and 4.5 have still more to offer. A big feature that finally made its way into core OpenGL with version 4.5 is Direct State Access (DSA), which provides a more object-oriented approach to OpenGL programming. To modify the state of an object in prior versions of OpenGL, you needed to bind the object to the OpenGL context and then call commands that would implicitly operate on the bound object. DSA adds commands that allow a program to specify the object to be modified without binding it, which prevents disturbing context state. The texture selector is eliminated, which can halve the number of API calls needed to set up texturing. In all, the GL_ARB_direct_state_access extension is possibly the largest single modification ever applied to the OpenGL API, and touches most parts of it. Where appropriate, we've updated the book's code and text to use DSA.

Final Thoughts

In addition to showcasing new API features, this latest edition of the OpenGL SuperBible demonstrates new techniques. Using multiple threads from an OpenGL program is covered by parallelizing application usage of OpenGL commands, as well as through generation of data in parallel using OpenMP. New samples demonstrate texture compression; culling from compute shaders; rendering of text and fonts; non-obvious uses for distance fields; and various new texture formats, blending modes, and other less dramatic features of OpenGL.

With the many improvements in the latest OpenGL specification, it's clear that there will be a place for OpenGL—and a need for updates to the venerable OpenGL SuperBible—for many years to come.

  • + Share This
  • 🔖 Save To Your Account