nvpro_core, the shared library under the NVIDIA samples, and why it was deprecated

The shared tree that most nvpro-samples applications link against

nvpro_core is not an application you run. The README describes it as a repository of shared source code, and the practical consequence is stated plainly: you must clone it, with submodules, before you can try the samples that treat it as a dependency. Almost every other project in the nvpro-samples organisation either uses it as a library or references code from it directly, which makes this one of those dependencies where a missing folder shows up as a build error rather than a missing feature.

The scope is broad. The tree defines a base class NVPSystem in nvpsystem headers, the main class NVPWindow in nvpwindow, a math library in nvmath that most samples use, and a set of platform macros in platform.h and NvFoundation.h that are written as NV_ prefixed helpers to ease cross platform coding. A cmake directory holds find files for locating CMake packages, and a doxygen directory holds the documentation generation setup, driven by docgen.py, a Python script that produces README files from comments gathered in the headers.

That mix of base classes, a math library and a shader pipeline is the real answer to what problem nvpro_core solves. Sample applications tend to spend most of their lines on setup rather than on the effect being demonstrated, and this tree absorbs the setup so that the sample itself stays readable.

The nvh, nvgl, nvvk and nvvkhl layers and what each one absorbs

The top level directories map cleanly onto graphics APIs. nvh holds API agnostic helpers that exist to simplify the code of the samples, and it is the layer every other API specific directory leans on. nvgl holds the OpenGL helpers, nvvk holds Vulkan helpers described as aiding extension use and simplifying initialization of Vulkan structures, with some files generated from scripting, and nvvkhl is the high level Vulkan layer used for creating samples, applications, loading scenes, HDR environments and G-Buffers. There is a matching nvvkhl/shaders directory for commonly used shading and tonemapping functions.

The remaining directories cover the rest of the API surface: nvoptix for Optix helpers, nvdx12 for DirectX 12 helpers, imgui for a version of Dear ImGui plus implementations to render it, GL and KHR for include files, and resources for icons. The GL include set is not hand written, because the README explains that a subset of extensions is generated and defined by nvgl/extensions_gl.lua. A fileformats directory adds helpers for loading some files, and nvp covers the platform abstraction.

If you are coming from a graphics background, the fastest way to read this tree is to note that nvvkhl is where a sample's visible behaviour comes from, while nvh and nvvk are where you would look first when a sample fails to initialise.

What it takes to build a sample that depends on this tree

There is no build recipe in the README beyond the warning about cloning with submodules, so the setup sequence has to be described rather than copied. The order that follows from the documentation is short. First, clone nvpro_core with its submodules so that the embedded third-party code is present. Second, obtain the third-party binaries, which the README points to in the third_party_binaries repository, because some samples rely on a few additional libraries in order to compile, mostly on win32. Third, install the SDK for the API you intend to use, because the use of Vulkan or DirectX APIs requires the appropriate SDKs to be installed.

The version constraint is the only hard number in the documentation: the minimum Vulkan SDK version is currently 1.3.261.0. The tree also carries a CMakeLists.txt with the project definition for the nvpro_core library, and the cmake directory supplies find files, so the build is CMake driven rather than script driven.

What you should expect to see after a successful build is a sample binary in a build tree of your choosing, and for the GUI based samples, a window. The README does not document a command line to launch a sample, and it does not document how the app locates its resources, so neither point can be given as a verified instruction.

The deprecation notice that changes how the rest of the tree should be read

The README opens with an important notice stating that the repository has been deprecated and is superseded by nvpro_core2, which provides an improved and consolidated version of the framework. It goes further, telling readers who plan to keep using nvpro_core that the repository is no longer actively maintained and will eventually be archived, including samples from nvpro-samples that use it.

That has two practical consequences. The first is a hard boundary: any new sample, tutorial or internal tool should be written against nvpro_core2 instead. The second is a deadline with an uncertain date. The repository is not archived yet, and the last push was on 2026-05-29, so it still receives occasional commits, but the notice makes clear that those commits are not a maintenance commitment. The repository also has no GitHub releases, so there is no tagged version to pin and no release note to diff. For a dependency you must reproduce, the practical substitute for a release is a specific commit hash.

One more detail deserves attention from a licensing perspective. The README says all third-party licenses are collected in the PACKAGE-LICENSES folder, that the include file mechanism inside nvh/shaderfilemanager.cpp is derived from the OpenGL Samples Pack, and that only the hash combine logic was derived from Boost. The project itself is licensed under the Apache License 2.0. Anyone redistributing a binary that links this code needs to carry the notices for the derived parts, which is a paperwork obligation rather than a legal opinion.

Where nvpro_core is the wrong building block

The clearest wrong case is new development. If you are starting a Vulkan or OpenGL application today, taking a deprecated tree as your foundation means writing code against an API surface the project itself has moved past, with a successor that is explicitly described as improved and consolidated. Migration cost later is higher than choosing correctly now.

The second wrong case is a project with a long maintenance horizon and a dependency policy that requires a maintained upstream. A tree that states it is no longer actively maintained and will eventually be archived cannot satisfy a supply chain review, and once it is archived the samples that depend on it stop receiving fixes along with it.

The third wrong case is work that does not need the framework at all. nvpro_core is a large shared layer with a math library, a windowing abstraction, an embedded UI toolkit and four graphics API backends. A small utility that renders a single offscreen triangle does not need any of it, and pulling in the whole tree for that is weight without benefit.

The right case is narrower and still real: reproducing, porting or extending an existing nvpro-samples application whose behaviour depends on the exact helpers in this tree. There, matching the original shared code is a feature, and the deprecation notice becomes a scheduling problem rather than a reason to rewrite.

nvpro_core2 and the case for consolidating instead of cloning

The successor changes the architectural question rather than just the version number. The README describes nvpro_core2 as an improved and consolidated version of the framework, which points at a tree organised around fewer, better separated pieces rather than a directory per API. For someone reading the current layout, the evidence for consolidation is visible in how specialised the directories are: nvgl, nvvk, nvvkhl, nvoptix and nvdx12 sit side by side with a shared nvh layer, and the high level Vulkan layer in nvvkhl sits on top of nvvk for the parts that most samples touch.

That structure served a purpose when each sample was a self-contained demonstration of one API, and it is exactly the structure that makes a consolidated successor a rewrite rather than a version bump. The practical difference in approach is therefore clear: in nvpro_core you clone a wide collection of API specific helpers and select the ones your sample needs, while in nvpro_core2 you take the consolidated framework. For a decision, the relevant test is not which is nicer but whether your work has to match the old tree exactly.

The maintenance picture in the current tree reinforces the point. The last push was on 2026-05-29, there are no GitHub releases, and the README announces that archiving is coming. Adopting a deprecated dependency is defensible when you are reproducing something, and hard to defend when you are starting something.

Editorial conclusion

nvpro_core still makes sense for an engineer who must reproduce an existing nvpro-samples application, pin the exact shared tree it was written against, and accept that a deprecated repository with a 2026-05-29 last push will eventually be archived. It does not make sense for new work, where nvpro_core2 is the documented successor and starting there avoids a later migration. Before committing to either, check which branch of the samples you are actually building, confirm that the Vulkan 1.3.261.0 SDK and the win32 third_party binaries are present, and read the deprecation notice in the README rather than assuming the tree is still supported.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nvpro-samples/nvpro_core on GitHub
4. README