1 / 37

“Workload Characterization of a First Person Shooter”

“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.

tale
Download Presentation

“Workload Characterization of a First Person Shooter”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related