A Real-Time Procedural Shading System for Programmable Graphics Hardware Kekoa Proudfoot William R. Mark Svetoslav Tzvetkov Pat Hanrahan

Introduction n Graphics processors are becoming programmable n Programmability makes it possible to make real-time graphics more lifelike n But somebody has to do the programming

Programmable graphics hardware n Problem: programming graphics hardware is difficult –Low-level interfaces –Different manufacturers produce hardware with different interfaces and functionality n Sounds familiar: microprocessors –Assembly language interface –Intel processor very different from Alpha

Programmable graphics hardware n Programming in assembly is difficult –Have to worry about register allocation, instruction scheduling, etc. n With normal processors, we program in higher-level languages, and compile down to assembly n Can we apply this idea to programmable graphics hardware?

Shading languages n High level description: programmer describes how objects should be drawn, instead of how to draw them n Kind of like C: you still need to know what you’re doing, but you don’t need to worry about low-level details n Makes programming easier, and makes programs portable

Compiling the shading language n Traditional compiler structure n Programmable pipeline program is an intermediate language shading language compiler front end programmable pipeline program retargetable compiler back end hardware-specific code

Front end analysis - computation frequencies n Primitives (cubes, etc) get converted to vertices (triangles) n Vertices get converted to fragments (pixels) n Computation can occur at any of these stages n Use type inference to perform computation as early as possible constantprimitive group vertexfragment

Compiler back end n Modular structure –To support new hardware, make a new module –One module per computation frequency –Modules can be interchanged n Arbitrarily complex computations can be done –Render in multiple passes if necessary –Use the CPU if all else fails

Back end optimizations n Group parallel scalar operations into vector operations n Copy propagation n Collapse MUL and ADD to MAD (multiply-and-add) n Use negate-on-read when possible

Conclusion n Shaders provide an abstraction barrier between the programmer and the hardware n But, the programmer no longer has direct control over the performance of the program

Discussion n The goal is to produce lifelike real-time graphics. Can we afford an extra layer of abstraction?