NVIDIA Graphics, Cg, and Transparency

NVIDIA Graphics, Cg, and Transparency Mark Kilgard Graphics Software Engineer NVIDIA Corporation GPU Shading and Rendering Course 3 July 30, 2006

Outline NVIDIA graphics hardware seven years for GeForce + the future Cg—C for Graphics the cross-platform GPU programming language Depth peeling out-of-order transparency now practical

Seven Years of GeForce DX9c 2.0 Transparency antialiasing, quad-GPU GeForce 7800 GTX 2005 DX9c 2.0 Vertex textures, structured fragment branching, non-power-of-two textures, generalized floating-point textures, floating-point texture filtering and blending, dual-GPU GeForce 6800 Ultra 2004 DX9c 2.1 Single-board dual-GPU, process efficiency GeForce 7900 GTX 2006 DX9 1.5 Vertex program branching, floating-point fragment programs, 16 texture units, limited floating-point textures, color & depth compression GeForce FX 2003 DX8.1 1.4 Early Z culling, dual-monitor GeForce4 Ti 4600 2002 DX8 1.4 Programmable vertex transformation, 4 texture units, dependent textures, 3D textures, shadow maps, multisampling, occlusion queries GeForce3 2001 DX7 1.3 Hardware transform & lighting, configurable fixed-point shading, cube maps, texture compression, anisotropic texture filtering GeForce 256 2000 Direct3D Version OpenGL Version New Features Product

2006: the GeForce 7900 GTX board 512MB/256-bit GDDR3 1600 MHz effective 8 pieces of 8Mx32 16x PCI-Express DVI x 2 sVideo TV Out SLI Connector

2006: the GeForce 7900 GTX GPU 278 million transistors 650 MHz core clock 1,600 MHz GDDR3 effective memory clock 256-bit memory interface Notable Functionality Non-power-of-two textures with mipmaps Floating-point (fp16) blending and filtering sRGB color space texture filtering and frame buffer blending Vertex textures 16x anisotropic texture filtering Dynamic vertex and fragment branching Double-rate depth/stencil-only rendering Early depth/stencil culling Transparency antialiasing

2006: GeForce 7950 GX2, SLI-on-a-card DVI x 2 sVideo TV Out 16x PCI-Express Sandwich of two printed circuit boards Two GeForce 7 Series GPUs 500 Mhz core 1 GB video memory 512 MB per GPU 1,200 Mhz effective Effective 512-bit memory interface!

GeForce Peak Vertex Processing Trends Millions of vertices per second Vertex units 1 1 2 3 6 8 8 2 ×8 rate for trivial 4x4 vertex transform exceeds peak setup rates—allows excess vertex processing Assumes Alternate Frame Rendering (AFR) SLI Mode

GeForce Peak Triangle Setup Trends Millions of triangles per second assumes 50% face culling Assumes Alternate Frame Rendering (AFR) SLI Mode

GeForce Peak Memory Bandwidth Trends Gigabytes per second Two physical 256-bit memory interfaces 128-bit interface 256-bit interface

Effective GPU Memory Bandwidth Compression schemes Lossless depth and color (when multisampling) compression Lossy texture compression (S3TC / DXTC) Typically assumes 4:1 compression Avoid useless work Early killing of fragments (Z cull) Avoid useless blending and texture fetches Very clever memory controller designs Combining memory accesses for improved coherency Caches for texture fetches

NVIDIA Graphics Core and Memory Clock Rates Megahertz (Mhz) DDR memory transition—memory rates double physical clock rate

GeForce Peak Texture Fetch Trends Millions of texture fetches per second Texture units 2 ×4 2×4 2×4 2×4 16 24 24 2 ×24 assuming no texture cache misses

GeForce Peak Depth/Stencil-only Fill assuming no read-modify-write Millions of depth/stencil pixel updates per second double speed depth-stencil only

GeForce Transistor Count and Semiconductor Process Millions of transistors Process ( nm ) 180 180 150 130 130 110 90 90 More performance with fewer transistors: Architectural & process efficiency!

GeForce 7900 GTX Parallelism Triangle Setup/Raster Shader Instruction Dispatch Fragment Crossbar Memory Partition Memory Partition Memory Partition Memory Partition Z-Cull 8 Vertex Engines 24 Fragment Shaders 16 Raster Operation Pipelines

16 GeForce FX 5900 GeForce 6800 Ultra Vertex Fragment 2 nd Texture Fetch 3 6 4+4 Raster Color Raster Depth 4+4 16+16 GeForce 7900 GTX Hardware Unit 8 24 16+16

2005: Comparison to CPU Pentium Extreme Edition 840 3.2 GHz Dual Core 230M Transistors 90nm process 206 mm^2 2 x 1MB Cache 25.6 GFlops GeForce 7800 GTX 430 MHz 302M Transistors 110nm process 326 mm^2 313 GFlops (shader) 1.3 TFlops (total)

2006: Comparison to CPU Intel Core 2 Extreme X6800 2.93 GHz Dual Core 291M Transistors 65nm process 143 mm^2 4MB Cache 23.2 GFlops GeForce 7900 GTX 650 MHz 278M Transistors 90nm process 196 mm^2 477 GFlops (shader) 2.1 TFlops (total)

Giga Flops Imbalance Theoretical programmable IEEE 754 single-precision Giga Flops

Future NVIDIA GPU directions DirectX 10 feature set Massive graphics functionality upgrade Language and tool support Performance tuning and content development Improved GPGPU Harness the bandwidth & Gflops for non-graphics Multi-GPU systems innovation Next-generation SLI

DirectX 10-class GPU functionality Generalized programmability, including Integer instructions Efficient branching Texture size queries, unfiltered texel fetches, & offset fetches Shadow cube maps for omni-directional shadowing Sourcing constants from bind-able buffer objects Per-primitive programmable processing Emits zero or more strips of triangles/points/lines New line and triangle adjacency primitives Output to multiple viewports and buffers

Per-primitive processing example: Automatic silhouette edge rendering emit edge of adjacent triangles that face opposite directions New triangle adjacency primitive = 3 conventional vertices + 3 vertices for adjacent triangles

More DirectX 10-class GPU functionality Better blending Improved blending control for multiple draw buffers sRGB and 32-bit floating-point framebuffer blending Streamed output of vertex processing to buffers Render to vertex array Texture improvements Indexing into an “array” of 2D textures Improved render-to-texture Luminance-alpha compressed formats Compact High Dynamic Range texture formats Integer texture formats 32-bit floating-point texture filtering

Uses of DirectX 10 functionality GPU Marching Cubes GPU Cloth Styled Line Drawing Deformable Collisions Sparkling Sprites Table-free Noise Deep Waves GPU Fluid Simulation

DirectX 10-class functionality parity Feature parity DirectX 10-class features available via OpenGL Cross API portability of programmable shading content through Cg Performance parity 3D API agnostic performance parity on all Windows operating systems System support parity Linux, Mac, FreeBSD, Solaris Shared code base for drivers

Multi-GPU Support Original SLI was just the beginning Quad-SLI SLI support infuses all NVIDIA product design and development New SLI APIs for application-control of multiple GPUs SLI for notebooks Better thermals and power

Vertex Cores Fragment Cores Raster Color Cores Raster Depth Cores GeForce 7900 GTX Hardware Unit 8 24 16+16 GeForce 7900 GTX Quad SLI 32 96 64+64

Cg: C for Graphics Cg as it exists today High-level, inspired mostly by C Graphics focused API-independent GLSL tied to OpenGL; HLSL tied to Direct3D; Cg works for both Platform-independent Cg works on PlayStation 3, ATI, NVIDIA, Linux, Solaris, Mac OS X, Windows, etc. Production language and system Cg 1.5 is part of 3D content creation tool chains Portability of Cg shaders is important

Evolution of Cg C (AT&T, 1970’s) C++ (AT&T, 1983) Java (Sun, 1994) RenderMan (Pixar, 1988) PixelFlow Shading Language (UNC, 1998) Real-Time Shading Language (Stanford, 2001) Cg / HLSL (NVIDIA/Microsoft, 2002) IRIS GL (SGI, 1982) OpenGL (ARB, 1992) Direct3D (Microsoft, 1995) Reality Lab (RenderMorphics, 1994) General-purpose languages Graphics Application Program Interfaces Shading Languages

Cg 1.5 Current release of Cg Supports Windows, Linux, Mac (including x86 Macs) + now Solaris Shader Model 3.0 profiles for Direct3D 9.0c Matches Sony’s PlayStation 3 Cg support Tool chain support: FX Composer 2.0 New functionality Procedural effects generation Combined programs for multiple domains New GLSL profiles to compile Cg to GLSL Improved compiler optimization

FX Composer for Cg shader authoring Shaders are assets Portability matters So express shaders in a multi-platform, multi-API language That’s Cg

Future: Modernizing Cg Opportunity to re-think the Cg language Experience-driven Shader writing was programming-in-the-small But not anymore! Provide better abstraction mechanisms Must be backward compatible Challenge : Instead of inventing yet-another shading language-specific keyword, think how a C++ programmer express the feature Think templates and classes

Cg Directions DirectX 10-class feature support Primitive (geometry) programs Constant buffers Interpolation modes Read-write index-able temporaries New texture targets: texture arrays, shadow cube maps Incorporate established C++ features, examples: Classes Templates Operator overloading But not runtime features like new/delete, RTTI, or exceptions

Why C++? Already inspiration for much of Cg Think of Cg’s first-class vectors simply as classes Functionality in C++ is well-understood and popular C++ is biased towards compile-time abstraction Rather than more run-time focus of Java and C# Compile-time abstraction is good since GPUs lack the run-time support for heaps, garbage collection, exceptions, and run-time polymorphism

Logical Programmable Graphics Pipeline 3D Application or Game 3D API: OpenGL or Direct3D Driver Programmable Vertex Processor Primitive Assembly Rasterization & Interpolation 3D API Commands Transformed Vertices Assembled Polygons, Lines, and Points GPU Command & Data Stream Programmable Fragment Processor Rasterized Pre-transformed Fragments Transformed Fragments Raster Operations Framebuffer Pixel Updates GPU Front End Pre-transformed Vertices Vertex Index Stream Pixel Location Stream CPU – GPU Boundary Program vertex and fragment domains

Future Logical Programmable Graphics Pipeline 3D Application or Game 3D API: OpenGL or Direct3D Driver Programmable Vertex Processor Primitive Assembly Rasterization & Interpolation 3D API Commands Transformed Vertices Output assembled Polygons, Lines, and Points GPU Command & Data Stream Programmable Fragment Processor Rasterized Pre-transformed Fragments Transformed Fragments Raster Operations Framebuffer Pixel Updates GPU Front End Pre-transformed Vertices Vertex Index Stream Pixel Location Stream CPU – GPU Boundary Programmable Primitive Processor Input assembled Polygons, Lines, and Points New per-primitive “geometry” programmable domain

Pass Through Geometry Program Example BufferInit<float4,6> flatColor; TRIANGLE void passthru( AttribArray < float4 > position : POSITION , AttribArray < float4 > texCoord : TEXCOORD0 ) { flatAttrib (flatColor: COLOR ); for ( int i=0; i<position.length; i++) { emitVertex (position[i], texCoord[i]); } } Primitive’s attributes arrive as “templated” attribute arrays Length of attribute arrays depends on the input primitive mode, 3 for TRIANGLE Bundles a vertex based on parameter values and semantics Makes sure flat attributes are associated with the proper provoking vertex convention flatColor initialized from constant buffer 6

Depth peeling Brute force order-independent transparency algorithm [Everitt 2001] Approach Render transparent objects repeatedly Each pass peels successive color layer using dual-depth buffers Composite peeled layers in order Caveats Typically makes “thin film” assumption No refraction or scattering

Transparency: The Good vs. the Ugly

Peeled layer visualization composite layers Fragment count per layer

Another example: The Good vs. the Ugly

Another peeled layer visualization composite layers Fragment count per layer

Depth peeling: How it works Conventional depth buffer after rendering Color buffer has color of closest fragment Depth buffer has depth of closest fragment Re-use the depth buffer! Make depth buffer into a shadow map Clear a 2 nd depth buffer Discard fragments if fragment depth is closer than corresponding pixel’s depth in shadow map Save color buffer for compositing Repeat this with current depth buffer to peel another layer Prior depth buffer works as “back stop” for next pass Discard fragments closer or as close as last pass for every pixel

Optimizations for real-time depth peeling Optimizations Render-to-texture to ping-pong between 2 back stop depth buffers (no depth buffer copies) Shadow mapping for 2 nd read-only “back stop” depth buffer Asynchronous occlusion queries to determine fragments still being peeled Threshold to stop peeling Smart front-to-back (“under”) compositing Result: 120+ fps depth peeling for peeling and composting up to 14 layers as needed

So is transparency a solved problem? Bounding the error Assume a lower bound on opacity of objects … and an upper bound on layers peeled worstCaseError = (1- minOpacity ) maxLayers Example: 20% min. opacity with 15 peeled layers Remaining potential transparency could be off by just 3.5% if looking through 15 layers of 20% opacity (worst possible case) Typical cases are much, much better than that As occlusion query can provide a count of mis-ordered pixels Arguably could be for a certain class of transparency Mostly opaque scenes with thin film transparency like windows CAD models made of virtual Jell-O ®

Conclusions NVIDIA GPUs Expect more compute and bandwidth increases >> CPUs DirectX 10 = large functionality upgrade for graphics Cg, the only cross-API, multi-platform language for programmable shading Think shaders as content, not GPU programs trapped inside applications Depth peeling Harnessing the GPU’s brute force for transparency

NVIDIA Graphics, Cg, and Transparency

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to NVIDIA Graphics, Cg, and Transparency (20)

More from Mark Kilgard (19)

Recently uploaded (20)

NVIDIA Graphics, Cg, and Transparency

Editor's Notes