Designing a Portable Shader Library For Current and

Future API’sMarch, 2003

Alex VlachosLead Programmer, ATI’s Demo TeamAlex@Vlachos.com

Outline• Intro & Motivation

• Demos

• Goals of designing a shader library

• Case study: ATI’s demo shader format

• Expanding to HLSL (or similar languages)

What is a Shader Library?• Library in the sense of a linkable .lib file or collection of

source code (not a collection of shaders).

• API that deals completely with setting render state, shaders, shader constants, etc.

• Provides a text file format for describing how to render a piece of geometry from preprocessing to runtime.

• Completely abstracts the graphics API. Necessary for cross-platform development.

• Often coupled with a windowing API that abstracts window creation and associated functionality.

Future of the Industry• Advances in the graphics industry are

becoming extremely shader-centric and will continue on that path.

• Designing a forward-looking engine equates to having a powerful and flexible shader library at the center.

• Every part of your engine needs to be designed with the shader library in mind.

Motivation for this Presentation• The majority of games target the least common

denominator for graphics

• PC developers often sidestep fallback paths for their graphics engines

• Overhead of cross platform/API porting can be a burden for some companies

• Share the lessons learned that caused my team to redesign our shader library last year

Demos Showing the Necessity of a Shader Library

Who Will Benefit?• Most important to PC developers due to

the varied graphics hardware consumers own

• Equally as important to console developers for cross platform development or future games based on the same engine

• Actually…it’s anyone who intends to do anything visually interesting in the coming years.

Design Goals• Cross platform / Cross API• Fallback shaders paired with optimal vertex and

index buffers• LOD shaders• Allow you to target a wide range of graphics

hardware including the most current hardware• Encompasses everything from artist interaction to

runtime execution• Reduce the frequency of redesigning your

graphics engine• Expandable to future shader languages and API’s

Common Graphics Concepts• Graphics hardware is very similar despite

differences in API’s– ATI: RADEON, Nintendo GameCube– NVIDIA: GeForce, Microsoft XBox

• Hardware is functionally identical:– Setting texture state– Vertex/index buffers, stream maps– Draw calls– Alpha blending & testing– Shader constant setup– Z state– Stencil state– Renderable textures– etc.

Shader Languages• DirectX fixed function• DirectX assembly shaders• DirectX HLSL• OpenGL fixed function• OpenGL assembly shaders

(ARB_vertex_program, ARB_fragment_program)

• GL2 Shading Language (Currently being defined)

• GameCube• PS2• NVIDIA’s Cg

Define a Common LanguageClipping TRUECull CWFillMode SolidShadeMode Gouraud

SetTexture 0 NULL CoordIndex(0) Transform(0) Linear LODBias(0.0) Clamp(www) Border(0x00000000)SetBlender 0 Color(SelectArg1, Diffuse, Diffuse) Alpha(SelectArg1, Diffuse, Diffuse)

Fog FALSE Table(None) Vertex(None) Color(0) Start(0.0) End(1.0) Density(1.0) RangeBased(FALSE)

AlphaTest FALSE Blend FALSE Src(One) Dest(Zero) Op(Add)ColorWriteEnable (R, G, B, A)MultiSampleAntiAlias TRUEMultiSampleMask 0xffffffffDitherEnable FALSE

Z TRUE Write(TRUE) Func(LessEqual) Bias(0.0) SlopeScale(0.0)

Stencil FALSE Pass(Keep) Fail(Keep) ZFail(Keep) Func(Always) Ref(0xFFFFFFFF) StencilCCW FALSE Pass(Keep) Fail(Keep) ZFail(Keep) Func(Always)

State vs. Shaders…• State is easily generalized for cross API

development

• Fixed function shader state is also easily generalized

• Advanced shader languages are currently unshared across different systems. Before we explore the solution…

ATI’s Demo Shader Format• As a case study, a brief explanation of the

shader format we’re using

• Topics:– How our artist use our shaders– Vertex buffer formats– Textures– Variables– Authoring multi-pass shaders (fur)– Fallback shaders

Artists Point-of-View• Artists associate a shader

file with a given material within the art tool.

• The art tool pulls instructions out of the shader file for the artists.

To the RIGHT are our Maya and 3DS MAX material plug-ins

Vertex and Index BuffersThis describes how to fully preprocess our vertex and index buffers, and the data associated with each stream element. There can be a unique index buffer associated with each Stream Map.StartStream sPosNorm (Normal)

float3 POSITION0 Positionfloat3 NORMAL0 VertexNormal

EndStream

StartStream sTexCoords (Normal)float2 TEX0 UV0 //BaseTexU, BaseTexVfloat3 TEX1 Tangent0

EndStream

StartStream sFurFins (FurFins) //Different geometry than above 2 streamsfloat3 POSITION0 Positionfloat3 NORMAL0 VertexNormalfloat4 TEX0 FinFaceData0 //FinTexU, FinTexV, BaseTexUVDist, RandOffsetfloat4 TEX1 FinFaceData1 //BaseTexU, BaseTexV, BaseTexDu, BaseTexDvfloat3 TEX2 FaceNormal

EndStream

StreamMap smBasePass (sPosNorm, sTexCoords)StreamMap smShellPass (sPosNorm, sTexCoords)StreamMap smFinsPass (sFurFins)

Texture DeclarationDescribes how to fully preprocess our textures including input formats, mip map generation, and output format. Our language allows for each output texture to be created from up to two input textures that the artists specify.Texture tBase 2D DXT1("Base", RGB, KaiserGamma)Texture tFurShellTexture 2D RGBA(“T1", RGB, Kaiser, “T2", GRAY, KaiserGamma)Texture tBump 2D DXT5("Bump", HEIGHT, Box, "Opacity", GRAY, Box)Texture tAnisoLookup 2D RGBA(“T5", RGB, Box, “T6", GRAY, Box)Texture tNormCube CM RGBX("Base3", RGB, Box)Texture tEnvMap CMAuto //This is an auto-generated cube map in our engine

Texture tWater Renderable("WaterReflection")

VariablesCan be bound to render state or shader constants. If a variable is editable, the artist can override the variable from within the art tool. Variables can also be tied to internal state such as camera position or transform matrices.

Float furHeight(4.0) EDITABLEVector furFadeScaleBias(0.5, 0.5, 0.0, 0.0)Vector objectSpaceCamPos(CAMERA_POSITION, OBJECT_SPACE)Vector objectSpaceLightPos(LIGHT_POSITION, OBJECT_SPACE, 0)Matrix wvp(MATRIX_WVP)Vector time(0.0, 0.0, 0.0, 0.0) AppUpdate(“Time”)

Sub-Shaders• A shader file can contain many sub-shaders which

describe how to render the geometry including multi-pass rendering.

• A shader file can contain one of these for each supported graphics card and acts as the fallback mechanism. Also acts as a shader LOD mechanism.

• Each sub-shader has a type in the form of a string. At load time, the first sub-shader that validates (found from top to bottom) of a given type is kept in memory and the rest are skipped.

Sub-Shaders (Cont’d)//--------------------------------------------------------------------StartShader //For vs.2.0 and ps.2.0 minimum

Type “Normal” //Can be anything, like “Wire frame”, “Invincible”StartPass

…EndPass

EndShader

//--------------------------------------------------------------------StartShader //For vs.1.1 and ps.1.4

Type “Normal”StartPass

…EndPassStartPass

…EndPass

EndShader

PassEach pass has a unique Stream Mapping, unique set of render state and textures, and vertex and pixel shader code.StartPass

//Set Stream Map//Set Textures//Set Render State

//Set Vertex Shader Constants//Vertex Shader Code

//Set Pixel Shader Constants//Pixel Shader Code

EndPass

Within a sub-shader, state is sticky between passes.

Current ASM ShadersVertex and pixel shader code can either be embedded in the shader file or reference an external file.VsConst 0 mWvp //Matrix takes up 4 constantsVsConst 4 vTimeConstVsConst 5 (0.0, 0.1, 2.0, 5.0)StartVertexShader

vs.1.1dcl_position v0dcl_color0 v5dcl_texcoord0 v7

m4x4 oPos, v0, c0 //Transform positionmov oT0, v7 //Base texture coordinatesmov oD0, v5 //Pass vertex light to PS

EndVertexShader

Adding DirectX 9 HLSL SupportOur Implementation Goals:• Build on our existing shader framework• Avoid explicit constant declarations• Allow HLSL include files to reference

common functions– Includes can contain their own variables and

textures

• Hidden from outside the shader lib• Need a “SetTexture” equivalent

Basic HLSL ShaderShader constants are no longer explicitly declared. We have a slightly different token to start/end HSLS shader.StartVertexShaderHLSL

matrix mWvp; //Same name as our variable

struct VS_OUTPUT{

float4 Pos : POSITION;float4 Diffuse : COLOR0;float2 TCoord0 : TEXCOORD0;

};

VS_OUTPUT main (float4 aPosition : POSITION, float4 aDiffuse : COLOR0, float2 aTC0 : TEXCOORD0){

VS_OUTPUT out = (VS_OUTPUT) 0;out.Pos = mul (mWvp, aPosition); //Transform position to clip spaceout.TCoord0 = vTC0; //Pass through base texture coordinatesout.Diffuse = vDiffuse; //Pass through vertex light to pixel shaderreturn out;

}EndVertexShaderHLSL

VsConst 0 mWvp //Matrix takes up 4 constantsVsConst 4 vTimeConstVsConst 5 (0.0, 0.1, 2.0, 5.0)StartVertexShader

vs.1.1dcl_position v0dcl_color0 v5dcl_texcoord0 v7

m4x4 oPos, v0, c0 //Transform positionmov oT0, v7 //Base texture coordinatesmov oD0, v5 //Pass vertex light to PS

EndVertexShader

Dealing With HLSL Includes• Using #include in HLSL code may sound like a

good idea, but can cause usability issues

• Variables and textures referenced in #include files need to be declared in your shader file format. You don’t want to do this manually!

• Includes need to be implemented at a higher level than HLSL code

Sample HLSL IncludeVector vTime AppUpdate(“Time”)Vector vObjectColor ArtistEditable(Color)StartHLSL

float4 MyFunc (float4 aInput){

//Calculate output based on variables and return}

EndHLSL

HLSL include file - MyFunc.shi

StartShaderStartPassVsInclude “MyFunc.shi” //Has its own variablesStartVertexShaderHLSL

VS_OUTPUT main (float4 aPosition : POSITION){

VS_OUTPUT out = (VS_OUTPUT) 0;//Call MyFunc() herereturn out;

}EndVertexShaderHLSL

How we reference the HLSL include file

Sample HLSL Include (Cont’d)• Our parser concatenates the include files with the

embedded shader code

• Include file declares its own variables and textures

• Every shader that includes that file doesn’t need to redundantly declare those variables

• Shader author needs no knowledge about the contents of the include file other than the function declaration

Textures in HLSL Includes• Including an HLSL pixel shader also requires

implicitly binding textures to texture stages

• In non-HLSL pixel shaders, we had:SetTexture 0 tBaseTexture Trilinear

• Since we can’t specify the stage to bind the texture to explicitly:

DefTexture tBaseTexture Trilinear

• HLSL compiler returns instructions for matching our DefTextures with stages

Default Shader• Defines all default state for your engine within a

shader file.

• You don’t need to rely on D3D’s or OpenGL’s default state since you override it with what is most useful to your app. This also helps reduce overall state change.

• Necessary for cross API development since different API’s have different default state

• Your shaders ultimately have less redundancy since you can rely on the defaults you set.

Falling Back• Some older hardware lacks multi-stream vertex

buffers. You often have to store redundant data on disk to do the most optimal thing at runtime. If you’ve generalized your vertex preprocessing, this should mean no additional work on your part.

• At runtime, load all shaders first, then load only the necessary vertex buffers, index buffers, and textures. More interesting shaders also require additional textures that are often not needed for the fallback sub-shaders and should be selectively loaded at runtime.

Summary• Why a shader library is needed

• Goals of designing a shader library

• Case study: ATI’s demo shader format

• Expanding to HLSL (or similar languages)

Questions?

Alex@Vlachos.com