GPU-Based Interactive Visualization of Billion-Point Cosmological Simulations

1
GPU-Based Interactive Visualization of
Billion-Point Cosmological Simulations

• Tamas Szalay,
• Volker Springel,
• Gerard Lemson

2
The Visualization Problem

• Getting better at storage and processing
• Distributed databases, clouds, etc
• I/O needs to be only as fast as computation
• Doesnt work for visualization
• Would need to read all the data every frame or
  have it all in memory
• Even rendering itself would be prohibitive
• Could use pre-rendered movies
• Trial and error takes time

3
The Aquarius Simulations

• A series of n-body dark matter simulations
• Run from the early universe to today
• Box roughly the size of galactic neighborhood
• Run five times at different particle resolutions
• Lowest has 2.3 million, takes up about 25 GB
  total
• Highest has 4 billion, and takes up 20 TB
• Each version has point data in 128 snapshots,
  with positions and velocities
• Movies have been rendered, took weeks

4
Visualization Motivation

• Certain types of analysis very difficult
  otherwise
• Qualitative impressions of gravitational
  structures
• Verification of simulation and accuracy of
  structure finding
• Identification of events of interest
• Comparisons of multiple objects
• Two colliding gravitational clusters
• Dark matter streams
• Public outreach

5
(No Transcript)
6
(No Transcript)
7
Hierarchical Rendering

• Dont need to render everything
• Saturates screen anyway
• So show the same data, but render less
• Create different levels-of-detail for entire
  dataset
• Load different parts from different levels as
  needed
• Put levels-of-detail on fast storage system
• And give it a rendering front-end
• Think Google Microsoft Maps

8
Level Structure

• Chose spatial octree because it is simple and
  general
• Each node also has associated data
• All of the data spatially contained within the
  cube
• Except simplified to lt N points
• Deeper in the tree means higher resolution
• Organized this way on disk

9
Selective Loading

• What resolution data to load in what spatial
  location?
• Close to viewer in high detail and far away in
  low detail
• Can use the on-screen size of the relevant octree
  cube to determine resolution
• Means, in theory, visually equivalent to entire
  dataset
• Automatically scales to rendering hardware
• Can spread out through time as well

10
(No Transcript)
11
Rendering Front-End

• GPUs are fast
• Really fast
• Can do an unbelievable amount of computation in
  rendering pipeline
• Allows tool to still do significant processing
• The actual rendering algorithm
• Brightness represents the line integral of the
  squared density in that pixel
• Color represents the temperature
• But there is quite a bit of computation involved

12
Practical Results

• Program currently runs on single desktop computer
  and attached storage
• 4 GB RAM, GeForce 8800 GTS, 2x750 GB disk
• Smoothly interacts with and renders 1 TB dataset
  (150 million points x 128 timesteps)
• Rarely loads or renders to full depth
• Could have arbitrarily large underlying data

13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
Future Possibilities

• Storing and accessing data via databases
• Could even do some processing in between
• Distributed rendering
• Remote rendering
• Other datasets and data types
• Meshes, volume data, medical imaging