Standardized Data-Parallel Rendering Using ANARI

TL;DR

The paper addresses the gap between the ANARI API, which is not inherently data-parallel, and the needs of large-scale sci-vis rendering that benefits from global shading and path-traced effects. It proposes DP-ANARI, a semantics-based extension that keeps the existing API surface while introducing distributed meaning for objects, frames, and synchronization, enabling true data-parallel rendering across ranks. Two prototype back-ends—ANARI-Composite (compositing-based) and BANARI/Barney (true data-parallel path tracing)—demonstrate the spectrum of capabilities and trade-offs, complemented by multiple integrations into mini-apps and established vis tools (ParaView, Ascent, VisItLibSim, VTK). The contributions include formalizing object locality, synchronization semantics, and practical integration patterns, along with proof-of-concept devices and usage scenarios that show improved global effects and rendering quality at scale. Collectively, the work lays groundwork for broader adoption by illustrating a feasible path toward standardized data-parallel rendering within ANARI and a viable collaboration between app developers and device implementers.

Abstract

We propose and discuss a paradigm that allows for expressing \emph{data-parallel} rendering with the classically non-parallel ANARI API. We propose this as a new standard for data-parallel sci-vis rendering, describe two different implementations of this paradigm, and use multiple sample integrations into existing apps to show how easy it is to adopt this paradigm, and what can be gained from doing so.

Figures (7)

• Figure 1: Illustration of how a typical data-parallel vis app would use our paradigm (also see \ref{['sec:illustration']}).
• Figure 2: Screenshots from our prototypical integrations of our DP-ANARI paradigm into VisIt/Libsim and ParaView. a) VisIt/Libsim data set generated by a mini-simulation used to test VisIt's in-situ capabilities, running on 8 ranks and using our data-parallel ANARI integration (see \ref{['sec:libsim']}). b) ParaView rendering the $1,225\times 580\times 2,000\times$-1floataircraft model with Q-criterion vortex field (see \ref{['sec:paraview']}). This case was rendered with BANARI on 4 ranks of 1 GPU each. c) ParaView rendering an iso-surface extracted from a $2\times$ reduced version of the DNS data set. d) ParaView rendering the $2,501\times 3,001\times 305\times$-1floatthunderstorm data set, in this case rendered with BANARI on 4 ranks of 1 GPU each (using Barney's volumetric path tracing mode).
• Figure 3: Some images from our ASCENT integration, used on two different HPC simulation codes and data sets (rendered using BANARI).
• Figure 4: Examples of our paradigm on traditional---i.e., not data parallel---applications: a) a stand alone ANARI-based viewer (in this case, using BANARI). b) -1blender, using -1ptc/visionaray. Though our paradigm does enable data-parallel path tracing, it does not change anything for traditional, non-parallel apps, which can therefore use our DP-enabled devices without any changes.
• Figure 5: Capabilities and limitations of compositing: A test case of $4^3$ boxes pseudo-randomly interleaved across 4 ranks. Left, rendered with the pass-through compositing (PTC) device, compositing images from another ANARI device that does not know that other ranks (or their data) even exist. Our ANARI PTC device can properly z-composite these images, but cannot create (global) shadows. Middle, the same data-parallel application using a natively data-parallel ANARI device (Barney, in this case), with proper global shading effects. Right: difference images generated with FLIP. Bottom row: similar experiment, conducted with the -1DNS data set in ParaView.