NVIDIA Vulkan Ray Tracing Tutorials: From Rasterization to VK_KHR Ray Tracing

A staged conversion path for an existing Vulkan renderer

vk_raytracing_tutorial_KHR addresses a specific transition problem: taking a modern Vulkan 1.4 rasterization application and adding ray tracing without presenting the feature as an isolated shader experiment. The README describes eight progressive, compilable phases. That structure is useful for developers who need to understand what changes in an existing renderer and where each Vulkan ray tracing mechanism enters the application.

The repository is based on `VK_KHR_acceleration_structure`, `VK_KHR_ray_tracing_pipeline`, and `VK_KHR_ray_query`. The first two extensions support the acceleration-structure and ray-tracing-pipeline model, while `VK_KHR_ray_query` supports ray queries inside the broader sample set. The repository also lists focused examples for reflections, motion blur, ray queries, callable shaders, and opacity micro-maps.

This is not positioned as a general-purpose game engine or a complete production renderer. It is a teaching repository built around a Vulkan application that already uses a rasterization workflow. The distinction matters because the README explicitly compares a rasterized starting point with a ray-traced result, rather than describing a blank project that builds an entire scene system, asset pipeline, lighting framework, and windowing stack from scratch.

The likely audience is therefore narrow but clear: C++ developers working with Vulkan and Slang, and graphics engineers who want a sequence that connects established rasterization code with ray tracing code. A developer looking for a downloadable library with a stable public API would not get that from this repository's stated purpose. A developer seeking a complete renderer also needs to account for the fact that the related `vk_gltf_renderer` project is described separately as a production-ready Vulkan ray and path tracer.

Tutorial phases, samples, and extension boundaries

The repository's central teaching device is progression. The README calls the tutorial “8 progressive, compilable phases,” which gives learners a concrete sequence rather than a single final ray tracing sample. Based on the repository layout, the tutorial code is under `raytrace_tutorial/`, shared Vulkan helpers and supporting code are under `common/`, documentation is under `docs/`, and build configuration is organized through `CMakeLists.txt` and `cmake/`.

The sample scope is broader than the initial conversion. The README names reflections, motion blur, ray queries, callable shaders, and opacity micro-maps as examples. That makes the repository useful after the first ray-traced image. It also exposes a useful distinction between adding a ray tracing pipeline and changing shading behavior for an existing rasterized scene. Reflections and motion blur require scene and shader decisions, while callable shaders and opacity micro-maps are separate Vulkan ray tracing topics.

The three named extensions define the technical boundary visible in the documentation. `VK_KHR_acceleration_structure` is relevant to representing ray tracing geometry for traversal. `VK_KHR_ray_tracing_pipeline` is relevant to dedicated ray tracing pipeline stages. `VK_KHR_ray_query` provides the ray-query capability covered by the samples. The README does not document a compatibility matrix for individual GPU models, Vulkan drivers, ray tracing feature levels, or shader model requirements beyond the stated requirement for a GPU and driver supporting Vulkan ray tracing.

That omission is material for adoption. A developer can understand the project direction from the documentation, but cannot use the README alone to select a supported GPU or guarantee that every sample will run on every Vulkan ray tracing implementation. The repository's tutorial pages are the appropriate place to inspect the exact phase and sample behavior.

Building the v2.0 tutorial from two adjacent repositories

The README provides a complete initial build sequence, but it assumes several prerequisites. The project requires `nvpro_core2`, a Vulkan 1.4+ SDK with Volk headers selected during installation, CMake 3.18+, and a GPU and driver supporting Vulkan ray tracing. The default branch is `v2`, while the README notes that the original pre-v2.0 tutorial remains on the `master` branch.

The documented workflow places the two repositories side by side. The first command fetches `nvpro_core2`, which supplies the Vulkan helpers used by the tutorial. The second command fetches the tutorial repository. The build is configured from the tutorial directory with CMake, then compiled into a `build` directory. The README states that compiled binaries are placed in `_bin`.

git clone https://github.com/nvpro-samples/nvpro_core2.git
git clone https://github.com/nvpro-samples/vk_raytracing_tutorial_KHR.git

cd vk_raytracing_tutorial_KHR
cmake -B build -S .
cmake --build build -j 8

This is the first real setup operation described by the project. A reader should see the two repositories cloned beside each other, CMake configuration complete successfully, the build command finish without errors, and binaries appear under `_bin`.

The README does not document a single launch command for a particular tutorial phase. It also does not state which environment variables, runtime data files, or application arguments are required. Consequently, this build sequence establishes compilation but does not by itself tell the reader which executable to run or how to select the initial tutorial phase. Those details must be taken from the online tutorial or the generated build output rather than inferred from the repository name.

C++ application architecture with Slang shaders

The repository identifies C++ as its primary language and uses Slang for shaders. The top-level layout separates the tutorial application from shared support code, with `raytrace_tutorial/` as the tutorial-specific directory and `common/` available for reusable Vulkan helpers and application components. The documented dependency on `nvpro_core2` indicates that much of the surrounding Vulkan infrastructure is expected to come from a separate helper repository rather than being reproduced inside the tutorial.

The rendering architecture described by the README moves from Vulkan 1.4 rasterization to ray tracing through progressive phases. In the starting state, the application follows the rasterization path. In the later state, the same repository can represent the ray-traced result shown in the documentation. The available documentation does not describe the exact class names, command-buffer sequence, descriptor layouts, acceleration-structure build passes, shader-stage mapping, or synchronization code. It would be inaccurate to claim how those pieces are wired beyond the repository layout and the named extensions.

The use of Slang is a concrete implementation detail rather than a cosmetic preference. Shader behavior is part of the tutorial's subject because ray tracing pipelines, ray queries, callable shaders, and opacity micro-maps all depend on code beyond ordinary fragment or vertex shading. The README also identifies a `slangdconfig.json` file at repository level, but it does not explain its contents or configuration workflow.

For an engineer, this means the project should be evaluated as a source-level teaching example. It offers a path through the Vulkan ray tracing feature set, but the README does not present a general library contract, stable public API, or production support model.

Rasterization versus ray and path tracing workloads

The project is a tutorial rather than a drop-in replacement for a production renderer. The README explicitly points developers with broader rendering needs to `vk_gltf_renderer`, describing that related project as production-ready and listing full glTF 2.0 support, IBL, denoising, and post-processing. That comparison points to a concrete difference in scope: the tutorial repository concentrates on teaching Vulkan ray tracing changes, while the related renderer is presented as a broader application for rendering assets and effects.

Another real alternative is to use a Vulkan sample collection that stays focused on isolated graphics capabilities. The README names `vk_mini_samples` as a collection of focused Vulkan samples beyond ray tracing. Its approach differs because it provides a wider set of small Vulkan examples rather than a progressive conversion of one rasterization application into a ray tracer.

The tutorial also leaves implementation boundaries visible. It requires Vulkan 1.4+, CMake 3.18+, Slang, `nvpro_core2`, and ray-tracing-capable hardware. It has no GitHub releases, so the README's build instructions and repository branch are more relevant than release-based upgrade planning. The default branch is `v2`, and the README provides a separate pointer to the legacy `master` tutorial.

That makes the repository most appropriate for learning or prototyping a ray tracing transition. It is less suitable when the requirement is a complete asset pipeline, a supported production renderer, or a deployment package whose compatibility matrix is required up front.

Maintenance, licensing, and upgrade considerations

The repository is not archived. Its last push was on 2026-09-20, so the available maintenance record is recent relative to the stated project date. However, the repository has no GitHub releases. That distinction matters for upgrade planning: there is no release history in the repository metadata from which to derive a semantic version schedule or migration path.

The README identifies the project as version `v2.0` and points users to the online tutorial, samples, and documentation. The default branch is `v2`, while the legacy pre-v2.0 content is on `master`. An engineer changing branches should therefore treat branch selection as part of the integration decision. The README does not document compatibility guarantees between the `v2` tutorial and the legacy branch.

The repository carries the Apache-2.0 license, and the README includes an Apache 2.0 badge. License obligations, notices, and compatibility with a larger codebase need to be checked against the repository's `LICENSE` file. This review does not provide legal advice, and the README does not summarize the license text or its distribution requirements.

The most concrete upgrade concern is dependency alignment. The build uses `nvpro_core2` from an adjacent clone, a Vulkan 1.4+ SDK, CMake 3.18+, and Slang. The README does not pin a Vulkan SDK version, driver version, GPU model, or `nvpro_core2` commit. It therefore does not support claims about reproducible builds or upgrade compatibility beyond the stated prerequisites.

Editorial conclusion

This repository fits developers who already have a Vulkan rasterization base and want to learn ray tracing through compilable stages rather than through disconnected snippets. It is a poor fit for a first Vulkan application, a production renderer replacement, or environments without a GPU and driver that support Vulkan ray tracing. Verify the Vulkan 1.4+ SDK installation with Volk headers, CMake 3.18+, and the hardware and driver support required by the selected sample before relying on it as an application foundation.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nvpro-samples/vk_raytracing_tutorial_KHR on GitHub
4. Project website
5. README