Stockholm Game Developer Forum 2010<br />Parallel Futures of a Game Engine (v2.0)<br />Johan Andersson<br />Rendering Arch...
Background<br />DICE<br />Stockholm, Sweden<br />~250 employees<br />Part of Electronic Arts<br />Battlefield & Mirror’s E...
http://badcompany2.ea.com/<br />3<br />
http://badcompany2.ea.com/<br />4<br />
Outline<br />Current parallelism<br />Futures<br />Q&A<br />Slides will be available online later today<br />http://public...
Current parallelism<br />6<br />
Levels of code in Frostbite<br />Editor (C#)<br />Pipeline (C++)<br />Game code (C++)<br />System CPU-jobs (C++)<br />Syst...
Levels of code in Frostbite<br />Editor (C#)<br />Pipeline (C++)<br />Game code (C++)<br />System CPU-jobs (C++)<br />Syst...
General ”game code” (1/2)<br />This is the majority of our 1.5 million lines of C++<br />Runs on Win32, Win64, Xbox 360 an...
General ”game code” (2/2)<br />PS3 is one of the main challenges<br />Standard CPU parallelization doesn’t help (much)<br ...
Levels of code in Frostbite<br />Editor (C#)<br />Pipeline (C++)<br />Game code (C++)<br />System CPU-jobs (C++)<br />Syst...
Job-based parallelism<br />Essential to utilize the cores on our target platforms<br />Xbox 360: 6 HW threads<br />PlaySta...
What is a Job for us?<br />An asynchronous function call<br />Function ptr + 4 uintptr_t parameters<br />Cross-platform sc...
Frostbite CPU job graph<br />Build big job graphs:<br /><ul><li>Batch, batch, batch
Mix CPU- & SPU-jobs
Future: Mix in low-latency GPU-jobs</li></ul>Job dependencies determine:<br /><ul><li>Execution order
Sync points
Load balancing
i.e. the effective parallelism</li></ul>Intermixed task- & data-parallelism<br /><ul><li>aka Braided Parallelism
aka Nested Data-Parallelism
aka Tasks and Kernels</li></ul>14<br />
Data-parallel jobs<br />15<br />
Task-parallel algorithms & coordination<br />16<br />
17<br />Timing View: Battlefield Bad Company 2 (PS3)<br />
Rendering jobs<br />Rendering systems are heavily divided up into CPU-& SPU-jobs<br />Jobs:<br />Terrain geometry [3]<br /...
Occlusion culling job example<br />Problem: Buildings & env occlude large amounts of objects<br />Obscured objects still h...
Solution: Software occlusion culling<br />Rasterize coarse zbuffer on SPU/CPU<br />256x114 float<br />Low-poly occluder me...
GPU occlusion culling<br />Ideally want to use the GPU, but current APIs are limited:<br />Occlusion queries introduces ov...
Levels of code in Frostbite<br />Editor (C#)<br />Pipeline (C++)<br />Game code (C++)<br />System CPU-jobs (C++)<br />Syst...
Shader types<br />Generated shaders [1]<br />Graph-based surface shaders<br />Treated as content, not code<br />Artist cre...
Futures<br />24<br />
3 major challenges/goals going forward:<br />How do we make it easier to develop, maintain & parallelize general game code...
Challenge 1<br />“How do we make it easier to develop, maintain & parallelize general game code?”<br />Shared State Concur...
Challenge 1 - Task parallelism<br />Multiple task libraries<br />EA JobManager<br />Dynamic job graphs, on-demand dependen...
Challenge 2 - Definition<br />”Real-time interactive graphics & simulation at Pixar level of quality”<br />Needed visual f...
Challenge 2 - Problems<br />Problems & limitations with current GPU model:<br />Fixed rasterization pipeline<br />Compute ...
Challenge 2 - Solutions<br />Absolutely a job for a high-throughput oriented data-parallel processor<br />With a highly fl...
”Pipelined Compute Shaders”<br />Queues as streaming I/O between compute kernels<br />Simple & expressive model supporting...
”Pipelined Compute Shaders”<br />Wanted for next major DirectX and OpenCL/OpenGL<br />As a standard, as soon as possible<b...
Language?<br />Future DP language is a big question<br />But the concepts & infrastructure are what is important!<br />Cou...
Future hardware (1/2)<br />Single main memory & address space<br />Critical to share resources between graphics, simulatio...
Future hardware (2/2)<br />2015 = 40 TFLOPS, we would spend it on:<br />80% graphics<br />15% simulation<br />4% misc<br /...
Conclusions<br />Future is an interleaved mix of task- & data-parallelism<br />On both the HW and SW level<br />But progra...
Thanks to<br />DICE, EA and the Frostbite team<br />The graphics/gamedev community on Twitter<br />Steve McCalla, Mike Bur...
References<br />Previous Frostbite-related talks:<br />[1] Johan Andersson. ”Frostbite Rendering Architecture and Real-tim...
Questions?<br />Email:johan.andersson@dice.se   Blog: http://repi.se    Twitter: @repi<br />39<br />For more DICE talks: h...
Bonus slides<br />40<br />
Game development<br />2 year development cycle<br />New IP often takes much longer, 3-5 years<br />Engine is continuously ...
Game engine requirements (1/2)<br />Stable real-time performance<br />Frame-driven updates, 30 fps <br />Few threads, inst...
Upcoming SlideShare
Loading in...5
×

Parallel Futures of a Game Engine (v2.0)

29,915

Published on

Game engines have long been in the forefront of taking advantage of the ever
increasing parallel compute power of both CPUs and GPUs. This talk is about how the
parallel compute is utilized in practice on multiple platforms today in the Frostbite game
engine and how we think the parallel programming models, hardware and software in
the industry should look like in the next 5 years to help us make the best games possible.

1 Comment
7 Likes
Statistics
Notes
No Downloads
Views
Total Views
29,915
On Slideshare
0
From Embeds
0
Number of Embeds
44
Actions
Shares
0
Downloads
185
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide
  • Xbox 360 version + offline super-high AA and resolution
  • ”Glue code”
  • Better code structure!Gustafson’s LawFixed 33 ms/fWe don’t use threads for anything that can be a bit computationally heavy, jobs instead
  • Data-layout
  • We have a lot of jobs across the engine, too many to go through so I chose to focus more on some of the rendering.Our intention is to move all of these to the GPU
  • Conservative
  • Want to rasterize on GPU, not CPU CPU Û GPU job dependencies
  • Simple keywords as override &amp; sealed have been a help in other areas
  • No low-latency GPU contextsNested data-parallelism
  • Would require multi-vendor open ISA standard
  • With nested data parallelism inside kernels
  • OpenCL
  • Isolate systems/areasWe do not use exceptions, nor much error handling
  • Havok &amp; Kynapse
  • Bindings to C very interesting!
  • Parallel Futures of a Game Engine (v2.0)

    1. 1. Stockholm Game Developer Forum 2010<br />Parallel Futures of a Game Engine (v2.0)<br />Johan Andersson<br />Rendering Architect, DICE<br />
    2. 2. Background<br />DICE<br />Stockholm, Sweden<br />~250 employees<br />Part of Electronic Arts<br />Battlefield & Mirror’s Edge game series<br />Frostbite<br />Proprietary game engine used at DICE & EA<br />Developed by DICE over the last 5 years<br />2<br />
    3. 3. http://badcompany2.ea.com/<br />3<br />
    4. 4. http://badcompany2.ea.com/<br />4<br />
    5. 5. Outline<br />Current parallelism<br />Futures<br />Q&A<br />Slides will be available online later today<br />http://publications.dice.se and http://repi.se<br />5<br />
    6. 6. Current parallelism<br />6<br />
    7. 7. Levels of code in Frostbite<br />Editor (C#)<br />Pipeline (C++)<br />Game code (C++)<br />System CPU-jobs (C++)<br />System SPU-jobs (C++/asm)<br />Generated shaders (HLSL)<br />Compute kernels (HLSL)<br />Offline<br />CPU<br />Runtime<br />GPU<br />7<br />
    8. 8. Levels of code in Frostbite<br />Editor (C#)<br />Pipeline (C++)<br />Game code (C++)<br />System CPU-jobs (C++)<br />System SPU-jobs (C++/asm)<br />Generated shaders (HLSL)<br />Compute kernels (HLSL)<br />Offline<br />CPU<br />Runtime<br />GPU<br />8<br />
    9. 9. General ”game code” (1/2)<br />This is the majority of our 1.5 million lines of C++<br />Runs on Win32, Win64, Xbox 360 and PS3<br />We do not use any scripting language<br />Similar to general application code<br />Huge amount of code & logic to maintain + continue to develop<br />Low compute density<br />”Glue code”<br />Scattered in memory (pointer chasing)<br />Difficult to efficiently parallelize<br />Out-of-order execution is a big help, but consoles are in-order <br />Key to be able to quickly iterate & change<br />This is the actual game logic & glue that builds the game<br />C++ not ideal, but has the invested infrastructure<br />9<br />
    10. 10. General ”game code” (2/2)<br />PS3 is one of the main challenges<br />Standard CPU parallelization doesn’t help (much)<br />CELL only has 2 HW threads on the PPU<br />Split the code in 2: game code & system code<br />Game logic, policy and glue code only on CPU<br />”If it runs well on the PS3 PPU, it runs well everywhere”<br />Lower-level systems on PS3 SPUs<br />Main goals going forward:<br />Simplify & structure code base<br />Reduce coupling with lower-level systems<br />Increase in task parallelism for PC<br />CELL processor<br />10<br />
    11. 11. Levels of code in Frostbite<br />Editor (C#)<br />Pipeline (C++)<br />Game code (C++)<br />System CPU-jobs (C++)<br />System SPU-jobs (C++/asm)<br />Generated shaders (HLSL)<br />Compute kernels (HLSL)<br />Offline<br />CPU<br />Runtime<br />GPU<br />11<br />
    12. 12. Job-based parallelism<br />Essential to utilize the cores on our target platforms<br />Xbox 360: 6 HW threads<br />PlayStation 3: 2 HW threads + 6 powerful SPUs<br />PC: 2-16 HW threads<br />Divide up system work into Jobs (a.k.a. Tasks)<br />15-200k C++ code each. 25k is common<br />Can depend on each other (if needed)<br />Dependencies create job graph<br />All HW threads consume jobs <br />~200-300 / frame<br />12<br />
    13. 13. What is a Job for us?<br />An asynchronous function call<br />Function ptr + 4 uintptr_t parameters<br />Cross-platform scheduler: EA JobManager<br />Uses work stealing<br />2 types of Jobs in Frostbite:<br />CPU job (good)<br />General code moved into job instead of threads<br />SPU job (great!)<br />Stateless pure functions, no side effects<br />Data-oriented, explicit memory DMA to local store<br />Designed to run on the PS3 SPUs = also very fast on in-order CPU<br />Can hot-swap quick iterations <br />13<br />
    14. 14. Frostbite CPU job graph<br />Build big job graphs:<br /><ul><li>Batch, batch, batch
    15. 15. Mix CPU- & SPU-jobs
    16. 16. Future: Mix in low-latency GPU-jobs</li></ul>Job dependencies determine:<br /><ul><li>Execution order
    17. 17. Sync points
    18. 18. Load balancing
    19. 19. i.e. the effective parallelism</li></ul>Intermixed task- & data-parallelism<br /><ul><li>aka Braided Parallelism
    20. 20. aka Nested Data-Parallelism
    21. 21. aka Tasks and Kernels</li></ul>14<br />
    22. 22. Data-parallel jobs<br />15<br />
    23. 23. Task-parallel algorithms & coordination<br />16<br />
    24. 24. 17<br />Timing View: Battlefield Bad Company 2 (PS3)<br />
    25. 25. Rendering jobs<br />Rendering systems are heavily divided up into CPU-& SPU-jobs<br />Jobs:<br />Terrain geometry [3]<br />Undergrowth generation [2]<br />Decal projection [4]<br />Particle simulation<br />Frustum culling<br />Occlusion culling<br />Occlusion rasterization<br />Command buffer generation [6]<br />PS3: Triangle culling [6]<br />Most will move to GPU<br />Eventually.. A few have already!<br />PC CPU<->GPU latency wall <br />Mostly one-way data flow<br />18<br />
    26. 26. Occlusion culling job example<br />Problem: Buildings & env occlude large amounts of objects<br />Obscured objects still have to:<br />Update logic & animations<br />Generate command buffer<br />Processed on CPU & GPU<br /> = expensive & wasteful <br />Difficult to implement full culling:<br />Destructible buildings<br />Dynamic occludees<br />Difficult to precompute <br />From Battlefield: Bad Company PS3<br />19<br />
    27. 27. Solution: Software occlusion culling<br />Rasterize coarse zbuffer on SPU/CPU<br />256x114 float<br />Low-poly occluder meshes<br />100 m view distance<br />Max 10000 vertices/frame<br />Parallel vertex & raster SPU-jobs<br />Cost: a few milliseconds<br />Cull all objects against zbuffer<br />Screen-space bounding-box test<br />Before passed to all other systems<br />Big performance savings!<br />20<br />
    28. 28. GPU occlusion culling<br />Ideally want to use the GPU, but current APIs are limited:<br />Occlusion queries introduces overhead & latency<br />Conditional rendering only helps GPU<br />Compute Shader impl. possible, but same latency wall<br />Future 1: Low-latency GPU execution context<br />Rasterization and testing done on GPU where it belongs<br />Lockstep with CPU, need to read back within a few ms<br />Should be possible on Larrabee & Fusion, want on all PC<br />Future 2: Move entire cull & rendering to ”GPU”<br />World, cull, systems, dispatch. End goal<br />Very thin GPU graphics driver – GPU feeds itself<br />21<br />
    29. 29. Levels of code in Frostbite<br />Editor (C#)<br />Pipeline (C++)<br />Game code (C++)<br />System CPU-jobs (C++)<br />System SPU-jobs (C++/asm)<br />Generated shaders (HLSL)<br />Compute kernels (HLSL)<br />Offline<br />CPU<br />Runtime<br />GPU<br />22<br />
    30. 30. Shader types<br />Generated shaders [1]<br />Graph-based surface shaders<br />Treated as content, not code<br />Artist created<br />Generates HLSL code<br />Used by all meshes and 3d surfaces<br />Graphics / Compute kernels<br />Hand-coded & optimized HLSL<br />Statically linked in with C++<br />Pixel- & compute-shaders<br />Lighting, post-processing & special effects<br />Graph-based surface shader in FrostEd 2<br />23<br />
    31. 31. Futures<br />24<br />
    32. 32. 3 major challenges/goals going forward:<br />How do we make it easier to develop, maintain & parallelize general game code?<br />What do we need to continue to innovate & scale up real-time computational graphics?<br />How can we move & scale up advanced simulation and non-graphics tasks to data-parallel manycore processors?<br />Challenges<br />Most likely the same solution(s)!<br />25<br />
    33. 33. Challenge 1<br />“How do we make it easier to develop, maintain & parallelize general game code?”<br />Shared State Concurrency is a killer<br />Not a big believer in Software Transactional Memory either <br />Because of performance and too ”optimistic” flow<br />A more strict & adapted C++ model<br />Support for true immutable & r/w-only memory access<br />Per-thread/task memory access opt-in<br />Reduce the possibility for side effects in parallel code<br />As much compile-time validation as possible<br />Micro-threads / coroutines as first class citizens<br />More?<br />Other languages?<br />26<br />
    34. 34. Challenge 1 - Task parallelism<br />Multiple task libraries<br />EA JobManager<br />Dynamic job graphs, on-demand dependencis & continuations<br />Targeted to cross-platform SPU-jobs, key requirement for this generation<br />Not geared towards super-simple to use CPU parallelism<br />MS ConcRT, Apple GCD, Intel TBB<br />All has some good parts!<br />Neither works on all of our current platforms<br />OpenMP <br />Just say no. Parallelism can’t be tacked on, need to be an explicit core part<br />Need C++ enhancements to simplify usage<br />C++ 0x lambdas / GCD blocks <br />Glacial C++ development & deployment <br />Want on all platforms, so lost on this console generation<br />27<br />
    35. 35. Challenge 2 - Definition<br />”Real-time interactive graphics & simulation at Pixar level of quality”<br />Needed visual features:<br />Complete anti-aliasing + natural motion blur & DOF<br />Global indirect lighting & reflections<br />Sub-pixel geometry<br />OIT<br />Huge improvements in character animation<br />These require massively more compute, BW and improved model!<br />(animation can’t be solved with just more/better compute, so pretend it doesn’t exist for now)<br />28<br />
    36. 36. Challenge 2 - Problems<br />Problems & limitations with current GPU model:<br />Fixed rasterization pipeline<br />Compute pipeline not fast enough to replace it<br />GPU is handicapped by being spoon-fed by CPU<br />Irregular workloads are difficult & inefficient<br />Can’t express nested data-parallelismwell<br />Current HLSL is a very limited language<br />29<br />
    37. 37. Challenge 2 - Solutions<br />Absolutely a job for a high-throughput oriented data-parallel processor<br />With a highly flexible programming model<br />The CPU, as we know it, and APIs/drivers are only in the way<br />Pure software solution not practical as next step after DX11 PC <br />Multi-vendor & multi-architecture marketplace<br />But for future consoles, the more flexible the better (perf. permitting)<br />Long term goal: <br />Multi-vendor & multi-platform standard/virtual DP ISA<br />Want a rich programmable compute model as next step<br />Nested data-parallelism & GPU self-feeding<br />Low-latency CPU<->GPU interaction<br />Efficiently target varying HW architectures<br />30<br />
    38. 38. ”Pipelined Compute Shaders”<br />Queues as streaming I/O between compute kernels<br />Simple & expressive model supporting irregular workloads<br />Keeps data on chip, supports variable sized caches & cores<br />Can target multiple types of HW & architectures<br />Hybrid graphics/compute user-defined pipelines<br />Language/API defining fixed stages inputs & outputs<br />Pipelines can feed other pipelines (similar to DrawIndirect)<br />Reyes-style Rendering with Ray Tracing<br />Shade<br />Split<br />Raster<br />Sub-D<br />Prims<br />Tess<br />Frame Buffer<br />Trace<br />31<br />
    39. 39. ”Pipelined Compute Shaders”<br />Wanted for next major DirectX and OpenCL/OpenGL<br />As a standard, as soon as possible<br />Run on all: discrete GPU, integrated GPU and CPU<br />Model is also a good fit for many of our CPU/SPU jobs<br />Parts of job graph can be seen as queues between stages<br />Easier to write kernels/jobs with streaming I/O <br />Instead of explicit fixed-buffers and ”memory passes”<br />Or dynamic memory allocation<br />32<br />
    40. 40. Language?<br />Future DP language is a big question<br />But the concepts & infrastructure are what is important!<br />Could be an extendedHLSL or ”data-parallel C++”<br />Data-oriented imperative language (i.e. not standard C++)<br />Think HLSL would probably be easier & the most explicit<br />Amount of code is small and written from scratch<br />Shader-like implicit SoA vectorization (SIMT)<br />Instead of SSE/LRBni-like explicit vectorization<br />Need to be first class language citizen, not tacked on C++<br />Easier to target multiple evolving architectures implicitly<br />33<br />
    41. 41. Future hardware (1/2)<br />Single main memory & address space<br />Critical to share resources between graphics, simulation and game in immersive dynamic worlds<br />Configurable kernel local stores / cache<br />Similar to Nvidia Fermi & Intel Larrabee<br />Local stores = reliability & good for regular loads<br />Together with user-driven async DMA engines<br />Caches = essential for irregular data structures<br />Cache coherency?<br />Not always important for kernels<br />But essential for general code, can partition?<br />34<br />
    42. 42. Future hardware (2/2)<br />2015 = 40 TFLOPS, we would spend it on:<br />80% graphics<br />15% simulation<br />4% misc<br />1% game (wouldn’t use all 400 GFLOPS for game logic & glue!)<br />OOE CPUs more efficient for the majority of our game code<br />But for the vast majority of our FLOPS these are fully irrelevant<br />Can evolve to a small dot on a sea of DP cores<br />Or run scalar on general DP cores wasting some compute<br />In other words: no need for separate CPU and GPU!<br />35<br />-> single heterogeneous processor<br />
    43. 43. Conclusions<br />Future is an interleaved mix of task- & data-parallelism<br />On both the HW and SW level<br />But programmable DP is where the massive compute is done<br />Data-parallelism requires data-oriented design<br />Developer productivity can’t be limited by model(s)<br />It should enhance productivity & perf on all levels<br />Tools & language constructs play a critical role<br />We should welcome our parallel future!<br />36<br />
    44. 44. Thanks to<br />DICE, EA and the Frostbite team<br />The graphics/gamedev community on Twitter<br />Steve McCalla, Mike Burrows<br />Chas Boyd<br />Nicolas Thibieroz, Mark Leather<br />Dan Wexler, Yury Uralsky<br />Kayvon Fatahalian<br />37<br />
    45. 45. References<br />Previous Frostbite-related talks:<br />[1] Johan Andersson. ”Frostbite Rendering Architecture and Real-time Procedural Shading & Texturing Techniques ”. GDC 2007. http://repi.blogspot.com/2009/01/conference-slides.html<br />[2] Natasha Tartarchuk & Johan Andersson. ”Rendering Architecture and Real-time Procedural Shading & Texturing Techniques”. GDC 2007. http://developer.amd.com/Assets/Andersson-Tatarchuk-FrostbiteRenderingArchitecture(GDC07_AMD_Session).pdf<br />[3] Johan Andersson. ”Terrain Rendering in Frostbite using Procedural Shader Splatting”. Siggraph 2007. http://developer.amd.com/media/gpu_assets/Andersson-TerrainRendering(Siggraph07).pdf<br />[4] Daniel Johansson & Johan Andersson. “Shadows & Decals – D3D10 techniques from Frostbite”. GDC 2009. http://repi.blogspot.com/2009/03/gdc09-shadows-decals-d3d10-techniques.html<br />[5] Bill Bilodeau & Johan Andersson. “Your Game Needs Direct3D 11, So Get Started Now!”. GDC 2009. http://repi.blogspot.com/2009/04/gdc09-your-game-needs-direct3d-11-so.html<br />[6] Johan Andersson. ”Parallel Graphics in Frostbite”. Siggraph 2009, Beyond Programmable Shading course. http://repi.blogspot.com/2009/08/siggraph09-parallel-graphics-in.html<br />38<br />
    46. 46. Questions?<br />Email:johan.andersson@dice.se Blog: http://repi.se Twitter: @repi<br />39<br />For more DICE talks: http://publications.dice.se<br />
    47. 47. Bonus slides<br />40<br />
    48. 48. Game development<br />2 year development cycle<br />New IP often takes much longer, 3-5 years<br />Engine is continuously in development & used<br />AAA teams of 70-90 people<br />40% artists<br />30% designers<br />20% programmers<br />10% audio<br />Budgets $20-40 million<br />Cross-platform development is market reality<br />Xbox 360 and PlayStation 3<br />PC (DX9, DX10 & DX11 for BC2)<br />Current consoles will stay with us for many more years<br />41<br />
    49. 49. Game engine requirements (1/2)<br />Stable real-time performance<br />Frame-driven updates, 30 fps <br />Few threads, instead per-frame jobs/tasks for everything <br />Predictable memory usage<br />Fixed budgets for systems & content, fail if over<br />Avoid runtime allocations<br />Love unified memory! <br />Cross-platform<br />The consoles determines our base tech level & focus<br />PS3 is design target, most difficult and good potential<br />Scale up for PC, dual core is min spec (slow!)<br />42<br />
    50. 50. Game engine requirements (2/2)<br />Full system profiling/debugging<br />Engine is a vertical solution, touches everywhere<br />PIX, xbtracedump, SN Tuner, ETW, GPUView<br />Quick iterations<br />Essential in order to be creative<br />Fast building & fast loading, hot-swapping resources<br />Affects both the tools and the game<br />Middleware<br />Use when it make senses, cross-platform & optimized<br />Parallelism have to go through our systems<br />43<br />
    51. 51. Editor & Pipeline<br />Editor (”FrostEd 2”)<br />WYSIWYG editor for content<br />C#, Windows only<br />Basic threading / tasks<br />Pipeline<br />Offline/background data-processing & conversion<br />C++, some MC++, Windows only<br />Typically IO-bound<br />A few compute-heavy steps use CPU-jobs<br />Texture compression uses CUDA, prefer OpenCL or CS<br />CPU parallelism models are generally not a problem here<br />44<br />
    52. 52. struct FB_ALIGN(16) EntityRenderCullJobData<br />{<br /> enum<br /> {<br /> MaxSphereTreeCount = 2,<br /> MaxStaticCullTreeCount = 2<br /> };<br /> uint sphereTreeCount;<br /> const SphereNode* sphereTrees[MaxSphereTreeCount];<br /> u8 viewCount;<br /> u8 frustumCount;<br /> u8 viewIntersectFlags[32];<br /> Frustum frustums[32];<br /> .... (cut out 2/3 of struct for display size)<br /> u32 maxOutEntityCount;<br /> // Output data, pre-allocated by callee<br /> u32 outEntityCount;<br /> EntityRenderCullInfo* outEntities;<br />};<br />void entityRenderCullJob(EntityRenderCullJobData* data);<br />void validate(const EntityRenderCullJobData& data);<br />Frustum culling of dynamic entities in sphere tree<br />struct contain all input data needed<br />Max output data pre-allocated by callee<br />Single job function<br />Compile both as CPU & SPU job<br />Optional struct validation func<br />EntityRenderCull job example<br />45<br />
    53. 53. EntityRenderCull SPU setup<br />// local store variables<br />EntityRenderCullJobData g_jobData;<br />float g_zBuffer[256*114];<br />u16 g_terrainHeightData[64*64];<br />int main(uintptr_t dataEa, uintptr_t, uintptr_t, uintptr_t)<br />{<br /> dmaBlockGet("jobData", &g_jobData, dataEa, sizeof(g_jobData));<br /> validate(g_jobData);<br /> if (g_jobData.zBufferTestEnable)<br /> {<br /> dmaAsyncGet("zBuffer", g_zBuffer, g_jobData.zBuffer, g_jobData.zBufferResX*g_jobData.zBufferResY*4);<br /> g_jobData.zBuffer = g_zBuffer;<br /> if (g_jobData.zBufferShadowTestEnable && g_jobData.terrainHeightData)<br /> {<br /> dmaAsyncGet("terrainHeight", g_terrainHeightData, g_jobData.terrainHeightData, g_jobData.terrainHeightDataSize);<br /> g_jobData.terrainHeightData = g_terrainHeightData;<br /> }<br /> dmaWaitAll(); // block on both DMAs<br /> }<br /> // run the actual job, will internally do streaming DMAs to the output entity list<br /> entityRenderCullJob(&g_jobData); <br /> // put back the data because we changed outEntityCount<br /> dmaBlockPut(dataEa, &g_jobData, sizeof(g_jobData)); <br /> return 0;<br />}<br />46<br />
    54. 54. Timing view<br />Example: PC, 4 CPU cores, 2 GPUs in AFR (AMD Radeon 4870x2)<br />Real-time in-game overlay <br />See timing events & effective parallelism<br />On CPU, SPU & GPU – for all platforms<br />Use to reduce sync-points & optimize load balancing<br />GPU timing through DX event queries<br />Our main performance tool!<br />47<br />
    55. 55. Language (cont.)<br />Requirements:<br />Full rich debugging, ideally in Visual Studio<br />Asserts<br />Internal kernel profiling<br />Hot-swapping / edit-and-continue of kernels<br />Opportunity for IHVs and platform providers to innovate here!<br />Goal: Cross-vendor standard<br />Think of the co-development of Nvidia Cg and HLSL<br />48<br />
    56. 56. Unified development environment<br />Want to debug/profile task- & data-parallel code seamlessly<br />On all processors! CPU, GPU & manycore<br />From any vendor = requires standard APIs or ISAs<br />Visual Studio 2010 looks promising for task-parallel PC code<br />Usable by our offline tools & hopefully PC runtime<br />Want to integrate our own JobManager<br />Nvidia Nexus looks great for data-parallel GPU code<br />Eventual must have for all HW, how?<br />Huge step forward!<br />49<br />VS2010 Parallel Tasks<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×