AMD AND MICROSOFT DEVELOPER DAY, JUNE 2014, STOCKHOLM STEPHAN HODES DEVELOPER TECHNOLOGY ENGINEER,...

AMD AND MICROSOFT DEVELOPER DAY, JUNE 2014, STOCKHOLM

STEPHAN HODESDEVELOPER TECHNOLOGY ENGINEER, AMD

GCN PERFORMANCE „FTW“

| GCN PERFORMANCE „FTW“ | AMD AND MICROSOFT GAME DEVELOPER DAY - JUNE 2 2014, STOCKHOLM2

AGENDA

GCN architecture explained

Top 10: GCN Performance Advice

Questions


AMD GRAPHICS CORE NEXT

What is GCN?‒Non VLIW architecture

‒ Less dependent on manual vectorization of shaders ‒ Susceptible to register pressure

‒Architecture used in:‒ AMD discrete GPUs since 2012 (HD7700 and better)‒ Kabini and Kaveri APUs‒ Future AMD hardware‒ New consoles

GCN Hardware is required for Mantle‒ DirectX 12 API support


PRODUCT SPECIFICATIONS

AMD RADEON™ R9 290 SERIES

R9 290X R9 290

Compute Units 44 40

Engine Clock Up to 1 GHz Up to 950 MHz

Compute Performance 5.6 TFLOPS 4.9 TFLOPS

Memory Configuration 4GB GDDR5 / 512-bit 4GB GDDR5 / 512-bit

Memory Speed 5.0 Gbps 5.0 Gbps

AMD TrueAudio Technology Yes Yes

API SupportDirectX® 11.2OpenGL 4.3

Mantle

DirectX® 11.2OpenGL 4.3

Mantle


GCN COMPUTE UNIT – SPECIFICS

Non VLIW instruction set architecture

4 [16-lane] Vector ALU (SIMD)‒ One wavefront is 64 threads‒ 1 SP (Single-Precision) op: 4 clocks‒ 1 DP (Double-Precision) ADD: 8 clocks‒ 1 DP MUL/FMA & Transcendental:16 clocks‒ 64KB Vector GPRs

1 fully programmable scalar ALU ‒ Shared by all threads of a wavefront‒ Used for flow control, pointer arithmetic, etc.‒ 8KB Scalar GPRs, scalar data cache, etc.

Branch & Message Unit

Scalar UnitVector Units(4x SIMD-16)

Vector Registers(VGPRs, 4x 64KB)

Texture Filter Units (4)

Local Data Share (LDS, 64KB)

L1 Cache(16KB)

SchedulerTexture Fetch

Load / Store Units (16)

Scalar Registers(SGPRs, 8KB)



Distributed programmable scheduler(up to 2560 threads)‒ Each compute unit can execute

instructions from multiple kernels‒ Separate decode/issue for:

‒ 1 Vector Arithmetic Logic Unit (ALU)‒ 1 Scalar ALU or Scalar Memory Read

or 1 Branch/Message‒ 1 Vector memory access

(Read/Write/Atomic)‒ 1 Local Data Share operation

(LDS)‒ 1 Export or Global Data Share operation

(GDS)

Plus 1 Special/Internal – [no functional unit](s_nop, s_sleep, s_waitcnt, s_barrier, s_setprio)






L1 Cache(16KB)






64KB Local Data Share(LDS)‒ 32 banks, with conflict resolution‒ Bandwidth amplification

16KB read/write L1 vector data cache

Texture Units (utilize L1)‒ 16 Load/Store units‒ 4 Filter units

1 Branch & Message Unit‒ Executes branch instructions

(as dispatched by Scalar Unit)






L1 Cache(16KB)





GCN COMPUTE UNIT – LATENCY HIDING

Up to 10 Wavefronts/SIMD ‒ Used to hide latency‒ Round Robin scheduling‒ Independent kernels‒ Often limited by GPR or LDS usage

Time (clocks)

Batch 2 Batch 3 Batch 4Batch 1

Stall

Runnable

Stall

Runnable

Stall

Runnable

Stall

Runnable

Done!

Done!

Done!

Done!


GDC COMPUTE UNIT – REGISTER PRESSURE

Vector GPRs‒ 64KB / 64 threads / 4 Byte / 10 wavefronts = 25.6 VGPR/thread => Max 24 VGPR per thread

Scalar GPRs‒ 8KB / 4 SIMD / 4 Byte / 10 wavefronts = 51.2 SGPR/wavefronts => Max 48 SGPR per wavefront

LDS‒ 32KB/threadgroup and threadgroup size 64 => 2 wavefronts/CU max.‒ 32KB/threadgroup and threadgroup size 256 => 8 wavefronts/CU max.‒ 16KB/threadgroup and threadgroup size 256 => 16 wavefronts/CU max.


GCN SHADER OPTIMIZATION STRATEGIES

Try reducing GPR count if you are slightly over a waves-per-SIMD threshold ‒ Deep nesting‒ Local array declarations‒ Long-lived temporary variables

Reducing GPRs not always optimal‒ Shadercompiler might use GPRs

to reduce latency‒ High number of threads/CU

can thrash your caches

image_load v6, v[35:38], s[4:11] v_mov_b32 v3, v35image_load v7, v[3:6], s[4:11]v_mov_b32 v38, v36image_load v8, v[37:40], s[4:11]v_mov_b32 v3, v37image_load v9, v[3:6], s[4:11]s_waitcnt vmcnt(2)v_min_f32 v6, v6, v7s_waitcnt vmcnt(1)v_min_f32 v6, v6, v8s_waitcnt vmcnt(0)v_min_f32 v40, v6, v9

image_load v6, v[35:38], s[4:11] v_mov_b32 v3, v35image_load v7, v[3:6], s[4:11]v_mov_b32 v38, v36v_mov_b32 v3, v37s_waitcnt vmcnt(0)v_min_f32 v6, v6, v7image_load v7, v[37:40], s[4:11]s_waitcnt vmcnt(0)v_min_f32 v6, v6, v7image_load v7, v[3:6], s[4:11]s_waitcnt vmcnt(0)v_min_f32 v6, v6, v7

Always profile your changes!http://developer.amd.com/tools-and-sdks/opencl-zone/opencl-tools-sdks/codexl/http://developer.amd.com/community/blog/2014/05/16/codexl-game-developers-analyze-hlsl-gcn

http://developer.amd.com/tools-and-sdks/opencl-zone/opencl-tools-sdks/codexl/

http://developer.amd.com/community/blog/2014/05/16/codexl-game-developers-analyze-hlsl-gcn


Top 10 Performance Advice


TOP 10 PERFORMANCE ADVICE

1. Use the power of DirectCompute

‒ Thread group size should be multiple of 64‒ 256 is often a good choice.

‒ Don‘t underestimate the benefits of LDS‒ Use asynchronous compute‒ Don‘t switch between Compute/Rasterization

too frequently



2. Don‘t over-tessellate

‒ Small triangles result in poor quad occupancy‒ Use [maxtessfactor(X)] in Hull Shader declaration

‒ Recommended value is 15 or less‒ Implement culling in Hull Shader‒ Use Adaptive Tessellation

‒ Distance Adaptive‒ Screen Space Adaptive‒ Orientation Adaptive

!

Especially when rendering Shadowmaps!!!



3. Keep your pipeline short‒ Avoid large expansion in the Geometry Shader‒ Often a Vertex Shader-only solution can

replace Geometry Shader usage‒ Bokeh expansion‒ Pointsprites

‒ Disable tessellation pipeline if unused

4. Pack shaderstage output‒ Limit Vertex and Domain Shader output size to

4 float4/int4 attributes for best performance.

struct PS_INPUT{ float3 vPosition; float3 vNormal; float2 vTexcoord1; float2 vTexcoord2; float2 vTexcoord3;}; // Unoptimal

struct PS_INPUT{ float4 vPositionTexcoord1U; float4 vNormalTexcoord1V; float4 vTexcoords23;}; // Good



5. Update your Data using map/unmap‒ Avoid MAP_WRITE_DISCARD

‒ Prefer MAP_WRITE_NO_OVERWRITE‒ Avoid UpdateSubresource

‒ Prefer Map and/or CopyResource instead‒ UpdateSubresource is ok for small (<=4KB) updates

‒ CopyResource introduces GPU stalls‒ Don‘t use the updated resource immediately‒ Using data without copying it to local first

sometimes can improve performance

Up to +20% Performance boost



6. Use flow control with care‒ Flow control has little overhead‒ Skipping data fetches usually is good‒ Avoid non-coherent codepaths

within a wavefront‒ Watch out for GPR pressure

caused by loops and deep nested branches

v_cmp_gt_f32 r0,r1 //a > b, establish VCCs_mov_b64 s0,exec //Save current exec masks_and_b64 exec,vcc,exec //Do “if”s_cbranch_vccz label0 //Branch if all lanes failv_sub_f32 r2,r0,r1 //result = a – bv_mul_f32 r2,r2,r0 //result=result * alabel0:s_andn2_b64 exec,s0,exec //Do “else”(s0 & !exec)s_cbranch_execz label1 //Branch if all lanes failv_sub_f32 r2,r1,r0 //result = b – av_mul_f32 r2,r2,r1 //result = result * blabel1:s_mov_b64 exec,s0 //Restore exec mask

// Branching code examplefloat fn0(float a,float b){ if(a>b) return((a-b)*a); else return((b-a)*b);}



7. Pack your G-Buffer using RGBA16_UINT‒ Fetches from RGBA16 are full rate (without filtering)

‒ Bilinear fetches to RGBA16 are half rate‒ Exports to RGBA16_INT are full rate (without blending)

Caution: Blended exports to RGBA16_INT are ¼ speed

8. Depth buffer: don’t render after read‒ Binding a depth buffer as texture will decompress it,

this will make subsequent Z ops more expensive.‒ Critical for shadow map atlas rendering!‒ Consider exporting depth to G-Buffer



9. Batch, Batch, Batch!‒ Add support for geometry instancing‒ Pool & batch your updates‒ Less important with Mantle/DirectX12

‒ Reduces Drawcall overhead‒ Allows better scheduling

10. (DX11) Prefer engine threadingover Deferred Contexts

‒ Deferred contexts are a software feature‒ … or move to Mantle/DirectX12



Avoid LDS bank conflicts‒ Accessing LDS with addresses that are

32 DWORD apart from different threads will cause bank conflicts

‒ Unless if it‘s the same address

Don't use gather with offsets‒ This will result in 4 image_gather4 instructions

image_gather4_c_lz v4, v[12:15], s[4:11], s[12:15] v_mov_b32 v11, 1 image_gather4_c_lz_o v5, v[11:14], s[4:11], s[12:15] v_mov_b32 v11, 0x00000100 image_gather4_c_lz_o v7, v[11:14], s[4:11], s[12:15] v_mov_b32 v11, 0x00000101 image_gather4_c_lz_o v0, v[11:14], s[4:11], s[12:15] s_waitcnt vmcnt(0)

Bonus Advice

image_gather4_c_lz v0, v[2:5], s[4:11], s[12:15]s_waitcnt vmcnt(0)

float4 PsExample( PsInput Input ) : SV_Target{ return tex.GatherCmpRed( g_SamplePointCmp, Input.vTex, Input.depth );}

float4 PsExample( PsInput Input ) : SV_Target{ return tex.GatherCmpRed( g_SamplePointCmp, Input.vTex, Input.depth, int2(0,0), int2(1,0), int2(0,1), int2(1,1) );}


[email protected]


DISCLAIMER & ATTRIBUTION

The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors.

The information contained herein is subject to change and may be rendered inaccurate for many reasons, including but not limited to product and roadmap changes, component and motherboard version changes, new model and/or product releases, product differences between differing manufacturers, software changes, BIOS flashes, firmware upgrades, or the like. AMD assumes no obligation to update or otherwise correct or revise this information. However, AMD reserves the right to revise this information and to make changes from time to time to the content hereof without obligation of AMD to notify any person of such revisions or changes.

AMD MAKES NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES, ERRORS OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION.

AMD SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL AMD BE LIABLE TO ANY PERSON FOR ANY DIRECT, INDIRECT, SPECIAL OR OTHER CONSEQUENTIAL DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF AMD IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

ATTRIBUTION

© 2013 Advanced Micro Devices, Inc. All rights reserved. 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 are for informational purposes only and may be trademarks of their respective owners.

AMD AND MICROSOFT DEVELOPER DAY, JUNE 2014, STOCKHOLM STEPHAN HODES DEVELOPER TECHNOLOGY ENGINEER,...

Documents

Transcript of AMD AND MICROSOFT DEVELOPER DAY, JUNE 2014, STOCKHOLM STEPHAN HODES DEVELOPER TECHNOLOGY ENGINEER,...