1. “Workload Characterization of a First Person Shooter” Luka Spoljaric Jeff Kwiat

2. The Problem Problem: Today’s games consume enormous amounts of CPU resources. –Complex graphics and faster movement require greater rendering speeds Can anything be done about this??

3. Solution We must form a better understanding of the workload generated by one these games –Increase efficiency within the game –Relieve the machine of excess burden to allow other processes more CPU resources

4. Presentation Overview Introduction to Games Methodology Data Analysis Implications, Conclusions, and Future Research

5. Introduction Several genres of video games –First Person Shooter Fast-paced, graphically enhanced Focus of this presentation –Role-Playing Games (RPGs) Lower graphics and slower play –Board Games Just plain boring

6. Methodology Hardware  TLAB setup –Dell Dimension 4100 –800 MHz Pentium III processor –256 MB DRAM –Video Card: NVIDIA_GLX-0.9-5 Software –Instrumented version of Linux Doom –Running on Redhat Linux release 6.2

7. Testing Phase 20 real-world tests were conducted using the Doom instrumentation Each run lasted for 180 seconds Each player started at the same point in the game –Shareware version - “Knee-deep in the Dead” Skill level was set to “Ultimate Violence” –Player could interact with more enemies

8. Doom Instrumentation Incoming Data (3 Blocks) –Doom Loop  wraps all of these –GetEvents() X Windows events  Doom Events –ProcessEvents() Process Doom Events –DisplayEvents() Update Sounds Display Submit Sounds

9. Task Sizes Represent the amount of CPU time needed to perform a specific task. We measured task sizes of each event block: –GetEvents() –ProcessEvents() –DisplayEvents Empty Tasks  Blocks where no events occurred –~98.5% !!

10. GetEvents() Block Task Size –With empty tasks Mean: 0.00176 seconds STD: 0.0050825 seconds Range: 0.1 – 0.4 seconds –Without empty tasks Mean: 0.01390 seconds STD: 0.00595 seconds Range: 0.1 – 0.4 seconds

11. Task Sizes With Empty Tasks Many cycles without events

12. Task Sizes Without Empty Tasks

13. Inter-arrival Times Inter-arrival times show multi-modal distributions Divided data into separate bins (short intervals and long intervals) Plotted each separately to present more effectively

14. GetEvents() Block Inter-arrival times –Mean: 0.0159 –STD: 0.0244 –Distribution: Tri-modal Distribution STD > Mean!! – Relates to multi- modal distribution

15. Inter-arrival Times vs. Percent

16. Inter-arrival Times (Short)

17. Inter-arrival Times (Long)

18. ProcessEvents() Block Task Size –With empty tasks Mean: 0.00387 STD: 0.00781 –Without empty task Mean: 0.0166 STD: 0.00703

19. Task Sizes with Empty Tasks

20. Task Sizes without Empty Tasks

21. ProcessEvents() Inter-arrival times –Mean: 0.029 s –STD: 0.026 s –Distribution: Multi-Modal distribution Longer intervals are more popular than in the GetEvents() blocks

22. Inter-arrival Times vs. Percent

23. Inter-arrival Times (Short)

24. Inter-arrival Times (Long)

25. Display() Block Task Size –With empty tasks Mean: 0.0016 STD: 0.0050 –Without empty tasks Mean: 0.0148 STD: 0.0065

26. Task Sizes with Empty Tasks

27. Task Sizes without Empty Tasks

28. Display() Block Inter-arrival Times –Mean: 0.0346 –STD: 0.0307 –Distribution: Multi-modal

29. Inter-arrival Times vs. Percent

30. Inter-arrival Times (Short)

31. Inter-arrival Times (Long)

32. Display() Events Event 1: “UpdateSounds”

33. Display() Events Event 2: “Display”

34. Display() Events Event 3: “SubmitSounds”

35. Future Work Extend workload characterization to other games (especially first person shooters) Participants with varying skill levels –Differences in task sizes –Differences in inter-arrival times Develop software to dynamically decide how much resources are necessary at a given point in the game

36. Conclusions The task sizes of event blocks range from 0.0 – 0.4 CPU seconds with a large number of empty tasks The inter-arrival times can be modeled as a multi-modal distribution

37. Thanks