ARUP; ISBN: 978-0-9562121-5-3 - CMBBE 2012 - Cardiff University

For each pixel on screen we first compute the ray parameters using the method proposed by
Krüger and Westermann 9 . This process spawns one thread on the GPU for each ray that intersects
the volume, making optimal use of the GPU’s massive parallelism.
4.2.1 Basic Raycasting Loop
To traverse the volume we perform the following two operations in a loop until the ray exits the
volume:
1. compute the current brick and the entry and exit positions inside the brick
2. perform ray casting, progressing until we leave that brick
While the second operation is performed mostly as described by Stegmaier et al. 10 , the first
operation is novel. Using the current ray position and direction, the operation determines the
appropriate level of detail to utilize. It then searches for the brick in a 3D texture atlas. If the
brick isn’t found, we use a coarser resolution for this rendering pass, and write the brick identifier
into the page cache table (described in detail below) for fetching later. It then returns whatever
brick was found, with an indicator of whether it was the desired brick or a lower-resolution
version.
The second operation needs only a few small modifications for chonophotographic visualization.
First, the compositing must take all active time steps (those with an importance value greater than
0) into account. Secondly, we need to be sure all the required data is in memory, which is done
by always uploading a corresponding bricks in time when uploading a new brick.
4.2.2 Hash Function
GPUs in general do not have native support for containers (e.g. hash tables), so a new
implementation had to be designed. Our implementation is based the
EXT_shader_image_load_store extension in OpenGL (native in version 4.0). This extension
gives a shader random read and write access to a 2D texture in any pipeline stage. The
mechanism allows not just for simple load and store calls, but also atomic operations such as a
atomic compare and swap. With that call in particular, we implement a lock free hash table with
rehashing as the collision avoidance method. Therefore, we compute a hash value from the 4D
brick coordinates (i.e. 3D for the brick position and 1D for the LoD) and use atomic compare and
swap to check that entry. If the entry is (i.e. zero), we enter our data into that table and the hash
function is done. If the entry was not empty we compare with our current brick. If it is identical,
we are also done, as it implies that the current brick has already been flagged as missing by
another ray. In any other case a new value is computed.
4.2.3 Atlas Update and Ray Resume
At the end of a frame we read the hash table back into CPU memory and check if it contains any
non-zero entries. An empty table indicates that the image was fully rendered at an appropriate
resolution, and therefore our rendering is complete. If the hash-table does contain non-zero
entries, the corresponding bricks are fetched from disk and inserted into the texture atlas, using
least recently used as an eviction strategy. Once the entire hash table has been processed, the atlas
presence table is updated and both the presence table and atlas are uploaded to the GPU. A new