The Khronos Group today released OpenGL 4.5, the newest version of the industry standard 3D programming API. The new version contains a mix of features designed to make developers' lives easier and to improve performance and reliability of OpenGL applications.
The big feature in OpenGL 4.5 is Direct State Access (DSA). OpenGL is a complex API that relies extensively on an implicit state that is maintained between function calls. For example, to specify properties of a texture, first a texture unit must be set as active. Then, the texture must be bound to the currently active texture unit. Then, the properties of the currently bound texture are specified. In each case, the link between the calls is implicit; the binding of the texture implicitly uses the active texture unit, and the property setting implicitly uses the bound texture.
This style is awkward for developers, especially for developers who are writing or using third-party middleware libraries. If the middleware wants to change the texture property, it has to do the activation/binding dance described—but then it has to undo the binding and the activation, because the application using the middleware may already have set its own bindings and active texture units.
Direct State Access allows developers to both set and query properties on objects (textures, shader programs, frame buffers, and so on) without having to make units active or bind objects to them; programs can operate directly on the objects themselves. This makes middleware much easier to develop, as it no longer needs to worry about disturbing the graphical state that the program has set up.
DSA has been available as an extension for some years but, until OpenGL 4.5, was not a standard feature of the specification proper. Developers could not rely on DSA being present, which was a major sore point when compared to Microsoft's Direct3D, which has supported DSA for many years.
Aside from DSA, OpenGL 4.5 also gives greater control of how commands are sent to hardware for execution, which can improve multithreaded performance and additional robustness capabilities to help isolate the effects of resetting the GPU. This is aimed in particular at WebGL, where isolation of 3D programs is particularly important to safeguard system security and stability.
SPIR 2.0
Also released today is SPIR 2.0. SPIR is Khronos' intermediate language for general purpose GPU (GPGPU) computation. OpenCL was Khronos' first system for using GPUs in this way, but OpenCL requires developers to use a C-like language. Often, programmers want to use something they're more familiar with, be it Python, C++, JavaScript, or any other language.
SPIR is Khronos' solution. Compilers for these other languages should produce SPIR code, and the OpenCL runtime will execute that SPIR code on the target machine. While technically those compilers could produce OpenCL C directly, SPIR is easier because it's designed to be used in this intermediate way.
SPIR is based on the intermediate representation used by the LLVM compiler suite. SPIR 2.0 gives SPIR full compatibility with all the features of OpenCL 2.0 and is based on LLVM 3.4.
The way forward
AMD's Mantle and Microsoft's Direct3D 12 are both promising to let developers extract more performance from 3D hardware, principally by giving greater control over how data is transferred to and from the graphics hardware and ensuring that as much work can be done in parallel on the CPU side as possible. While OpenGL proponents such as NVIDIA have claimed that many of the advantages of these APIs can be realized in OpenGL—as long as the right extensions are present—Khronos has decided to produce a standard high-performance, low-level API.
Khronos has embarked on radical new OpenGL specifications before. The original plan for OpenGL 3.0 was to make it an all-new API that removed the dependence on implicit state and was designed for multithreading. However, CAD vendors threw a fit, unwilling to update their applications to use a radically new API and unwilling to stick with OpenGL 2.x in perpetuity. Khronos abandoned the effort, and the OpenGL 3.0 that eventually shipped was a much more modest update to OpenGL 2.x.
Khronos representatives told us that OpenGL 4.x will continue to be supported and updated and that CAD vendors are aware of the direction of the next generation API, so this time around, there shouldn't be a CAD revolt to derail the group's progress. If Mantle or Direct3D 12 catch on, OpenGL's proponents can't afford for it to be left behind, even if this upsets the CAD community.
reader comments
69