Paper - IDAV: Institute for Data Analysis and Visualization

14 · Lefohn, Kniss, Strzodka, Sengupta, and Owens4.3.1 Address Iterators. Address iterators are an important concept for the Glift implementation for two reasons.First, address iterators can be efficiently implemented as GPU rasterizer interpolants (i.e., texture coordinates). Second,they are the iterator type supported by AddrTrans components. The concept enables address translators to specifyiteration without having knowledge of physical data.Glift address translators generate a stream of valid virtual addresses for a GPU data structure. They abstract thescreen-space geometry used to initiate GPU computation as well as the physical-to-virtual translation required to mapfrom fragment position to the virtual address domain. Glift represents address iterators using vertex data, vertex shadercode and parameters, and a viewport specification.Note that this design means that modifying a Glift data structure (e.g., inserting or deleting elements) means writingto both the address translator memory and the iterator representation. The latter operation requires either render-tovertex-arraysupport or CPU involvement.4.3.2 Element Iterators. Glift element iterators pose several challenges for implementation on current GPUs.First, element iterators are a pointer-like abstraction, and GPUs do not support pointers. Second, GPU data structuretraversal is usually accomplished with the rasterizer, yet the rasterizer cannot generate true memory addresses.It can only generate N-D indices via texture coordinate interpolation (i.e., address iterators). As such, Glift implementselement iterators by combining an address iterator with a Glift container (either PhysMem or VirtMem). Thelast challenge is the design requires shading language structures that contain a mixture of uniform and varyingmembers. This feature has recently only been added to Cg and is not yet supported in other languages.4.4 Mapping Glift Data into CPU MemoryAll Glift components are designed to support data access on both the CPU and GPU. Glift implements this featureby supporting explicit map cpu and unmap cpu functionality. Just as with mappable GPU memory like vertexbuffer objects and pixel buffer objects, map copies the data into CPU memory while unmap copies data into GPUmemory. The default behavior is to transfer the entire data structure; however, Glift can optionally operate in a paged,lazy-transfer mode where only the required portions of the structure are copied. This mode reduces CPU read/writeefficiency but can greatly reduce the amount of data sent between the CPU and GPU.Initial designs attempted to automatically map data to the appropriate processor based on usage. This proved problematic,however, because it is not possible to detect all cases when a GPU-to-CPU or CPU-to-GPU synchronizationis required. For example, this can arise if a user binds a Glift structure to a shader, writes to the CPU mapping ofthe structure, then later re-binds the shader without explicitly re-binding the Glift structure. This is a perfectly legalOpenGL usage pattern, but one in which Glift cannot detect that the structure is now being read by the GPU. To supportthis automatic virtualization, Glift would either have to subsume a much larger portion of the GPU programmingmodel (shader binding, etc.) or be integrated directly into GPU drivers.4.5 Virtualized Range OperationsProviding generic support for virtualized range operations (read, write, copy) was one of the toughest challenges inthe design of Glift. The goal is for application programmers to be able to easily create new containers that havefull support for these operations. The challenge is that the contiguous virtual region over which these operations aredefined often maps to multiple physical regions.Early designs placed this functionality in the VirtMem component. This approach, however, required each datastructure to implement a significant amount of redundant, complex code. Our solution is inspired by a concept fromautomatic parallelization research. In their work to create a parallel STL, Austern et al. describe a range partitionadaptor as an entity that takes a range defined by a begin and end iterator and breaks it up into subranges which canbe executed in parallel [1996]. Applying this idea to Glift, the generic range operation problem is solved if addresstranslators can translate a virtual range into an ordered sequence of physical ranges.The prototypical usage of this operation is:ACM Transactions on Graphics, Vol. 25, No. 1, January 2006.