Marijn Suijten
c42117f7c2
The initialization path for both the capture and replay layers were modifying a global `static` structure containing `VkApplicationInfo` to update it when `Vulkan_Debug_ReplaceAppInfo` is enabled (the default), and also always to pass through the most accurate `apiVersion` from the caller instead of defaulting to a minimum. Worse, code after `vkCreateInstance()` was reading back the value for `apiVersion` passed through this global constant (rather than reading the local copy). The end result is that, at least on Android where 3 instances are created at roughly the same time _on three different threads_ (as seen in the logs captured in #3903) they all clobber this global state and because `vkCreateInstance()` could easily take some time (4-12ms) those threads would be reading back each others' `apiVersion`. In turn when the last write to `renderdocAppInfo.apiVersion` is lower than what an app originally set and expected based on the queried Vulkan instance and physical device versions, all kinds of weird things happen when expected promoted-to-core extensions are no longer treated as available by RenderDoc [^1]. [^1]: A good example is an app enabling Ray Tracing extensions on a Vulkan 1.2+ device: the buffer_device_address extension is in core here and not explicitly enabled by at least our application, but if an instance initializer for Vulkan 1.1 "won" the race condition (that's the version `android framework` uses as of writing, even on Android 16) RenderDoc doesn't load the extension function pointers. Ray Tracing (currently) forces RenderDoc to query BDA for every buffer and crashes at the first occurrence on a NULL PFN. Similar NULL pointers occurred in our app when relying on `vkWaitSemaphores()` from the promoted `VK_KHR_timeline_semaphore` extension for example. The most trivial and correct solution is to no longer update this global state, but instead keep it as `const` data and copy it to the stack for modification and passing through to `vkCreateInstance()` without ever leaking `apiVersion` outside of the calling function.
RenderDoc is a frame-capture based graphics debugger, currently available for Vulkan, D3D11, D3D12, OpenGL, and OpenGL ES development on Windows, Linux, Android, and Nintendo Switch™. It is completely open-source under the MIT license.
RenderDoc is intended for debugging your own programs only. Any discussion of capturing programs that you did not create will not be allowed in any official public RenderDoc setting, including the issue tracker, discord, or via email. For example this includes capturing commercial games that you did not create, or capturing Google Maps or Google Earth. Note: Capturing projects you created that use a third party engine like Unreal or Unity, or open source and free projects is completely fine and supported.
If you have any questions, suggestions or problems or you can create an issue here on github, email me directly or come into IRC or Discord to discuss it.
To install on windows run the appropriate installer for your OS (64-bit | 32-bit) or download the portable zip from the builds page. The 64-bit windows build fully supports capturing from 32-bit programs. On linux only 64-bit x86 is supported - there is a precompiled binary tarball available, or your distribution may package it. If not you can build from source.
- Downloads: Stable and nightly builds: https://renderdoc.org/builds ( Symbol server )
- Documentation: HTML online, CHM in builds, Videos
- Contact: baldurk@baldurk.org, #renderdoc on OFTC IRC, Discord server
- Code of Conduct: Contributor Covenant
- Information for contributors: All contribution information, Compilation instructions
- Community extensions: Extensions repository
Screenshots
 |
 |
|---|---|
 |
 |
API Support
| Windows | Linux | Android | |
|---|---|---|---|
| Vulkan | ✔️ | ✔️ | ✔️ |
| OpenGL ES 2.0 - 3.2 | ✔️ | ✔️ | ✔️ |
| OpenGL 3.2 - 4.6 Core | ✔️ | ✔️ | N/A |
| D3D11 & D3D12 | ✔️ | N/A | N/A |
| OpenGL 1.0 - 2.0 Compat | ✖️ | ✖️ | N/A |
| D3D9 & 10 | ✖️ | N/A | N/A |
| Metal | N/A | N/A | N/A |
- Nintendo Switch™ support is distributed separately for authorized developers as part of the NintendoSDK. For more information, consult the Nintendo Developer Portal.
Downloads
There are binary releases available, built from the release targets. If you just want to use the program and you ended up here, this is what you want :).
It's recommended that if you're new you start with the stable builds. Nightly builds are available every day from the v1.x branch here if you need it, but correspondingly may be less stable.
Documentation
The text documentation is available online for the latest stable version, as well as in renderdoc.chm in any build. It's built from restructured text with sphinx.
As mentioned above there are some youtube videos showing the use of some basic features and an introduction/overview.
There is also a great presentation by @Icetigris which goes into some details of how RenderDoc can be used in real world situations: slides are up here.
License
RenderDoc is released under the MIT license, see LICENSE.md for full text as well as 3rd party library acknowledgements.
Compiling
Building RenderDoc is fairly straight forward on most platforms. See Compiling.md for more details.
Contributing & Development
I've added some notes on how to contribute, as well as where to get started looking through the code in Developing-Change.md. All contribution information is available under CONTRIBUTING.md.