Cg a system programming graphics hardware in a c like language
Download
1 / 62

Cg: A system programming graphics hardware in a C-like language - PowerPoint PPT Presentation


  • 109 Views
  • Uploaded on

Cg: A system programming graphics hardware in a C-like language. William R. Mark The University of Texas at Austin R. Steven Glanville NVIDIA Corporation Kurt Akeley NVIDIA Corporation Mark J. Kilgard NVIDIA Corporation.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Cg: A system programming graphics hardware in a C-like language' - kimo


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Cg a system programming graphics hardware in a c like language

Cg: A system programming graphics hardware in a C-like language

William R. MarkThe University of Texas at AustinR. Steven Glanville NVIDIA CorporationKurt Akeley NVIDIA CorporationMark J. Kilgard NVIDIA Corporation

Siggraph 2003


Cg s model of gpu
Cg’s Model of GPU language

[Cg Toolkit]


The graphics pipeline
The Graphics Pipeline language

[Programming Graphics Hardware]


Outline

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline


Introduction
Introduction language

  • Graphics architectures are now highly programmable, and support application-specified assembly programs for both vertex processing and fragment processing

  • Most effective tool for programming these architectures is a high level language

    • program portability, improved programmer productivity, easier develop programs incrementally and interactively

    • particularly valuable for shader programs


Introduction1
Introduction language

  • A system for programming graphics hardware that supports programs written in a new C-like language named Cg


Outline1

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline


The evolution of gpu programming language

IRIS GL language(SGI, 1982)

RenderMan(Pixar, 1988)

OpenGL(ARB, 1992)

PixelFlow Shading Language (UNC, 1998)

Reality Lab(RenderMorphics, 1994)

Real-Time Shading Language (Stanford, 2001)

Direct3D(Microsoft, 1995)

The Evolution of GPU Programming Language

C(AT&T, 1970s)

C++(AT&T, 1970s)

Java(Sun, 1970s)

HLSL(Microsoft, 2002)

Cg(NVIDIA, 2002)

GLSL(ARB, 2003)

[NVIDIA]


Background
Background language

  • In real-time rendering systems, support for user programmability has evolved with the underlying graphics hardware

  • For many years, mainstream commercial graphics hardware was configurable , but not user programmable

    • multipass rendering techniques: SGI’s OpenGL shader system [2000] and Quake III’s shading language [1999]


Background1
Background language

  • In response to this trend, graphics architects began to incorporate programmable processors into both the vertex-processing and fragment-processing stages of single-chip graphics architectures [2001]

  • The most recent generation of PC graphics hardware (DirectX 9 or DX9 hardware [2002]), continues the trend of adding programmable functionality to both the fragment and the vertex processors


Dx9 class architectures
DX9-class Architectures language

  • Vertex processor

    • adds conditional branching functionality

  • Fragment processor

    • adds flexible support for floating-point arithmetic and computed texture coordinates


Outline2

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline


Design goals
Design Goals language

  • Ease of programming

    • programming in AL is slow and painful

    • easy reuse of code

  • Portability

    • hardware from different companies

    • hardware generations (DX8-class hardware or better)

    • operating systems (Windows, Linux, MacOS)

    • major 3D APIs (OpenGL, DirectX)


Design goals1
Design Goals language

  • Complete support for hardware functionality

  • Performance

  • Minimal interference with application data

  • Ease of adoption

  • Extensibility for future hardware

  • Support for non-shading uses of GPU

  • (some of these goals are in partial conflict with each other)


Outline3

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline


Key design decisions
Key Design Decisions language

  • A “general-purpose language”,not a domain-specific “shading language"

  • A program for each pipeline stage

  • Permit subsetting of language

  • Modular system architecture


Domain specific vs general purpose language
Domain-specific vs. General-purpose Language language

  • Domain-specific languages

    • shading computation

  • General-purpose languages

    • expose the fundamental capabilities of programmable graphics architectures


General purpose language
“General-purpose Language language"

  • When considered with our design goals,let us to develop a hardware focused general-purpose language

    • high performance

    • minimal management of application data

    • support for non-shading uses of GPU’s


Cg follows c s philosophy
Cg follows C language's philosophy

  • C language in achieving goals for performance, portability, and generality of CPU programs that were very similar to our goals for a GPU language

  • Extend and modify C to support GPU architectures effectively → Cg

    • language follows syntax and philosophy of C

    • reserves all C and C++ keywords

    • selectively uses ideas from C++, Java, RenderMan, RTSL

    • 3Dlabs, OpenGL ARB(GLSL), Microsoft (HLSL)


Programming model
Programming Model language

  • Choosing a programming modelto layer on top of the stream-processing architecture

    • RTSL, RenderMan: single program

    • OpenGL, Direct3D: two separate programs

    • the programs consume an element of data from one stream, and write an element of data to another stream

  • Single-program model is not a natural match for the underlying dual-processor architecture


A program for each pipeline stage

Vertex Program language

Executed Once Per Vertex

Fragment Program

Executed Once Per Fragment

A Program for Each Pipeline Stage

The user-programmable processors in today's graphics architectures use a stream-processing model

[Programming Graphics Hardware]


A language for expressing stream kernels
A language for Expressing Stream Kernels language

  • A single language specification for writing a stream kernel (i.e. vertex program or fragment program)

    • simplify and generalize the language by eliminating most of the distinctions between vertex / fragment programs

  • And then allowed particular processors to omit support for some capabilities of the language

    • e.g. use of texture lookuptoday’s vertex processor don’t support texture lookups


A language for expressing stream kernels1
A language for Expressing Stream Kernels language

  • Current Cg system can be thought as a specialized stream processing system

  • Cg system relies on the established graphics pipeline dataflow of GPUs

    • not connect stream processing kernels together

  • Cg’s focus on kernel programming

    • specialized for stream-kernel programming

    • could be extended to support other parallel programming models


A data flow interface for program inputs and outputs
A Data-flow Interface for Program Inputs and Outputs language

  • Should the system allow any vertex program communicates with any fragment program ?

    • via the rasterizer / interpolator

  • How should the vertex program outputs and fragment program inputs be defined to ensure compatibility ?


A data flow interface for program inputs and outputs1
A Data-flow Interface for Program Inputs and Outputs language

  • When programming GPUs at the assembly level

    • the interface between fragment programs and vertex programs is established at the register level

    • For example: user can establish a conventionTEXCOORD3 I/O register

  • The binding names must be chosen from a predefined namespace with predefined data types


A data flow interface for program inputs and outputs2
A Data-flow Interface for Program Inputs and Outputs language

  • Cg and HLSL: modified bind-by-name scheme

    • a predefined namespace is used instead of the user-defined identifier name

    • provide maximum control over the generated code

  • Cg also supports a bind-by-position

    • requires that data be organized in an ordered list

    • a function-parameter list or a list of structure members

  • GLSL: purebind-by-name

    • not supported by either Cg or HLSL


Permit subsetting of language
Permit Subsetting of Language language

  • Conflict goals: portability and comprehensive

  • Major differences in functionality between the different graphics architecture that Cg supports

    • e.g. DX9: floating-point fragment arithmetic

  • Consider a variety of possible approaches to hiding or exposing these difference

    • minor architectural differences could be efficiently hidden by the compiler, Cg did so

    • major architectural differences can not be hidden by a compiler → Performance


Permit subsetting of language1
Permit Subsetting of Language language

  • Cg wanted both support

    • the existing installed base of DX8-class hardware

    • to provide access to the capabilities of the latest hardware

  • Cg:

    • expose major architectural differences asdifferences in language capabilities

    • to minimize the impact on portability, Cg exposed the differences using a subsetting mechanism

    • each processor is defined by aprofile

      • specifies which subset of the full Cg specification is supported on that processor



No mandatory virtualization
No Mandatory Virtualization language

  • Whether or not to automatically virtualizehardware resources using software-based multi-pass techniques ?

  • Do not require it in the Cg language specification (not support in the current release of Cg)

    • effective virtualization of this hardware is impossible

    • too slowly to be useful in a real-time application

    • conflicted with our design goals(virtualization on current hardware requires global management of application data and hardware resources)


Layered above an assembly language interface
Layered Above An Assembly Language Interface language

  • Whether or not to expose machine / assembly language as an additional interface for system users ?

  • By providing access to the assembly code, the system allows users

    • tune their code by studying the compiler output

    • manually editing the compiler output

    • even write programs entirely in assembly language

      • maximize performance


Explicit program parameters
Explicit Program Parameters language

  • All input parameter to a Cg program

    • be explicitly declared using non-static global variables

    • by including the parameters on the entry function’s parameter list

  • Cg also provides a set of runtime API routines that allow parameters to be passed using their true names and types


Explicit program parameters1
Explicit Program Parameters language

  • The Cg compiler prepends a header to its assembly code output to describe the mapping betweenprogram parameter and registers

    #profile arbvp1

    #program simpleTransform

    #semantic simpleTransform.brightness

    #semantic simpleTransform.modelViewProjection

    #var float4 objectPosition : $vin.POSITION : POSITION : 0 : 1

    #var float color : $vin.COLOR : COLOR : 1 : 1

    ….

    #var float brightness :: c[0] : 8 : 1

    #var float4x4 modelViewProjection :: c[1], 4 : 9 : 1


Outline4

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline


Example program

vector of four float language

Example Program

  • Example Cg Program for Vertex Processor

    void simpleTransform(float4 objectPosition : POSITION,

    float4 color : COLOR,

    float4 decalCoord : TEXCOORD0,

    out float4 clipPosition : POSITION,

    out float4 oColor : Color,

    out float4 oDecalCoord : TEXCOORD0,

    uniform float brightness,

    uniformfloat4x4 modelViewProjection)

    {

    clipPositon = mul(modelViewProjection, objectPosition);

    oColor = brightness * color;

    oDecalCoord = decalCoord;

    }


Other cg functionality
Other Cg Functionality language

  • Provides structure, arrays, (+, *, /, etc.), boolean type and (||, &&, !, etc.), (++/--), (?:), (+=, etc.)

  • Supports programmer-defined functions(recursive functions are not allowed)

  • Provides only a subset of C’s control flow construct:(do, while, for, if, break, continue) (goto, switch) are not supported

  • Doesn’s support pointers or bitwise operations

  • Supports #include, #define, #ifdef, etc. (matching the C preprocessor)


Outline5

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline


Design issues
Design Issues language

  • Support for hardware

  • User-defined interfaces between modules

  • Other language design decisions

  • Runtime API


Support for hardware
Support for Hardware language

  • The discussion below is organized around the characteristics of GPU hardware

    • Stream processor

    • Data types

    • Indirect addressing

    • Interaction with the rest of the graphics pipeline

    • Shading-specific hardware functionality


Stream processor
Stream Processor language

  • A GPU program is executed many times –once for each vertex or fragment

    • efficiently: input → changes vs. unchanged(reside in different register sets)

  • A GPU language compiler must know the category to which an input belongs before it can generate assembly code


Stream processor1
Stream Processor language

  • Terminology for the two kind of input

    • varying input

    • uniform input

  • Cg uses the uniform qualifier

  • Computation that depend only on uniform parameter

    • do not need to be redone for every vertex or fragment


Data type
Data Type language

  • Multiple numeric data types

    • float(32-bit), half(16-bit), fixed(12-bit)

  • Vector data types and operators

  • Matrix data types and operations

  • Not support integer data types

  • Add a bool data type for conditional operation


Indirect addressing
Indirect Addressing language

  • Current graphics processors have very limited indirect addressing capability (uniform, sampler)

  • An array assignment in Cg performs a copy of the entire array

  • Cg currently forbids the use of pointer

  • Cg currently forbids recursive function calls

  • Support call-by-value-result semantics

    • using a notation (in and out parameter modifier)


Interaction with the rest of the graphics pipeline
Interaction with the Rest of the Graphics Pipeline language

  • Some of the I/O register are used to control the non-programmable parts of the graphics pipeline, rather than to pass general-purpose data

  • The Cg specification mandates that certain register identifiers(e.g. POSITION) be supported as an output by all vertex profiles, and that certain other identifiers be supported by all fragment profiles


Shading specific hardware functionality
Shading-specific Hardware Functionality language

  • The least generation of graphics hardware include a variety of capabilities specialized for shading

  • Chose to expose the latest generation of graphics hardware capability via Cg’s standard library functions

    • maintains the general-purpose nature of the language

  • Cg standard library supports a variety of mathematical, geometric, and specialized functions


User defined interface between modules
User-defined Interface Between Modules language

  • The general-purpose solution we chose is adopted from Java and C#

  • Programmer may define an interface, which specifies one or more function prototypes

  • Programmer implements the interface by defining a struct (i.e. class) that contains definition for the interface’s function


Other language design decisions
Other Language Design Decisions language

  • Function overloading by types and by profiles

  • Constants are typeless

  • No type checking for textures


Function overloading by types and by profile
Function Overloading by Types and by Profile language

  • Support function overloading by data type

    • mechanism is similar to C++ (less complex)

  • Also permit overloaded by profile

    • it is possible to write multiple versions of a function that are optimized for different architecture

    • the compiler will automaticallychose the version for the current profile


Overloading
Overloading language

  • Function overloading by hardware profile

    // For ps_1_1 profile, use cubemap to normalize

    ps_1_1 float3 mynomalize(float3 v)

    {

    return texCUBE(norm_cubmap, v.xyz).xyz;

    }

    //For ps_2_0 profile, use stdlib routine to normalize

    ps_2_0float3 mynormalize(float3 v)

    {

    return normalize(v);

    }


Constants are typeless
Constants are Typeless language

  • Change the type promotion rulesfor constants

    • C: float x; 2.0*x → double precision

    • Cg: half y; 2.0*y → half precision

  • Internally, the new constant promotion rules are implemented by assigning a different type (cfloat or cint) to constants that do not have an explicit type suffix


No type checking for textures
No Type Checking for Textures language

  • The Cg system leaves the responsibility for most texture management (e.g. loading textures, specifying texture formats, etc.) with the underlying 3D API

  • Thus, the Cg system has very little information about the texture types

  • Stronger type checking would be possible by integrating the Cg system more tightly with the 3D API


Runtime api
Runtime API language

  • Cg runtime API is composed of two parts

    • Independent of the 3D API andprovide a procedural interface to the compiler and its output

    • Layered ontop of 3D API and used to load and bind Cg program,to pass uniform and varying parameters to them, andto perform miscellaneous housekeeping tasks


Compound types are exploded to cross api
Compound Types are Exploded to Cross API language

  • Cg programs may declare uniform parameters with compound types such as structures and arrays

  • The application passes the values of these parameters to the Cg program by using the Cg runtime API

  • To explode compound data structures into their constituent parts to pass them across the API


Cg system can shadow parameter values
Cg System can Shadow Parameter Values language

  • The Cg runtime can manage many Cg programs at once, each with its own uniform parameters

  • GPU hardware can only hold a limited number of programs and parameters at time

  • The Cg runtime can be configured to shadowa program’s parameters, so that the parameter values persist when the program is changed


Outline6

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline


Cg a system programming graphics hardware in a c like language
CgFX language

  • CgFX can represent and manage:

    • Functions that execute on the CPU

    • Multi-pass rendering effects

    • Configurable graphics state

    • Assembly-language GPU programs

    • Multiple implementations of a single shading effect


Outline7

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline



Example
Example language


Outline8

Introduction language

Background

Design Goals

Key Design Decisions

Cg Language Summary

Design Issues

CgFX

System Experiences

Conclusion

Outline


Conclusion
Conclusion language

  • Cg system:

    • A system for programming GPUs

  • Cg language:

    • Extends and restricts C as needed for GPU’s

    • Expresses stream kernels

    • HW oriented language

  • Designed to age well

    • By reintroducing missing C features


Resource cg toolkit

Resource: Cg Toolkit language

~End~