Title: D3DX High Level Language and Effects
1D3DX High Level Language and Effects
- Anuj Gosalia
- Development Lead
- DirectX Graphics
- Microsoft Corporation
2Design Goals
- High level enough to hide hardware specific
details - Simple enough for efficient code generation
- Familiar enough to reduce learning curve
- Based on C-like syntax
- Provide enough optimizing back-ends for
portability
3Back Ends
- Vertex Shader 1.0, 1.1, 2.0
- Pixel Shader 2.0
- Maybe even 1.x
- X86, etc
- Useful for vertex programs and per-primitive
expressions - Authoring tool languages?
- Or have them use DirectX based renderer
4Types
- Basic type is 32-bit float
- Structs and arrays supported
- Typedef to shorthand user defined types
- Component access and swizzles
5Type Casts
- Float can be promoted to any type by replicating
the float as necessary - (v 0.5 0.5) instead of
- (v vec3(0.5, 0.5, 0.5) vec3(0.5, 0.5, 0.5))
- Vectors can be down-cast
- Left prefix
- Matrices can be down-cast
- Upper left subset
6Variables
- 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
7VS input semantics
- positionn
- blendweightn
- blendindicesn
- normaln
- psizen
- diffusen
- specularn
- texcoordn
- tangentn
- binormaln
8VS output / PS input semantics
- position
- psize
- fog
- colorn
- texcoordn
9Operators
- Pretty much all of C operators
- Incl ?, sizeof and comma(,)
- No new semantics
- Despite temptation
- Arithmetic operators are per component
- Matrix multiply is an intrinsic function
- Logical operators are per component
- No bitwise operators
10Statement Syntax
- statements
- expression
- return expression
- if ( expression ) statement else statement
- for ( expression variable_declaration
expression expression ) statement
11Functions
- Standard C like functions
- Output type and input parameters
- Parameters can be passed by value or reference
(C style syntax) - Externally referenced function must have
semantics associated with parameters - Needed for future versions of DirectX
- Inlined internally. No recursion
12Functions (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
13Intrinsic functions
14Difference from C
15Preprocessor
- define
- elif
- else
- endif
- error
- Function-style defines not supported
16Language API Standalone
- Compiler returns a VS or PS
- And a symbol table
- map extern constants to registers
- Any expression of constants (i.e. per primitive
expressions) still performed per vertex
17Language API Effect Framework
- Use effect parameters
- Per primitive expressions of parameters computed
outside the vertex shader
18Effect 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 alpha
blending fill rate is less - Helps rapid prototyping
- Runtime interpretation of text-based effect
definition
19Effect 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
20Effect FrameworkFallback Techniques
- Uses controlled effect fallbacksEffect
- Technique
- Pass
- Implementation
- Simple text file (.fx) to define effects
21Effect 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
22Effect Data types
- DWORD, FLOAT
- VECTOR, MATRIX
- TEXTURE
- VERTEXSHADER, PIXELSHADER
- STRING
- Enables user-data associated with effects
- Not used to program device state
23Parameterized 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
24Parameterized 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
25Example
26Design 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
27Unify 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
28Unify 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
29Effect-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
30Linking 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
31Reconciling Geometry Layout
- DirectX 8 VS assume geometry layout
- Decl VS code tied together
- Forces shader author to communicate with geometry
provider - Standard register conventions can help some
- DirectX will decouple decl from VS
- Both decl and VS refer to semantics rather than
register names - Direct3D runtime will connect appropriate vertex
stream data to VS registers
32Vertex Component Semantics
- VertexDecl now has usage field
- Position, Normal, Tangent, Binormal, etc.
- Connect shaders to geometry
- No need for a register convention
- Accommodates more semantics than limited by
register count - Any shader to any geometry
- Well almost
- Semantics were needed for fixed-function pipe
33DX8 Vertex Declaration
Strm0
Strm1
Vertex layout
v0
skip
v1
Declaration
vs 1.1 mov r0, v0
Shader handle
Shader program
34New Vertex Declaration
Strm0
Strm1
Vertex layout
pos
norm
diff
Declaration
vs 1.1 dcl_position v0 dcl_diffuse v1 mov r0,
v0
Shader program (Shader handle)
35Vertex 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 -
36Example VertexDecl
- D3DFVF_POSITION D3DFVF_DIFFUSE
D3DFVF_SPECULAR D3DFVF_TEX1 - D3DVERTEXELEMENT9 ve 0, 0,TYPE_FLOAT3,
METHOD_DEFAULT, USAGE_POSITION,0, 0, 12,
TYPE_D3DCOLOR, METHOD_DEFAULT,
USAGE_DIFFUSE,0, 0, 16, TYPE_D3DCOLOR,
METHOD_DEFAULT, USAGE_SPECULAR,0, 0, 20,
TYPE_FLOAT2, METHOD_DEFAULT, USAGE_TEXCOORD,0,
D3DDECL_END()
37Example Vertex Shader
- vs.2.0
- dcl_dmap v0
- dcl_position v1
- dcl_normal v2
- dcl_blendweight v3
- def c0 1.,1.,1.,1 // white
- add oT0, v2, r1
38Call to Action
- Give feedback of language design
- We would like to work with you
- Help create a consistent standard
- Play with prototype
- When we actually give you one
- Integrate it with your tools
39Questions?