In a few years, GPUs will have the compute horsepower to render scenes containing cinematic-quality surfaces in real-time. Unfortunately, if they render these subpixel polygons (micropolygons) using the same techniques as they do for large triangles today, GPUs will perform extremely inefficiently. Instead of trying to parallelize Pixar's Reyes micropolygon rendering system, we're taking a hard look at how the existing Direct3D 11 rendering pipeline, and GPU hardware implementations, must evolve to render micropolygon workloads efficiently in a high-throughput system. Changes to software interfaces, algorithms, and HW design are fair game! Slides describing what we've learned as of Summer 2010 can be found in this SIGGRAPH course talk (for a complete list of publications related to this project, see the bottom of this page).

Evolving the Real-Time Graphics Pipeline for Micropolygon Rendering (Stanford University Ph.D. Dissertation)

Reducing Shading on GPUs using Quad-Fragment Merging (SIGGRAPH 2010)

DiagSplit: Parallel, Crack-Free, Adaptive Tessellation for Micropolygon Rendering (SIGGRAPH Asia 2009)

Data-Parallel Rasterization of Micropolygons with Defocus and Motion Blur (High Performance Graphics 2009)

Sequoia is a hierarchical stream programming language that arose from the observation that expressing locality, not parallelism is the most important responsibility of parallel application programmers in scientific/numerical domains. Sequoia presents a parallel machine as an abstract hierarchy of memories and gives the programmer explicit control over data locality and communication through this hierarchy using first-class language constructs (basically, Sequoia supports nested kernels and streams of streams). Sequoia programs have run on a variety of exposed-communication architectures such as clusters, the CELL processor, GPUs, and even supercomputing clusters at Los Alamos. Learn more at the Sequoia project page or at the Stanford Pervasive Parallelism Lab's Sequoia page.

Sequoia: Programming the Memory Hierarchy (Supercomputing 2006)

There are two ways to think about GRAMPS. Graphics folks should think of GRAMPS as a system for building custom graphics pipelines. We simply gave up on adding more and more configurable knobs to existing pipelines like OpenGL/Direct3D and instead allow the programmer to programmatically define a custom pipeline with an arbitrary number of stages connected by queues. To non-graphics folks, GRAMPS is a stream programming system that embraces heterogeneity in underlying architecture and anticipates streaming workloads that exhibit both regular and irregular (dynamic) behavior. The GRAMPS runtime dynamically schedules GRAMPS programs onto architectures containing a mixture of compute-optimized cores, generic CPU cores, and fixed-function processing units.

GRAMPS: A Programming Model for Graphics Pipelines (SIGGRAPH TOG Jan 2009)

While at Stanford, I've also helped out with the BrookGPU (abstracting the GPU as a stream processor for numerical computing) and Merrimac Streaming Supercomputer projects.