Dragged, Kicking and Screaming:

1. Dragged,Kicking and Screaming: Multicore Architecture and Video Games

2. Summary of Topics: • Console Architecture • Meaning of Paper’s Title/Why the Video Game Developer HATED the new • Techniques/Problems • The Future

3. Video Game Architecture • For the most part, same as computer: • Very operating system-linked. • With PCs, almost always have been games. • Mac Gaming is sparse, recently increased. • Linux users have to compile/make their own. • Console Games = primarily single-core processors…until 2005.

4. XBOX 360 • 3.2 GHz “Xenon” triple-core PowerPC, 2 hardware threads per processor • 256 MB main RAM • 500 MHz ATI “Xenos” GPU -CPU accesses memory through the GPU! • GPU has 10 MB RAM embedded frame buffer

5. XBOX 360 vs. Playstation 3 Triple-Core PPC Multicore Cell Engine PS3 - 512 MB total 256 MB 3.2 GHz XDR main RAM for the CPU 256 MB 700 MHz GDDR3 video RAM for the GPU • • Xbox 360 - 512 MB, 700 MHz, GDDR3, shared by CPU and GPU • • CPU accessesmemory through the GPU! • • GPU has 10 MB RAM embedded frame buffer

6. Cell Architecture Multiple synergistic core units that attach to local stores, which then feed into DMAs going into the on-chip bus. One set-off PPE (Power Processing Element), with an L1 and L2 cache. Developers are having some serious problems with this model.

7. Why So Unhappy? • Delays, setbacks, ecetera = unhappy fans. • Yu Suzuki; Saturn VirtuaFighter: “One very fast central processor would be preferable...I think that only one in 100 programmers are good enough to get this kind of speed out of the Saturn.” • Not implementing parallelism, use of multicore architecture, etc = unhappy fans. • If game developers utilize parallelism, the game will be delayed – 6 months, 1 year?

8. Multicore Parallelism Implementations “I guess, if we have to.”

9. Beginning Techniques • Patches, so computers at least realize there’s multiple cores available. • Intel releases several multicore assists; especially in the beginning (coaxing people into it) • Building Blocks • Codeplay’s sieve compilers • Broke a program into “sieve blocks” where automatic parallelization could be utilized

10. What do we do today? • Multithreading from the ground up • Decent (and fast!) parallelization • One of two main ways: • Every process on a different thread • Dependencies galore~!

11. “Best” Multithreading Approach Main gaming thread, with branches coming off for specific parts of the game and splintering into other threads. Particularly beastly programs get their own multithreading implementations. Networking and I/O get their own threads.

12. CASE EXAMPLE: Kameo CASE EXAMPLE: Kameo, which achieved 2.2~2.5 cores in 6mos. Rendering, decompression were on a separate thread Latter saved space on the DVD and improved load times for the game. Additionally, file I/O was separated onto two threads – one for reading, and one for decompressing.

13. Best Processes for MT • File decompression – improve load times. • Rendering – separate update and render; can be problematic • Physics Engine? – Physics/Update/Render, but latency issues. • Graphical Fluff – always and forever. • Artificial Intelligence - position independency of data, cache coherency

14. Cascade Project • Fix dataflow by sending data from the parent to the child before the parent had completed! • Respect dependencies, divided AI • Resulted in reducing “the average time per frame from 15.5ms using a single thread to 7.8ms using eight threads.” • 51% Speedup! • Work in progress – CDML • List constraints in language instead of working out later.

15. Multithreading is Tricky • Threads can fight over the cache • Dependencies • Data corruption, deadlocks • Bugs might not be apparent right away • Debugging sets developers back

16. The Future • ARM’s GPU/CPU Chip • Intel’s Larrabee Chip • Mobile Gaming Platforms laugh for now… • Unreal 4 Engine – “We’re waiting for massively multicore processors.”

17. It’s just not that easy anymore. Thanks for watching!