Increase your FPS. with CPU Onload Josh Doss. Doug McNabb.

Transcription

1 Increase your FPS with CPU Onload Josh Doss Doug McNabb

2 3 Introduction When optimizing your game it s all about FPS. It s easy to be graphics-bound! Heavy Post Processing Higher resolutions Multi-monitor Stereo/3D Balance work across the platform

3 4 Motivation CPUs can do graphics too - balance the platform for best PC performance CPUs are increasing in power More cores Wider SIMD More FLOPS Opportunities from integration of graphics units We ll show you some workloads that illustrate this

4 5 Agenda Why would we want the CPU to do graphics? How? Show me some examples!

5 Trends GFLOPS Pentium 3 Pentium Extreme Core Duo 2nd Gen Core

6 7 The CPU Can Help with Graphics Easy to become graphics-bound Free up some graphics resources to increase graphics performance What challenges exist? Any showstoppers? How well does the CPU perform this work? How do we leverage the CPU s flexibility?

7 8 Scaling with the new generation of processors? Shared LL$ cache Gfx EU/Frequency similar across parts (Mobile/Not LV/ULV) Core CPU count, frequency and shared LL$ differ across parts SCALE on the CPU when targeting PG!

8 9 CPUs, GPUs and Processor Graphics Industry movement of CPU workloads to GPU Physics AI Processor Graphics aim for mainstream Focus the processor s graphics resources on graphics Keep classic CPU workloads on CPU Improve load balancing by moving some workloads to the CPU

9 10 Scalable/Vectorized Code is getting easier! Tools/APIs now exist and are pervasive Tasking/Threading CILK, TBB SIMD IPP, Ct, OpenCL, etc.

10 11 Barriers? Showstoppers? CPU doesn t have dedicated Texture Samplers No dedicated rasterizer Existing APIs weren t designed with CPU/GPU sameframe cooperation in mind Currently requires copying data back and forth between CPU and GPU No known showstoppers

11 12 The CPU can perform with graphics This is not your grandfather s CPU In the ballpark with GPUs for some workloads Performance numbers later in the talk Not constrained by APIs Better/more efficient branching can help with some workloads

12 13 Onloading Techniques Intra-frame onload Use some CPU cores to perform a specific graphics element of a frame Full screen effects Bloom, HDR, etc. Data generation Heat maps, shadow maps, etc Asynchronous full pipeline duplication

13 14 A Rendered Frame Is Combination of Different Workloads Forward Renderer Z-prepass SSAO Shadow map(s) Reflection map(s) Opaque Geometry Semi-transparent geometry Foliage Particles Post Processing UI/HUD Deferred Renderer Reflection Map(s) Render G Buffer SSAO Loop Over Lights Shadow Map(s) Light Pass Semi-transparent Geometry Foliage Particles Post Processing UI/HUD

14 15 Different Workloads Have Different Optimization Opportunities Shadow map generation, Z-Prepass Don t require texture mapping* Particles Screen-facing quads/sprites Trivial clipping/scissoring Constant depth, gradients Simple pixel shader Regular texture access patterns Post Processing No general purpose texture sampling Regular texture access patterns Can share partial results while marching across pixels UI/HUD Sprite systems have same characteristics as particles

15 16 Constraints Sharing data with CPU and GPU E.g., EU(s) Render frame to a point, then CPU contributes, then EU(s) continue, etc. Keeping both devices busy Different from single-rendering-device approach CPU and EU(s) alternate working on the frame E.g., EU(s) render first part of next frame while CPU performs Post Processing Rasterization rules differences? Example: CPU Z-Prepass, shadow maps, etc.

16 17 Case Studies High-Dynamic-Range Post Processing Particle Renderer Onloaded Shadows (view invariant heterogeneous CSS + EVSM implementation)

17 18 DXUT App Processor Graphics Renders HDR Scene to Render Target Float16 RGBA Copy Render Target to CPU CPU Processes HDR scene to produce LDR result Copy CPU results to the Back Buffer to complete frame and Present() HDR Post Processing

18 x800 RGBA16F ~2 msec / frame on 6-Core Desktop Gulftown ~3 msec / frame on 4-Core Laptop 2 nd Generation Core CPU Not yet optimized for AVX Minimum frame-time limited by data copy to/from ~3.5 msec/frame Working on fixing this now

19 20 Post Processing Steps Convert from float16 to float32 Downsample to ¼ x ¼ sized buffer Calc average luminance +Brightpass Separable Gaussian blur downsampled buffer Tone map and Bloom Copy CPU-side result to back buffer

20 21 Pipelining Want CPU work to overlap with EUs (Keep both devices busy) GPU Render Scene Frame N HDR Frame N Render UI Frame N Render Scene Frame N+1 HDR Frame N+1 Render UI Frame N+1 GPU-Only Rendering GPU CPU Render Scene Frame N Render UI Frame N-1 HDR Frame N Render Scene Frame N+1 Render UI Frame N HDR Frame N+1 Render Scene Frame N+2 Render UI Frame N+1 HDR Frame N+2 Pipelined GPU + CPU Rendering

21 22 Tasking Keep Multiple CPU Cores Busy and Productive Mechanism for dividing work There are others, like simple threads Why tasks instead of threads? Only one task runs at-a-time per-hw-thread Tasks run to completion Avoids oversubscription Provides automatic dependency chain enforcement

22 23 Divide and Conquer Divide the problem around dependencies (as straightforward or complex as required) Break the problem into pieces (tasks) that can be performed at the same time HDR accomplishes this with tiles A picture is worth a thousand words

23 24 Task Visualization HW Thread 1 HW Thread 2 HW Thread 3 HW Thread 4 HW Thread 5 HW Thread 6 HW Thread 7 HW Thread 8 Time = Downsample Task = Blur Task = Upsample, Tonemap, Bloom tasks

24 25 Keep Multiple SIMD Lanes Busy SSE provides 4 32-bit floats per register AVX provides 8 32-bit floats per register 2X for shorts. 4X for chars. SIMD allows us to perform multiple operations with a single instruction. Find SIMD opportunities in our algorithms to get this gain.

25 26 Downsample Using SIMD Source Pixels (4 groups of 4x4 pixels) Downsampled Pixels (4 pixels, each an average of a 4x4 source pixel block)

26 27 Downsample with C/C++ Source Compute Luminance Destination For each destination pixel For each of the 4x4 corresponding source pixels Load and accumulate result Multiply by 1/16 to get average and write to destination Compute Luminance (or Log(lum)) and accumulate + Accumulated Luminance

27 28 Downsample with Pixel Shader Source Destination (implicitly) for each destination pixel For each of the 4x4 corresponding source pixels Issue texture fetch and accumulate result. Would likely leverage sampler s bilinear-filtering capability to do 2x2 at a time. Divide by 16 to get average and return result Memory access pattern called gather Can t accumulate Luminance here. Programming model doesn t support it. Need separate pass(es)

28 29 CPU SIMD Sum Source Pixels Vertical SIMD Sum Could do Horizontal Sum here. But, expensive, computes only one at-a-time. We have a better way!

29 30 Transpose Allows Final Sum to be SIMD Too Now have four values, each the sum of a 4x4 source-image pixel block Multiple by 1/16 to get final average (or, avoid multiply and work in *16 space ) Can skip this for luminance! We don t need the average luminance for each 4x4 pixel block. We need only the final average. Transpose Compute luminance and accumulate Final, SIMD Sum

30 31 Avg Luminance with Pixel Shader Could compute luminance and write to alpha channel, or separate (MRT) render target during downsample But, still gives one luminance per-pixel instead of accumulated Need separate pass(es) to ping-pong downsample to 1x1 render target And, then need to use texture fetch to use the result when we tonemap later CPU Flexibility = optimization opportunity Can accumulate to a global for use with tonemapping

31 32 Downsample CPU v. DX (Vertex/Pixel Shader) CPU Compute average of 4x4 pixel block Compute luminance (four at-a-time SIMD) and accumulate to per-tile global Perform threshold (if brightpass desired) DX Downsample. Render fullscreen quad to downsample render target Compute luminance. Render fullscreen quad, bind downsample RT as texture, write luminance to luminance RT Downsample luminance render target. Ping pong until 1x1 Brightpass (if desired). Render fullscreen quad, bind downsample RT as texture.

32 33 Particle Rasterizer Direct quad rasterizer vs. general tri rasterizer Tile and bin for multi-core parallelism Process 4 (SSE) or 8 (AVX) particles at a time for SIMD parallelization of setup phase Render 2x2 (SSE), 4x2 (AVX) pixel blocks for SIMD parallelism of rasterize phase ~100 K (smallish) particles/msec on 6-core Gulftown

33 34 Onloaded Shadows CPU-side cascaded shadow map generation Distribute work over several frames Use Microsoft WARP software rasterizer on one core White paper and source code

34 35 Call to Action/Conclusion With today s CPUs it s possible to move graphics workloads to the CPU Some workloads map better to Onloading techniques Performance of certain techniques is on par with discrete graphics hardware Thanks for listening... now go out and think about the potential for CPU Onload techniques and stay tuned to our Visual Adrenaline site for samples coming soon!

35 36

36 Legal Disclaimers INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY RELATING TO SALE AND/OR USE OF INTEL PRODUCTS, INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT, OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications. Intel Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights that relate to the presented subject matter. The furnishing of documents and other materials and information does not provide any license, express or implied, by estoppel or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights. Intel may make changes to specifications, product descriptions, and plans at any time, without notice. The Intel processor and/or chipset products referenced in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. All dates provided are subject to change without notice. All dates specified are target dates, are provided for planning purposes only and are subject to change. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. * Other names and brands may be claimed as the property of others. Copyright 2010, Intel Corporation. All rights reserved.

37 Optimization Notice Optimization Notice Intel compilers, associated libraries and associated development tools may include or utilize options that optimize for instruction sets that are available in both Intel and non-intel microprocessors (for example SIMD instruction sets), but do not optimize equally for non-intel microprocessors. In addition, certain compiler options for Intel compilers, including some that are not specific to Intel micro-architecture, are reserved for Intel microprocessors. For a detailed description of Intel compiler options, including the instruction sets and specific microprocessors they implicate, please refer to the Intel Compiler User and Reference Guides under Compiler Options." Many library routines that are part of Intel compiler products are more highly optimized for Intel microprocessors than for other microprocessors. While the compilers and libraries in Intel compiler products offer optimizations for both Intel and Intel-compatible microprocessors, depending on the options you select, your code and other factors, you likely will get extra performance on Intel microprocessors. Intel compilers, associated libraries and associated development tools may or may not optimize to the same degree for non- Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include Intel Streaming SIMD Extensions 2 (Intel SSE2), Intel Streaming SIMD Extensions 3 (Intel SSE3), and Supplemental Streaming SIMD Extensions 3 (Intel SSSE3) instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. While Intel believes our compilers and libraries are excellent choices to assist in obtaining the best performance on Intel and non-intel microprocessors, Intel recommends that you evaluate other compilers and libraries to determine which best meet your requirements. We hope to win your business by striving to offer the best performance of any compiler or library; please let us know if you find we do not. Notice revision #

38 39 Appendix I Graphics Performance Analyzers: Visual Computing Home Page Graphics Samples Home Page Keep up to date with samples releasing throughout the year Graphics Samples Page: Sandy Bridge Samples Page: