Chapter 5: DirectX

1
(No Transcript)
2
Chapter 5 DirectX

• Chas. Boyd

3
Outline

• What drove the language design?
• Background
• What does it look like?
• Syntax definition
• How does it work?
• API integration
• How is it used?
• Effects Framework

4
Background

• The DirectX Process
• Evolution of DirectX

5
Industry Process

• Based on iteration with partners
• Requirements from software developers
• Feasibilities from hardware developers
• Combine to deliver product for programmers
• Pipelined to work in parallel
• Relies on Reference Implementation

6
Direct3D Reference

• Software model of hardware
• Analogous to/input to C model stage of hardware
  design
• Acts as compilable specification
• Used to communicate new features and requirements
  to IHVs
• Provided as comparison to ISVs
• to check behavior of drivers while coding
• Used to test drivers for conformance
• Color rules by Jim Blinn

7
Industry Process
Hardware Vendors
Software Developers
DirectX Team
DirectX Components
New Hardware
End Users
8
DirectX Evolution

• 
  DX9 Float Pixels
• 
  DX8.1 More Shaders
• DX8
  Programmability
• DX7 Hardware TL
• DX6 Multi-Texture
• DX5 DrawPrim
• DX3 1st Direct3D

96 97 98 99 00 01 02
03 04
9
DirectX Graphics Architecture
Vector Data
VB
Vertex Shader
Geometry Ops
Vertex Components
Primitive Ops
Pixel Shader
Pixel Ops
Image Surface
Samplers
Output pixels
10
Vertex Shader

Vec4
Vec15
A0
Const0
R0
Const1
R1
Vertex ALU
Const2
R2
R3
Const3


R11
Const95
Hpos
Color0
Color1
11
Pixel Shader Architecture
Hpos
color
d0
d1
constant
texture
c0
t0
Stage0
c1
Pixel ALU
t1
Stage1
t2
c2
Stage2
t3
c3
Stage3
c4
temp
Texture Stages
r0
...
Pixel
r1
c7
12
DirectX 6 Multitexture

• Texture registers 2-8
• Temp registers 1
• Color registers 2
• Constant registers 1
• Output registers 0
• Instruction count 2-8
• Supports dependent reads

13
DirectX 8 Pixel Shaders

• Texture registers 4
• Temp registers 2
• Color registers 2
• Constant registers 8
• Output registers 0
• Instruction count 8
• texture address ops 4

14
DirectX 9 Pixel Shaders

• Texture registers 16
• Temp registers 12
• Color registers 2
• Texture Coordinates 8
• Output registers 4
• Instruction count 64
• texture address ops 32
• Supports flow control

15
DirectX 9.1 Pixel Shaders

• Texture registers 16
• Temporary registers 16
• Color registers 0
• Texture Coordinates 8
• Constant registers 64
• Output Registers 4
• Instruction count 1024
• Dynamic flow control

16
DirectX 6 API

• Multitexture
• SetTSS( 0, COLOROP, SELECT )
• SetTSS( 0, COLORARG1, TEXTURE )
• SetTSS( 1, COLOROP, ADD )
• SetTSS( 1, COLORARG1, CURRENT )
• SetTSS( 1, COLORARG2, TEXTURE )

17
Multi-Texture Macros

• SETINSTR( 0, SELECT, TEXTURE, )
• SETINSTR( 1, ADD, CURRENT, TEXTURE )

18
DirectX 8 Assembly

• tex t0 base texture
• tex t1 environment map
• add r0, t0, t1 apply reflection

19
DirectX 9 HLL Syntax

• outColor tex2d( baseTextureCoord, baseTexture )
• texCube( EnvironmentMapCoord, Environment )

20
Compulsory Figures

• Specular Bump Mapping
• BRDFs
• Procedural Wood

21
Per-Pixel Specular
Microsoft
DIRECTX
22
BRDFs
23
Basic Procedural Wood
24
Wood with Noise
25
2-Hemisphere Model
Sky Color
q
Ground Color
26
Hemisphere Lighting
27
(No Transcript)
28
Hemisphere Result
29
Why an HLL?

• Scalability vs hw
• Programming complexity
• Higher Level Language solves these

30
Design Goals

• High level enough to hide hardware specific
  details
• Simple enough for efficient code generation
• Familiar enough to reduce learning curve
• With enough optimizing back-ends for portability

31
Design Baseline

• C -like syntax
• A standard language
• like c or C or HTML
• in the VS.net IDE

32
Graphics Architecture
Application
D3DX
Assembler, compiler, effects, utilities
Direct3D
Semantic mapping
Driver
Code translation
Hardware
33
Preprocessor

• define
• elif
• else
• endif
• error
• Function-style defines not supported

• if
• include
• line
• undef

34
Types

• Basic type is 32-bit float
• Structs and arrays supported
• Typedef to shorthand user defined types
• Component access and swizzles

35
Variables

• Local / global
• Static
• Global variables that are not externally visible
• Const
• Cannot be modified by the shader program
• Can be set external to the program
• Can have initializers
• Can have semantics
• For function parameters

36
Operators

• Pretty much all of C operators
• Including ? and sizeof()
• No new language semantics
• Despite temptation
• Arithmetic operators are per component
• Matrix multiply is an intrinsic function
• Logical operators are per component
• No bitwise operators

37
Statement Syntax

• statements
• expression
• return expression
• if ( expression ) statement else statement
• for ( expression variable_declaration
  expression expression ) statement

38
Intrinsic functions
39
User Functions

• Standard C-like functions
• Output type and input parameters
• Parameters can be passed by copy in/copy out
  mechanism
• in/out declaration
• Inlined internally -no recursion

40
Functions (cont.)

• Can be static (not externally accessible)
• Non-static functions parameters must have
  Direct3D declarator semantics
• Parameters can be marked const
• Parameters can have default initializers

41
Differences from C

• No pointers
• No recursion

42
HLSL Summary

• Ease of Use
• Enable software developers
• Consistency of Implementation
• Enable multiple vendors
• Management of Evolution
• Enable multiple generations
• Result
• Fundamental architecture of DXG software stack
  and higher level language

43
Application Integration
44
Geometry Mapping

• DirectX 8 Vertex Shaders assume a data layout
• Decl shader code are tied together
• Forces shader author to communicate with geometry
  provider
• Standard register conventions can help some
• Complicates combining shaders

45
Semantics

• DirectX 9 decouples decl from VS
• Both decl and VS refer to semantics rather than
  register names
• Direct3D runtime connects appropriate vertex
  stream data to Vertex Shader registers
• Key feature of DirectX9 low-level API
• driven by HLSL and shader requirements

46
DX8 Vertex Declaration
Strm0
Strm1
Vertex layout
v0
skip
v1
Declaration
vs 1.1 mov r0, v0
Shader handle
Shader program
47
New Vertex Declaration
Strm0
Strm1
Strm0
Vertex layout
pos
norm
diff
pos
norm
diff
Declaration
vs 1.1 dcl_position v0 dcl_diffuse v1 mov r0,
v0
vs 1.1 dcl_position v0 dcl_diffuse v1 mov r0,
v0
Shader program (Shader handle)
48
Vertex Declaration

• struct D3DVERTEXELEMENT9
• Stream // id from setstream() Offset
  // offset verts into str Type // float
  vs byte, etc. Method // tessellator
  op Usage // default semantic(pos, etc)
  UsageIndex // e.g. texcoord

49
VS Input Semantics

• positionn
• blendweightn
• blendindicesn
• normaln
• psizen
• diffusen
• specularn
• texcoordn
• tangentn
• binormaln

50
VS output / PS input semantics

• position
• psize
• fog
• colorn
• texcoordn

51
 Uses for Semantics

• A data binding protocol
• Between vertex data and shaders
• Between pixel and vertex shaders
• Between pixel shaders and hardware
• Between shader fragments

52
Integrating with Applications

• Extract dissassembly and use as .asm shader code
  ala DX8
• Use compiled shader object
• Enables constant table access
• Via ID3DXConstantTable Interface
• Use in an effect object
• Manage constants, fallbacks, etc.
• Via ID3DXEffect Interface

53
Language API Standalone

• Compiler returns a VS or PS and a symbol table
• Maps extern constants to registers
• Any expression of constants (i.e. per primitive
  expressions) still performed per vertex
• Symbol table is a set of constants
• ID3DXConstantTable interface

54
ID3DXConstantTable

• Exposes constant parameter metadata
• For convenient specification of shader input data
• SetMatrix( curv, matrix )
• String or handle
• D3DXHandle hHandle
• SetVector()
• SetValue()
• Use effect parameters
• Per primitive expressions of parameters computed
  outside the vertex shader

55
Shader Management

• Due to varying effects desired
• Diffuse, ambient, or specular terms
• Skinning on or off, number of lights
• Due to different hardware generations
• DirectX 8, 9, 9.1
• Apps must manage a combinatoric number of shaders
• FF pipeline does not have these issues

56
Solution Effects

• D3DX Effect Framework
• Routines to load and select shaders
• Originally developed to manage multitexture
  shaders in DirectX 6
• Now fully integrated with the HLSL

57
Effect Framework

• Encapsulation of device state
• Enables scalable rendering techniques
• Allows controlled fallback
• Cant just switch to multi-pass
• Older hardware cant do more passes since fill
  rate is less
• Helps rapid prototyping
• Runtime interpretation of text-based effect
  definition

58
Effect Framework Goals

• Standard way of representing shading algorithms
• Ease of authoring
• Enable some abstraction between author of effect
  and user of the effect
• Facilitates sharing of effects
• Enables effect geometry optimizations to be
  done at author-time, install-time, load-time or
  runtime
• Cross Platform
• Efficient for runtime use

59
Effect Model
Effect Water
Technique DX9
pass0
pass1
Technique DX8
pass0
Technique DX7
pass0
60
Effect FrameworkFallback Techniques

• Techniques are grouped by their quality or LOD
• Techniques can be chosen based on what hardware
  creates successfully
• Can test performance in back buffer
• User responsible for drawing geometry

61
Parameterized Effects

• Effects can have parameters of various types
• Parameters augment static state description in
  the .fx files
• How (and which) parameters get used defined by
  the effect

62
Parameterized Effects

• Shared parameters (aka Globals)
• Shared across multiple effects
• Tagged in effect file as shared
• User selects the list of effects whose shared
  parameters are linked at runtime
• Setting once updates all linked effects
• Naming convention for artist tweakable
• Enables hooking UI to specific parameters
• .X file reference for the same

63
Design for Runtime Efficiency

• Compile effects into hardware friendly format
• State blocks and push buffers
• Efficient setting of effect parameters
• Can set parameters within effect application
• Integration with an optimizing language back end
• Caching common parameter combinations

64
Unify Fixed and Programmable Pipelines

• A consistent framework for programming shaders
• Fixed-function programming using render states,
  texture stage state, fixed-function vertex
  processing
• Assembly level vertex and pixel shader
  programming
• Shading language based programming

65
Unify Cross-Platform Programming

• Techniques in an effect can span shader models
  (like VS 1.1, VS 2.0, etc.)
• Unified parser allows handling the same effect
  file cross platform
• Only techniques that validate on runtime platform
  available for actual use

66
Effect-Language Integration

• Techniques can call language functions
• This is where the back-end is specified
• Same function can be used in multiple techniques
  compiled to multiple back-ends
• Expressions of parameters can be used in state
  assignment
• Per-primitive expressions detected and optimized
  out by compiler when within an effect

67
Specialization

• Specify constants that are to be literals
• via ID3DXEffectCompiler Interface
• Call CompileEffect() method
• returns pre-optimized shader
• Easily generate multiple shaders optimized for
  specific cases
• Can helps shader management by generating them on
  the fly

68
Linking Effects with Geometry

• .X file extensions to link effect with geometry
• Enhance the notion of materials to include effect
  files
• Inline or external references
• Besides referencing effects, certain parameter
  values can be specialized in EffectInstance
• This is usually the artist tweakable ones
• D3DX API support for associating effects with
  meshes

69
Fragment Linker

• Efficiently links together
• HLL fragments
• And asm fragments
• Current Features
• Symbol table resolution
• Register use optimization
• Dead code removal
• via ID3DXFragmentLinker interface

70
Performance 

• Compiler updates will be frequent
• Microsoft has good compiler people

71
Current Back Ends

• Vertex Shader 1.1, 2.0
• Pixel Shader 1.1, 1.4, 2.0

72
Summary

• HLSL abstraction solve
• Continuing hardware evolution
• Shader programming complexity
• API semantics solve
• Shader interoperability
• D3DX Effects, specializers solve
• Combinatoric numbers of shaders

73
Summary

• HLSL is the next step in graphics API/hardware
  evolution
• DirectX implementation provides
• Close API integration
• Semantic binding to low-level API
• Shader management via D3DX effects
• Full IDE support including debugging
• Performant cross vendor support

74
Action Items

• Check it out!
• Use it in your research development
• Let us know what you think
• directx_at_microsoft.com

75
Questions
76
Backup
77
Pixel Shader ALU
Inputs
Input Modifier
bias ltlt, -
bias ltlt, -
bias ltlt, -
bias ltlt, -
Alpha Op
Color Op
Instruction
Output Modifier
ltlt, gtgt
ltlt, gtgt
Destination
78
Unique Features

• Cleanly integrated with Direct3D API
• Run-time compilable
• Integrated with Effect Framework

79
API Integration

• Co-designed with DirectX 9 API
• Enables ease-of-use in apps and in tools
• Enables improved performance

80
Run-Time Compilable

• Enables CPU to construct and optimize shaders for
  GPU dynamically
• Facilitates authoring tool/art pipeline
• Enables dynamic content/titles