Vol-a-Tile Benchmarks

Shalini Venkataraman, Luc Renambot

Version: April 12, 2004

ResearchGear ID: 20040412_venkataraman

Vol-a-Tile is a volume rendering tool for large-scale, time-series scientific datasets for scalable resolution displays. These large scale datasets can be dynamically processed and retrieved from remote data stores over photonic networks. Vol-a-Tile focuses on very large volumetric data and time-dependent simulation results such as seismic data and ultra-high resolution microscopy.

System design

There are 3 components to the system - Optistore, Volatile and tfUI as shown below.

Optistore

Optistore is the dataserver which stores objects as 3D volumes or geometry. Optistore is designed to assist visualization dataset handling, including data management, processing, representation and transport. It is built upon existing functionality in VTK such as the marching cubes, gradient estimation, data reduction and sampling filters .

Vol-a-Tile

Vol-a-tile handles the rendering, scalable displaying and user interaction. All the nodes in Vol-a-tile (master and slaves) have a dedicated link to Optistore to retrieve the datasets. The master handles user interaction and any transfer function updates from the transfer function editor and broadcasts it to the slaves using MPI. The slaves are responsible for processing commands from the master and rendering to their respective view frustums.

Transfer function Editor (tfUI)

tfUI is the user interface for transfer function selection based on the Simian system at Univ of Utah. The color and opacity can be selected using the classification widgets. These widgets can be overlayed and then rasterized to a 2D texture which is sent to Vol-a-Tile. The 2D Histogram for the dataset is retrived from Vol-a-Tile and displayed to guide the user in the selection.

The diagram below shows in detail, the different software components and how they interact.

Interaction - Roaming sequence

Shown below is a sequence diagram for a typical roam operation. This highlights the main steps that occur when a user presses a key to when the volume is received. Click on each of the colored boxes to access the benchmark graphs for that process.

Benchmarks

System configuration for the tests-

  • Scylla cluster at EVL - 15-node Dual Proc Xeon CPU 1.80GHz
  • GPU - NVidia Quandro Fx 3000 ;1600x1200 resolution
  • Main Memory - 1.5GB
  • Network - gigE interface

Disk-Memory load

Done at the beginning of the program execution. The whole dataset is loaded into memory from disk. The graph below compares loading time for the 3 datasets used with the different compression schemes - Raw binary, Run-length Encoded (RLE) and gzipped.

Arad full volume load (1001x801x801)

Raw - 94.3s RLE - 161.63s Gzip - 47.0s

Subvolume extraction

Called by the renderer to get a subvolume from the full volume The subvolume size is selected so as to fit into texture memory. Time to crop the full volume for the different subvolume sizes is shown below.

Network data transfer

The graphs below shows the time for network data transfer and the total roam time. Three possible cases have been tested - local, cluster and remote

Local

The server and the renderer are collocated ie the same machine runs Optistore and Vol-a-tile. There is no actual network communication involved here.

Cluster

The server and the renderer are running on different nodes but within the same cluster. So, half the nodes of scylla run Optistore and the other half Vol-a-tile. Network data transfer is over GigE.

Remote

The data server is remote, in the case at IGPP/SIO in San Diego and the rendering on scylla cluster at EVL. Data transfer is over regular internet. As expected, the network transfer times are high.

Histogram calculations

Optionally, the renderer can request a 2D histogram from the dataserver. This histogram is computed based on the data and gradient values and is eventually used by the transfer function editor as a guide for the user. If we are loading previously saved transfer functions, this compute-intensive step can be omitted. There are 2 steps in the calculation

vtkGradient - update

We simply maintain 1 copy of the volume data and use the vtkGradient estimator to calculate the gradient values on the fly. This expensive process can be avoided if we precompute and store the gradient volume in addition to the data (which increases main memory and disk storage requirements).

Calculate 2D Histogram

Calculates a 2D logarithmic histogram using the voxel and the gradient values.

The graph below compares the 2 steps just described.

Memory-Texture download

When the renderer receives a new subvolume is from the dataserver, it has to be downloaded to the graphics memory to be visualized as 3D textures.

Render

The graph below compares frame-rates for rendering with different tile-configurations. The number of texture slices is constant throughout and all nodes render to full screen (1600x1200). The performance of standalone version of Vol-a-Tile is also shown which is lower than the corresponding distributed version. The reason being the glutIdleFunc which does the continuous redraw. In the distributed version, MPI does this for us.

Table showing the different tile configurations and their respective display resolutions

Tile Configuration Resolution MPixels
1x1 1600x1200 1.875
2x2 3200x2400 7.5
3x3 4800x3600 16.875
5x3 8000x3600 28.125

Relevant Links

 

EVL ResearchGear publishes preliminary software, technical reports, data or results that the Electronic Visualization Laboratory openly shares with the research community. The work presented here is preliminary and we are not responsible for any damages that may result from its use or misuse. If you would like to cite any of this information in your research papers, presentations, etc, please reference the ResearchGear ID above. Thank you, and we hope you find the information on this page useful.


Visit ResearchGear Home Page