RenderDoc: a frame-capture graphics debugger for Vulkan, D3D11, D3D12, OpenGL and OpenGL ES

What RenderDoc is for, and who it is not for

RenderDoc is a frame-capture based graphics debugger, available for Vulkan, D3D11, D3D12, OpenGL and OpenGL ES development on Windows, Linux, Android and Nintendo Switch. The workflow it enables is narrow and specific: you run your program, trigger a capture of one frame, and then inspect the recorded API calls, resources and pipeline state in a replay tool rather than in the live application. That distinction matters. A profiler tells you how long something took; RenderDoc tells you what the GPU was actually asked to do in that frame, and it does so deterministically because the frame is replayed from recorded data.

The intended audience is graphics programmers debugging their own programs. The README states this as a hard boundary rather than a preference: it says RenderDoc is intended for debugging your own programs only, and that discussion of capturing programs you did not create will not be allowed in any official RenderDoc setting, including the issue tracker, Discord or email. The README gives capturing commercial games you did not create, or capturing Google Maps or Google Earth, as examples. It also clarifies the other side of the line: capturing projects you created that use a third party engine such as Unreal or Unity, or open source and free projects, is fine and supported.

That policy shapes what the project is willing to help with. If your interest is inspecting a shipped game's rendering, RenderDoc is the wrong tool by design, not by technical limitation.

The capture and replay model behind RenderDoc

The architecture is split across the repository layout. The renderdoc/ directory holds the core library and the platform and API backends; qrenderdoc/ is the Qt-based user interface; renderdoccmd/ is a command line front end; and renderdocshim/ is a small shim component. A CMakeLists.txt at the top level and a renderdoc.sln Visual Studio solution sit alongside them, so the same source tree produces both the library and the GUI.

The mechanism is interception. RenderDoc hooks the graphics API calls your program makes, records them along with the associated resource state, and then replays that recording in a separate process. Because replay happens against the recorded data rather than against your live application, you can step through draw calls, inspect the pipeline state at each one, view textures and buffers, and use the pixel history and shader debugging features shown in the README screenshots. The screenshots listed there cover texture view, pixel history and shader debug, mesh viewer, and pipeline viewer with constants.

This design has a consequence worth stating plainly: capture is invasive. The tool has to be present in the process, which is why the README answers questions about injection and why the supported platform matrix is as specific as it is. Replay is where the analysis happens, and replay is a separate program reading a capture file.

Installing RenderDoc and taking a first capture

On Windows the README points at installers rather than a package manager. It says to run the appropriate installer for your OS, linking a 64-bit MSI and a 32-bit MSI, or to download the portable zip from the builds page. The 64-bit Windows build fully supports capturing from 32-bit programs, so a 32-bit target does not force you onto the 32-bit build.

# Windows: download and run the installer
# 64-bit: https://renderdoc.org/stable/latest/RenderDoc_latest_64.msi
# 32-bit: https://renderdoc.org/stable/latest/RenderDoc_latest_32.msi
# portable zip and nightly builds: https://renderdoc.org/builds

On Linux the README is more constrained. Only 64-bit x86 is supported. There is a precompiled binary tarball, and your distribution may package it. If neither applies, the README directs you to build from source, with instructions in docs/CONTRIBUTING/Compiling.md.

# Linux: precompiled tarball
# https://renderdoc.org/stable/latest/renderdoc_latest.tar.gz
# or install the package your distribution provides
# otherwise build from source, see docs/CONTRIBUTING/Compiling.md

Once installed, the README describes the documentation set rather than a step by step tutorial: HTML documentation online for the latest stable version, a renderdoc.chm file included in any build, and YouTube videos showing basic features and an introduction. If you are new, the README recommends starting with the stable builds; nightly builds are produced every day from the v1.x branch and may correspondingly be less stable. The project also maintains a symbol server at renderdoc.org/symbols, which is relevant if you want symbols resolved during replay.

Where the platform and API matrix stops

The support table is the most useful part of the README for a decision, because the gaps are as informative as the checkmarks. Vulkan is supported on Windows, Linux and Android. OpenGL ES 2.0 to 3.2 is supported on all three. OpenGL 3.2 to 4.6 Core is supported on Windows and Linux, with Android marked not applicable. D3D11 and D3D12 are Windows only, with Linux and Android marked not applicable.

The unsupported entries are equally explicit. OpenGL 1.0 to 2.0 Compatibility is marked unsupported on Windows and Linux. D3D9 and D3D10 are marked unsupported on Windows. Metal is marked not applicable on every platform in the table. If your renderer targets any of those, RenderDoc will not capture it, and no amount of configuration changes that.

Two further constraints are easy to miss. Linux is 64-bit x86 only, so an ARM Linux target is outside the supported set regardless of which API you use. And Nintendo Switch support is not in the open source tree at all: the README says it is distributed separately for authorized developers as part of the NintendoSDK, with more information available through the Nintendo Developer Portal. The open source repository under the MIT licence therefore does not give you Switch capture on its own.

RenderDoc versus GPU vendor frame debuggers

The obvious alternative is the frame debugger shipped inside a GPU vendor's tooling, such as the capture tools that come with a vendor's graphics SDK. The difference in approach is scope. A vendor tool is typically tied to that vendor's hardware and driver, and often to a narrower set of APIs, in exchange for deeper integration with that vendor's driver internals and profiling counters. RenderDoc is vendor-neutral and API-broad: one tool covers Vulkan, D3D11, D3D12, OpenGL and OpenGL ES across Windows, Linux and Android, which is why it is often the only option when you need to compare behaviour on a machine that is not running the vendor's hardware.

The trade-off runs the other way too. Because RenderDoc is an interception layer rather than a driver-integrated tool, it does not give you hardware performance counters, and its answers are about correctness and state rather than about where time went. Teams commonly keep both: a vendor profiler for timing and counters, RenderDoc for inspecting the actual command stream and resources in a frame.

There is also a community extensions repository, linked from the README as renderdoc-contrib, for functionality that is not part of the core project. If a feature you want is not in the main tree, that is the first place to look before assuming it does not exist.

Licence, third party code and upgrade cadence

RenderDoc is released under the MIT licence. The README points at LICENSE.md for the full text as well as the third party library acknowledgements, and those acknowledgements are the part worth reading before you redistribute a build. MIT is permissive, but the bundled libraries carry their own terms, and the repository does not summarise them in the README. This is not legal advice; if you ship RenderDoc components inside a product, read LICENSE.md and the individual library licences.

On cadence, the release history shows a steady rhythm: v1.44 on 2026-05-01, v1.45 on 2026-07-02, and v1.46 on 2026-08-31, with the last push to the v1.x branch on 2026-09-21. Releases land roughly every two months, and nightly builds are published daily from v1.x. Upgrading is therefore a real decision rather than a one-off: stable builds are the recommended starting point, and nightlies exist for people who need a fix that has not shipped yet. The practical upgrade cost is low for the application itself, since Windows and Linux both offer prebuilt binaries, but it rises if you build from source or if you depend on capture compatibility across versions. The README does not document rollback behaviour or capture file version compatibility, so verify that against your own workflow before standardising on a nightly.

Editorial conclusion

Adopt RenderDoc if you write your own renderer against Vulkan, D3D11, D3D12, OpenGL or OpenGL ES and need to inspect a single frame in detail. Do not adopt it if you need to capture someone else's commercial game, if you target Metal, D3D9 or D3D10, or if you need a Linux build on anything other than 64-bit x86. Verify first that your API and platform combination appears in the support table, and confirm the licence obligations you inherit from the third party acknowledgements in LICENSE.md.

Frequently asked questions

Official sources

1. baldurk/renderdoc on GitHub
2. License: MIT
3. Project website
4. README
5. Releases