Remember the API wars of the late 1990s and early 2000s when Microsoft’s Direct3D and early DirectX versions competed against variants of OpenGL? Microsoft’s DirectX, of course, has been the de facto standard for years, yet something still stirs in the land of OpenGL. The Khronos Group (the industry consortium that took over the development of OpenGL) recently announced the Vulkan open standard API, which is designed to provide applications near direct control over GPU acceleration. Could we soon be witness to API Wars II? We’ll examine the history of OpenGL and see what the future holds for open API standards.
SGI & OpenGL
Short for Open Graphics Library, OpenGL has long been designed as a multiplatform, cross-language API for hardware-accelerated graphics rendering. The open-source nature lets hardware and software developers customize the API for high-performance computing fields and applications, which have historically included CAD, flight simulation, scientific and information data analysis, and videogames. As previously mentioned, Microsoft’s DirectX has been the primary area of focus of game developers over the last decade, but OpenGL is still vital for those running games on Linux and Mac operating systems. OpenGL was officially released in 1992. SGI, which is now known as Silicon Graphics International but was Silicon Graphics, Inc. at the time, developed the standard. In 1992, SGI was acclaimed for its digital visual effects platform and technology. For example, SGI products were used to create the groundbreaking visuals in “Jurassic Park” and “Terminator 2: Judgment Day.” The initial API for OpenGL served an open alternative to SGI’s Iris GL, which was the proprietary graphics API on SGI workstations. On the whole, SGI viewed OpenGL 1.0 as a state machine that controls a set of specific drawing operations. For programmers, OpenGL 1.0 served as another way to specify geometric objects and render those objects within the card’s frame buffer. Within a typical program, OpenGL 1.0 starts with calls to open a window where the application will draw. The calls are made to allocate graphics language context, as well as to control the frame buffer. In the early 1990s, most consumer graphics cards didn’t support OpenGL, so it wasn’t initially the most useful tool for game designers. In 1996, the OpenGL API found a strong advocate in id Software’s John Carmack, who developed Quake for OpenGL and found that, at the time, it was a much better videogame API than Microsoft’s Direct3D. Carmack and id went on to create GLQuake, which was a source port for Quake and Quake 2 that took advantage of the OpenGL API. GLQuake allowed for effects such as transparent water, reflective surfaces, and shadows. In part due to Carmack and Quake’s influence, graphics card companies began to support OpenGL via MiniGL drivers that allowed for better 3D acceleration. NVIDIA would add even more augmentations to OpenGL with register combiners. This was notable because the combiners took full advantage of NVIDIA’s TNT hardware and let the GPU access, from any stage, the texture values and per-vertex colors. Versions of OpenGL evolved along with new hardware advancements. OpenGL 1.1 was released in 1997, while OpenGL 1.2 (and 1.2.1) hit in 1998. Imaging subset was one of the most important features added to OpenGL 1.2 for image processing, as the subset included core capabilities for 3D texturing and level of detail controls. When NVIDIA released its GeForce 256 (the card where NVIDIA coined the term “GPU”) in 1999, OpenGL was able to take advantage of the card’s distinctive T&L (transform & lighting) features, because the API had a dedicated T&L pipeline. Microsoft, by comparison, had to add T&L to support the DirectX standard with the release of DirectX 7.
Fahrenheit
In 1997, SGI and Microsoft joined forces to “create a common, extensible architecture” under a project code-named “Fahrenheit.” The undertaking was designed to bring together the consumer (DirectX) and professional (OpenGL) graphics APIs, so developers would only need to know one API for graphics and visualization applications. At the time, Ed McCracken, chairman and CEO of SGI, said, “Today, Silicon Graphics and Microsoft are defining a clear path for developers that enables both of us to expand the market for graphics.” The alliance would last only two years. Microsoft and SGI could not find common ground, and the entire project was abandoned with little to no functional code ever produced. Experts have speculated a variety of reasons for the failed marriage, and although a general lack of industry support was seen as the primary roadblock, there’s never been a clear story about why the project failed. Microsoft, of course, continued work on its DirectX API, and when Windows 2000 was released, the OS was loaded with DirectX 7.
Progress Slows
At the turn of the century, the once prolific group of graphics AIB (add-in board) developers had started to dwindle. Microsoft had begun to work primarily with NVIDIA and ATI, and a new version of DirectX would often coincide with Team Green’s and Team Red’s newest GPUs. OpenGL, on the other hand, tacked on support with the updates that sometimes didn’t appear until a year after the relevant hardware had been released. For example, OpenGL 1.3 wasn’t released until 2001, almost three years after OpenGL 1.2. Some have pointed towards the ARB (Architectural Review Board) as a major factor in the delay, as new features required approval from a standards committee. It didn’t help that many members of the ARB were rival companies, and intellectual property threats in particular were seen as key frustrations. In some cases, the biggest advances were made in OpenGL extensions, rather than updating the standard as a whole. With each company promoting its own technology, OpenGL began to fall behind. By 2002, Microsoft had created DirectX 9 and a high-level shading language (Shader Model 2.0) to support GPU improvements for pixel shading, vertex shading, and overall visual quality. OpenGL, at the time, wasn’t able to take full advantage of dedicated hardware shader pipelines. To help catch up, the ARB would work with 3DLABS to spearhead the development of OpenGL 2.0 and support for shading language. OpenGL 2.0 wasn’t released until 2004, and not long after 3DLABS exited the graphics card business altogether, stopping development in 2006.
Khronos Group Takes Control
At SIGGRAPH 2006, the OpenGL ARB passed governance of OpenGL’s API over to the Khronos Group. One of the first acts of the Khronos Group was to establish an OpenGL Working Group that would be responsible for controlling and evolving the OpenGL standard. At the time, ARB secretary Jon Leech said, “The evolution of the OpenGL API and the membership of the ARB have reflected the changes in the graphics industry over the years as the use of 3D graphics moved from high-end workstations and simulators to PCs and mobile laptops, thanks to a new generation of consumeroriented companies, such as Apple, ATI, and NVIDIA. We have decided to move the OpenGL specification into Khronos to ensure the future health of OpenGL in all its forms.” With a joint road map, the OpenGL train was no longer off the tracks. But by this time, OpenGL API support was not nearly as important to developers as Microsoft’s DirectX, and the standard was years behind. By 2008, the Khronos Group was able to deliver OpenGL 3.0. This release marked a major revision of the API, as it included a new version of the OpenGL shading language (GLSL 1.3) and a set of OpenGL extensions that would bring the new functionality to older hardware. AMD, Intel, and NVIDIA all made contributions to the design of OpenGL 3.0 and would immediately support it within the respective product lineups. The Khronos Group also focused on defining how the OpenGL specification would evolve and retire obsolete functions. In the press release announcing OpenGL 3.0, the Khronos Group stated, “The new OpenGL API supports the future creation of profiles to enable products to support specific market needs while not burdening every implementation with unnecessary costs. To avoid fragmentation, the core OpenGL specification will contain all defined functionality in an architecturally coherent whole, with profiles tightly specifying segment-relevant subsets.” Barthold Lichtenbelt, chair of the OpenGL working group at Khronos, said, “OpenGL 3.0 sets the stage for a revolution to come. We now have the roadmap machinery and momentum in place to rapidly and reliably develop OpenGL and are working closely with OpenCL to ensure that OpenGL plays a pivotal role in the ongoing revolution in programmable visual computing.” In March of 2009, the Khronos Group released OpenGL 3.1, which had additional shading language updates and improved programmability that would allow for more efficient development of supporting software. “The rapid nine-month development of OpenGL 3.1 demonstrates the scheduledriven approach to the standard that is enabling and inspiring cutting-edge, crossplatform GPU functionality,” Lichtenbelt said. “OpenGL 3.1 answers the requests from the developer community to streamline and modernize the OpenGL API.” OpenGL 4.0 landed one year later. The 4.0 update introduced shader stages that let the GPU offload tessellation from the CPU, as well as the ability to use per-sample fragment shaders and programmable fragment shader input positions. The greater flexibility helped to increase rendering quality and antialiasing. At the same time, Khronos introduced OpenGL 3.3 and a set of ARB extensions, which brought many of OpenGL 4.0’s new features to older OpenGL 3.0 cards. Subsequent releases of OpenGL have rolled out on a fairly consistent basis. For example, OpenGL 4.2 was announced in 2011, OpenGL 4.3 in 2012, OpenGL 4.4 in 2013, and OpenGL 4.5 in 2014. With the latter, the Khronos Group introduced core functionality for DSA (Direct State Access) that lets developers set and query the properties of objects, which could be textures, shader programs, and frame buffers, among others, without binding the object. This way, developers using or designing middleware won’t need to activate and undo bindings. DSA-like functionality has long been a part of Direct3D. For easier porting between OpenGL and Direct3D, OpenGL 4.5 offers a DX11 emulation capability
Vulkan
With OpenGL brought up to speed with many of the most critical graphics acceleration techniques and technologies, the Khronos Group set its sights on something new. Vulkan is a ground-up design that removes much of the complex driver overhead that can slow down performance. Developers call this a low-level
No comments:
Post a Comment