Many-Core Programming with GRAMPS & “Real Time REYES” Jeremy Sugerman, Kayvon Fatahalian Stanford University June 12, 2008

2 Background, Outline  Stanford Graphics / Architecture Research  CPU, GPU trends  And collision?  Two research areas: –HW/SW Interface, Programming Model –Future Graphics API

3 Problem Statement  Drive efficient development and execution in many- /multi-core systems.  Support homogeneous, heterogeneous cores.  Inform future hardware Status Quo:  GPU Pipeline (Good for GL, otherwise hard)  CPU (No guidance, fast is hard)

4  Software defined graphs  Producer-consumer, data-parallelism  Initial focus on rendering GRAMPS Input Fragment Queue Output Fragment Queue Rasterization Pipeline Ray Tracing Pipeline = Thread Stage = Shader Stage = Fixed-func Stage = Queue = Stage Output Frame Buffer Ray Queue Ray Hit Queue Fragment Queue CameraIntersect Shade FB Blend Frame Buffer Shade FB Blend Rasterize

5 As a GPU Evolution  Not (too) radical for ‘graphics’  Like fixed → programmable shading –Pipeline undergoing massive shake up –Diversity of new parameters and use cases  Bigger picture than ‘graphics’ –Rendering is more than GL/D3D –Compute is more than rendering –Larrabee has no innate pipeline

6 As a Compute Evolution  Sounds like streaming: Execution graphs, kernels, data-parallelism  Streaming: “squeeze out every FLOP” –Goals: bulk transfer, arithmetic intensity –Intensive static analysis, custom chips (mostly) –Bounded space, data access, execution time  GRAMPS: “interesting apps are irregular” –Goals: Dynamic, data-dependent code –Aggregate work at run-time –Heterogeneous commodity platforms –Naturally supports streaming when applicable

7 GRAMPS’ Role  A ‘graphics pipeline’ is now an app!  GRAMPS models parallel state machines.  Compared to status quo: –More flexible than a GPU pipeline –More guidance than bare metal –Portability in between –Not domain specific

8 GRAMPS Interfaces  Host/Setup: Create execution graph  Thread: Stateful, singleton  Shader: Data-parallel, auto-instanced

9 What We’ve Built (System)

10 GRAMPS Scheduler  Tiered Scheduler  ‘Fat’ cores: per-thread, per-core  ‘Micro’ cores: shared hw scheduler  Top level: tier N

11 What We’ve Built (Apps) Direct3D Pipeline (with Ray-tracing Extension) Ray-tracing Pipeline IA 1 VS 1 RO Rast Trace IA N VS N PS Frame Buffer Vertex Buffers Sample Queue Set Ray Queue Primitive Queue Input Vertex Queue 1 Primitive Queue 1 Input Vertex Queue N … … OM PS2 Fragment Queue Ray Hit Queue Ray-tracing Extension Primitive Queue N Tiler Shade FB Blend Frame Buffer Sample Queue Tile Queue Ray Queue Ray Hit Queue Fragment Queue Camera Sampler Intersect = Thread Stage = Shader Stage = Fixed-func = Queue = Stage Output = Push Output

12 Initial Results  Queues are small, utilization is good

13 GRAMPS Visualization

14 GRAMPS Visualization

15 GRAMPS Portability  Portability really means performance.  Less portable than GL/D3D –GRAMPS graph is hardware sensitive  More portable than bare metal –Enforces modularity –Best case, just works –Worst case, saves boilerplate

16 High-level Challenges  Is GRAMPS a suitable GPU evolution? –Enable pipeline competitive with bare metal? –Enable innovation: advanced / alternative methods?  Is GRAMPS a good parallel compute model? –Map well to hardware, hardware trends? –Support important apps? –Concepts influence developers?

17 What’s Next for GRAMPS?  Implementation: scheduling, simulation details  Model: Graph modification (state change) Blocking calls (join) Intra/inter-stage synchronization primitives Data sharing / ref-counting  Workloads: REYES, physics, others?  Develop new graphics pipelines…

“Real-Time REYES” 18

19 Just Build It Build a real-time REYES pipeline... … that is tightly integrated with ray tracing for global effects.

20 What does real-time REYES mean? (to us)  Smooth surfaces via adaptive tessellation –Everything is a displaced subdivision surface  Shade on surface, prior to rasterization  Stochastic rasterization for motion blur and DOF  Order-independent transparency

21 Split Dice Shade Rasterize Z Test Blend/Resolve Displace Early Z Tessellate (xbox) Early Z Frag Shade Z Test Blend/Resolve Vertex Shade Rasterize REYES OpenGL/Direct3D

22 Split primitive into smaller primitives until a “GOOD” grid can be created. REYES Tessellation

23

24

25

26 Grids GOOD GRID = - Max polygon area < 1 pixel - All polys about the same size - Bounded # polys per grid Regular parametric sampling of primitive surface (like XBox360). Compact representation for many adjacent polygons. Grids provide SIMD efficiency and bulk processing benefits.

27 Split Dice Shade Rast/Crack Fix Z Test Blend/Resolve Displace Early Z Tessellate (xbox) Early Z Frag Shade Z Test Blend/Resolve Vertex Shade Rast REYESOpenGL/Direct3D

28 What does real-time REYES mean? (to us)  Smooth surfaces via adaptive tessellation –Splitting is irregular (and serial) –Crack fixing  Shade on surface, prior to rasterization –We feel confident about this –But most “work” done before moving to raster space… hmm  Stochastic rasterization for motion blur and DOF –Many tiny polygons  parallel rasterization –SIMD tricky  Order-independent transparency –Not unique to REYES

29 Shading in a Hybrid System  Evaluate displacement (due to REYES or on demand for ray tracing)  Shade grids  Shade ray hits  Looking forward… shade quads too? One shading system or two or three?

This Project is Really About  Re-architecting REYES pipeline for real-time performance (for throughput architectures like LRB)  Hybrid rendering: study interoperability of advanced techniques (REYES + ray tracing + maybe Direct3D ) –Hybrid shading system –Understand workload balance  Hybrid pipeline interface: real-time, retained mode  Pursuit of more flexible, advanced graphics pipelines

31 Questions?