370 likes | 521 Views
“Workload Characterization of a First Person Shooter”. Luka Spoljaric Jeff Kwiat. 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??. Solution.
E N D
“Workload Characterization of a First Person Shooter” Luka Spoljaric Jeff Kwiat
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??
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
Presentation Overview • Introduction to Games • Methodology • Data Analysis • Implications, Conclusions, and Future Research
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
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
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
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
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% !!
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
Task Sizes With Empty Tasks Many cycles without events
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
GetEvents() Block • Inter-arrival times • Mean: 0.0159 • STD: 0.0244 • Distribution: Tri-modal Distribution • STD > Mean!! – Relates to multi-modal distribution
ProcessEvents() Block • Task Size • With empty tasks • Mean: 0.00387 • STD: 0.00781 • Without empty task • Mean: 0.0166 • STD: 0.00703
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
Display() Block • Task Size • With empty tasks • Mean: 0.0016 • STD: 0.0050 • Without empty tasks • Mean: 0.0148 • STD: 0.0065
Display() Block • Inter-arrival Times • Mean: 0.0346 • STD: 0.0307 • Distribution: Multi-modal
Display() Events • Event 1: “UpdateSounds”
Display() Events • Event 2: “Display”
Display() Events • Event 3: “SubmitSounds”
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
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