BuildingANARI

Instructions for how to build ANARI on Linux. This is the basic ANARI, independent of VR capabilities, which will be documented separately.

Building ANARI on Linux

The generic ANARI SDK has minimal system requirements to build. However, for the GPU-accelerated backends, there generally will be additional required features (such as Cuda or Optix).

When building ANARI, there is a choice between downloading/cloning the reference ANARI-SDK, and separately obtaining the GPU accelerated backends, or it is possible to download the pseudo-Superbuild that will download selected backends, and do a complete build.

This documentation last tested with ANARI-SDK version 0.10.1.

Prerequisites

ANARI makes use of the CMake build system. You should have at least version 3.11 of CMake.

Cloning ANARI

Clone from the Khronos Github ANARI reposoitory.

NOTE: Because ANARI is still in flux, I always add the current date (YYYYMMDD) and Version as a postfix of my cloned directory name.

% git clone -b next_release --single-branch https://github.com/KhronosGroup/ANARI-SDK.git anari-sdk-<date>nr

or for the master branch:

% git clone https://github.com/KhronosGroup/ANARI-SDK.git

Configuring the Build and Installing

Configuring and compiling the build:

% module load optix cuda jpeg-turbo tbb
% mkdir ANARI-SDK/Build
% cd ANARI-SDK/Build
% cmake -DCMAKE_INSTALL_PREFIX=... -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_CTS:BOOL=OFF -DBUILD_TESTING:BOOL=OFF -DBUILD_REMOTE_DEVICE:BOOL=ON -DINSTALL_VIEWER:BOOL=ON ..
% make
% make install

Running ANARI

The ANARI build process includes a simple tutorial application that will render a scene consisting of a pair of triangles into two image files (one with the first pass of the render, and one with a later pass). An optional "anariViewer" may also be built (and the above instructions will build it) which contains a handful of reference scenes, along with an OBJ viewer.

Running the ANARI backend info tool

% ./anariInfo -l helide

This will then output a slew of information about the backend, including what version of ANARI it was built for, and what Parameters and Extensions it handles. In some respect, it can be considered a quick summary of the ANARI specification, insofar as how that particular library implements the spec.

Running the ANARI tutorial example

Note that the "anariTutorial" executable (without code changes) will always use the helide backend.

% ./anariTutorial
% display *.ppm

Running the ANARI viewer example

The choice of ANARI backend for anarViewer is controlled by the ANARI_LIBRARY environment variable

% export ANARI_LIBRARY=helide
% ./anariViewer

Build/Install additional ANARI backends

Once the base ANARI SDK is built, additional backends can be compiled and added to the overall ANARI installation.

Some of the available backends include:

• The "helide" backend, which is a basic CPU-based rendered, compiled with ANARI
• OSPRay
• VisRTX / VisGL (see below)
• Barney ANARI backend (BANARI)
• Visionaray ANARI backend
• The "remote" rendering backend (see below)
• The "OSD" backend
• The "debug" backend, which is a pass-through backend that does extra sanity checking
• The "sink" backend, which is a NULL-renderer for testing

VisRTX & VisGL ANARI backends (building/installing)

% module load optix cuda anari
% git clone -b next_release --single-branch https://github.com/NVIDIA/VisRTX visrtx2_version
% mkdir visrtx2_version/Build
% cd visrtx2_version/Build
% cmake .. -DCMAKE_INSTALL_PREFIX=$ANARI_DIR(<same-as-ANARI-base>) -DCMAKE_BUILD_TYPE:STRING=Release
% make
% make install

Then:

% export ANARI_LIBRARY=visrtx
% anariViewer

Building/using the "remote" ANARI backend

The remote ANARI backend allows an application to be rendered on one computer but displayed on another. Unlike some remote graphics viewers that require the data to be on the remote computer, for the ANARI remote backend operates such that all the graphical data be first sent from the local computer to the remote computer before rendering.

Note that there are a couple additional system package dependency required to compile the remote backend:

• The Boost "system" package
• JPEG-turbo
• Snappy — the libsnappy.so library may exist without the package, but on Rocky-8, I've found that the "SnappyConfig.cmake" file has an error (the details of which are too gory to post here).

And to build you must add to the cmake (or ccmake operation:

• BUILD_REMOTE_DEVICE=ON

And that works best when jpeg-turbo and snappy can be found.

NOTE: a word of caution (at least for Rocky-8/Centos-8), the "Snappy" package has an error in the ".cmake" file that can be overcome, but it's a bit of a hassle.

NOTE: a second word of caution when building the remote-server — you may have to add -lboost_system to the link.txt file for anariRemoteServer.

Running on the remote server

To use the remote server:

• On the remote computer:

  % ANARI_LIBRARY=helide anariRemoteServer [--port <number>]

  (or whatever backend you want to use in place of helide)

• on the local computer:

  % export ANARI_REMOTE_SERVER_HOSTNAME=<remost-host>

  % export ANARI_REMOTE_SERVER_PORT=31050

  % export ANARI_LIBRARY=remote

  % anariViewer

  (or whatever application you want to run)

Tunneling to the remote computer

Sometimes firewalls can make it difficult to access non-standard ports on organizational computing systems. The general solution to this is to use ssh-tunneling, whereby a local port becomes an access point to a port on the remote computer. Of course in this case, when setting the hostname that should now point to localhost since that is now where the port can be found.

% ssh -L 31050:localhost:31050 <remote-host>

Suggestions for improving ANARI

I have a few things that I need to pass along to the ANARI working group that could/should be fixed in future versions -- especially by the time we get to SDK version 1.0.0.

• anariViewer should have a command-line-argument (and/or interactive widget) to set the samples-per-pixel and unit-distance values.
• anariTutorial should honor the ANARI_LIBRARY flag.
• Running anariInfo -l visgl shouldn't seg-fault
• Running anariInfo -l <non-existant backend> shouldn't seg-fault
• When running anariInfo -l visrtx there appear to be some spaces in parameter names that are bugs — e.g. " transform" & " transferFunction1D"
  • Probably anariInfo should put quotes around subtype and parameter names to make these errors more obvious

Other issues that I am personally experiencing

• My ANARI-VR test programs render incorrectly when running with the visgl backend
• My ANARI-VR test program (anari_ex8) crashes when running with the any backend
• There is some code in the installed share/anari directory that I'm not sure what it does/is-for
• The "SnappyConfig.cmake" file on Rocky-8 has an error, so I had to copy that file to where I could edit it and correct the path to the library file
• Sometimes when doing a parallel make -j 8 I get an error in the build process, but a single-threaded make works fine.

ANARI Applications

Here are some other applications that are using ANARI:

• VTK
  • vtkAnariPass Class
  • Amstutz' VTK ANARI examples (C++ & Trame)
• ParaView
  • Building ParaView with ANARI support (Discourse conversation)
  • Dynamic GUI for ANARI devices (Discourse conversation)
• ANARI Volume Viewer (on Github.com)
• VTK-m Graph tool
  • Uses: VTK-m