Design Of A High Performance Volume Visualization System Barthold Lichtenbelt* Graphics Products Laboratory, Hewlett-Packard memory bandwidth and bus bandwidth. Visualizing a reasonable Abstract volume dataset of 64 Mbytes in real time is beyond today’s desktop computers. Visualizing an ever bigger dataset of about 512 Mbytes in real time is beyond today’s supercomputers. Visunlizing three dimensional discrete datasets has been a topic of Therefore people have been designing, and building special many research projects and papers in the past decade. We discuss purpose hardware that will accelerate the rendering of volume the issues that come up when designing a whole computer system datasets, much beyond what a general CPU is capable of doing. cnpable of visualizing these datasets in real time. We explain the This makes perfect sense because we expect that a well designed three way chicken and egg problem and discuss Hewlett- volume visualization system will outperform general CPU Packard’s effort at breaking it with the Voxelator API extensions solutions by several orders of magnitude. to OpenGL. We enumerate what a good hardware design should accomplish, We discuss what system issues are important and One of the problems we are faced with in designing a volume show how to integrate volume visualization hardware in one of visualization system is system integration. Globally there are Hewlett-Packard’s graphics accelerators, the VISUALIZE-48XP. three crucial areas that need to be addressed in order to be able to We show why the Voxelator is an efficient and well designed API produce a good volume visualization system. First, there should by explnining how various existing hardware engines will easily be hardware that accelerates the volume visualization. There are tit into the Voxelator framework. many problems associated with building this kind of hardware. We will not discuss these issues in this paper. Second, the CR Categories and Subject Descriptors: C.5.3 [Computer hardware should interface to a computer. This includes the System Implementation] Microcomputers - Workstations; D.2.0 hardware interface itself, like bus issues. The physical size, power [Software Engineering] General - Standards; 1.3.1 [Computer consumption, and heat dissipation of the hardware also falls in Gmphics] Hardware Architecture - Graphics Processors; 1.3.7 this category. Third, applications that allow the user to visualize [Computer Graphics] Three-Dimensional Graphics and Realism - their volume data need to talk to the hardware through some kind Rnytracing. of software interface, or API (Application Programming Interface). An API hides hardware details from the application, Additional Keywords: volume rendering, visualization, volume which allows software developers to design an application that is nccelemtor, OpenGL, system design. portable across platforms. I INTRODUCTION These three problems need to be solved to design and build a high performance volume visualization system. To also make this system affordable makes it even harder. Hewlett-Packard’s goal is Designing a hardware volume rendering engine is a non-trivial to make volume visualization pervasive. With that we mean that task. Many designs have been proposed [2, 4, 7, 8, 9, 10, 11, 12, every professional, who today uses a 3D workstation, will be able 15, 16, 171, and n few either simulated or actually built [l, 4, 9, to afford to do volume visualization with that kind of a system. 10, 151. Volume visualization is compute intensive and very demanding on system resources like CPU compute power, In achieving this we see a three way chicken and egg problem that needs to be solved. Fast volume visualization hardware does not function without a good industry standard API, which does not function without applications that use that API, and these * Hewlett-Packard, 3404 East Harmony Road, Fort Collins, applications will not function without fast hardware. We wanted CO 80525, USA. [email protected] to break this circle and started at the API level. The reasons for starting there are: Pcnni~ioll to ,,l&e digitd/hrd copies of all or pnri Ofdk Il~~bXkdIbr pcmo,,n~ or cln~qqol,l~c is granted Allout i& provided lint 1111:coPi= l A good API outlives hardware. By hiding hardware details nrd llot Illndu or distrihWl for prolit or conmlercin~ ~dv~N% 11~ coPY- from the application, hardware designers have the freedom to rig,ll notice, tile title &IJC pubka:ntion and its date appmr. md mticc is change hardware from one generation to the next, without Bi\tca tllnl copvigllt ir by permissioll oftIle XL!. Illc. To coPY olknVisr~ impacting the application. This is crucial to the wide spread to rq\~~>\i~\,.1; ,-,og o,, se:~verjor to redistribtlto lo lists. rrWir= specilic acceptance of volume visualization. This means that the API peni+Gm niill/orfc ‘2 has to be general enough to allow for several hardware 199 7 ,yIc;(.;lblpI~/~uro~rnphics WorksIf 0p copyrjg~l~1997 ACM 0.89791.961-O/9718-$3.50 generations, without limiting potential new developments and improvements in hardware design. 111 The API has to deal with both hardware on one end and . optimally uses system resources. The critical resources in a applications on the other end. Both have specific constrains volume visualization system are memory, memory that govern the design and definition of the API. bandwidth, bus bandwidth, accelemtion hardware and the Without a standard API there is no incentive to develop general purpose CPU. For example,. the API should not be applications. Applications need to be portable across designed so that it has to make an extra copy of the dntaset in platforms. A standard API provides the means for a high memory. degree of portability. l provides enough flexibility for applications. Without a standard API that is available on several different . implements the full volume rendering pipeline. With this we platforms it is hard to justify developing special purpose mean gradient computation, classification, lighting and volume visualization hardware. A standard highly available shading, interpolation and compositing. The full pipeline API will help making volume visualization pervasive, which will be discussed in detail in the next section. means that hardware development costs can be amortized . integrates well with the existing OpenGL geometry and over a much broader base of systems. imaging pipelines. The 3D texture mapping OpenGL extension is in widespread . is unambiguous. All stages in the API are well defined as is use today [I, 5, 6, 13, 201, but it only solves parts of the the order in which the stages are executed. The dcfnult volume visualization problem. It only accelerates the values are defined. rasterization stage of the volume pipeline. This will be explained in more detail in section 3. Some of these design constraints conflict with each other, like the desired flexibility for applications and the defined order in which The next section discusses requirements for a good volume stages of the pipeline are executed. Applications want maximum visualization API. Section 3 describes the Voxelator API, our flexibility, which means that they would like to m-define the volume visualization extensions to OpenGL. Section 4 explains order in which stages are executed. However, this will make the concept of blocking. Section 5 discusses important factors that hardware acceleration a great deal more complex, How WCdealt make for a good volume visualization system and discusses the with these issues is the topic of the next section. integration of volume visualization hardware into one of Hewlett- Packard’s graphics accelerators. Section 6 validates the Voxelator by discussing how existing hardware engines map to it. Section 7 3 THE VOXELATOR API and 8 discuss future directions and draw some conclusions. t .OpenGL [19] is the standard visualization API at this moment, 2 API REQUIREMENTS and will be in the foreseeable future. Therefore we chose to use OpenGL as the API of choice for our volume visualization The API is the most essential part of a volume visualization system. Since volume visualization is n new field, OpenGL did system, since it enables the hardware and the applications using not adequately address this topic yet. Figure 1 shows a high lcvcl the hardware to work together as a volume visualization system. overview of the OpenGL pipeline. The pixel pipeline and the Therefore careful thought has to be given to its design. We used geometry pipeline exist in OpenGL today. The images that arc the following list of design goals in the design of the Voxelator API extensions to OpenGL. A good volume visualization API: r----T ---tff&- ‘Y<>,; is based on the industry standard API, OpenGL. We did not want to design a proprietary API. OpenGL is a widely adopted visualization API and is available on all major platforms. outlives a hardware design. Several generations of hardware should fit under the API. Therefore the API should not dictate one specific hardware implementation, as the 3D texture mapping extensions to OpenGL do. is extensible. That means that if new features need to make it into the API, there is a mechanism to do so. OpenGL provides a general extension mechanism to do just that. The next section will list some explicit examples of possible future extensions to the Voxelator. has low overhead. This means that the API does not neutralize the hardware performance by forcing significant software preprocessing. The API is a thin layer on top of hardware, just enough to hide hardware details from the applications. tits numerous hardware designs. It allows for some or all of its stages to be accelerated by hardware. This choice should be up to the hardware designer, not dictated by the API. Figure 1. The standard OpenG~pipelineplus Ihe new voxel pipeline. 112 input into the imaging pipeline either can be routed to texture implementation of the Voxelator pipeline can be different from memory or to the frame buffer, through the fragment operations the one shown in Figure 2.