2. OpenGL Shader Evolution
of expectations for the quality of images they could produce. In turn, these led
to the graphics engines developed by companies like Evans and Sutherland
(E&S) and Silicon Graphics (SGI) and others that began to implement basic
graphics processes in hardware. These again increased the expectations of per-
formance and quality. A part of the “family tree” of public, non-proprietary
graphics standards is shown in Figure 2.1.
Originally, graphics standards were meant to solve portability problems.
That is, graphics standards enabled programmers to re-deploy existing appli-
cations on dierent hardware systems with a minimal amount of work. But as
hardware acceleration became more common, graphics standards also became
a blueprint for what operations needed to be accelerated.
For example, in order to take advantage of the SGI graphics engines,
the engineers at SGI also developed a graphics API that mapped well to the
engines’ processes. This was Iris GL, and it made developing graphics applica-
tions so much more straightforward that an industry-wide version was cre-
ated. The resulting OpenGL API can be said to have been one of the key factors
that has made graphics so ubiquitous in the computing world. Of course, oth-
ers have looked at OpenGL and have believed they could do beer by match-
ing the API more closely to their particular platforms or by extending the func-
tionality of the API in dierent ways, so we continue to nd ourselves in a
world with many competing “standards.”
OpenGL makes no assumptions of hardware support. The spec only says
what should be done, not how it should happen, or how fast. It is possible
to implement OpenGL entirely in software without aecting the applications
in any way except speed. However, many—perhaps most—graphics appli-
cations need to create images at interactive speeds. This is particularly true
Figure 2.1. Some graphics standards that led to OpenGL.