Cg: A system for programming graphics hardware in a Clike language

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

• Mark, Glanville, Akeley, Kilgard

2
High Level Design Goals

• Ease of programming
• Portability (hardware, OS, API)
• Complete support for hardware functionality
• Performance
• Minimal interference with application data
• Ease of adoption (familiar incremental)
• Extensibility for future hardware
• Support for non-shading uses of the GPU

3
Key Design Decisions

• General Purpose not Domain-Specific

Design goals of performance, minimal management
of application data, and support for non-shading
uses of GPU

• Whereas with Domain-Specific
• Runtime cost of operators not obvious
• May not match desired abstraction
• Abstraction may not match hardware

4
Key Design Decisions

• A Program for Each Pipeline Stage

• Closer match to underlying hardware
• Easier to support branching
• Mix-and-Match vertex pixel kernels
• Specialized stream processing
• Single language for both stream kernels
• Processors omit support for capabilities
• Specific mechanism for attaching kernels

5
Key Design Decisions

• A Program for Each Pipeline Stage

• Data flow interface for inputs outputs
• Cg, HLSL, Assembly language support a modified
  bind-by-name scheme (data is put in specific
  registers)
• Cg also supports bind-by-position where data is
  organized in an ordered list
• GLSL uses pure bind-by-name where binding of
  identifiers to actual hardware is deferred until
  kernels are paired

6
Key Design Decisions

• Permit subsetting of the language

Processors are defined by profiles that specify
which subset of the full language is supported by
that processor (GLSL does not support profiles,
however the OpenGL extension mechanism reduces
the significance of this difference)
7
Key Design Decisions

• Modular system architecture

8
Key Design Decisions

• Modular System Architecture

• No Mandatory Virtualization
• Virtualization is most valuable on hardware with
  the fewest resources (DX8) which cannot be
  effectively virtualized
• Resource limits on newer hardware are high
  enough that programs exceeding the limits likely
  would run too slowly
• Requires system to manage both the vertex and
  pixel kernels

9
Key Design Decisions

• Modular System Architecture

• Assembly Language Interface
• Compiler can be used as a command-line tool or
  invoked via an API at runtime
• Assembly code can be further tuned
• Application developer can guarantee a pre-tested
  version of the compiler is used
• HLSL takes same approach while GLSL integrates
  the compiler into the driver

10
Key Design Decisions

• Modular System Architecture

• Explicit program parameters
• All program parameters must be explicitly
  declared using non-static globals or via
  parameters to the entry function
• As in assembly language, parameters can be
  passed in untyped via registers
• Cg runtime API allows for parameters to be
  passed using true names types

11
Cg Language Summary

• Supports

• First-class support for vector and matrix types
• Function overloading as in C
• Operators accept and return scalars vectors
• uniform keyword indicates a variables value
  will not vary over a batch of data
• out keyword indicates a variable is an output
• structures, arrays, Cs math operators, etc.

12
Cg Language Summary

• Does Not Support

• Recursive functions, switch, goto
• pointers
• bitwise operations
• lacks most C features for programming in the
  large (e.g. classes, templates, operator
  overloading, exception handling, namespaces)

13
Design Issues

• Hardware Support

• Stream Processor
• uniform and varying keywords identify data types
• Data Types
• multiple numeric types (float, half, fixed) and
  bool
• vector data types and operators up to length 4
• Indirect Addressing
• not supported in Cg
• read/write parameters implemented via call-by
  value-result semantics using in and out as in
  Ada

14
Design Issues

• Hardware Support

• Interaction with rest of the graphics pipeline
• certain register identifiers must be supported
  as an output by all vertex profiles and certain
  identifiers must be supported by all fragment
  profiles (e.g. vertex kernel must output a
  position vector in a specific register and
  fragment shader that modifies a depth value must
  write to a particular register)
• Shading-specific hardware functionality
• Exposed in a standard library instead of the
  language itself (e.g. specific texture sampling)

15
Design Issues

• Other Design Decisions

• User-defined interfaces between modules
• Programmer can define an interface specifying one
  or more function prototypes to create
  interoperable modules
• Function overloading by type and profile
• Constants are typeless (easier modification)
• No type checking for textures

16
Design Issues

• Runtime API

• Compound types are exploded to cross API
• Cg system can shadow parameter values

17
CgFX

• Managing the non-programmable parts

• Functions that execute on the CPU to perform
  setup operations
• Multi-pass rendering effects
• Configurable graphics state such as texture
  filtering modes
• Assembly-language GPU programs
• Multiple implementations of a single effect