your game needs direct3d 11, so get started now!

Your Game Needs Direct3D 11, So Get Started Now!

Bill BilodeauISV RelationsAMD Graphics Products [email protected]

V1.0

Your Game Needs Direct3D 11, So Get Started Now! 04/11/23 2

Topics covered in this session

Why your game needs Direct3D 11

Porting to Direct 3D 11 in the real world

– A view from the “Battlefield” trenches with Johan Anderson from DICE

Important Direct3D 11 features for your game

– How you can use these features on current hardware

Strategies for moving to Direct3D 11


Faster Rendering -> More Rendering -> Better Graphics

Direct3D 11 can make rendering more efficient

Tessellation

– Faster rendering using less space

Compute Shaders

– More programming freedom

– Efficient reuse of sampled data

Multithreading

– Takes advantage of modern multi-core CPUs

Why your game needs Direct3D 11


Superset of Direct 3D 10.1

– Gather() function speeds up texture fetches

– Standard API access to MSAA depth buffers

– MSAA sample patterns/mask, Cube map arrays, etc.

Supports multiple “device feature levels”

– 11.0

– 10.1, 10.0

– 9.3, 9.2, 9.1

– One API for all of your supported hardware

Runs on both Windows 7 and Vista

– Not tied to one operating system

More reasons to switch to Direct3D 11


You can run Direct3D 11 on downlevel hardware

If you stay within the feature level of the device you can use the Direct3D 11 API

Even some new Direct3D 11 features will run on old hardware:

– Multithreading

– Compute shaders

On some Direct3D hardware with new drivers

– Some restrictions may apply

Sometimes you can teach an old dog new tricks.


Porting to Direct3D 11 in the real world

Frostbite Engine

Johan Anderson

Rendering Architect

DICE


Frostbite DX11 port

Starting point– Cross-platform engine (PC, Xenon, PS3)

– Engine PC path used DX10 exclusively

– 10.0 and 10.1 feature levels

Ported entire engine from DX10 to DX11 API in 3 hours!– Mostly search’n’replace – 70% of time spent changing Map/Unmap calls that has

moved to immediate context instead of resource object Compile-time switchable DX10 or DX11 API usage

– As it will take a (short) while for the entire eco-system to support DX11 (PIX, NvPerfHud, IHV APIs, etc.)

– #define DICE_D3D11_ENABLE, currently ~100 usages

– Will be removed later when everything DX11 works


Temporary switchable DX10/DX11 wrappers#ifdef DICE_D3D11_ENABLE #include <External/DirectX/Include/d3d11.h>#else #include <External/DirectX/Include/d3d10_1.h>#endif

#ifdef DICE_D3D11_ENABLE #define ID3DALLDevice ID3D11Device #define ID3DALLDeviceContext ID3D11DeviceContext #define ID3DALLBuffer ID3D11Buffer #define ID3DALLRenderTargetView ID3D11RenderTargetView #define ID3DALLPixelShader ID3D11PixelShader #define ID3DALLTexture1D ID3D11Texture1D #define D3DALL_BLEND_DESC D3D11_BLEND_DESC1 #define D3DALL_BIND_SHADER_RESOURCE D3D11_BIND_SHADER_RESOURCE #define D3DALL_RASTERIZER_DESC D3D11_RASTERIZER_DESC #define D3DALL_USAGE_IMMUTABLE D3D11_USAGE_IMMUTABLE#else #define ID3DALLDevice ID3D10Device1 #define ID3DALLDeviceContext ID3D10Device1 #define ID3DALLBuffer ID3D10Buffer #define ID3DALLRenderTargetView ID3D10RenderTargetView #define ID3DALLPixelShader ID3D10PixelShader #define ID3DALLTexture1D ID3D10Texture1D #define D3DALL_BLEND_DESC D3D10_BLEND_DESC1 #define D3DALL_BIND_SHADER_RESOURCE D3D10_BIND_SHADER_RESOURCE #define D3DALL_RASTERIZER_DESC D3D10_RASTERIZER_DESC #define D3DALL_USAGE_IMMUTABLE D3D10_USAGE_IMMUTABLE#endif

Want the full header-file to save on typing? Drop me an email


Switchable DX10/DX11 support examples

// using D3D10 requires dxgi.lib and D3D11 beta requires dxgi_beta.lib and if we// link with only one through the common method then it crashes when creating// the D3D device. so instead conditionally link with the // correct dxgi library here for now --johan#ifdef DICE_D3D11_ENABLE #pragma comment(lib, "dxgi_beta.lib")#else #pragma comment(lib, "dxgi.lib")#endif

// Setting a shader takes an extra parameter on D3D11: ID3D11ClassLinkage// which is used for the D3D11 subroutine support (which we don’t use)#ifdef DICE_D3D11_ENABLE m_deviceContext->PSSetShader(solution.pixelPermutation->shader, nullptr, 0);#else m_deviceContext->PSSetShader(solution.pixelPermutation->shader);#endif


Mapping buffers on DX10 vs DX11

#ifdef DICE_D3D11_ENABLE

D3D11_MAPPED_SUBRESOURCE mappedResource; DICE_SAFE_DX(m_deviceContext->Map( m_functionConstantBuffers[type], // cbuffer 0, // subresource D3D11_MAP_WRITE_DISCARD, // map type 0, // map flags &mappedResource)); // map resource data = reinterpret_cast<Vec*>(mappedResource.pData); // fill in data m_deviceContext->Unmap(m_functionConstantBuffers[type], 0);

#else

DICE_SAFE_DX(m_functionConstantBuffers[type]->Map( D3D10_MAP_WRITE_DISCARD, // map type 0, // map flags (void**)&data)); // data // fill in data m_functionConstantBuffers[type]->Unmap(); #endif


Frostbite DX11 parallel dispatch

The Killer Feature for reducing CPU rendering overhead! ~90% of our rendering dispatch job is in D3D/driver

1. Have a DX11 deferred device context per core – Together with dynamic resources (cbuffer/vbuffer) for usage

on that deferred context

2. Renderer has list of all draw calls we want to do for the each rendering “layer” of the frame

3. Split draw calls for each layer into chunks of ~256 and dispatch in parallel to the deferred contexts

– Each chunk generates a command list

4. Render to immediate context & execute command lists

5. Profit! – Goal: close to linear perf. scaling up to octa-core when we get

DX11 driver support (hint hint to the IHVs)


Frostbite DX11 - Other HW features of interest

Short term / easy:

Read-only depth buffers. Saves copy & memory.

BC6H compression for static HDR envmaps or lightmaps

BC7 compression for high-quality RGB[A] textures

Per-resource fractional MinLod. Properly fade in streamed textures.

Longer term / more complex:

Compute shaders! (post fx, OIT, particle collision)

DrawIndirect (procedural generation, keep on GPU)

Tessellation (characters, terrain, smooth objects)


Frostbite DX11 port – Questions?

[email protected]

from: igetyourfail.com


Advantages of Hardware Tessellation

An extremely compact representation of a surface

– Each primitive in the low-res input mesh represents up to 64 levels of tessellation

A faster way to render high resolution meshes

– Vertices are generated by dedicated hardware

Levels of detail can changed without needing to be uploaded to the GPU

– No need to wait for uploads

– LODs don’t need to be stored in system or GPU memory

– LOD algorithm can run entirely on the GPU

New Direct3D 11 Feature: The Tessellator


3 Tessellation Stages

2 Programmable Stages

– Hull Shader

– Domain shader

1 Fixed Function Stage

– Tessellator

Direct3D 11 Tessellator Stages

Tessellator in the D3D 11 Pipeline


Hull Shader

Operates in 2 phases

“Control point phase” allows conversion from one surface type to another

– Example: sub-division surface to Bezier patches

– Runs once per control point

“Patch constant phase” sets tessellation factors and other per-patch constants

– Runs once per input primitive




Tessellator Stage

Fixed Function Stage

Generates new vertices within each of the input primitives

The number of new vertices is based on the tessellation factors computed by the hull shader



Level 1.0 Level 1.5 Level 3.0


Domain Shader

Evaluates the surface at each vertex

Uses the control points generated by the hull shader

– Can implement various types of surfaces, for example Beziers

Displacement Mapping

– Fetch displacements from a displacement map texture

– Translate the vertex position along the normal




ATI Tessellator

A new fixed function stage

Can be used for prototyping D3D 11 algorithms

Available on all ATI Direct3D 10 capable hardware and Xbox 360

Tessellation SDK now available for Direct3D 9

– http://developer.amd.com/gpu/radeon/Tessellation

You can do tessellation on today’s hardware.

ATI Tessellator in the D3D 9 Pipeline


Comparison: D3D 9 vs D3D 11 Tessellator

Various Algorithms can be implemented on both

D3D11 Tessellator algorithms can usually be done in one pass.

Even with extra passes hardware tessellation is still faster than rendering high polygon count geometry without a tessellator.

– 3 times faster with less than 1/100th the size!

D3D11 Tessellator has more tessellation levels 64 vs 15

– More polygons per mesh

D3D11 Tessellator has a cleaner API

– Control points are passed to hull and domain shader

– ATI tessellator relies on vertex texture fetch


Alternate Tessellation Method

Instanced Tessellation (Gruen 2005)

Does not require dedicated tessellation hardware

Uses hardware instancing to render tessellated surfaces

– Create a vertex buffer that contains a tessellation of a generic triangle

– Use instancing to instance that vertex buffer for every triangle in the mesh

– The vertex shader can be used to transform the instanced triangles according to patch control points and/or a displacement map


Allows you to bypass the entire graphics pipeline for GPGPU programming

– Post-processing, OIT, AI, Physics, and more

– Avoid too many context switches

Application has control over dispatching and synchronization of threads

Shared memory between Compute Shader threads

– Thread Group Shared Memory (TGSM)

– Avoids redundant calculations and fetches

Random access to output buffer

– “Unordered Access View” (UAV)

– Scatter writes – multiple random access writes per shader

New Direct3D 11 feature: Compute Shaders


Compute Shader: Threads

A thread is the basic CS processing element

A “thread group” is a 3 dimensional array of threads

– CS declares the number of threads in a group

eg. [numthreads(X, Y, Z)]

– Each thread in the group executes the same code

Thread groups are also organized as 3D arrays

Execution of threads is started by calling the device Dispatch( nX, nY, nZ ) function

– Where nX, nY, nZ are the number of thread groups to execute


Compute Shader: Threads and Thread Groups

pDev11->Dispatch(3, 2, 1); // D3D API call [numthreads(4, 4, 1)] // CS 5.0 HLSL Total threads = 3*2*4*4 = 96


Compute Shader: Thread Group Shared Memory

Shared between threads

– Think of it as fast local memory reserved for threads

Read/write access at any location Declared in the shader

– groupshared float4 vCacheMemory[1024];

Limited to 32 KB Need synchronization before reading back data

written by other threads

– To ensure all threads have finished writing

– GroupMemoryBarrier();

– GroupMemoryBarrierWithGroupSync();


Compute Shaders are available on some D3D 10 Hardware

CS 4.x is a subset of CS 5.0

– Includes CS 4.0 and CS 4.1

– CS 4.1 includes instructions from SM 4.1 (D3D 10.1)

Requires support in the driver

– Use CheckFeatureSupport()

D3D11_Feature enum: D3D11_FEATURE_D3D10_X_HARDWARE_OPTIONS

boolean value: ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x

– Drivers are now available!

Contact us for details

You can use compute shaders on today’s hardware.


CS 4.x Limitations

Limitations

Max number of threads per group is 768 total

Dispatch Zn==1 & no DispatchIndirect() support

Thread Group Shared Memory (TGSM) Limitations

– Max size is 16 KB vs 32 KB in CS 5.0

– Threads can only write to their own offsets in TGSM

But they can still read from anywhere in the TGSM

No atomic operations or append/consume

Only one UAV can be bound

– Must be Raw or Structured, not Typed (no textures)


CS 4.0 Example: HDR Tone Map Reduction

Rendered HDR Image

1D Buffer

1D Buffer

8

8

Final Result



C++ Code:

CompileShaderFromFile( L"ReduceTo1DCS.hlsl", "CSMain", "cs_4_0", &pBlob ) );

HLSL Code (reduction from 2D to 1D):Texture2D Input : register( t0 );

RWStructuredBuffer<float> Result : register( u0 );

cbuffer cbCS : register( b0 )

{

uint4 g_param; // (g_param.x, g_param.y) is the x and y dimensions of

// the Dispatch call.

// (g_param.z, g_param.w) is the size of the above

// Input Texture2D

};



#define blocksize 8

#define blocksizeY 8

#define groupthreads (blocksize*blocksizeY)

groupshared float accum[groupthreads];

static const float4 LUM_VECTOR = float4(.299, .587, .114, 0);

[numthreads(blocksize,blocksizeY,1)]

void CSMain( uint3 Gid : SV_GroupID, uint3 DTid : SV_DispatchThreadID, uint3 GTid : SV_GroupThreadID, uint GI : SV_GroupIndex )

{

float4 s = Input.Load( uint3((float)DTid.x/81.0f*g_param.z, (float)DTid.y/81.0f*g_param.w, 0) );

accum[GI] = dot( s, LUM_VECTOR );

uint stride = groupthreads/2;

GroupMemoryBarrierWithGroupSync();



if ( GI < stride )

accum[GI] += accum[stride+GI];

if ( GI < 16 )

{

accum[GI] += accum[16+GI];





}

if ( GI == 0 )

{

Result[Gid.y*g_param.x+Gid.x] = accum[0];

}

}


Comparison: CS 4.x vs CS 5.0

CS 4.x is great to have but CS 5.0 will be better

Better performance – D3D 11 Hardware will be faster

Better Thread Group Shared Memory

– More storage 32K vs 16K

– Better access – threads can write anywhere in TGSM, not just within their thread group

Better interaction with graphics pipeline

– Can output to textures (typed UAVs)

No need to draw a full screen quad

Better precision – Double Precision (optional)

Better synchronization - Atomics

CS 4.x is still your best alternative on downlevel hardware


Multithreaded Rendering

Render calls are now part of the “Immediate” context or the “Deferred” context

Immediate context calls get executed right away, just like D3D 9 and D3D 10 rendering

Deferred context calls are used for building “command lists” i.e. display lists.

– Draw calls and other rendering calls are recorded by the deferred context and stored in the command list

– When the command list is finished, it can then be placed in the queue on the immediate thread using the ExecuteCommandList() function

New Direct3D 11 feature: Multithreading



Immediate Deferred Deferred

DrawPrim DrawPrim DrawPrim



Thread 1 Thread 2 Thread 3

Execute

Execute


Deferred Contexts

Deferred contexts are intended to run in separate threads

One immediate context on the main render thread

Multiple deferred contexts on worker threads

Running each deferred context in it’s own thread takes advantage of modern multi-core CPUs

Re-play of command lists, like the traditional use of display lists in OpenGL may not be the best use of this feature

Some overhead with multiple contexts, so make sure you’re doing enough work in each context

Scale the number of deferred contexts (in threads) with the number of CPU cores.



Multithreaded Resources

Resources can be created with the device interface in a separate thread, concurrent to a device context.

– D3D 11 Device interface creation methods are free threaded

– Create VBs, Textures, CBs, State, and Shaders while rendering in another thread.

Resources can be uploaded asynchronously as well

– Concurrent with shader compilation


Multithreading is implemented in the Direct3D 11 runtime

Independent of driver or hardware

Runtime will emulate features not supported by driver

Easy for testing and backwards compatibility!

Limitations on downlevel hardware

Concurrency is limited by driver support

– Check for driver support using ID3D11Device::CheckFeatureSupport()

D3D11_FEATURE_DATA_THREADING

– DriverConcurrentCreates, DriverCommandLists

You can do multithreading with today’s hardware.


Comparison of Multithreading on D3D 11 vs Downlevel Hardware

This is primarily a performance issue

You may get some improvement with multithreading, even without driver/hardware support

– See the latest Microsoft DirectX SDK sample

Multithreaded driver support will allow more concurrency = better performance

Direct3D 11 Hardware will be faster


Fetches 4 point-sampled values in a single texture instruction

Better/faster shadow kernels

Optimized SSAO implementations

Can also select which components to sample:

– GatherRed(), GatherGreen(), GatherBlue(), GatherAlpha()

Compare version which can be used for shadow mapping:

– GatherCmp (), GatherCmpRed(), GatherCmpGreen(), GatherCmpBlue(), GatherCmpAlpha()

New Direct3D 11 SM 5.0 Feature: Gather()

X Y

ZW


Gather() is part of Direct3D 11 SM 4.1

Works on all Direct3D 10.1 hardware

Limitations with SM4.1 Gather()

Only works with single component formats

– No ability to select which component to gather

Comparison form - GatherCmp() - is not supported

Still works great for custom shadow map kernels and SSA0, since the depth buffer is a single component.

You can use Gather() on today’s hardware


Consider doing the port in stages

Use the HAL when you can

– Software rendering isn’t fun

If your starting with D3D 9, the D3D 10 feature level should be your first target

First, get the engine working with D3D 10.1 feature level before adding Direct3D 11 specific features

– 10.1 is the highest level that will work with the HAL

Next, add new features on downlevel hardware where available

Finally, some new features will need to use the reference rasterizer without D3D 11 hardware

Strategies for Transitioning to Direct3D 11


A simple port from D3D 9 to D3D 11 will not perform well

Hopefully we’ve all learned this lesson from D3D 10

Going from D3D 9 to device feature level 10 will be a big chunk of the work

– Very similar to the Direct3D 10 API

Direct 3D 10 fundamentals are still important

You can still use SM 3.0 for this stage

Starting with Direct3D 9


Constant Buffers

Group constants into buffers by frequency of update

Remember: when one constant is updated, the whole buffer needs to get uploaded

State Changes

State objects are immutable for better performance

Initialize the state you need before you need it

Avoid creating lots of state objects on the fly

Resources

Resource creation and deletion is slow

Create most of your resources at the beginning

Direct3D 10 programming review


Direct3D 10 programming review

Texture Updates

Call Map() with the DO_NOT_WAIT flag to update staging textures, then CopyResource() to update the video memory texture

Do not use UpdateSubResource() – slow

Batch Counts

Keep batch counts low with instancing

Alpha test is now done with clip()/discard()

Don’t put this in every shader – it may disable early z!

Try to do the clip early to avoid unnecessary shader instructions


Fairly easy port from Direct3D 10 to D3D 11 with 10 or 10.1 device feature level

You can still use the HAL

Modify the existing Direct3D 10 code to use a Rendering Context

– You should only need the Immediate Context for now

– Essentially just replacing API calls

Get the simple port working first

You can still use your SM 4.0 or 4.1 shaders at this point in the process

Going from Direct3D 10 to Direct3D 11


Multithreading

Requires changes to your rendering code

Add Windows multithreading support

Run deferred contexts in separate threads

– Need to break up your rendering workload in to logical chunks

– Parallelize the command list building to improve performance

Fortunately the runtime will emulate this feature

– Performance improvements may not be fully realized until new drivers and new hardware is released.

Adding in new Direct3D 11 features


Adding in new Direct3D 11 features

Compute Shader Post Processing

– Replace your old pixel shader implementations with faster compute shader versions

Use CS 4.x on current hardware

– Good for testing and backwards compatibility

Tessellation Prototype tessellation algorithms using the ATI

tessellator on Direct3D 9 Use instanced tessellation for Direct3D 11 on

downlevel hardware Consider how Tessellation will affect your art pipeline

– better to prepare early


Add new features that require Direct3D 11 hardware

Not too difficult, since you’ve already done most of the work!

Tesellation

– Simplify your algorithms by using the hull shader

Compute Shader

– Start using CS 5.0

More local storage, write anywhere, can output to textures

Multithreading

– Should automatically see improvements with new hardware and drivers

Full Direct3D 11 Implementation


Direct 3D 11 features will improve your game

Multithreading, Compute Shader, Tessellation and more

Current Hardware will take you close to a full Direct3D 11 implementation

Downlevel support is good for prototyping and for backwards compatibility

Have your game ready to ship when Direct3D 11 ships

Windows 7 and powerful new hardware will help spotlight your game!

There’s nothing stopping you from starting now


Johan Andersson, DICE – advice on porting to D3D 11

Nicholas Thibieroz, AMD – Compute Shader

Holger Gruen, Efficient Tessellation on the GPU through Instancing, Journal of Game Development Volume 1, Issue 3, December 2005

Tatarchuk, Barczak, Bilodeau, Programming for Real-Time Tessellation on GPU, 2009 AMD whitepaper on tessellation

Microsoft Corporation, DirectX 11 Software Development Kit, November, 2008

Acknowledgements


Trademark Attribution

AMD, the AMD Arrow logo and combinations thereof are trademarks of Advanced Micro Devices, Inc. in the United States and/or other jurisdictions. Other names used in this presentation are for identification purposes only and may be trademarks of their respective owners.

©2008 Advanced Micro Devices, Inc. All rights reserved.

[email protected]

Questions

your game needs direct3d 11, so get started now!

Technology