workload characterization of a first person shooter l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
“Workload Characterization of a First Person Shooter” PowerPoint Presentation
Download Presentation
“Workload Characterization of a First Person Shooter”

Loading in 2 Seconds...

play fullscreen
1 / 37

“Workload Characterization of a First Person Shooter” - PowerPoint PPT Presentation


  • 100 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '“Workload Characterization of a First Person Shooter”' - tale


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the problem
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
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
Presentation Overview
  • Introduction to Games
  • Methodology
  • Data Analysis
  • Implications, Conclusions, and Future Research
introduction
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
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
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
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
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
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
Task Sizes With Empty Tasks

Many cycles without events

inter arrival times
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 block14
GetEvents() Block
  • Inter-arrival times
    • Mean: 0.0159
    • STD: 0.0244
    • Distribution: Tri-modal Distribution
  • STD > Mean!! – Relates to multi-modal distribution
processevents block
ProcessEvents() Block
  • Task Size
    • With empty tasks
      • Mean: 0.00387
      • STD: 0.00781
    • Without empty task
      • Mean: 0.0166
      • STD: 0.00703
processevents
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
Display() Block
  • Task Size
    • With empty tasks
      • Mean: 0.0016
      • STD: 0.0050
    • Without empty tasks
      • Mean: 0.0148
      • STD: 0.0065
display block28
Display() Block
  • Inter-arrival Times
    • Mean: 0.0346
    • STD: 0.0307
    • Distribution: Multi-modal
display events
Display() Events
  • Event 1: “UpdateSounds”
display events33
Display() Events
  • Event 2: “Display”
display events34
Display() Events
  • Event 3: “SubmitSounds”
future work
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
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