directx 10 performance and directx 11 preview
Post on 12-Sep-2021
40 Views
Preview:
TRANSCRIPT
DirectX 10 Performanceand
DirectX 11 Preview
DirectX 10 Performanceand
DirectX 11 Preview
Agenda
General GPU Performance TipsGeneral DX10 API usageOptimizing your DX10 GameDX11 Preview
General GPU Performance Tips
Batching
The more API calls, the more overhead on the driver side Batch: A group of similar API calls
Using a smaller number of larger batches is a great way to improve performance.
Fewer “draw calls” (DrawPrimitive, DrawIndexedPrimitive, etc.) can yield better performance
Balance Shader Workload
In general, putting more computing tasks in vertex shader saves considerable workloads
Fewer vertex number than pixel numberIn some cases, moving computing tasks to pixel shader will improve performance
Too many vertex shader outputDetailed mesh with lots of small triangles which may fall under sub-pixel level
Texture (1)
Texture fetching is much more expensive than any arithmetic instructionWhen possible, always use compressed texture
Better cache performanceLess memory footprintTextures remain compressed in L1 cacheDXT1 is better than DXT5, performance wise
Texture (2)
Always use mipmap if possibleBetter cache performanceBetter image quality
Choosing lowest precision format (avoid “fat” textures)128bit texture: RGBA32FGamma corrected texture: sRGB
Buffer Usage
Avoid lock/map buffers frequently DYNAMIC flag is designed for buffers requiring to be locked multiple times per frame. Placed in AGP memoryUse DISCARD flag when possible
General DX10 API usage
DX10 Runtime and Driver are designed for Performance
DX10 validation moved from runtime to creation timeOnly basic error checking at runtime
Immutable state objectsCan be pre-computed and cachedSubset of command buffer at creation time
Vista driver model delegates scheduling and memory management to OS
Pro: more responsive system, GPU sharing across appsCon: harder to guarantee performance if multiple apps share the GPU
Fullscreen mode should be fine
Batch Performance
The truth about DX10 batch performance
“Simple” porting job will not yield expected performance
Need to use DX10 features to yield gains:Geometry instancing or batchingIntelligent usage of state objectsIntelligent usage of constant buffersTexture arrays
Geometry InstancingBetter instancing support in DX10 - DrawInstanced()Use “System Values” to vary renderingSV_InstanceID, SV_PrimitiveID, SV_VertexID
Additional streams not requiredPass these to PS for texture array indexingHighly-varied visual results in a single draw call
Watch out for:InputAssembly bottlenecks due to instancingSolution: Load() per-instance data from Buffer in VS or PS using SV_InstanceID Texture cache trashing if sampling textures from system values (SV_PrimitiveID)Too many attributes passed from VS to PS
State Management
DX10 uses immutable “state objects”Input Layout ObjectRasterizer ObjectDepthStencil ObjectBlend ObjectSampler Object
DX10 requires a new way to manage statesA naïve DX9 to DX10 port will cause problems hereAlways create state objects at load-timeAvoid duplicating state objectsRecommendation to sort by states still valid in DX10!
Constant Buffer Management (1)
Probably a major cause of poor performance in initial naïve DX10 ports!
Constants are declared in buffers in DX10:
When any constant in a cbuffer is updated the full cbuffer has to be uploaded to GPUNeed to strike a good balance between:
Amount of constant data to uploadNumber calls required to do it (== # of cbuffers)
cbuffer PerFrameConstants{
float4x4 mView;float fTime;float3 fWindForce;
};
cbuffer SkinningMatricesConstants{
float4x4 mSkin[64];};
Constant Buffer Management (2)
Use a pool of constant buffers sorted by frequency of updates
Don’t go overboard with number of cbuffers!(3-5 is good)
Sharing cbuffers between shader stages can be a good thing
Example cbuffers:PerFrameGlobal (time, per-light properties)PerView (main camera xforms, shadowmap xforms)PerObjectStatic (world matrix, static light indices)PerObjectDynamic (skinning matrices, dynamic lightIDs)
Constant Buffer Management (3)
Group constants by access pattern to help cache reuse due to locality of accessExample:
cbuffer PerFrameConstants{
float4 vLightVector;float4 vLightColor;float4 vOtherStuff[32];
};
cbuffer PerFrameConstants{
float4 vLightVector;float4 vOtherStuff[32];float4 vLightColor;
};
float4 PS_main(PSInput in){float4 diffuse = tex2D0.Sample(mipmapSampler, in.Tex0);float ndotl = dot(in.Normal, vLightVector.xyz);return ndotl * vLightColor * diffuse;
}
GOOD BAD
Constant Buffer Management (4)
Careless DX9 port results in a single $Globals cbuffer containing all constants, many of them unused
$Globals cbuffer typically yields bad performance:Wasted CPU cycles updating unused constants
Check if used: D3D10_SHADER_VARIABLE_DESC.uFlagscbuffer contentionPoor cbuffer cache reuse due to suboptimal layout
When compiling SM3 shaders for SM4+ target with D3D10_SHADER_ENABLE_BACKWARDS_COMPATIBILITY: use conditional compilation to declare cbuffers(e.g. #ifdef DX10 cbuffer{ #endif )
Constant Buffer Management (5)
Consider tbuffer if access pattern is more random than sequential
tbuffer access uses texture Loads, so higher latency but higher performance sometimesWatch out for texture-bound cases resulting from tbufferusage
Use tbuffer if you need more data in a single buffercbuffer limited to 4096*128-bit tbuffer limited to 128 megabytes
Resource Updates
In-game destruction and creation of Texture and Buffer resources has a significant impact on performance:
Memory allocation, validation, driver checks
Create all resources up-front if possibleDuring level load, cutscenes, or any non-performance critical situations
At runtime: replace contents of existing resources, rather than destroying/creating new ones
Resource Updates: Textures
Avoid UpdateSubresource() for texturesSlow path in DX10
(think DrawPrimitiveUP() in DX9)Especially bad with larger textures!
Use ring buffer of intermediate D3D10_USAGE_STAGING texturesCall Map(D3D10_MAP_WRITE,...) withD3D10_MAP_FLAG_DO_NOT_WAIT to avoid stalls If Map fails in all buffers: either stall waiting for Map or allocate another resource (cache warmup time)Copy to textures in video memory (D3D10_USAGE_DEFAULT):CopyResource() or CopySubresourceRegion()
Resource Updates: BuffersTo update a Constant bufferMap(D3D10_MAP_WRITE_DISCARD, …);UpdateSubResource()Recall full buffer must be updated, but with Map() CPU can skip parts that the shader does not care about. All the data must be uploaded to GPU though
To update a dynamic Vertex/Index bufferUse a large shared ring-buffer type; writing to unused portions of buffer using:
Map(D3D10_MAP_WRITE_DISCARD,…) when full or if possible the first time it is mapped at every frameMap(D3D10_MAP_WRITE_NO_OVERWRITE, …) thereafter
Avoid UpdateSubResource()not as good as Map() in this case either
Accessing Depth and Stencil
DX10 enables the depth buffer to be read back as a textureEnables features without requiring a separate depth render
Atmosphere passSoft particlesDepth of FieldDeferred shadow mappingScreen-space ambient occlusionEtc.
Popular features in most recent game engines
Accessing Depth and Stencil with MSAA
DX10.0: reading a depth buffer as SRV is only supported in single sample mode
Requires a separate render path for MSAAWorkarounds:
Store depth in alpha of main FP16 RTRender depth into texture in a depth pre-passUse a secondary rendertarget in main color passUse NVIDIA DX10 extension
MultiSampling Anti-Aliasing
MSAA resolves cost performanceCost varies across GPUs but it is never freeAvoid redundant resolves as much as possibleE.g.: no need to perform most post-process ops on MSAA RT. Resolve once, then apply p.p. effects
No need to allocate SwapChain as MSAAApply MSAA only to rendertargets that matter
Be aware of CSAA:Certain DXGI_SAMPLE_DESC.Quality values will enable higher-quality
but slightly costlier MSAA modeSee http://developer.nvidia.com/object/coverage-sampled-aa.html
Optimize Your DX10 Game
Optimizing your DX10 Game
Use PerfHUD to identify bottlenecks:
Step 1: are you GPU or CPU bound?Check GPU idle timeIf GPU is idle you are probably CPU bound either by other CPU workload on your application or by CPU-GPU synchronization
Step 2: if GPU bound, identify the top buckets and their bottlenecksUse PerfHUD Frame Profiler for this
Step 3: try to reduce the top bottleneck/s
If Input Assembly is the bottleneck
Optimize IB and VB for cache reuseUse ID3DXMesh::Optimize() or other tools
Reduce number of vector attributesPack several scalars into single 4-scalar vector
Reduce vertex size using packing tricks:Pack normals into a float2 or even RGBA8 Calculate binormal in VSUse lower-precision formats
Use reduced set of VB streams in shadow and depth-only passesSeparate position and 1 texcoord into a streamImproves cache reuse in pre-transform cacheAlso use shortest possible shaders
Attribute Boundedness
Interleave data when possible into a less VB streams:at least 8 scalars per stream
Use Load() from Buffer or Texture instead
Dynamic VBs/IBs might be on system memory accessed over PCIe:maybe CopyResource to USAGE_DEFAULT before using (especially if used multiple times in several passes)
Passing too many attributes from VS to PS may also be a bottleneckpacking and Load() also apply in this case
If Vertex Shader is the bottleneck
Improve culling and LOD (also helps IA):Look at wireframe in debugging tool and see if it’s reasonableCheck for percentage of triangles culled:
Frustum cullingZero area on screen
Use other scene culling algorithmsCPU-based cullingOcclusion culling
Use Stream-Output to cache vertex shader results for multiple usesE.g.: StreamOut skinning results, then render to shadowmap, depth prepass and shading passStreamOut pass writes point primitives (vertices) Same index buffer used in subsequent passes
If Geometry Shader is the bottleneck
Make sure maxvertexcount is as low as possiblemaxvertexcount is a shader constant declaration need different shaders for different valuesPerformance drops as output size increases
Minimize the size of your output and input vertex structuresGS not designed for large-expansion algorithms like tessellation
Due to required ordering and serial executionConsider using instancing in current hardwareMove some computation to VS to avoid redundancyKeep GS shaders short
If Stream-Output is the bottleneck
Avoid reordering semantics in the output declarationKeep them in same order as in output structure
You may have hit bandwidth limitSO bandwidth varies by GPU
Remember you don’t need to use a GS if you are just processing vertices
Use ConstructGSWithSO on Vertex ShaderRasterization can be used at the same time
Only enable it if needed (binding RenderTarget)
If Pixel Shader is the bottleneck (1)
Verify by replacing with simplest PS (PerfHUD)Move computations to Vertex ShaderUse pixel shader LODOnly use discard or clip()when requireddiscard or clip() as early as possible
GPU can skip remaining instructions if test succeedsUse common app-side solutions to maximize pixel culling efficiency:
Depth prepass (most common)Render objects front to backTriangle sort to optimize both for post-transform cache and Z culling within a single meshDeferred shading
If Pixel Shader is the bottleneck (2)
Shading can be avoided by Z/Stencil cullingCoarse (ZCULL)Fine-grained (EarlyZ)
Coarse Z culling is transparent, but it may underperform if:If shader writes depthHigh-frequency information in depth bufferIf you don’t clear the depth buffer using a “clear” (avoid clearing using fullscreen quads)
If Pixel Shader is the bottleneck (3)
Fine-grained Z culling is not always activeDisabled on current hardware if:
PS writes depth (SV_Depth)Z or Stencil writes combined with:
Alpha test is enabled (DX9 only)discard / texkill in shadersAlphaToCoverageEnable = true
Disabled on current NVIDIA hardware if:PS reads depth (.z) from SV_Position input
Use .w (view-space depth) if possibleZ or Stencil writes combined with:
Samplemask != 0xffffffff
Any Shader is still the bottleneck (1)
Use NVIDIA’s ShaderPerfBe aware of appropriate ALU to TEX hardware instruction ratios:
10 scalar ALU per TEXCheck for excessive register usage
> 10 vector registers is high on GeForce 8 seriesSimplify shader, disable loop unrollingDX compiler behavior may unroll loops so check output
Use dynamic branching to skip instructionsBut make sure branching has high coherency
Any Shader is still the bottleneck (2)
Some instructions operate at a slower rateInteger multiplication and division
Too many of those can cause a bottleneck in your code
If Texture is the bottleneck (1)
Verify by replacing textures with 1x1 texturePerfHUD can do this
Basic advice:Enable mipmappingUse compressed textures where possible
Block-compressed formats Compressed float formats for HDR
Avoid negative LOD bias (aliasing != sharper)If multiple texture lookups are done in a loop
Unrolling partially may improve batching of texture lookups, reducing overall latencyHowever this may increase register pressureFind the right balance
If Texture is the bottleneck (2)
DirectX compiler moves texture instructions that compute LOD out of branchesUse SampleLevel (no anisotropic filtering) with constant LOD valueSampleGrad can be used too, but beware of the extra performance cost
Texture cache misses may be high due to poor coherenceIn particular in post-processing effectsModify access pattern
Not all textures are equal in sample performanceFiltering modeVolume texturesFat formats (128 bits)
If ROP is the bottleneck: Causes
Pixel shader is too cheap Large pixel formats High resolutionBlendingMSAAMRTRendering to system memory over PCIe(parts with no video memory)Typical problem with particle effects:little geometry, cheap shading, but high overdraw using blending
If ROP is the bottleneck: Solutions
Render particle effects to lower resolution offscreen texture See GPUGems 3 chapter by Iain Cantlay
Disable blending when not needed, especially in larger formats (R32G32B32A32_FLOAT)
Unbind render targets that are not neededMultiple Render TargetsDepth-only passes
Use R11G11B10 float format for HDR(if you don't need alpha)
If performance is hitchy or irregular
Make sure you are not creating/destroying critical resources and shaders at runtime
Remember to warm caches prior to rendering
Excessive paging when the amount of required video memory is more than available
Could be other engine component like audio, networking, CPU thread synchronization etc.
Clears
Always Clear Z buffer to enable ZCULL
Always prefer Clears vs. fullscreen quad draw calls
Avoid partial ClearsNote there are no scissored Clears in DX10, they are only possible via draw calls
Use Clear at the beginning of a frame on any rendertarget or depthstencil buffer
In SLI mode driver uses Clears as hint that no inter-frame dependency exist. It can then avoid synchronization and transfer between GPUs
Depth Buffer Formats
Use DXGI_FORMAT_D24_UNORM_S8_UINT
DXGI_FORMAT_D32_FLOAT should offer very similar performance, but may have lower ZCULL efficiency
Avoid DXGI_FORMAT_D16_UNORMwill not save memory or increase performance
CSAA will increase memory footprint
ZCULL ConsiderationsCoarse Z culling is transparent,but it may underperform if:
If depth test changes direction while writing depth (== no Z culling!)Depth buffer was written using different depth test direction than the one used for testing(testing is less efficient)If stencil writes are enabled while testing (it avoids stencil clear, but may kill performance)If DepthStencilView has Texture2D[MS]Array dimension (on GeForce 8 series) Using MSAA (less efficient)Allocating too many large depth buffers (it’s harder for the driver to manage)
Conclusion
DX10 is a well-designed and powerful API
With great power comes great responsibility!Develop applications with a “DX10” state of mindA naïve port from DX9 will not yield expected gains
Use performance tools availableNVIDIA PerfHUDNVIDIA ShaderPerf
Talk to us
Questions?
DirectX 11 Preview
Key Takeaways
Direct3D 11 focuses on Increasing scalability, Improving the development experience, Extending the reach of the GPU,Improving Performance.
Direct3D 11 is a strict superset of D3D 10 & 10.1Adds support for new featuresStart developing on Direct3D 10/10.1 today
Available on Windows Vista & future Windows operating systemsSupports 10 / 10.1 level hardware
New Features Overview
TessellationCompute ShaderDynamic Shader LinkageImproved Texture CompressionQuick Glance at Other Features
Tessellation(Rocket Frog Taken From Loop &Schaefer, "Approximating Catmull-Clark Subdivision Surfaces with Bicubic Patches“)
Sub-D Modeling Animation Displacement Map
Polygon Mesh Generate LODs
Direct3D 11 Pipeline
Direct3D 10 pipelinePlus
Three new stages for Tessellation
Input Assembler
Vertex Shader
Pixel Shader
Hull Shader
Rasterizer
Output Merger
Tessellator
Domain Shader
Geometry Shader Stream Output
Hull Shader (HS)
Hull Shader
Tessellator
Domain Shader
HS output:Patch control pts afterBasis conversion
HS output:• TessFactors (how much to tessellate) • fixed tessellator mode declarations
HS input:patch control pts One Hull
Shader invocation per patch
Fixed-Function Tessellator (TS)
Tessellator
Domain Shader
Hull Shader
TS input:• TessFactors (how much to tessellate)• fixed tessellator mode declarations
TS output:• U V {W} domain points
TS output:• topology(to primitive assembly)
Note: Tessellatordoes not see control points
Tessellatoroperates per patch
Domain Shader (DS)
Domain Shader
Hull Shader
Tessellator
DS input:• U V {W} domain points
DS input:• control points• TessFactors
DS output:• one vertex
One Domain Shader invocation per point from Tessellator
Direct3D 11 Pipeline
D3D11 HW FeatureD3D11 OnlyFundamental primitive is patch (not triangle)Superset of Xbox 360 tessellation
Input Assembler
Vertex Shader
Pixel Shader
Hull Shader
Rasterizer
Output Merger
Tessellator
Domain Shader
Geometry Shader Stream Output
Tessellation: SummaryProvides
Smooth silhouettes Richer animations for less
Scale visual quality across hardware configurationsSupports performance improvements
Coarse model = compression, faster I/0 to GPUCheaper skinning and simulationImprove pixel shader quad utilizationScalable rendering for each end user’s hardware
Render content as artists intend it!
New Features Overview
TessellationCompute ShaderDynamic Shader LinkageImproved Texture CompressionQuick Glance at Other Features
GPGPU & Data Parallel Computing
GPU performance continues to growMany applications scale well to massive parallelism without tricky code changesDirect3D is the API for talking to GPUHow do we expand Direct3D to GPGPU?
Direct3D 11 Pipeline
Direct3D 10 pipelinePlus
Three new stages for Tessellation
PlusCompute Shader
Input Assembler
Vertex Shader
Pixel Shader
Hull Shader
Rasterizer
Output Merger
Tessellator
Domain Shader
Geometry Shader Stream Output
Compute ShaderData Structure
Integration with Direct3D
Fully supports all Direct3D resourcesTargets graphics/media data typesEvolution of DirectX HLSLGraphics pipeline updated to emit general data structures……which can then be manipulated by compute shader…And then rendered by Direct3D again
Example Scenario
Render sceneWrite out scene imageUse Compute for image post-processingOutput final image
Input Assembler
Vertex Shader
Pixel Shader
Hull Shader
Rasterizer
Output Merger
Tessellator
Domain Shader
Geometry Shader Stream Output
Compute ShaderData Structure
Target Applications
Image/Post processing:Image ReductionImage HistogramImage ConvolutionImage FFT
A-Buffer/OITRay-tracing, radiosity, etc.PhysicsAI
Compute Shader: Summary
Enables much more general algorithmsTransparent parallel processing modelFull cross-vendor support
Broadest possible installed base
New Features Overview
TessellationCompute ShaderDynamic Shader LinkageImproved Texture CompressionQuick Glance at Other Features
Shader Issues TodayShaders getting bigger, more complexShaders need to target wide range of hardwareOptimization of different shader configurations drives shader specialization
Combinatorial Explosion
Number of Lights
Num
ber of Materials
Environmental Effects
Solution: Dynamic Shader Linkage & OOP
Introducing new OOP features to HLSLInterfacesClasses
Can be used for static codeAlso used as the mechanism for linking specific functionality at runtime
Interfaces
interface Light{
float3 GetDirection(float3 eye);
float3 GetColor();};
Classesclass DirectionalLight : Light{
float3 GetDirection(float3 eye){
return m_direction;}
float3 GetColor(){
return m_color;}
float3 m_direction;float3 m_color;
};
Dynamic Shader Linkage
Dynamic SubroutineMaterial1(…) { … }Material2(…) { … }Light1(…) { … }Light2(…) { … }
foo(…) {myMaterial.Evaluate(…);myLight.Evaluate(…);
}
In the Runtime
Select specific class instances you wantRuntime will inline class methods
Equivalent register usage to a specialized shaderInlining is done in the native assembly
Fast operationApplies to all subsequent Draw(…) calls
New Features Overview
TessellationCompute ShaderDynamic Shader LinkageImproved Texture CompressionQuick Glance at Other Features
Why New Texture Formats?
Existing block palette interpolations too simpleResults often rife with blocking artifactsNo high dynamic range (HDR) supportNB: All are issues we heard from developers
Two New BC’s for Direct3D11
BC6 (aka BC6H)High dynamic range6:1 compression (16 bpc RGB)Targeting high (not lossless) visual quality
BC7LDR with alpha 3:1 compression for RGB or 4:1 for RGBAHigh visual quality
Comparisons
Orig BC3
Orig BC7
Abs Error
Comparisons
Orig BC3
Orig BC7
Abs Error
Comparisons
Abs ErrorHDR Original atgiven exposure
BC6 atgiven exposure
New Features Overview
TessellationCompute ShaderDynamic Shader LinkageImproved Texture CompressionQuick Glance at Other Features
Lots of Other FeaturesAddressable Stream OutDraw IndirectPull-model attribute evalImproved Gather4Min-LOD texture clamps16K texture limitsRequired 8-bit subtexel, submipfiltering precision
Multithreading SupportConservative oDepth2 GB ResourcesGeometry shader instance programming modelOptional double supportRead-only depth or stencil views
Questions?
top related