Performance Measurement Capabilities of VR Juggler

1
Performance Measurement Capabilities of VR Juggler

• Christopher Just
• Carolina Cruz-Neira
• Albert Baker

2
Introduction

• Importance of Performance Measurements
• Performance measurement features in VR Juggler
• Initial uses and findings

3
Importance of Performance Measurements

• Users need for interactivity
• engagement, accurate simulation
• comfort and health
• Optimization
• find bottlenecks
• reduce cost of required hardware
• Debugging

4
Throughput v. Latency

• Throughput is the time required to draw a frame
  or run one step of a simulation
• Latency is the time between when a user acts, and
  when the results of that action are displayed
• We are interested both in average measurements,
  and the frequency and severity of anomalies

5
The Need for Built-in Tools

• Graphics profiling tools dont show the big
  picture of a VR app
• Traditional profiling tools dont deal well with
  interactive, multithreaded applications.

6
VR Juggler

• Open Source library for VR applications,
  developed at VRAC
• Abstracted, Object-Oriented Architecture
• Heavily multithreaded
• 1 Kernel thread
• 1 or more drawing threads
• Threads for each I/O device

7
VR Juggler Overview
8
Performance Features

• Measure performance of key VR Juggler threads
  using timestamps
• Measure latency of input data
• Allow applications to measure their own functions
  and threads
• Log performance data for later use, or display
  interactively

9
VjControl Performance Screen
10
Measuring Function Timings

• Timing breakdowns of VR Juggler Kernel and Draw
  threads show us
• overhead of VR Juggler itself
• time required by key functions of the application
  API (preFrame, draw, etc.)
• variations when interacting with different
  objects, viewing different parts of a scene, etc.

11
Measuring Latency

• We can compare the age of input data in 3 key
  places
• 1. when received from input hardware
• 2. when app starts to use it
• 3. when the results are displayed
• The time between 2 and 3 is largely
  application-dependent.

12
Initial Tests

• VR Juggler bug revealed by first performance test

13
Interesting Results

• Tested a single OpenGL application
• Tested in ISUs C2
• multiple processors
• two graphics pipes (each responsible for two C2
  walls)
• Varied VR Juggler build/configuration options

14
2 v. 4 Drawing Threads

• Default C2 configuration uses 2 drawing threads -
  one for each graphics pipe
• Using 4 draw threads lowered framerate from 16 to
  14 fps
• Caused significant variations, large single-frame
  anomalies, etc.

15
MIPS3 v. MIPS4 Build

• Mips4 build of VR Juggler and application
  approximately 6 faster for all measured
  functions.
• For this application, resulted in a 50 framerate
  increase, due to buffer swap waits

16
POSIX threads v. Sproc( )
17
Tracker Latency
18
A Real Application

• Used performance code to optimize the Octopus
  demo shown today
• High variation in X Window event handling code
  revealed a configuration error
• Analysis of applications draw() routine helped
  identify targets for optimization.

19
The Future

• Test with a wider array of applications
• Comparison of C2/C6 performance
• Tests on additional platforms
• Integration with other performance-measurement
  tools (eg processor utilization, Iris Performer
  graphics metrics)

20