Many-Core Programming with GRAMPS& “Real Time REYES”

Jeremy Sugerman, Kayvon FatahalianStanford 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

GRAMPSInput

FragmentQueue

OutputFragment

Queue

Rasterization Pipeline

Ray Tracing Pipeline

= Thread Stage= Shader Stage= Fixed-func Stage

= Queue= Stage Output

RayQueue

Ray HitQueue Fragment

Queue

Camera Intersect

Shade FB Blend

Shade FB BlendRasterize

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

SampleQueue Set

RayQueue

PrimitiveQueue

Input VertexQueue 1

PrimitiveQueue 1

Input VertexQueue N

OM

PS2

FragmentQueue

Ray HitQueue

Ray-tracing Extension

PrimitiveQueue N

Tiler

Shade FB Blend

SampleQueue

TileQueue

RayQueue

Ray HitQueue

FragmentQueue

CameraSampler 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 primitivesData 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

REYES OpenGL/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?