History of Graphics APIs

This article is taken from the book The Metal Programming

1. Pioneering Efforts (1960s-1970s): During this period, pioneers like James Blinn and Edwin Catmull laid the foundation for three-dimensional computer graphics. Their work marked the initial steps toward creating realistic digital visualizations, highlighting the potential of computer-generated imagery.
2. Cross-Platform Challenges (1980s): The 1980s saw the rise of personal computers and gaming systems, but each platform had its unique hardware architecture and software drivers. Developing cross-platform software, especially graphics-intensive games, was a daunting task due to the need for different versions of the software tailored to each platform.
3. SGI and Proprietary Graphics (1981): Silicon Graphics (SGI) entered the scene, offering high-performance 3D workstations. However, these workstations used SGI's proprietary IRIS GL graphics API, creating a siloed environment where software developed for IRIS GL wouldn't work on other platforms.
4. Dominance and Erosion (1980s-early 1990s): IRIS GL became a dominant graphics API in the industry. However, the proprietary nature of the technology meant limited interoperability, and as other platforms and APIs emerged, SGI's market share started declining.
5. Opening IRIS GL (1992): To combat the decline in market share, SGI decided to open up IRIS GL and rebrand it as OpenGL. By making it accessible to a wider audience, SGI aimed to regain traction in the market.
6. Quake and OpenGL Adoption (1997): The release of the game "Quake by idSoftware" marked a turning point. "John Carmack's decision to use OpenGL for porting Quake" across multiple platforms demonstrated the need for a standardized graphics API to simplify development across diverse hardware.
7. Standardization through OpenGL: Carmack's approach of leveraging OpenGL for porting Quake was a significant move toward creating a common ground for graphics development. It motivated manufacturers to support OpenGL to ensure compatibility with popular games like Quake.
8. Manufacturers' Compliance and Widespread Support: Manufacturers complied with the demand for OpenGL support, leading to the development of OpenGL-compatible drivers. This unified effort provided a consistent graphics framework across different hardware and operating systems.
9. Cross-Platform Promise: OpenGL's cross-platform compatibility and its adoption by both developers and manufacturers made it an appealing choice. Game developers, in particular, embraced OpenGL for its assurance of consistent performance across various devices.
10. OpenGL as Industry Standard: As a result of these developments, OpenGL became the de facto 3D graphics API. Its widespread support and cross-platform capabilities established it as an industry standard, ensuring that developers could create visually impressive applications that reached a broad audience.

The evolution of graphics APIs, as exemplified by the history of OpenGL, illustrates the need to overcome challenges posed by proprietary systems, lack of interoperability, and the complexity of cross-platform development. The success of OpenGL in providing a unified graphics framework underlines the importance of standardization and accessibility in the field of computer graphics.

As the introduction of shaders approached, a significant transformation occurred in the capabilities of GPUs. Over time, GPUs have undergone substantial improvements in power and efficiency. This progress highlighted the inefficiencies in many of the initial techniques for performing tasks. While adjustments were made to incorporate these advancements, the original methods were retained in the API. This led to a scenario where diverse ways of achieving the same tasks coexisted within the API, with varying degrees of efficiency.

By the time shaders were added to OpenGL:

The API was starting to get rather crufty. When OpenGL was initially released, GPUs were not particularly powerful. They couldn’t handle much work. The original OpenGL API was designed to push as much work as possible to the CPU because the GPU was a bottleneck. By the time shaders were announced, this limitation had changed dramatically. GPUs had gotten progressively more powerful, and many of the original ways of performing tasks were incredibly inefficient. New methods were introduced over time to accommodate for this new reality, but the old methods were never removed from the API. There were multiple ways to perform the same tasks, and some were more efficient than others.

OpenGL ES (2003-2007):

In 2003, a streamlined version of OpenGL was released: OpenGL ES. OpenGL ES is a subset of OpenGL. It removed all of the old, crufty implementations that were no longer the optimal way of allocating work to the GPU. It was developed for embedded devices, such as video-game consoles and smartphones, but any program written in OpenGL ES can work on a program that uses OpenGL, with some small modifications to the shaders. In 2007, OpenGL ES 2.0 was released. This version incorporated shaders and a programmable pipeline.

iPhone and OpenGL ES (2007-2010):

It was also in 2007 that the first iPhone was released. The graphics frameworks and APIs available in the first iOS SDK were incredibly limited, but the iPhone did support OpenGL ES. Most developers who wanted to adopt sophisticated graphics for games and applications had to program everything in OpenGL ES. Many programmers who had years of experience working with OpenGL were able to create sophisticated graphics for the iPhone at a time when the SDK was in its infancy. In 2010, Apple began to support OpenGL ES 2.0, along with programmable shaders, on the iPhone.

Apple's Higher-Level Abstractions (Over the Years):

Over the years, Apple has developed higher-level abstractions for graphics on the iPhone: Sprite Kit, Scene Kit, and so on. But if you wanted to program the GPU directly, you had to use OpenGL ES. You also were constrained to programming the GPU for graphics. You couldn’t utilize the GPU for general-purpose programming, nor could you take advantage of the tight hardware/software integration that Apple has with its other frameworks.