Bricking

The most common way of storing volumetric data is a linear volume layout. Volumes are typically thought of as a stack of two-dimensional images (slices) which are stored in an array linearly. The work-flow of a standard volume raycasting algorithm on a linearly stored volume is as follows: For every pixel of the image plane a ray is cast through the volume and the volume data is resampled along this ray. At every resample position resampling, gradient computation, shading, and compositing is performed. The closer the neighboring rays are to each other, the higher the probability is that they partially process the same data. Given the fact that rays are shot one after the other, it is very likely that the same data has to be read several times from main memory, because in general the cache is not large enough to hold the processed data of a single ray. This problem can be targeted by a technique called tile casting. Here, rather than processing one ray completely, each pass processes only one resample point for every ray. However, different viewing directions still cause a different amounts of cache line requests to load the necessary data from main memory which leads to a varying frame-rate.

The concept of bricking supposes the decomposition of data into small fixed-sized data blocks (see Figure 3.8). Each block is stored in linear order. The basic idea is to choose the block size according to the cache size of the architecture so that an entire block fits into a fast cache of the system. It has been shown that bricking is one way to achieve high cache coherency, without increasing memory usage [40]. However, accessing data in a bricked volume layout is very costly.

Figure 3.8: Linear and bricked volume layouts. (a) linear volume layout stored as a stack of slices. (b) bricked volume layout stored as a set of blocks.
\includegraphics{algorithm/images/linearvolumelayout.eps} \includegraphics{algorithm/images/brickedvolumelayout.eps}
(a) (b)