Analysis Towards Energy-Aware Image-based In Situ Visualization on the Fugaku

Energy efficiency has become a serious concern when running applications on HPC systems. Although these systems were designed to mainly run simulation codes as fast as possible, due to the ever-increasing size of the simulation outputs, the in situ visualization has gained increasing attention. In situ visualization uses the same HPC system to execute a part or even the entire visualization processing, and there are currently a variety of tools and libraries, that facilitate domain scientists to integrate them with their simulation codes. Among different approaches, image- and video-based in situ visualization has been widely adopted as an effective approach for the subsequent offline visual analysis. In this approach, a large number of renderings are required at every visualization time step and can consume a considerable computational resource. Fugaku adopted PowerAPI which enables the users to set the power mode for their jobs. However, simulation and visualization codes may have different processing behaviors requiring different power settings for obtaining the most energy-efficient runnings. In this work, we tried to shed light on the energy efficiency of the visualization portion that was not considered before. We investigated the computational cost and energy consumption of some rendering techniques by using the PowerAPI and KVS (Kyoto Visualization System) on the Fugaku, and hope that the obtained findings will be useful for potential users looking to run in situ visualization on the Fugaku and other PowerAPI-enabled HPC systems.

ever-increasing size of the simulation outputs, the in situ visualization has gained increasing attention.In situ visualization uses the same HPC system to execute a part or even the entire visualization processing, and there are currently a variety of tools and libraries, that facilitate domain scientists to integrate them with their simulation codes.Among different approaches, image-and video-based in situ visualization has been widely adopted as an effective approach for the subsequent offline visual analysis.In this approach, a large number of renderings are required at every visualization time step and can consume a considerable computational resource.Fugaku adopted PowerAPI which enables the users to set the power mode for their jobs.However, simulation and visualization codes may have different processing behaviors requiring different power

INTRODUCTION
Visualization is a vital step that is performed by researchers to extract meaningful information from simulation output.With the advancement of technology, specifically high-performance computing (HPC) [8], researchers now can perform larger-scale simulations which leads to the drastic increase of simulation outputs to be visualized.One of the major challenges that needs to be addressed is the I/O bottleneck.Hence, researchers have resorted to in situ visualization [15], which can drastically reduce the I/O data movement while decreasing the storage requirement.In the conventional post-processing methods, the simulation data are written from the memory to disk throughout the simulation, and the visualization only starts after the simulation is complete and requires the data to be read from disk into memory.Thus, the conventional methods can lead to an I/O bottleneck.To overcome this, combining the simulations with in situ processing has been widely recognized as a viable solution.That is, by coupling the visualization code with the simulation codes, the data generated can be processed in memory without being stored in the storage system for subsequent post-hoc visual analysis.
We can verify various techniques and approaches for in situ processing from the proposed terminology for in situ visualization and analysis [14].Among them, tightly-and loosely-coupled approaches are two popular approaches, where the tightly-coupled visualization is performed by embedding the visualization software in the simulation process, allowing the visualization application to share the same resources allocated for the simulation.On both approaches a part or even the entire visualization pipeline [32] is executed on the HPC side.Hence, we focused on the tightly coupled approach in this work, which executes the entire visualization pipeline on the HPC side and stores the rendering images.Although there is no precise ratio between the simulation and visualization in an in situ visualization setting, a range between 10% to 20% is usually heard in the in situ visualization community.That is, the visualization processing will be responsible for consuming not only computational time but more importantly energy.
Due to the dramatic increase in energy prices, issues such as renewable energy and energy security have gained a lot of attention.There is a study on the spillover effects of rising energy prices following the 2022 Russian invasion of Ukraine [46], and it is reported that immediately after the invasion, the energy inflation rate of 20.8% in Japan, which was the highest in 42 years since the oil shock at the end of 70's.Data centers and HPC centers have an infamous reputation for being energy-hungry, and to minimize this problem the EE HPC WG (Energy Efficient HPC Working Group) [2] has actively worked on a more sustainable future.One of the efforts of this community is the Power API [7,19], a community specification for power monitoring and control.The supercomputer Fugaku was co-designed, by RIKEN and Fujitsu, with some energy efficiency functionalities [43], and also supports the Power API functionalities, where the power settings can be set by the users for their jobs, and even be modified during run time.
Kodama et al. [25] evaluated the available four power modes (Normal, Normal Eco, Boost, and Boost Eco) for simulation kernels (computational-bounded and memory-bounded), and observed that the optimal power mode depends on the application.Since the power mode set for the simulation may not match the visualization, in this work, we focused on evaluating the power modes for the visualization processing.Considering the ability of Power API to change the power setting during the job running, in the tightly-coupled visualization, the setting for visualization can also be changed independently of the simulation, thus, it may make both processes more energy efficient as shown in Fig. 1.From the HPC operational side, we should emphasize that opportunities to save energy from the visualization steps should also be taken seriously when adopting in situ visualization.The main contributions of this paper are: • Analysis on the energy consumption side of the visualization processing when running on the HPC system side.• Analysis on energy efficient visual representations that can be used during in situ visualization runs.• Analysis on the shared-memory parallelism available on the Mesa 3D graphics library.
The structure of this paper is organized as follows.The related works are presented in Section 2, while the experimental setup are presented in Section 3. The results of the evaluation are discussed in Section 4, and the summary of our findings, conclusion, and ideas for future works are discussed in Section 5.

BACKGROUND AND RELATED WORKS
Although it is scarce, there already have been some previous works focusing on energy consumption for visualization-related processing on the HPC system side.Labasan et al. [27] analyzed the energy consumption behaviors for eight representative visualization agorithms on an Intel CPU-based HPC system.They analyzed the effects of the power capping mechanism and observed that the power cap has little effect on performance for most of the evaluated rendering algorithms, and the exceptions were particle advection and volume rendering.Their previous work [26] focused on the energy consumption of volume rendering and evaluated the power capping mechanism for proposing an adaptive power scheduling mechanism for optimizing the overall visualization performance.Adhinarayanan et al. [9] analyzed the energy consumption behaviors for traditional post-processing and in situ visualization pipelines on an Intel CPU-based HPC cluster testbed.They observed up to 43% of energy saving when adopting in situ visualization, where most of the saving (91%) comes from reducing the system idle time obtained by reducing the data transfer time.There is also a study by Gamel et al. [18], on the power and performance trade-offs targeting in situ data analytics using the Titan supercomputer.They formulated and analyzed a power/performance model using an Intel CPU-based cluster and extrapolated it onto the Titan supercomputer.In the following paragraphs, we present some related works closely related to this work.
Image-based In Situ Visualization.The image-based in situ visualization approach by applying multiple renderings from different camera positions at every visualization time step was proposed almost a decade ago by Kageyama et al. [23] and Ahrens et al. [10].Although the main concept is similar, the former handles the timevarying rendering results as a movie and uses a custom-developed movie player, currently named 4DStreetView [22], for immersive post-hoc analysis.The latter stores as a traditional CSV (Comma Separated Values)-based database specification and can be analyzed by using different viewers developed by the Cinema Science community [1].Cinema databases can be saved using a spherical camera configuration that can be described by using 2 angles,  and  , that define the view direction as in the spherical coordinate system.Adjusting the  and  will allow the user to see the input from different camera angles.Depending on the camera parameter settings, i.e.  and  on the CINEMA, tens or even hundreds of renderings can be executed at every visualization time step.For instance, Nealey et al. [33] evaluated their web socket tool (cin-ema_transfer) for streaming the Cinema database to a remote site by rendering 36 4K images (3840 × 2160) per time step.There are also some works trying to reduce the final set of rendering images.Marsaglia et al. [29] analyzed user-preferred camera positions and proposed their own information entropy-based Viewpoint Quality (VQ) metrics.They also proposed an automatic in situ camera placement for isosurface rendering [31], and when varying over time [30].Although the final set of rendering images can be reduced, there is still a need to render from different camera positions to select the most important image at every time step.We can also mention an ongoing work [21] to further reduce this amount of renderings by coarsely sampling the best camera positions and by estimating a smooth camera path between them and avoiding the intermediate camera position estimation.
CINEMA.When considering the popular image- [10] or video- [22] based in situ visualization approaches, a considerable number of renderings can be executed at every time step.Although it is not an in situ visualization, ParaView and VisIt implemented the imagebased CINEMA database export functionality as shown in Fig. 2, and in the default settings, ParaView renders 36 images ( =  = 6) and VisIt renders 84 images ( = 12;  = 7) per time step, thus it can greatly influence the amount of visualization processing, and as a result, on energy consumption.For the real CINEMA-based in situ visualization, users can use ParaView Catalyst [13], VisIt Libsim [45], or Kombyne [12] to instrument their simulation codes.
Mesa Graphics Library.OpenGL [5] has widely been used for developing hardware-accelerated 2D and 3D visualization applications.Mesa [3] has been the de facto standard alternative for those systems that do not have graphics hardware (GPU), such as the Fugaku supercomputer and its predecessor K computer.We should mention that there are visualization applications that do not depend on OpenGL, and we can cite the well-known raytracing-based OSPRay [44] and POV-Ray [6].On the K computer, the official visualization library [36] provided by Fujitsu was a non-OpenGL library, and the visualization system (HIVE [37]), developed by the RIKEN, was also a non-OpenGL application.Considering the importance of supporting Mesa for enabling the use of traditional OpenGL-based visualization applications, Mesa library was provided almost at the end of the operation life cycle of the K computer [34].With the change of the CPU hardware architecture from the SPARC to ARM, the Mesa library was provided on the supercomputer Fugaku via Spack package manager [17] since the beginning of its operation.The Mesa version installed on the Fugaku is 22.1.6,and that some classic drivers as well as the Intel OpenSWR rasterizer [38], highly optimized for Intel CPU with AVX (Advanced Vector Extensions), were removed for the mainline code.The Gallium LLVMpipe driver, which uses LLVM for the runtime code generation for the GLSL (OpenGL Shading Language) codes, became the default Mesa driver.The LLVMpipe driver takes advantage of the multi-threading (shared-memory parallelism), and until version 22 it was limited to 16 threads, and from version 23 it was increased to 32 threads.
Volume Rendering.Direct volume rendering [16,28] is a popular rendering technique that appeared almost 35 years ago.A variety of optimizations and extensions have been proposed so far as we can see on the extensive survey made by Sarton et al. [42].In addition to the traditional RayCasting, another volume rendering approach that has been used in Japan is the Particle-Based Volume Rendering (PBVR) [41] proposed almost 15 years ago.It is based on Sabella's volume rendering approach [39], where a set of tiny self-illuminated opaque particles are used for the volume rendering.Since it does not use transparent information during the final rendering processing, its order-independent processing nature makes it highly suitable for distributed processing.The PBVR was found to be the main rendering technique provided by Fujitsu's visualization library for the K computer users.The open-source KVS (Kyoto Visualization System) [40], used in this work, provides the PBVR functionality and can be used on the Fugaku.There is also an open-source In-Situ PBVR framework [24] developed by the Japan Atomic Energy Agency (JAEA) that can also be used on the Fugaku.

EXPERIMENTAL SETUP
One of the main objectives of this work is to better understand the performance and energy consumption of the Mesa-based rendering (used during the in situ visualization) on the Fugaku compute nodes (Fujitsu A64FX CPUs) when using the available four power modes on the Fugaku.We used the Power API available to the Fugaku users, and instrumented some KVS-based rendering applications for setting different power modes (Normal, Normal Eco, Boost, Boost Eco) [25] during the run time to evaluate the energy consumption behavior.Akimoto et al. [11] discussed the difficulties of measuring the power consumption due to the hardware variability, such as transistor characteristics and manufacturing process, and the existence of CPUs with different roles (compute nodes and compute & I/O nodes).Therefore, we tried to use the allocated node (CPU) during the interactive job as long as possible (maximum use period limited to 6 hours) to obtain the necessary measurements for the evaluation and analysis.
For the evaluation of rendering, we used the open-source Kyoto Visualization System (KVS) [40], which has been used for the in situ visualization at the RIKEN R-CCS since the K computer period [35].We evaluated RayCasting, IsoSurface, and Particle-Based Volume Rendering (PBVR), which have been the representative rendering techniques when using KVS-based in situ visualization.In this study, we measured only the rendering portion and ignored the data loading time as well as the image compositing time.For the measurement of energy consumption, we used the node object in the Power API tree, which includes the CPU, Memory, PCI bus, and TOFU interconnect.We also used the wall-clock time (in nanoseconds) measured by the Power API for obtaining the rendering time.We are aware that during parallel rendering, each rendering process will be responsible for a portion of the entire simulation domain as shown in Fig. 3.In addition, the visualization processing time and its energy consumption will also depend on the input data and Figure 5 shows the variations in the rendering time and energy consumption when changing camera-related parameters (viewpoint).Considering that image-based in situ visualization renders a set of images from different viewpoints (camera positions) at every visualization time step, we evaluated by using a pre-defined set of camera positions (12 positions separated at every 30  on the horizontal plane).Due to the non-existence of a default benchmark dataset, in this work, we selected some small-sized volume data to mimic the subdomain during the parallel renderings.We selected five volume data (voxel data) for the measurements, namely CAR, CHEST, BONSAI, OUT, and ENGINE as shown in Tab. 1.A part of the data was obtained from the Open SciVis Dataset repository [4], and another part was obtained from the former RIKEN R-CCS Advanced Visualization Research Team.Considering that numerical simulation results are usually floating point data, we converted  RIKEN R-CCS uses the Spack package manager to provide the applications, libraries, and tools for the Fugaku users.The current version of the Spack installed on the Fugaku is 0.19.0, and within this version, the newest available Mesa 3D graphics library is 22.1.6,which has the maximum number of threads limited to 16 for the LLVMpipe driver.As mentioned in the previous section, its limit was increased to 32 from the version 23, and as such, we used the Mesa 23.1.6for the evaluations.To understand the impact of the multi-threading on the Fujitsu A64FX CPU, which has 48 compute cores, we set the upper limit to 48, that is, by setting LP_MAX_NUM_THREADS=48.
Thus, for the evaluation, we instrumented three KVS-based rendering applications (RayCasting, PBVR, and Isosurface) with Pow-erAPI, available to the Fugaku, in order to evaluate the performance and energy consumption in the rendering process on the Fugaku supercomputer.We used the extension attribute (PWR_ATTR _MEASURED_ENERGY ) available to the Fugaku compute nodes (A64FX CPUs) to obtain the measured energy consumption.This was done by setting the extended PowerAPI context parameter type (PWR_CNTXT_FX1000) available on the Fugaku.We used the Fujitsu compiler to build the rendering application as shown below, and used GCC (GNU Compiler Collection) for building the Mesa We used the following four power modes to evaluate energy consumption by changing the modes during the evaluation run time.For this purpose, we used the PWR_ObjAttrSetValue function to set the operational frequency of the CPU, and used the PWR_GrpAttrSetValue to set or unset the eco mode for the compute cores.We used the PWR_ObjAttrGetValue function to obtain the measured energy in Joules (W.s) as well as the wall-clock time (ns) between two measurement points, that is, before and end of the rendering.

• Power modes
-Normal runs at 2.0 GHz without eco mode.
-Normal eco runs at 2.0 GHz with eco mode.
-Boost runs at 2.2 GHz without eco mode.
-Boost eco runs at 2.2 GHz with eco mode.
For the rendering, we used a pre-defined transfer function (Brewer Spectral [20]), and a pre-defined image size of 512 × 512.There is no strong reason for this selection, and any other color mapping and image size could be selected.We used the default setup for Ray-Casting (defined by the KVS), and used different repetition values for the PBVR to evaluate its energy consumption behavior and to understand the potential of PBVR as an energy-efficient alternative for RayCasting.These aforementioned rendering methods use 3D Texture or VAO (Vertex Array Object) for storing the input data for subsequent rendering by using GLSL shaders.The 3D texture is used for RayCasting, and the VOA is used for PBVR and Isosurface rendering.The stored data is then rendered by using GLSL shaders.We also used different isovalues for the isosurface rendering to evaluate its behavior.For all the measurements, we rendered 12 images one time from different camera positions separated by 30  on the horizontal plane around the rendering target.

RESULTS AND DISCUSSION
In this section, we will present and discuss the obtained results of the performance and energy consumption when using the three rendering methods (RayCasting, Isosurface, and PBVR) to the five volume data (CAR, CHEST, BONSAI, OUT, and ENGINE).We varied the number of LLVMpipe driver's threads for RayCasting, isolevels for Isosurface, and the number of repetitions in PBVR to observe the power consumption and performance during the rendering processes of these data.Apart from that, four different power modes (Normal, Normal Eco, Boost, and Boost Eco) are also evaluated to find the most energy-efficient power mode and best the performance of the rendering process.The lowest rendering energy and rendering performance are highlighted in each table, and the tradeoffs are calculated to provide insights on the gains and losses in the performance in search for the best energy-efficient power mode.
4.0.1 RayCasting.We evaluated the rendering time and energy consumption for the five input data and the obtained results are tabulated in Tab. 2 and in Tab. 3 .All the input volume data are evaluated using 16 and 32 threads (LP_NUM_THREADS).Fig. 7 shows some example images that were rendered by using this method.Table 2. shows the Raycasting rendering performance using different number of threads for the Mesa graphics library, via _ _  environment variable.We can clearly observe that the Boost mode gives the best performance among all measurements.However, the Normal mode is shown as the optimal energy-efficient power mode for RayCasting rendering for most of the data.We can also see in Tab. 3, that the rendering energy when using 16 and 32, as the number of threads for the Mesa library, differs up to 3.7%, which can be considered small.Although the normal mode can lead to a reduction in performance from 12.9% to 15.2%, considering the energy consumption, this mode should be seriously considered as the power mode to be used.Normal Eco mode, however, shows the highest energy consumption among all power modes and has the worst performance.Even though Normal Eco mode is expected to be the best practice for energy-efficient visualization processes, this finding shows otherwise.We are aware that the computational time of RayCasting highly depends on the utilized transfer function (color and opacity), which can influence the amount of data that can be skipped or early terminate the computational of certain rays.Therefore, the gains observed in Tab. 3 will vary when applying other visualization parameters.However, since we can clearly observe that even when using the same visualization parameters, the rendering energy can vary highly using different numbers of threads, and thus the users should be aware of this parameter for energy efficiency.4.0.2Isosurface.We also rendered the five volume data by using the Isosurface method.In this method, the isosurface from a predefined isovalue is previously extracted as polygonal data, and this extracted data is rendered.We selected three isovalues (0.05, 0.1, and 0.2), and Fig. 8 shows the isosurface obtained by using these isovalues.As we can see in this figure, as the isolevel changes, the amount of polygonal surface changes, thus expected to directly influence the computational cost.We are aware that the isolevel that is chosen for isosurface rendering is vital to generate high-quality outputs and allow the users to obtain useful information from the rendered images.In addition, the optimum isovalue highly depends on what the user is trying to visualize in the data, and sometimes it can be obtained via the traditional trial-and-error process.For simple evaluation purposes, we applied this set of isovalues (0.05, 0.1, and 0.2) for the five volume data.The isosurface rendering time and its corresponding energy consumption are presented in Tab. 4 and 5.The isosurface rendering cost is usually proportional to the amount of polygons present in the extracted isosurface.Therefore, in BONSAI and OUT data, the increase in the selected isolevel range greatly decreased the amount of extracted polygons, and a large decrement in power consumption is observed, between 330.4-390.0%and 159.4-175.3%,respectively.In other data, the rendering energy is found to decrease from 2.2 to 34.5%.We could confirm in practice that selecting isolevels that bring to a small number of polygons can largely assist the low energy consumption.Different power modes were also used to run the isosurface rendering.In contrast to the RayCasting, the power mode that shows the least rendering energy is Boost Eco mode in all tests.Hence, Boost Eco mode shall become the power mode of choice to perform high energy savings visualization.However, in terms of performance, Boost Eco mode shows slower performance compared to Boost mode, which is the power mode with the best performance in all tests.The reduction of 5.3% to 6.6% can be observed compared to the Boost mode.Even so, the tradeoff between the performance and the power consumption is small, and Boost Eco mode will be a good option to carry out an energy-aware Isosurface rendering process.As mentioned before, we practically confirm that the number of extracted polygonal data in the isosurface will greatly influence energy consumption, and if a simple isosurface is sufficient for obtaining important information from the data, the isosurface can become the energy-efficient visualization method to choose.4.0.3PBVR.This rendering method works by previously extracting a set of tiny particles to be used for the rendering.A user-defined number of repetitions is used for the particle generations, and the ensemble averaging is applied to the set of partially generated images from the particle sets.Fig. 9 shows the PBVR-based volume rendering results of ENGINE data by using the number of repetitions of 3, 4, 5, and 10.As we can see in this figure, clearer and less noisy images are generated as the number of repetitions increases.Thus, we acknowledge the need for higher repetition to render better images for more effective visualization.Tables 6 and 7 show the PBVR-based volume rendering performance and energy consumption when using repetitions of 3, 4, 5, and 10.Similar to the isosurface rendering, the amount of previously extracted (tiny opaque particles in the case of PBVR) is expected to influence the rendering process, and we could confirm this in practice.Increasing repetition from 3 to 10 shows huge increases in power consumption, from 151.0% to 523.0%.The increase in rendering energy is also accompanied by the huge increase in rendering time, which is from 139.4% up to 523.2%.All tests show that Boost is the most energy-efficient power mode.This mode also shows the best performance among other power modes, making it a good choice for PBVR.The energy-efficient rendering process can be employed in PBVR without having any tradeoff in term of performance.These findings are important since Fugaku users have been requested to avoid the use of Boost mode in an attempt to reduce the overall power consumption of Fugaku.Although Boost  mode is the most power-consuming among all modes, the reduction in the computational time can result in a small energy consumption penalty while gaining in the rendering performance.
For PBVR, the quality of the images can surely be increased with the increase of repetition.However, a higher number of repetitions can lead to higher rendering time and energy consumption as well.Therefore, the user needs to find a good tradeoff between the number of repetitions to be selected and the energy that will be consumed throughout the process.Comparing it with the RayCasting, PBVR using 10 repetitions shows much lower energy consumption compared to 32-thread RayCasting in almost all tests.A tremendous reductions in energy consumption can be observed, which is from 43.0% up to 538.6%.The RayCasting only shows small reduction compared to PBVR in ENGINE data.However, the reduction is between 3.8% to 11.2%, which is considered small.Thus, we observed that the energy consumption can be lowered by choosing PBVR instead of RayCasting if there are not much requirements for the image quality, such as during test runs and parameter sweep job running, as some examples.

CONCLUSION
In this paper, we investigated the computational cost and energy consumption of the rendering portion when considering the tightlycoupled in situ simulation and visualization sharing the same HPC system resources.Based on our evaluations, Boost mode is found to be the best choice in RayCasting and PBVR rendering methods.For Isosurface, Boost Eco mode is found to be a good choice as it offers only a small tradeoff in performance, compared to Boost mode.However, Fugaku users may have limitations in using Boost in some instances.Thus, the second most energy-efficient power mode can be selected, with the tradeoffs in performance in mind.As previously stated, the optimal power mode may depend on the behavior of the simulation code, we could observe that the optimum power mode for the visualization portion will greatly depend on the utilized rendering technique as well as the visualization-related parameters such as the image size and camera positions.We could also observe a considerable variation in energy consumption, as a gain or as an overhead, when changing the visualization methods as well as their inherent parameters.For instance, when the users are not looking for the best rendering image, they could select an energy-efficient alternative for the renderings.With the increasing recognition and adoption of in situ visualization, users are expected to be more of the energy consumption of the visualization portion, and we hope that the findings in this work will be useful for those users using in situ visualization on PowerAPI-enabled HPC systems such as the Fugaku.For future works, we aim to expand this study to the entire visualization pipeline as well as in the combination of the simulation.Considering that the PowerAPI can change the power mode during run time, we are also considering working on an adaptive approach for selecting the power modes based on the rendering method and visualization parameters.

Figure 2 :
Figure 2: Cinema database export functionality available on the ParaView and VisIt visualization applications (running on the Fugaku Pre/Post Environment [x86/GPU] and accessed via Fugaku OpenOnDemand Service)

Figure 3 :
Figure 3: KVS-based parallel isosurface rendering of a CFD simulation result (OUT Data) subdivided into 8 domains (right side).The eight sub-images are merged (via parallel image composition) to reconstruct the final image (left side).

Figure 4 :
Figure4: RayCasting volume rendering time, when using Normal power mode, of OUT data when using different image sizes (left side), and when rendering each of the eight subdomains of OUT data as shown in Fig.3).

Figure 5 :
Figure 5: Influence of the camera-related parameter (viewpoint) on the rendering time and energy consumption library and LLVM compiler (required for the LLVMpipe driver) without using the Spack package manager.• Fujitsu Compiler 4.9.0 -KVS 3.0.0• GNU Compiler Collection 8.5.0 -Mesa 23.1.6-LLVM 13.0.1

Figure 6 :
Figure 6: Histogram of the scalar data distribution for the input dataset.

Figure 7 :
Figure 7: Some RayCasting volume rendering results for the CHEST (above) and CAR (below) data.

Figure 8 :
Figure 8: Isosurface rendering of the BONSAI data by applying different isolevels.From the left, the isolevels are 0.05, 0.1, and 0.2

Figure 9 :
Figure 9: PBVR-based volume rendering of ENGINE data using different repetitions.From the left, the repetitions are 3, 4, 5, and 10

Table 1 :
Input data (scalar volume data) utilized in the evaluations.

Table 2 :
Performance of RayCasting rendering on different data using different numbers of threads(16 and 32).

Table 3 :
Energy consumption of RayCasting rendering on different data using different numbers of threads(16 and 32).

Table 4 :
Performance of Isosurface rendering for different isolevels (when using 32 threads).

Table 5 :
Energy consumption of Isosurface rendering for different isolevels (when using 32 threads).

Table 6 :
Performance of PBVR using different number of repetitions (and 32 threads).

Table 7 :
Energy consumption of PBVR using different number of repetitions (and 32 threads).