Graphics Shaders, 2nd Edition

25

OpenGL Shader Evolution

2

In its early days, computer graphics had no standard programming models.

Vendors provided a low-level interface to their hardware, and each person or

group then developed their own approach to taking geometry and appear-

ance information and applying their particular algorithms to create a screen

display. It was fun (in a geeky sort of way), but not very ecient or portable.

While many of the images created in this period might seem very simple by

today’s standards, a lot of work went into them, and the basic ideas generated

in those days still impact us today.

Early aempts to reduce the amount of development work needed for

production focused on building graphics standards, but the standards gener-

ally provided only a least-common-denominator level of functions. However,

as standards developed, they led to a growing understanding of the funda-

mental operations needed in the graphics process and provided a rising level

26

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 dierent 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 beer by match-

ing the API more closely to their particular platforms or by extending the func-

tionality of the API in dierent 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 aecting 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.