Since our first formal product releases of OSPRay and OpenSWR libraries in 2016, CPU-based Software Defined Visualization (SDVis) has achieved wide-spread adoption. This rapid uptake is the result of two factors: (1) the general availability of highly-optimized CPU-based rendering software such as the open-source OSPRay ray tracing library and the high performance OpenSWR raster library in Mesa3d  integrated into popular visualization tools like Kitware’s Paraview and VTK, as well as the community tool, VisIt; and (2) SDVis filling the big data visualization community need for software that uses runtime visualization algorithms that can handle giga-scale and larger data.

These technologies aim to enable production visualization at scale on high performance computing resources, including supercomputers at Argonne National Laboratory, Los Alamos National Laboratory, the Texas Advanced Computing Center and many other facilities.

Award winning results, such as the Best Visualization and Data Analytics Showcase award won by the Los Alamos’ Data Science at Scale Team at Supercomputing 2016, highlight the fact that CPU-based rendering is now at the forefront of visualization technology. The LANL team’s award winning asteroid impact visualization is featured as an LANL newsroom picture of the week.

Dr. Aaron Knoll (Research Scientist, Scientific Computing and Imaging Institute at the University of Utah) explains that the key change from last year lies in how much OSPRay and other SDVis CPU-based visualization libraries are now being used. “2016 is the year OSPRay became used in practice and production,” he said.

This trend has occurred throughout the scientific community. For example, four out of six finalists at Supercomputing 2016 used OSPRay and/or OpenSWR for their CPU-based visualizations. Of the remaining two finalists, one expressed interest in VMD rendering using OSPRay (now supported by that package), and the other used purely information visualization techniques outside the scope of OSPRay and SWR. Knoll also observed that about half of the non-finalists – at least 50 percent – used OSPRay or CPU-based visualization in some fashion. “Before,” he said, “people knew that OSPRay existed – now they just use it by default in production.”  So, unlike 2015, CPU-based visualizations are no longer a contrary view.

An exascale requirement

The idea behind SDVis is that larger data sets imply higher resolution (and therefore quality) that is too big for typical GPU memory. Focusing directly on the needs of large scale visualization rather than first targeting gaming means that SDVis software components can be designed to utilize massive-memory hardware and algorithms that scale as needed across the nodes in a cluster or inside a computational cloud.

Massive data poses a problem as it simply becomes impractical from a runtime point of view to move it around or keep multiple copies. It just takes too much time and memory capacity. This makes in-situ visualization (which minimizes data movement by running the visualization and simulation software on the same hardware) a “must-have.”  As I like to say, “A picture is worth an Exabyte”.

Eliminating data movement with in-situ visualization is a hot topic in the scientific literature and is now viewed by experts as a technology requirement for visualization in the exascale era. The paper “An Image-based Approach to Extreme Scale In Situ Visualization and Analysis” by James Ahrens et al. quantifies the data movement challenge as follows: “Imagery is on the order of 10**6 in size, whereas extreme scale simulation data is on the order of 10**15 in size.” Nine orders of magnitude is significant.

Ahrens explained, “We believe very strongly that in-situ is a requirement for exascale supercomputing.” More specifically, “For exascale, we need to be portable across all platforms. It’s an IO and memory capacity issue.” Knoll agrees that in-situ visualization is a requirement, “the old way of business has to change.”

Managing success: CPU-based SDVis robustly encompasses new algorithmic and software approaches

Dr. Knoll points out that in-situ visualization encompasses a spectrum of technologies, not just software alone. He references the 3D XPoint and Intel Omni-Path architecture. Jointly developed by Micron and Intel, 3D XPoint is a non-volatile storage media that can be used as storage or to augment main memory as the media is byte-addressable. Intel Omni-Path is a high-bandwidth, low-latency communications architecture created by Intel to increase performance and decrease cost.

“Memory is key,” Knoll stresses. He points out that, “An Intel Xeon Phi processor can support up to 24x more DRAM than an equivalent single GPU (NVIDIA Tesla P100 with 16 GB RAM), and an Intel Xeon workstations (e.g., the Brickland-EX platform with 6 TB) up to 384x more. With 3D XPoint the cost of this ‘memory’ will decrease substantially, which goes hand in hand with the benefits of big data runtime algorithms where it does not cost substantially more to access (and render) 6 TB or data than 16 GB of data.”

Knoll envisions 3D XPoint working as an in-core file-system at scale that blurs the line between RDMA, in-situ visualization, and distributed file-systems. One example is the CORAL project that, “leverages Intel Crystal Ridge [now known as 3D XPoint] non-volatile memory technology that is configured in DDR4 compatible DIMM form factor with processor load/store access semantics on CORAL point design compute nodes. This software design will allow applications running on any CORAL point design compute node to have a global view of and global access to Crystal Ridge that is on other compute nodes.”

“This technology gets me very excited,” Knoll says, noting the importance of the communications fabrics in making fast distributed memory a reality.

Focusing visualization solutions on data size rather than gaming usage means that SDVis software components can be designed to utilize massive-memory hardware and scale as needed across the nodes in a cluster or inside a computational cloud. This frees developers to design for the user rather than the hardware.

The transition from OpenGL targeted hardware rasterization to CPU-based rendering means that algorithm designers can exploit large memory (100’s of GBs or larger) visualization nodes to create logarithmic runtime algorithms.

Dr. Knoll stresses the importance of logarithmic runtime algorithms (a subtle but key technical point) as users are faced with orders of magnitude increases in data sizes on the big supercomputers. Logarithmic runtime algorithms are important for big visualizations and exascale computing as the runtime increases slowly (e.g. logarithmically) even when data sizes increase by orders of magnitude. Such algorithms tend to consume large amounts of in-core memory to hold the data and associated data structures. Thus memory capacity and latency are two key hardware metrics.

Research at the University of Utah [PDF] shows a single large memory (3 terabyte) workstation can deliver competitive and even superior interactive rendering performance compared to a 128-node GPU cluster; this is paradigm-changing. The group is exploring in-situ visualization using P-k-d trees and other fast, in-core approaches [PDF]. This project at the University of Utah showed that large “direct” in-core techniques are not only viable, but are at the bleeding edge of visualization research.

Our design efforts on OSPRay includes the recognition that our software cannot – and does not – exist in a vacuum. The challenge is to provide sufficient modularity so researchers can adapt the package without having to touch the golden build source code. In other words, OSPRay is designed so researchers can explore new approaches without breaking the code for everyone. Our solution was to extend OSPRay with the aptly named ‘modules’ capability, which first appeared in v1.2.0. In using modules, the University of Utah team notes that modules provide a logical pairing between algorithm and data where researchers can: (1) write a module and (2) pair it with distributed parallel data processing and rendering API such as the Argonne vl3 volume rendering library. Ultimately, this can allow simpler workflows and more efficient visualization of specific large problems, such as materials and cosmology data. By design, successful and widely-utilized modules can be evaluated by the OSPRay team across a number of platforms as possible additions to the main body of the OSPRay code. Such accessibility and portability across CPU platforms highlights the adaptable yet robust characteristics of SDVis software.

Education will likely increase the rate of adoption

The adoption rate over the past year has been phenomenal, but we expect it to increase even further. As Dr. Knoll stated, “2016 is the year OSPRay became used in practice and production.” As a production visualization tool for scientific computing, OSPRay and more generically CPU-based SDVis has clearly come of age. Integration into packages such as ParaView and VisIt has made CPU-based rendering mainstream, which in turn means that using a CPU for visualization can no longer be considered a contrary viewpoint; it’s becoming the norm.

It is expected that education will likely increase the rate of adoption. A number of excellent educational resources are available online. For example, view the 2016 Intel HPC Developer software visualization track videos to delve more deeply into the technology and third-party use cases. Of course, hands-on experience and interacting with peers is always of value. Such interactions can be had at the IXPUG May 2017 Visualization workshop at the Texas Advanced Computing Center. Immediate hands-on experience can also be had simply by working with VisIt and ParaView, or downloading the OSPRay code from github and the OpenSWR code via the Mesa3D website.  Further background and up to date information about Software Defined Visualization is available at our IDZ (Intel Developer Zone) SDVis landing page., and in Chapter 17 of my Morgan Kaufman published book Intel Xeon Phi High Performance Programming: Knights Landing Edition.

To utilize CPU-based SDVis in your software, look to the following packages: (1) the OSPRay scalable, and portable ray tracing engine; (2) the Embree library of high-performance ray-tracing kernels; and (3) OpenSWR, a drop-in OpenGL replacement, highly scalable, CPU-based software rasterizer all provide core functionality for current SDV applications.

About the Author

Jim Jeffers is a Principal Engineer and engineering leader at Intel who is passionate about world changing technology as well as author and industry expert on parallel computing hardware.