OSPRay is a CPU ray tracer that needs Embree, VKL, TBB and an ISPC compiler to build

A rendering engine for visualisation, not a general ray tracer

OSPRay is an open source, scalable and portable ray tracing engine for high performance, high fidelity visualisation on Intel Architecture CPUs, Intel Xe GPUs and Aarch64 CPUs. It is part of the Intel Rendering Toolkit, Render Kit, and is released under the permissive Apache 2.0 licence.

The stated purpose is to provide an open, powerful and easy-to-use rendering library that allows one to easily build applications that use ray tracing based rendering for interactive applications, including both surface-based and volume-based visualisations. OSPRay runs on anything from laptops to workstations to compute nodes in HPC systems.

The word visualisation is doing the specifying here. This is not a general purpose path tracer you would use to render a film. It is an engine for applications that need physically correct light transport in an interactive setting, which in practice means scientific visualisation, product configurators, and the kind of medical or engineering imaging where a physically plausible result matters more than an artistically controllable one.

That distinction shows up in the internals. OSPRay builds on top of Intel Embree for ray tracing against geometry, Intel Open VKL for volumetric sampling, and Intel Open Image Denoise for image denoising. The CPU implementation is written in Intel ISPC, the Implicit SPMD Program Compiler, and it exploits SSE4, AVX, AVX2, AVX-512 and NEON.

The hardware floor follows from that. A CPU with support for at least SSE4.1 is required on x86, or a CPU with NEON support on ARM64. That is a low bar by modern standards, which is a deliberate choice for a library meant to run on everything from a laptop to a cluster node.

The README describes the current state as release v3.3.0 on the devel branch, and the recent tags are v3.2.0 from 2024-07-23, v3.1.0 from 2024-02-22 and v3.0.0 from 2023-10-18. The last push to the repository was on 2026-10-14 with the repository not archived, so work continues on the development branch while the tags lag.

Six Intel components, each with a version floor and a CMake hint

The prerequisites section is the part of the README that tells you what this project actually is, because the dependency list is long and every entry is an Intel project.

The base requirements are CMake, a C++11 compiler with GCC recommended but Clang, MSVC and the Intel C++ Compiler also supported, and the standard Linux development tools. On top of that you need the Intel Implicit SPMD Program Compiler, ISPC, version 1.30.0 or later, and if CMake cannot find it you hint its location with the variable `ISPC_EXECUTABLE`.

The Render Kit common library, rkcommon, is the foundation. It provides the abstractions for tasking, aligned memory allocation and vector math types, and the recommended tasking system is the Intel Threading Building Blocks, TBB, for performance and flexibility reasons. TBB must be built from source when targeting ARM CPUs, or can be built from source as part of the superbuild, and alternatively you can set the CMake variable `RKCOMMON_TASKING_SYSTEM` to `OpenMP` or `Internal`.

Then the rendering components. Embree 4.3.3 or newer is required, with the variable `embree_DIR` to hint its location. Open VKL 2.0.1 or newer is required, with `openvkl_DIR`, and volume rendering is enabled by default via `OSPRAY_ENABLE_VOLUMES`, so the simplest build already pulls VKL in.

The denoiser image operation is an optional module enabled by `OSPRAY_MODULE_DENOISER`, requiring Open Image Denoise 2.3.0 or newer, with the CMake variable `OpenImageDenoise_DIR` to hint it.

The optional MPI modules, enabled by `OSPRAY_MODULE_MPI`, provide the `mpiOffload` and `mpiDistributed` devices, and they need an MPI library and Google Snappy.

That pattern of a version floor plus a hint variable is repeated for every dependency, and it is a good pattern. A rendering stack pinned to specific library versions silently changes behaviour when one of them moves, so the build says exactly what it expects and lets you point at a specific copy rather than whatever is on the system path.

The GPU path is beta, and it is a specific device list

The GPU implementation is marked as beta status and is built on SYCL, the Khronos cross-platform programming language, implemented by the Intel oneAPI Data Parallel C++ compiler, DPC++.

The supported hardware is narrow and stated explicitly. It currently supports Intel Arc GPUs on Linux and Windows, and the Intel Data Center GPU Flex and Max Series on Linux, exploiting the ray tracing hardware support of those devices.

So the GPU story is: a real SYCL ray tracing path, with hardware ray tracing, on a defined set of Intel devices. It is not a portable GPU renderer, and the beta label is doing real work in that sentence. For a team that wants GPU rendering today, the alternatives are not in the same category: OSPRay's strength is the CPU path, which is the one that scales across the range of hardware the README describes.

The build requirement for the GPU module is a SYCL compiler, either the open source oneAPI DPC++ Compiler of a specific dated release, 2023-10-26, or the latest Intel oneAPI DPC++/C++ Compiler.

The CPU and GPU paths sharing the rest of the engine is what makes the comparison interesting. The scene description, the materials, the volume sampling and the denoiser are the same in both, so an application written against OSPRay's API does not care which device renders it, and that is the argument for the SYCL path existing at all.

One more detail in the repository root is worth noting. There is a `third-party-programs.txt` and then one file per dependency, such as `third-party-programs-Embree.txt`, `third-party-programs-ISPC.txt`, `third-party-programs-OpenVKL.txt` and `third-party-programs-oneDNN.txt`. Listing the third party components by file rather than in one place is what lets the build and the licensing check stay in step as the dependency set changes, and it is a small sign of how carefully the project is maintained.

Installing dependencies per platform, and the superbuild

The installation instructions are given per package manager and per platform, which reflects how much variation there is between distributions.

On Linux with yum, the commands are for cmake and the TBB development packages, and on apt-get they are for cmake-curses-gui and libtbb-dev. The apt variant is notable for pulling in a curses build of CMake, which is what the project asks for.

sudo yum install cmake.x86_64
sudo yum install tbb.x86_64 tbb-devel.x86_64

sudo apt-get install cmake-curses-gui
sudo apt-get install libtbb-dev

Under Mac OS X the dependencies come from MacPorts.

sudo port install cmake tbb

Under Windows the README says to use the appropriate installers for CMake, TBB, ISPC for your Visual Studio version and Embree.

The README notes that depending on the distribution these packages might already be installed or might have slightly different names, which is the honest framing given that the dependency set here is unusual enough that most distributions will not have it ready to go.

The superbuild is mentioned twice, once for building TBB from source as part of the CMake build and once more for the same purpose on ARM. That is the escape hatch for the case where the system's libraries are the wrong version, and it is what makes the whole thing workable on a platform that does not ship a compatible Embree.

For the example application, the test suite and the benchmarks, there is one more set of requirements: some version of OpenGL and GLFW, plus GoogleTest and Google Benchmark. The examples live in `apps/`, the tests in `test_image_data/` and the source tree, and the `scripts/` directory holds the build helpers.

The support statement is unusually candid for a rendering library

The support and contact section is worth reading in full, because it sets expectations honestly.

OSPRay is under active development, and though the project does its best to guarantee stable release versions, a certain number of bugs, as-yet-missing features, inconsistencies, or any other issues are still possible. The instruction is to use the GitHub issue tracker for such requests or findings, and to send a pull request if you have a fix.

That is a straightforward statement, and the fact that it is made in a library used for high fidelity visualisation is worth noting. A rendering engine that silently produces a slightly wrong image is worse than one that says it might. The commitment to stable release versions combined with the explicit caveat is the combination you want from a dependency you are putting in a pipeline.

The other operational detail is the branch layout. The latest OSPRay sources are always available at the GitHub repository, and the default `master` branch should always point to the latest bugfix release. The README header says this is release v3.3.0 on the devel branch, and the default branch in the repository metadata is `devel`.

So there are two lines: `master` for the latest bugfix release and `devel` for what comes next. A consumer should be on `master` or on a tag, and the tags are v3.2.0, v3.1.0 and v3.0.0 for the recent history, which is a slower tag cadence than the commit cadence.

The repository also carries a `SECURITY.md` and a `STYLEGUIDE.md`, plus a `CHANGELOG.md` that the README points to for changes and new features, and a `.clang-format` file, so the project has the standard hygiene of a serious native code project.

Editorial conclusion

Adopt OSPRay if you need physically based ray traced rendering for scientific or high fidelity visualisation and you are already in the Intel ecosystem, since the build assumes Intel's own components. Do not adopt it if you need a GPU renderer you can deploy anywhere, because the GPU implementation is in beta and supports a specific list of Intel devices. Verify first that the version of Embree, Open VKL, TBB and Open Image Denoise you have meets the stated minimums, that your CPU supports at least SSE4.1 or NEON, and that the volume rendering and denoiser modules you intend to use are enabled by the CMake options you set.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. RenderKit/ospray on GitHub