The GPU Revolution: Programmable Graphics Hardware David Luebke University of Virginia.

Slides:



Advertisements
Similar presentations
Fragment level programmability in OpenGL Evan Hart
Advertisements

Perspective aperture ygyg yryr n zgzg y s = y g (n/z g ) ysys y s = y r (n/z r ) zrzr.
COMPUTER GRAPHICS CS 482 – FALL 2014 NOVEMBER 10, 2014 GRAPHICS HARDWARE GRAPHICS PROCESSING UNITS PARALLELISM.
Normal Map Compression with ATI 3Dc™ Jonathan Zarge ATI Research Inc.
Understanding the graphics pipeline Lecture 2 Original Slides by: Suresh Venkatasubramanian Updates by Joseph Kider.
CS-378: Game Technology Lecture #9: More Mapping Prof. Okan Arikan University of Texas, Austin Thanks to James O’Brien, Steve Chenney, Zoran Popovic, Jessica.
9/25/2001CS 638, Fall 2001 Today Shadow Volume Algorithms Vertex and Pixel Shaders.
Informationsteknologi Wednesday, December 12, 2007Computer Graphics - Class 171 Today’s class OpenGL Shading Language.
The Programmable Graphics Hardware Pipeline Doug James Asst. Professor CS & Robotics.
CS5500 Computer Graphics © Chun-Fa Chang, Spring 2007 CS5500 Computer Graphics April 19, 2007.
Control Flow Virtualization for General-Purpose Computation on Graphics Hardware Ghulam Lashari Ondrej Lhotak University of Waterloo.
A Crash Course on Programmable Graphics Hardware Li-Yi Wei 2005 at Tsinghua University, Beijing.
Cg: C for Graphics Jon Moon Based on slides by Eugene Lee.
ATI GPUs and Graphics APIs Mark Segal. ATI Hardware X1K series 8 SIMD vertex engines, 16 SIMD fragment (pixel) engines 3-component vector + scalar ALUs.
The programmable pipeline Lecture 10 Slide Courtesy to Dr. Suresh Venkatasubramanian.
Vertex & Pixel Shaders CPS124 – Computer Graphics Ferdinand Schober.
Status – Week 260 Victor Moya. Summary shSim. shSim. GPU design. GPU design. Future Work. Future Work. Rumors and News. Rumors and News. Imagine. Imagine.
Cg Overview Cg is the High Level language from NVIDIA for programming GPUs, developed in close collaboration with Microsoft Cg is 100% compatible with.
Computer Science – Game DesignUC Santa Cruz Adapted from Jim Whitehead’s slides Shaders Feb 18, 2011 Creative Commons Attribution 3.0 (Except copyrighted.
GPU Tutorial 이윤진 Computer Game 2007 가을 2007 년 11 월 다섯째 주, 12 월 첫째 주.
GPU Graphics Processing Unit. Graphics Pipeline Scene Transformations Lighting & Shading ViewingTransformations Rasterization GPUs evolved as hardware.
Cg Kevin Bjorke GDC NVIDIA CONFIDENTIAL A Whole New World with Cg Graphics Program Written in Cg “C” for Graphics Compiled & Optimized Low Level,
Cg – C for Graphics Eric Vidal CS 280. History General graphics processing languages – Renderman shading language (1988) Assembly languages for graphics.
REAL-TIME VOLUME GRAPHICS Christof Rezk Salama Computer Graphics and Multimedia Group, University of Siegen, Germany Eurographics 2006 Real-Time Volume.
OpenGL 3.0 Texture Arrays Presentation: Olivia Terrell, Dec. 4, 2008.
GPU Programming Robert Hero Quick Overview (The Old Way) Graphics cards process Triangles Graphics cards process Triangles Quads.
Enhancing GPU for Scientific Computing Some thoughts.
Programmable Pipelines. Objectives Introduce programmable pipelines ­Vertex shaders ­Fragment shaders Introduce shading languages ­Needed to describe.
Real-time Graphical Shader Programming with Cg (HLSL)
Geometric Objects and Transformations. Coordinate systems rial.html.
GPU Computation Strategies & Tricks Ian Buck Stanford University.
Graphics Graphics Korea University cgvr.korea.ac.kr 1 Using Vertex Shader in DirectX 8.1 강 신 진
OpenGL Shading Language (Advanced Computer Graphics) Ernest Tatum.
GPU Shading and Rendering Shading Technology 8:30 Introduction (:30–Olano) 9:00 Direct3D 10 (:45–Blythe) Languages, Systems and Demos 10:30 RapidMind.
Programmable Pipelines. 2 Objectives Introduce programmable pipelines ­Vertex shaders ­Fragment shaders Introduce shading languages ­Needed to describe.
Cg Programming Mapping Computational Concepts to GPUs.
1 Dr. Scott Schaefer Programmable Shaders. 2/30 Graphics Cards Performance Nvidia Geforce 6800 GTX 1  6.4 billion pixels/sec Nvidia Geforce 7900 GTX.
The programmable pipeline Lecture 3.
CSE 690: GPGPU Lecture 6: Cg Tutorial Klaus Mueller Computer Science, Stony Brook University.
Computer Graphics The Rendering Pipeline - Review CO2409 Computer Graphics Week 15.
GRAPHICS PIPELINE & SHADERS SET09115 Intro to Graphics Programming.
Programmable Pipelines Ed Angel Professor of Computer Science, Electrical and Computer Engineering, and Media Arts Director, Arts Technology Center University.
David Luebke 1 11/24/2015 Programmable Graphics Hardware.
09/16/03CS679 - Fall Copyright Univ. of Wisconsin Last Time Environment mapping Light mapping Project Goals for Stage 1.
A User-Programmable Vertex Engine Erik Lindholm Mark Kilgard Henry Moreton NVIDIA Corporation Presented by Han-Wei Shen.
Computer Graphics 3 Lecture 6: Other Hardware-Based Extensions Benjamin Mora 1 University of Wales Swansea Dr. Benjamin Mora.
Lab: Vertex Shading Chris Wynn Ken Hurley. Objective Hands-On vertex shader programming Start with simple programs … Part 1: Textured-Lit Teapot.
David Luebke 1 1/25/2016 Programmable Graphics Hardware.
09/25/03CS679 - Fall Copyright Univ. of Wisconsin Last Time Shadows Stage 2 outline.
Ray Tracing using Programmable Graphics Hardware
What are shaders? In the field of computer graphics, a shader is a computer program that runs on the graphics processing unit(GPU) and is used to do shading.
Mesh Skinning Sébastien Dominé. Agenda Introduction to Mesh Skinning 2 matrix skinning 4 matrix skinning with lighting Complex skinning for character.
Programmable Graphics Hardware CS 446: Real-Time Rendering & Game Technology David Luebke University of Virginia.
CgFX Sébastien Dominé, NVIDIA. Overview What is CgFX? CgFX runtime Production pipeline with CgFX CgFX Tools set Demo.
GLSL I.  Fixed vs. Programmable  HW fixed function pipeline ▪ Faster ▪ Limited  New programmable hardware ▪ Many effects become possible. ▪ Global.
An Introduction to the Cg Shading Language Marco Leon Brandeis University Computer Science Department.
GLSL Review Monday, Nov OpenGL pipeline Command Stream Vertex Processing Geometry processing Rasterization Fragment processing Fragment Ops/Blending.
Computer Science – Game DesignUC Santa Cruz Tile Engine.
COMP 175 | COMPUTER GRAPHICS Remco Chang1/XX13 – GLSL Lecture 13: OpenGL Shading Language (GLSL) COMP 175: Computer Graphics April 12, 2016.
第七课 GPU & GPGPU.
Programmable Pipelines
A Crash Course on Programmable Graphics Hardware
Graphics Processing Unit
Chapter 6 GPU, Shaders, and Shading Languages
UMBC Graphics for Games
Introduction to Programmable Hardware
Computer Graphics Practical Lesson 10
RADEON™ 9700 Architecture and 3D Performance
CIS 441/541: Introduction to Computer Graphics Lecture 15: shaders
CS 480/680 Computer Graphics GLSL Overview.
Presentation transcript:

The GPU Revolution: Programmable Graphics Hardware David Luebke University of Virginia

GPUCPU Recap: Modern OpenGL Pipeline Application Vertex Processor Assembly & Rasterization Pixel Processor Video Memory (Textures) Vertices (3D) Xformed, Lit Vertices (2D) Fragments (pre-pixels) Final pixels (Color, Depth) Graphics State Render-to-texture Vertex Processor Pixel Processor Vertex shadersFragment shaders

l Framebuffer l Textures l Fragment processor l Vertex processor l Interpolants 32-bit IEEE floating-point throughout pipeline

Hardware supports multiple data types l Can support 32-bit IEEE floating point throughout pipeline –Framebuffer, textures, computations, interpolants l Fragment processor also supports: –16-bit “half” floating point, 12-bit fixed point –These may be faster than 32-bit on some HW l Framebuffer/textures also support: –Large variety of fixed-point formats n E.g., classical 8-bit per component RGBA, BGRA, etc. –These formats use less memory bandwidth than FP32

Vertex processor capabilities l 4-vector FP32 operations l True data-dependent control flow –Conditional branch instruction –Subroutine calls, up to 4 deep –Jump table (for switch statements) l Condition codes l New arithmetic instructions (e.g. COS) l User clip-plane support

Vertex processor resource limits l 256 instructions per program (effectively much higher w/branching) l 16 temporary 4-vector registers l 256 “uniform” parameter registers l 2 address registers (4-vector) l 6 clip-distance outputs

Fragment processor has flexible texture mapping l Texture reads are just another instruction (TEX, TXP, or TXD) l Allows computed texture coordinates, nested to arbitrary depth –This is a big difference w/ NVIDIA and ATI right now l Allows multiple uses of a single texture unit l Optional LOD control – specify filter extent l Think of it as… A memory-read instruction, with optional user-controlled filtering

Additional fragment processor capabilities l Read access to window-space position l Read/write access to fragment Z l Built-in derivative instructions –Partial derivatives w.r.t. screen-space x or y –Useful for anti-aliasing l Conditional fragment-kill instruction l FP32, FP16, and fixed-point data

Fragment processor limitations l No branching –But, can do a lot with condition codes l No indexed reads from registers –Use texture reads instead l No memory writes

Fragment processor resource limits l 1024 instructions l 512 constants or uniform parameters –Each constant counts as one instruction l 16 texture units –Reuse as many times as desired l 8 FP32 x 4 perspective-correct inputs l 128-bit framebuffer “color” output (use as 4 x FP32, 8 x FP16, etc…)

Cg – “C for Graphics” l Cg is a high-level GPU programming language l Designed by NVIDIA and Microsoft l Competes with the (quite similar) GL Shading Language, a.k.a GLslang

Programming in assembly is painful … FRC R2.y, C11.w; ADD R3.x, C11.w, -R2.y; MOV H4.y, R2.y; ADD H4.x, -H4.y, C4.w; MUL R3.xy, R3.xyww, C11.xyww; ADD R3.xy, R3.xyww, C11.z; TEX H5, R3, TEX2, 2D; ADD R3.x, R3.x, C11.x; TEX H6, R3, TEX2, 2D; … … L2weight = timeval – floor(timeval); L1weight = 1.0 – L2weight; ocoord1 = floor(timeval)/ /128.0; ocoord2 = ocoord /64.0; L1offset = f2tex2D(tex2, float2(ocoord1, 1.0/128.0)); L2offset = f2tex2D(tex2, float2(ocoord2, 1.0/128.0)); … L2weight = timeval – floor(timeval); L1weight = 1.0 – L2weight; ocoord1 = floor(timeval)/ /128.0; ocoord2 = ocoord /64.0; L1offset = f2tex2D(tex2, float2(ocoord1, 1.0/128.0)); L2offset = f2tex2D(tex2, float2(ocoord2, 1.0/128.0)); … Easier to read and modify Cross-platform Combine pieces etc. Assembly

Some points in the design space l CPU languages –C – close to the hardware; general purpose –C++, Java, lisp – require memory management –RenderMan – specialized for shading l Real-time shading languages –Stanford shading language –Creative Labs shading language

Design strategy l Start with C (and a bit of C++) –Minimizes number of decisions –Gives you known mistakes instead of unknown ones l Allow subsetting of the language l Add features desired for GPU’s –To support GPU programming model –To enable high performance l Tweak to make it fit together well

How are current GPU’s different from CPU? 1. GPU is a stream processor –Multiple programmable processing units –Connected by data flows Application Vertex Processor Fragment Processor Assembly & Rasterization Framebuffer Operations Framebuffer Textures

Cg uses separate vertex and fragment programs Application Vertex Processor Fragment Processor Assembly & Rasterization Framebuffer Operations Framebuffer Textures Program

Cg programs have two kinds of inputs l Varying inputs (streaming data) –e.g. normal vector – comes with each vertex –This is the default kind of input l Uniform inputs (a.k.a. graphics state) –e.g. modelview matrix l Note: Outputs are always varying vout MyVertexProgram(float4 normal, uniform float4x4 modelview) { … vout MyVertexProgram(float4 normal, uniform float4x4 modelview) { …

Two ways to bind VP outputs to FP inputs a) Let compiler do it –Define a single structure –Use it for vertex-program output –Use it for fragment-program input struct vout { float4 color; float4 texcoord; … }; struct vout { float4 color; float4 texcoord; … };

Two ways to bind VP outputs to FP inputs b) Do it yourself –Specify register bindings for VP outputs –Specify register bindings for FP inputs –May introduce HW dependence –Necessary for mixing Cg with assembly struct vout { float4 color : TEX3 ; float4 texcoord : TEX5; … }; struct vout { float4 color : TEX3 ; float4 texcoord : TEX5; … };

Some inputs and outputs are special l e.g. the position output from vert prog –This output drives the rasterizer –It must be marked struct vout { float4 color; float4 texcoord; float4 position : HPOS; }; struct vout { float4 color; float4 texcoord; float4 position : HPOS; };

How are current GPU’s different from CPU? 2. Greater variation in basic capabilities –Most processors don’t yet support branching –Vertex processors don’t support texture mapping –Some processors support additional data types Compiler can’t hide these differences Compiler can’t hide these differences Least-common-denominator is too restrictive Least-common-denominator is too restrictive We expose differences via language profiles (list of capabilities and data types) We expose differences via language profiles (list of capabilities and data types) Over time, profiles will converge Over time, profiles will converge Compiler can’t hide these differences Compiler can’t hide these differences Least-common-denominator is too restrictive Least-common-denominator is too restrictive We expose differences via language profiles (list of capabilities and data types) We expose differences via language profiles (list of capabilities and data types) Over time, profiles will converge Over time, profiles will converge

How are current GPU’s different from CPU? 3. Optimized for 4-vector arithmetic –Useful for graphics – colors, vectors, texcoords –Easy way to get high performance/cost C philosophy says: expose these HW data types C philosophy says: expose these HW data types Cg has vector data types and operations e.g. float2, float3, float4 Cg has vector data types and operations e.g. float2, float3, float4 Makes it obvious how to get high performance Makes it obvious how to get high performance Cg also has matrix data types e.g. float3x3, float3x4, float4x4 Cg also has matrix data types e.g. float3x3, float3x4, float4x4 C philosophy says: expose these HW data types C philosophy says: expose these HW data types Cg has vector data types and operations e.g. float2, float3, float4 Cg has vector data types and operations e.g. float2, float3, float4 Makes it obvious how to get high performance Makes it obvious how to get high performance Cg also has matrix data types e.g. float3x3, float3x4, float4x4 Cg also has matrix data types e.g. float3x3, float3x4, float4x4

Some vector operations // // Clamp components of 3-vector to [minval,maxval] range // float3 clamp(float3 a, float minval, float maxval) { a = (a < minval.xxx) ? Minval.xxx : a; a = (a > maxval.xxx) ? Maxval.xxx : a; return a; } // // Clamp components of 3-vector to [minval,maxval] range // float3 clamp(float3 a, float minval, float maxval) { a = (a < minval.xxx) ? Minval.xxx : a; a = (a > maxval.xxx) ? Maxval.xxx : a; return a; } Swizzle – replicate and/or rearrange components. ? : is per-component for vectors Comparisons between vectors are per-component, and produce vector result

Cg has arrays too l Declared just as in C But, arrays are distinct from built-in vector types: float4 != float[4] l Language profiles may restrict array usage vout MyVertexProgram( float3 lightcolor[10], …) { … vout MyVertexProgram( float3 lightcolor[10], …) { …

How are current GPU’s different from CPU? 4. No support for pointers –Arrays are first-class data types in Cg 5. No integer data type –Cg adds “bool” data type for boolean operations –This change isn’t obvious except when declaring vars

Cg basic data types l All profiles: –float –bool l All profiles with texture lookups: –sampler1D, sampler2D, sampler3D, samplerCUBE l NV_fragment_program profile: –half -- half-precision float –fixed -- fixed point [-2,2)

Other Cg capabilities l Function overloading l Function parameters are value/result –Use “out” modifier to declare return value l “discard” statement – fragment kill void foo (float a, out float b) { b = a; } void foo (float a, out float b) { b = a; } if (a > b) discard; if (a > b) discard;

Cg Built-in functions l Texture lookups (in fragment profiles) l Math –Dot product –Matrix multiply –Sin/cos/etc. –Normalize l Misc –Partial derivative (when supported) l See spec for more details

Cg Example – part 1 // In: // eye_space position = TEX7 // eye space T = (TEX4.x, TEX5.x, TEX6.x) denormalized // eye space B = (TEX4.y, TEX5.y, TEX6.y) denormalized // eye space N = (TEX4.z, TEX5.z, TEX6.z) denormalized fragout frag program main(vf30 In) { float m = 30; // power float3 hiCol = float3( 1.0, 0.1, 0.1 ); // lit color float3 lowCol = float3( 0.3, 0.0, 0.0 ); // dark color float3 specCol = float3( 1.0, 1.0, 1.0 ); // specular color // Get eye-space eye vector. float3 e = normalize( -In.TEX7.xyz ); // Get eye-space normal vector. float3 n = normalize( float3(In.TEX4.z, In.TEX5.z, In.TEX6.z ) );

Cg Example – part 2 float edgeMask = (dot(e, n) > 0.4) ? 1 : 0; float3 lpos = float3(3,3,3); float3 l = normalize(lpos - In.TEX7.xyz); float3 h = normalize(l + e); float specMask = (pow(dot(h, n), m) > 0.5) ? 1 : 0; float hiMask = (dot(l, n) > 0.4) ? 1 : 0; float3 ocol1 = edgeMask * (lerp(lowCol, hiCol, hiMask) + (specMask * specCol)); fragout O; O.COL = float4(ocol1.x, ocol1.y, ocol1.z, 1); return O; } What does this shader look like?

Toon Shader l This is a simple a “toon shader” designed to give a cartoonish look to the geometry

New vector operators l Swizzle – replicate/rearrange elements a = b.xxyy; l Write mask – selectively over-write a.w = 1.0; Vector constructor builds vector a = float4(1.0, 0.0, 0.0, 1.0);

Change to constant- typing mechanism l In C, it’s easy to accidentally use high precision half x, y; x = y * 2.0; // Double-precision multiply! l Not in Cg x = y * 2.0; // Half-precision multiply l Unless you want to x = y * 2.0f; // Float-precision multiply

l Dot product –dot(v1,v2); // returns a scalar l Matrix multiplications: –matrix-vector: mul(M, v); // returns a vector –vector-matrix: mul(v, M); // returns a vector –matrix-matrix: mul(M, N); // returns a matrix Dot product, Matrix multiply

Demos and Examples

Cg runtime API helps applications use Cg l Compile a program l Select active programs for rendering l Pass “uniform” parameters to program l Pass “varying” (per-vertex) parameters l Load vertex-program constants l Other housekeeping

Runtime is split into three libraries l API-independent layer – cg.lib –Compilation –Query information about object code l API-dependent layer – cgGL.lib and cgD3D.lib –Bind to compiled program –Specify parameter values –etc.

Runtime API for OpenGL // Create cgContext to hold vertex-profile code VertexContext = cgCreateContext(); // Add vertex-program source text to vertex-profile context // This is where compilation currently occurs cgAddProgram(VertexContext, CGVertProg, cgVertexProfile, NULL); // Get handle to 'main' vertex program VertexProgramIter = cgProgramByName(VertexContext, "main"); cgGLLoadProgram(VertexProgramIter, ProgId); VertKdBind = cgGetBindByName(VertexProgramIter, "Kd"); TestColorBind = cgGetBindByName(VertexProgramIter, "I.TestColor"); texcoordBind = cgGetBindByName(VertexProgramIter, "I.texcoord"); // Create cgContext to hold vertex-profile code VertexContext = cgCreateContext(); // Add vertex-program source text to vertex-profile context // This is where compilation currently occurs cgAddProgram(VertexContext, CGVertProg, cgVertexProfile, NULL); // Get handle to 'main' vertex program VertexProgramIter = cgProgramByName(VertexContext, "main"); cgGLLoadProgram(VertexProgramIter, ProgId); VertKdBind = cgGetBindByName(VertexProgramIter, "Kd"); TestColorBind = cgGetBindByName(VertexProgramIter, "I.TestColor"); texcoordBind = cgGetBindByName(VertexProgramIter, "I.texcoord");

Runtime API for OpenGL // // Bind uniform parameters // cgGLBindUniform4f(VertexProgramIter, VertKdBind, 1.0, 1.0, 0.0, 1.0); … // Prepare to render cgGLEnableProgramType(cgVertexProfile); cgGLEnableProgramType(cgFragmentProfile); … // Immediate-mode vertex glNormal3fv(&CubeNormals[i][0]); cgGLBindVarying2f(VertexProgramIter, texcoordBind, 0.0, 0.0); cgGLBindVarying3f(VertexProgramIter, TestColorBind, 1.0, 0.0, 0.0); glVertex3fv(&CubeVertices[CubeFaces[i][0]][0]); // // Bind uniform parameters // cgGLBindUniform4f(VertexProgramIter, VertKdBind, 1.0, 1.0, 0.0, 1.0); … // Prepare to render cgGLEnableProgramType(cgVertexProfile); cgGLEnableProgramType(cgFragmentProfile); … // Immediate-mode vertex glNormal3fv(&CubeNormals[i][0]); cgGLBindVarying2f(VertexProgramIter, texcoordBind, 0.0, 0.0); cgGLBindVarying3f(VertexProgramIter, TestColorBind, 1.0, 0.0, 0.0); glVertex3fv(&CubeVertices[CubeFaces[i][0]][0]);

CgFX l Extensions to base Cg Language –Designed in cooperation with Microsoft l Primary for use in stand-alone files l Purpose –Integration with DCC applications –Multiple implementations of a shader –Represent multi-pass shaders –Use either Cg code or assembly code

How DCC application can use CgFX l Create sliders for shader parameters –CgFX allows annotation of parameters –E.g. to specify reasonable range of values l Switch between different implementations of same effect –E.g. GeForce4 and NV30 l Rendering setup (e.g. filter modes)

MAX CgFX Plugin Screenshot

CgFX Example texture cubeMap : EnvMap ; matrix worldView : WorldView; matrix wvp : WorldViewProjection; technique t0 { pass p0 { Zenable = true; Texture[0] = ; Target[0] = TextureCube; MinFilter[0] = Linear; MagFilter[0] = Linear; VertexShaderConstant[4] = ; VertexShaderConstant[10] = ;

CgFX Example ( cont. ) VertexShader = asm { vs.1.1 mul r0.xyz, v3.x, c4 mad r0.xyz, v3.y, c5, r0 mad oT0.xyz, v3.z, c6, r0 m4x4 oPos, v0, c10 mov oD0, v5 }; PixelShader = asm { ps.1.1 tex t0 mov r0, t0 }; }

Coming Soon… l Future hardware and drivers will be exposing even more programmability l Current-generation chips: NV3X, R3XX –The first fully-programmable parts –More or less the same feature set n ATI R300: only 24-bit precision, no 16-bit support, shorter programs, less flexible dependent texturing, better performance n ATI R350: Includes an F-buffer which stores and replays fragments in rasterization order n Not currently exposed, though

Coming Soon… l Next-generation chips: NV40, R400 –Still under wraps, but ps3.0 gives us an idea –Expect: n At least some branching in fragment program n Much longer programs (virtualized to multipass) n Flexible memory: render-to-vertex array, etc. n Faster readbacks (with PCI-express) –Don’t expect: n Precision higher than 32-bit