Realease Bundles (for java integration)

[Eclesia]

Hello, (and likely hello again jeffamstutz)

Opening an issue here too on the same line as :

• Java implementation or bindings ?
• A default GL engine ?

Would it be possible to have the CI to make some basic static builds and have those artifacts as part of each release ?
To have the visrtx and visgl anari backends ready to be embedded in Java applications ?

Thanks,

Johann Sorel

[jeffamstutz]

This is something I've thought about for a bit, but I haven't moved on yet because OptiX headers are not easily available to fetch in CI. I suppose VisGL could still be done, which is a matter of enabling a build job with the right dependencies. I'm not sure how much work it will be to get it working on Windows, but I think Linux should be a matter of installing the right packages with apt.

Is the goal to statically link the devices? I'm not sure the ramifications of a statically linked ANARI front end library with a separately statically linked device library -- that may be a road block if you want to do everything static. If that does incur link issues, you may have to do the build/linking yourself...we shall see.

[Eclesia]

I understand it's not an easy task to make something more or less portable with C. It's one of the reasons java dev try to avoid native code as much as possible, it doesn't fit well. We have a CI to build a few C libs but it's a lot of work to keep up to date for just one build every one or two years.

It's going to change a lot in the coming years because of Panama which allows us to bind with native code without writing any native code and also share/manage the memory space. It makes everything better,simpler and without overheap.

I've try to build Visrtx and also Ospray but failed miserably, some libs too old or missing on my distro, no admin rights for some actions. It ends with a very long list of libs to build at the right version, then configure all the variables right .... it's really frustrating. :(
I really tried hard before asking....

C/C++ projects should adopt a friendly build tool like Rust with Cargo or Java with Maven or Gradle or Ivy.

To give a bit of context, I'm working off hours to see if ANARI and the current implementations could be a solution to render OGC 3D tiles. Something like this : https://www.geomatys.com/2018/07/18/3d-tiles-et-enc-en-action/

The goals are numerous, sometimes just a quick snapshot (helide would suffise) sometimes a more immersive navigation with high FPS (VisGL or O3DE would do i guess) and at some point high quality outputs will be required (VisRTX, Ospray). Anari is well designed and should be able to allow us to do all this without changing the code. The problem is setting up every engine, that's no easy task.

[jeffamstutz]

One update worth noting here -- VisRTX now fetches OptiX headers now that they have been released open source. So if you have an install of CUDA 12+, then a CMake configure/build/install should be fairly straightforward.

If you encounter specific issues, let us know! We are aiming to eventually have VisRTX in vcpkg, as the ANARI-SDK is already available there. Hopefully more package managers will follow.

[Eclesia]

Made a test :

(base) jsorel@pc10:~$ nvidia-smi
Wed May 14 11:20:47 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.144                Driver Version: 570.144        CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1070 ...    On  |   00000000:01:00.0  On |                  N/A |
| N/A   55C    P0             31W /   80W |     961MiB /   8192MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

my cuda version is ok. 12.8

But build fails here :

(base) jsorel@pc10:~/dev/VisRTX/build$ cmake -DCMAKE_INSTALL_PREFIX=/home/jsorel/dev/VisRTX/release/ /home/jsorel/dev/VisRTX/
-- CMake version: 3.30.8
-- The C compiler identification is GNU 14.2.1
-- The CXX compiler identification is GNU 14.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:79 (find_package):
  Could not find a configuration file for package "anari" that is compatible
  with requested version "0.14.0".

  The following configuration files were considered but not accepted:

    /home/jsorel/.local/lib64/cmake/anari-0.11.1/anariConfig.cmake, version: 0.11.1

-- Configuring incomplete, errors occurred!

So I went to get anari 0.14.0
But the latest version available is 0.13.1
https://github.com/KhronosGroup/ANARI-SDK/releases

tryed to install it with vcpkg :

(base) jsorel@pc10:~$ vcpkg install anari
error: Invalid triplet: x64-linux
Built-in Triplets:
Community Triplets:
See https://learn.microsoft.com/vcpkg/users/triplets?WT.mc_id=vcpkg_inproduct_cli for more information.

Not sure what is wrong here, also latest version available is 0.13.1 too.

[jeffamstutz]

Sorry for the delay -- the next_release branch of the ANARI-SDK always reports what the version will be once a tagged release its made. Thus for now next_release of the ANARI-SDK reports itself as 0.14.0. (same is true for VisRTX, too)

In general, the next_release branches of both ANARI-SDK and VisRTX stay in sync, and tagged releases should also track each other. The next_release branch happens to be the default branch, so you may want to switch to a tagged release instead, depending on what you are trying to do.

[jsorel]

Hello,

I have try a build once again (on tag 0.12.0) but I've been hit with a :

(base) jsorel@pc10:~/dev/VisRTX/build$ cmake -DCMAKE_INSTALL_PREFIX=/home/jsorel/dev/VisRTX/build/release/ /home/jsorel/dev/VisRTX/
-- CMake version: 3.30.8
-- Found glm: (internal) /home/jsorel/dev/VisRTX/external/glm/lib/cmake/glm
CMake Error at /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:838 (message):
  Compiling the CUDA compiler identification source file
  "CMakeCUDACompilerId.cu" failed.

  Compiler: /usr/local/cuda/bin/nvcc

  Build flags:

  Id flags: --keep;--keep-dir;tmp -v


  The output was:

  1

  #$ _NVVM_BRANCH_=nvvm

  #$ _NVVM_BRANCH_SUFFIX_=

  #$ _SPACE_=

  #$ _CUDART_=cudart

  #$ _HERE_=/usr/local/cuda/bin

  #$ _THERE_=/usr/local/cuda/bin

  #$ _TARGET_SIZE_=

  #$ _TARGET_DIR_=

  #$ _TARGET_DIR_=targets/x86_64-linux

  #$ TOP=/usr/local/cuda/bin/..

  #$ NVVMIR_LIBRARY_DIR=/usr/local/cuda/bin/../nvvm/libdevice

  #$
  LD_LIBRARY_PATH=/usr/local/cuda/bin/../lib:/home/jsorel/.tensornvme/lib:/home/jsorel/Programs/pdal/build/lib/:/home/jsorel/.tensornvme/lib:/home/jsorel/Programs/pdal/build/lib/::/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64

  #$
  PATH=/usr/local/cuda/bin/../nvvm/bin:/usr/local/cuda/bin:/home/jsorel/.npm-global/bin:/home/jsorel/Programs/jdk-22.0.2+9/bin:/home/jsorel/Programs/gradle-8.8/bin:/home/jsorel/Programs/apache-maven-3.9.6-bin/apache-maven-3.9.6/bin:/home/jsorel/.nvm/versions/node/v16.20.2/bin:/usr/bin:/usr/condabin:/home/jsorel/.npm-global/bin:/home/jsorel/Programs/jdk-22.0.2+9/bin:/home/jsorel/Programs/gradle-8.8/bin:/home/jsorel/Programs/apache-maven-3.9.6-bin/apache-maven-3.9.6/bin:/home/jsorel/.local/bin:/home/jsorel/bin:/home/jsorel/.npm-global/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin:/usr/local/cuda/bin

  #$ INCLUDES="-I/usr/local/cuda/bin/../targets/x86_64-linux/include"

  #$ LIBRARIES= "-L/usr/local/cuda/bin/../targets/x86_64-linux/lib/stubs"
  "-L/usr/local/cuda/bin/../targets/x86_64-linux/lib"

  #$ CUDAFE_FLAGS=

  #$ PTXAS_FLAGS=

  #$ rm tmp/a_dlink.reg.c

  #$ gcc -D__CUDA_ARCH_LIST__=520 -D__NV_LEGACY_LAUNCH -E -x c++ -D__CUDACC__
  -D__NVCC__ "-I/usr/local/cuda/bin/../targets/x86_64-linux/include"
  -D__CUDACC_VER_MAJOR__=12 -D__CUDACC_VER_MINOR__=4
  -D__CUDACC_VER_BUILD__=99 -D__CUDA_API_VER_MAJOR__=12
  -D__CUDA_API_VER_MINOR__=4 -D__NVCC_DIAG_PRAGMA_SUPPORT__=1 -include
  "cuda_runtime.h" -m64 "CMakeCUDACompilerId.cu" -o
  "tmp/CMakeCUDACompilerId.cpp4.ii"

  Dans le fichier inclus depuis
  /usr/local/cuda/bin/../targets/x86_64-linux/include/cuda_runtime.h:82,

                   depuis <ligne-de-commande>:

  /usr/local/cuda/bin/../targets/x86_64-linux/include/crt/host_config.h:143:2:
  erreur: #error -- unsupported GNU version! gcc versions later than 13 are
  not supported! The nvcc flag '-allow-unsupported-compiler' can be used to
  override this version check; however, using an unsupported host compiler
  may cause compilation failure or incorrect run time execution.  Use at your
  own risk.

    143 | #error -- unsupported GNU version! gcc versions later than 13 are not supported! The nvcc flag '-allow-unsupported-compiler' can be used to override this version check; however, using an unsupported host compiler may cause compilation failure or incorrect run time execution. Use at your own risk.
        |  ^~~~~

  # --error 0x1 --

Call Stack (most recent call first):
  /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:8 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:53 (__determine_compiler_id_test)
  /usr/share/cmake/Modules/CMakeDetermineCUDACompiler.cmake:131 (CMAKE_DETERMINE_COMPILER_ID)
  devices/rtx/CMakeLists.txt:38 (project)


-- Configuring incomplete, errors occurred!

... damn, always something wrong with a version... 🥲

[jeffamstutz]

Hi, looks like it's a CUDA/gcc version mismatch -- because CUDA has to deal with parsing the C++ standard library sources, CUDA is only compatible with gcc up to a particular version. This is an issue with any CUDA project, not just VisRTX, but inevitably it's an issue here. There are a couple of solutions:

• update CUDA (which may require a driver upgrade too, depending on what you are running)
• use an older gcc

Either should be fine to build VisRTX. If you'd like any help with either of those, I'm happy to chime in on that too. If you happen to be on Ubuntu, then the easiest thing to do is to use the official NVIDIA package repos, which will let you trivially apt install newer CUDA toolkit versions (and drivers too) without needing to wait for new Ubuntu versions. You can get those here: https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&Distribution=Ubuntu&target_version=24.04&target_type=deb_network

Also if you're on Ubuntu, it's easy to get older versions of gcc/g++ by using the g++-{version} packages, then using -DCMAKE_CXX_COMPILER=g++-{version} when you configure your VisRTX build.

On other Linux distros both options above are possible, I would just need to re-lookup how best to do it.

Hope this helps!

[Eclesia]

I managed to install gcc-13. but so far all my attempts to replace the base gcc failed.

I'm on Fedora 41 but for security reasons I don't have full control over my machine. (only a few sudo operations available).

Is there a build option to disable visrtx compilation and compile at least VisGL ?

[jeffamstutz]

Of course my memory failed me -- there's a specific CMake variable used to control which host compiler gets used by CUDA. You'll need to configure with:

-DCMAKE_CXX_COMPILER=g++-13 -DCMAKE_CUDA_HOST_COMPILER=g++-13

You can disable building the RTX device with -DVISRTX_BUILD_RTX_DEVICE=OFF.

[Eclesia]

Okay it's better : but the new error is not very helpfull

(base) jsorel@pc10:~/dev/VisRTX/build$ cmake -DCMAKE_CXX_COMPILER=gcc-13 -DCMAKE_CUDA_HOST_COMPILER=gcc-13 -DCMAKE_INSTALL_PREFIX=/home/jsorel/dev/VisRTX/build/release/ /home/jsorel/dev/VisRTX/
-- CMake version: 3.30.8
-- The C compiler identification is GNU 14.3.1
-- The CXX compiler identification is GNU 13.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /var/lib/snapd/snap/bin/gcc-13
-- Check for working CXX compiler: /var/lib/snapd/snap/bin/gcc-13 - works
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found glm: (internal) /home/jsorel/dev/VisRTX/external/glm/lib/cmake/glm
CMake Error at /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:838 (message):
  Compiling the CUDA compiler identification source file
  "CMakeCUDACompilerId.cu" failed.

  Compiler: /usr/local/cuda/bin/nvcc

  Build flags:

  Id flags: --keep;--keep-dir;tmp;-ccbin=gcc-13 -v



  The output was:

  1

  cc1plus: fatal error: /tmp/tmpxft_00012209_00000000-2.cpp: No such file or
  directory

  compilation terminated.

  nvcc fatal : Failed to preprocess host compiler properties.





Call Stack (most recent call first):
  /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:8 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:53 (__determine_compiler_id_test)
  /usr/share/cmake/Modules/CMakeDetermineCUDACompiler.cmake:131 (CMAKE_DETERMINE_COMPILER_ID)
  devices/rtx/CMakeLists.txt:38 (project)


-- Configuring incomplete, errors occurred!

[jeffamstutz]

It looks like CMake is failing to invoke the CUDA compiler -- are you able to run nvcc --version successfully by chance?

[Eclesia]

Yes, it works :

(base) jsorel@pc10:~/dev/VisRTX/build$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2024 NVIDIA Corporation
Built on Tue_Feb_27_16:19:38_PST_2024
Cuda compilation tools, release 12.4, V12.4.99
Build cuda_12.4.r12.4/compiler.33961263_0

[Eclesia]

Disabling RTX I managed to go further, but still not build VisGL.

[ 11%] Built target stb_image
[ 13%] Generating anari_library_visgl_queries.h, anari_library_visgl_queries.cpp
opened device VisGL
[ 16%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLLibrary.cpp.o
[ 18%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLDevice.cpp.o
[ 20%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLArrayObjects.cpp.o
[ 23%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLInstanceObject.cpp.o
[ 25%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLGroupObject.cpp.o
[ 27%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLWorldObject.cpp.o
[ 30%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLSurfaceObject.cpp.o
[ 32%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLFrameObject.cpp.o
[ 34%] Building CXX object devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLDeviceObject.cpp.o
/home/jsorel/dev/VisRTX/devices/gl/src/VisGLDeviceObject.cpp:37:10: fatal error: anari_library_visgl_queries.h: No such file or directory
   37 | #include "anari_library_visgl_queries.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [devices/gl/CMakeFiles/anari_library_visgl.dir/build.make:256: devices/gl/CMakeFiles/anari_library_visgl.dir/src/VisGLDeviceObject.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:378: devices/gl/CMakeFiles/anari_library_visgl.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

[jeffamstutz]

Hmm, other than there being permissions issues for writing files to /tmp, I can't think of anything else. The error is coming from CMake trying to do a test compile of a dummy CUDA program to validate the compiler environment can be invoked successfully, in which case it cannot do here. I'm not sure what can be done, but I can ask some of my colleagues.

[jeffamstutz]

Are you building with ANARI-SDK v0.14.x? Also, what version of CMake are you using? None of these things should be problems, but inevitably something is very wrong.