RenderDoc is a graphics debugger that was first launched over 4 years ago. Today they reached the massive 1.0 milestone! RenderDoc is open source under the MIT license, available for Windows, Linux and Android. RenderDoc is capable of working with the following APIs:
The 1.0 release brings several new features, the biggest of this release has to be the addition Android support, although Windows users might appreciate the newly rewritten Qt client.
Full details of the release from the release notes:
- The Qt RenderDoc UI is now shipping on Windows, the previous .NET winforms UI has been completely deprecated and removed. Aside from better consistency between platforms this comes with a number of benefits to Windows users.
- Qt natively supports high-dpi displays, which should ‘just work’ including per-monitor DPI awareness.
- The Qt UI doesn’t require an interoperability copy-layer between C++ and C# so should be more efficient.
- Likewise Qt’s rendering and updating is generally faster and the UI should feel more responsive.
- Qt being C++ greatly increases my abililty to diagnose crashes from crash dumps as I actually get a minidump, not just an exception callstack.
- RenderDoc now supports Android, with both OpenGL ES 2.0 – 3.2 and Vulkan 1.0, thanks to contributions from Samsung and Google.
- Any android application is supported as long as it is built as debuggable, there is no patching or setup step needed, you just select your device and run the application. A step-by-step guide is available in the docs.
- The workflow is deliberately almost identical to the familiar process on Desktop. Aside from selecting the Android device as the active replay context, you browse to the desired package, launch it, and when you open captures they appear to open locally even though the replay happens on the device.
- All standard features for GL and Vulkan are supported on android, subject to hardware support for certain features.
- This also comes with the same requirements as GL, such as all contexts being created as shared.
- The internal serialisation system used for saving captures has been completely rewritten to be much more flexible and future-proof. This enables a lot of nice features in this release and opens the door for some interesting features in future. This is the reason behind v1.0 not being able to open v0.x captures.
- It’s now possible to export capture files to another format, such as human readable xml. This XML lists all of the function calls recorded in the capture and all the parameters and structures. This XML can be edited, added to, changed, and then re-imported back into a capture file for replay. Future RenderDoc versions may include more formats.
- Previously any GL calls that were serialised the same way – e.g. glTexImage2D, glTextureImage2D, glTextureImage2DEXT, glTextureImage2DARB were all serialised and displayed as one of these, regardless of which you called. Now gl functions correspond to the exact function called.
- Errors that happen during loading of a capture can now in most cases be caught and gracefully propagated to the UI. This means instead of the whole program crashing, you at least get a message indicating that there’s a problem replaying the capture.
- RenderDoc now saves thread IDs, timestamps, and durations for every function call. This can be exported in chrome tracing format, and in future may be displayed in-UI.
- Resource Inspector
- As a side bonus of the above serialisation refactor, there is a new centralised resource inspector panel. This panel contains a list of all resources available in the capture, and lists the details of the functions used to create and initialise them.
- It also shows the links back and forth between related or dependent resources.
- Resources with special viewers like buffers, textures and shaders have links from the resource inspector to go to those viewers.
- Everywhere in the UI that resources are mentioned, they link back to the central resource inspector panel.
- The RenderDoc python API has been revamped to be an explicitly designed and carefully documented interface into RenderDoc’s internals
- The previous API was autogenerated from reflected C# internals, which meant that any internal warts were exposed and there was no documentation beyond code commenting.
- The new API has been designed to be more naturally pythonic where possible and present a more consistent and unified interface.
- Likewise all API endpoints and structures are documented with python docstrings for
help(), as well as being generated into the sphinx documentation.
- RenderDoc now has features for annotating capture files
- A general capture comments system now allows saving some arbitrary text with a capture, and it will be displayed first and foremost when opening a new capture. This could be used for storing a build date or version, some reproduction information, or other metadata that is useful to store embedded in the capture file.
- Bookmarks can be saved with the capture, so that you can save an important event with the capture before sharing it, making it easier for someone else (or you in the future) to jump to the most useful event.
- The resource inspector allows for renaming of any resource, which can be used both to give names to important resources that only have an autogenerated name, as well as renaming resources based on how they are used within the particular capture. If one buffer in particular is related to a bug, it can be renamed to highlight it.
- AMD have provided performance counter integration into RenderDoc. This includes both access to all of their hardware counters on all APIs that RenderDoc supports, but also a simple sortable table view of counters for browsing the results and finding hot drawcalls.
- This does not mean RenderDoc is a full-featured profiler! However it can be useful to obtain these counters on existing RenderDoc frame captures.
- The bug reporting system is much improved. As well as being a more streamlined experience, it tries to help users provide more useful bug reports.
- Most bug reports without contact information and without a reproduction capture cannot be resolved and end up getting ignored, only a small fraction end up resulting in actual fixes.
- To address this, the bug reporter encourages users to put in their email address and stores it for any future bugs.
- The user is also able to opt-in to upload the most recently loaded capture file. If able to share this will greatly help with reproducing any bug.
The source code and precompiled binaries are available on Github.