VulkanTools bundles the Configurator and the LunarG debug layers

Three tools, and the SDK is where you get them

The VulkanTools repository contains the following Vulkan tools: the Vulkan Configurator, and the VK_LAYER_LUNARG_api_dump, VK_LAYER_LUNARG_screenshot and VK_LAYER_LUNARG_monitor layers, with the documentation for the layers in the layersvt directory and the Configurator's own documentation in vkconfig_gui.

The most important practical line in the README is the third one. These tools have binaries included within the Vulkan SDK. You do not normally build this repository to use the tools. You install the Vulkan SDK, and the tools are inside it.

That is a deliberate arrangement, and it changes who this repository is for. A developer who needs to look at Vulkan driver configuration, capture a screenshot of a rendered frame, or dump the API calls an application makes does not install from GitHub. The repository is for the people who change the tools.

The three layers are the interesting part for most developers, and they are validation layers, which means they are enabled through the Vulkan loader's layer mechanism rather than linked into an application. The api_dump layer prints the API calls that pass through it, the screenshot layer captures images from a running application, and the monitor layer watches and reports on the application's Vulkan usage. All three are only useful during development, and all three add work to the API calls they observe, which is why they are opt-in rather than always on.

The Configurator is a graphical tool for inspecting and changing the Vulkan configuration on a machine, and the repository carries a command line companion in vkconfig_cmd alongside the core library in vkconfig_core and the GUI in vkconfig_gui.

Two tagging schemes that mean different things

The version tagging scheme is documented carefully, and it is the kind of detail that saves an hour when you are trying to work out which build you have.

Updates to this repository which correspond to a new Vulkan specification release are tagged using the format v<version>, for example v1.3.266. There is a note attached, and the note is the point: marked version releases have undergone thorough testing but do not imply the same quality level as SDK tags.

SDK tags follow the vulkan-sdk-<version>.<patch> format, for example vulkan-sdk-1.3.266.0. The two schemes exist side by side, and the difference is a statement about assurance. An SDK tag is the tested artefact that ships to users. A repository version tag marks the point at which the sources were updated for a new specification release, and while those have been tested, the SDK tag carries the stronger guarantee.

The README also says when the scheme was adopted, following the 1.3.266 Vulkan specification release, which is useful when you are looking at an older tag and wondering which convention it follows.

For anyone pinning a dependency, the practical rule is that a vulkan-sdk tag is the one to pin. A v<version> tag tells you the sources are aligned with a specification release, which is what you want when you are reading the code, and it is not the same promise as the SDK build.

The repository is not archived, the last push was on 2026-09-28, and it publishes no GitHub releases, so the tags are the version history.

Deprecated tools and where they went

The Removed Tools section is unusually informative, because it records the fate of several tools people still encounter in older documentation and in CI images.

The Vulkan Installation Analyzer, known as vkvia, has been deprecated and replaced by the Vulkan Configurator diagnostics tab. The last available version was released with Vulkan SDK 1.4.309, and the README links to the tagged tree so you can find it.

VkTrace and VkReplay have been deprecated, removed from VulkanTools and replaced by gfxreconstruct, and they can now be found in the vktrace archive. Both are also no longer part of the Vulkan SDK, which is the practical detail: an image built against a current SDK will not have them, so a pipeline that still calls them needs either an older SDK or a change of tool.

Vulkan-Layer-Factory is deprecated and has been archived in its own repository.

Taken together, these three moves describe a consolidation. Layer authoring became its own project, frame capture and replay became gfxreconstruct, and configuration inspection became a tab in the Configurator. That is a healthier arrangement than one repository accumulating tools that overlap, and the cost is that anyone with scripts pointing at vkvia, VkTrace or VkReplay has migration work to do.

The replacement path is documented in each case, and the old binaries are still reachable at the tags named in the README, which matters for reproducing an old environment.

What the repository actually contains

The top level listing tells you how the pieces are separated, and it is a sensible layout for a project that has to build a GUI, a command line tool and three layers.

There is a CMakeLists.txt at the root and a BUILD.gn alongside it, so the build is described for both CMake and the GN build system. BUILD.md holds the directions for building all the components and running the tests, which is where you go if you are changing the code rather than using the tools. There is a CONTRIBUTING.md, a GOVERNANCE.md and a .clang-format, which tells you both how to contribute and how the project is governed, and the .gitattributes and .github directories for the rest of the repository housekeeping.

The source is split by tool. vkconfig_gui holds the graphical Configurator, vkconfig_core its core library and vkconfig_cmd the command line companion. layersvt holds the three validation layers, with the api_dump, screenshot and monitor layers documented in its README. There is a scripts directory and a tests directory at the top level.

The project is primarily developed by LunarG, and the acknowledgements section names the other contributors, starting with Valve Corporation funding project development, and the README notes that many other companies and individuals make it possible.

The licence is described as an open source Apache-style license from Khronos that includes a Khronos copyright, with the text in LICENSE.txt. GitHub cannot classify the recorded licence, which is a common shape for a Khronos-style Apache variant with additional wording.

Where VulkanTools is the wrong tool

The limits here are about category rather than capability.

First, these are developer tools, not a library. A project that wants to talk to Vulkan links against the loader and the SDK, not against this repository. Adding VulkanTools to an application's dependency list is the wrong shape of decision, and the SDK already contains the binaries you would have wanted.

Second, the layers are for development. A validation layer observes every call that passes through it, and the screenshot and monitor layers do considerably more work than a no-op. Enabling them in a shipped build costs performance and changes timing, so they belong in a debug configuration rather than in a product.

Third, the Configurator is a desktop GUI for a machine, and the repository carries a command line counterpart for scripted use, but the tool's scope is the local Vulkan configuration: the ICD, the layers present, the configuration files. It is not a remote management tool, and it is not a way to inspect a Vulkan application running on another host.

Fourth, the deprecation history is a warning. Three of the tools that lived in this repository are gone or moved, and two of them are no longer in the SDK at all. A pipeline that reaches for VkTrace today is reaching for something that has left the distribution, and the replacement, gfxreconstruct, lives in a different repository. Reading the Removed Tools section before choosing a tool saves a migration later.

Fifth, there are no GitHub releases here. The tags are the version history, and the distinction between a specification version tag and an SDK tag is the one to keep in mind when you pin something.

Editorial conclusion

Graphics developers who need to inspect Vulkan driver configuration or trace API calls should take the Vulkan SDK, because these tools ship inside it and the Configurator plus the api_dump, screenshot and monitor layers cover the three questions that come up first. It is the wrong dependency to add to a project, since these are developer tools and validation layers rather than a library your application links against, and the layers add runtime cost that a shipping application should not pay. Before relying on them, check the version tagging scheme, because the repository tags and the SDK tags mean different things, and note that the licence is an Apache-style Khronos licence rather than a standard OSI identifier.

Frequently asked questions

Official sources

1. Issues
2. LunarG/VulkanTools on GitHub
3. README