from, each of which introduces a different kind of visual for polygon rasterization and Z-buffer read-modify-write artifact in the image, and each of which uses different operations), as well as for other operations such as the algorithms that may in turn run best on different archi- thread scheduling needed by the programmable stages. tectures. In essence, the system design problem is reduced Many of the individual pipeline stages are program-to the ill-specified problem of which system (software and mable (to support programmable material shading hardware) produces the best-quality game images for a computations in particular), with all of the program-specific cost. Figure 1 illustrates this problem. In prac- mable stages multiplexed onto a single set of homoge-tice, there are also other constraints, such as backward neous programmable hardware processors. The programs compatibility and a desire to build systems that facilitate executing within these pipeline stages, however, are content creation. heavily restricted in how they can communicate with

As VLSI technology advances with time, the system each other and in how—if at all—they can access the designer is provided with more transistors. If we assume global shared memory. This programming model provides that the frame rate is fixed at 60 Hz, the additional high performance for the computations it is designed to computational capability provided by these transistors support, but makes it difficult to support other computa-can be used in three fundamental ways: increasing the tions efficiently. screen resolution; increasing the scene detail (polygon It is important to realize that modern game applica-count or material shader complexity); and changing the tions fundamentally require programmability in the overall approximations, by changing the basic rendering graphics hardware. This is because the real world contains algorithm or specific components of it. an enormous variety of materials (wood, metal, glass,

Looking back at the past six years, we can see these skin, fur, ...), and the only reasonable way to specify the forces at work. Games have adopted programmable shaders that allow sophisticated modeling of E volution of Graphics Programming Models materials and multipass _{techniques that approxi-} a . today’s graphics programming model b . future graphics programming model mate shadows, reflections, and other effects. Graphics _{flexible multicore} architectures have enabled ^{vertex architecture} program these changes through the addition of programmable vertex and fragment units, ^{geometry specialized} program ISA as well as more flexibil- extensions ity in how data moves between stages in the ^rasterizer graphics pipeline. _rasterizer Current graphics proces- _{fragment texture} sors use the programming program unit model illustrated in figure 2a. This model supports output texture the traditional Z-buffer ^{merger unit} (ROP) algorithm and is organized around a predefined pipe- _{2 D 2 D} line structure that is only v ideo decode v ideo decode partially reconfigurable by the application. ¹ The n on-programmable predefined pipeline struc- p rogrammable ture employs specialized hardware for the Z-buffer algorithm (in particular F IG 2