Greetings, developers. My name is David DeMarle and I am a developer at Kitware. I’d like to discuss some of the work we’ve been doing recently with Intel and the Texas Advanced Computing Center (TACC). Kitware is a software consulting company that primarily develops open source technologies. CMake* is our best-known product, but I work on our original product The Visualization Toolkit* (VTK) and a scalable application built on VTK called ParaView*. ParaView runs on some of the largest supercomputers in the world, including those at TACC, where scientists use it to look at and analyze spatially organized data. The work we’ve been doing is improving VTK and ParaView’s rendering subsystem by incorporating Intel’s OpenSWR rasterizer and OSPRay ray tracer, both part of Software Defined Visualization (SDVis) that is available to the public, to draw better-looking pictures more quickly.
First let’s talk about rasterization.
For many years VTK has used OpenGL* and thus rasterization almost exclusively to draw pictures. We’ve never been particularly picky about what specific OpenGL implementation we need; as long as it supported the circa 1997 version 1.1 API, we were good. On machines with graphics cards we could use the vendor drivers. On other machines, including most supercomputers, we used Mesa*. That situation was adequate, but graphics and compute capabilities grew tremendously and Mesa, which wasn’t highly threaded, and more so the 1.1 API, hobbled us.
Fortunately, thanks to the National Institutes of Health’s grant R01EB014955 for Accelerating Community-Driven Medical Innovation with VTK, we were able to rewrite VTK’s OpenGL code to use modern OpenGL practices and in the process improve VTK’s rendering rate in some cases by a factor of more than 100. Meanwhile the SDVIS team at Intel chose to improve Mesa and so they created OpenSWR, “the software rasterizer.” OpenSWR was built to take full advantage of the parallelism (both threading and vectorization) on modern CPUs in the rendering pipeline. For the type of data we tend to draw with VTK, OpenSWR is tens of times faster than Mesa’s own llvmpipe software renderer.
As Intel developed OpenSWR, Kitware collaborated with them, such as assisting with the task of using VTK’s regression tests to prove out the feature set of OpenSWR. Starting with ParaView 5.0 we began to include OpenSWR with our Linux* binaries, which proved especially useful on desktop systems that did not provide a recent enough version of OpenGL for our new code base. Later Intel did a wonderful thing and worked with the Mesa developers to upstream OpenSWR into Mesa itself. Starting in version 12.0.0 OpenSWR is now a back-end that everyone who uses Mesa can use.
At Kitware we’ve had great success with OpenSWR on some large systems where our customers run it daily. We demonstrated a 1.1 trillion triangle benchmark session on the Trinity* supercomputer at Los Alamos National Laboratory in the open science period before the machine was switched over to classified use. For that run we used only a fraction of the machine and can estimate that the entire machine is capable of drawing up to 20 trillion triangles, rendering at a few seconds per frame.
Now let’s talk about ray tracing.
While the above updates were happening, Intel was also working on a very fast ray tracing engine called OSPRay. Like OpenSWR, OSPRay takes advantage of both threading and vectorization to render images very quickly. As a ray tracer it also has built-in support for visual effects like translucency and reflectivity, which are not straightforward to achieve with rasterization in a complex system like VTK.
TACC took the lead here and developed a plug-in for ParaView 4.4 that acted as an interface between ParaView and OSPRay. This plug-in successfully demonstrated the potential benefits of ray tracing for general-purpose scientific visualization. Beside the aforementioned aesthetics, the ray tracing algorithm’s insensitivity to data size (frequently only a fraction of the scene is ever visited in making an image) is quite useful in extreme scale visualization problems. With OSPRay we found that the scene setup time (also parallelized) was finally fast enough to make the system usable in practice.
Eventually Kitware, TACC, and Intel worked to improve the interface between ParaView and OSPRay and promote it from ParaView to VTK. For details, refer to this article published in the Kitware Source magazine. At the VTK level it is more easily usable in applications besides ParaView. This incarnation first appeared in ParaView 5.1 and will appear in VTK 7.1.
Now let’s talk about the future.
While I’ve mostly been involved in developing the OSPRay interface, I will say that we expect to continue to benefit from OpenSWR on large-scale supercomputers without GPUs. Especially on systems with Intel® Xeon Phi™ processors, ParaView’s Catalyst incarnation (a version of ParaView’s server-side library that is linked directly into simulation codes for in situ processing) will greatly benefit from OpenSWR.
With OSPRay, where we have an entirely new rendering algorithm backing ParaView, there is more potential for disruptive change. We have a few minor items left on our to-do list. First, we’ve just brought back OSPRay volume rendering to ParaView and are working on progressive refinement. Then the real fun starts when we bring in the path tracer. For the majority of users who do not use VTK on extreme-scale supercomputers, the aesthetic benefits of the path tracer are probably more exciting than speed. With the path tracer we get to extend VTK with new light and material types and provide controls for the end user to place them into the scene to make great-looking images. Even physical scientists will have uses for some of the things we’ll be able to show with expanded material types.
Kitware, TACC, and Intel have collaborated quite successfully. In a short time we’ve made advances in the field of open source scientific visualization. Both OpenSWR and OSPRay have been tested now by many of Kitware’s customers, and feedback has been positive. We already have a list of feature requests, particularly for the ray tracer, which is great for Kitware since this is how we earn our keep as an open source software consulting company, and it’s how we all keep pushing the boundaries of open source software forward.
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804