Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
NOTE: A crash bug with D3D11 & MSAA has been found in v0.22. It's recommended that you instead use v0.23 with the fix included.
Binary zips and installers for this release (and others) can be found on the builds page. Both stable and beta builds are up to date with this release, but beta builds will be updated more regularly. You can choose which type of release you want to install and receive updates for.
Almost exactly 1 year ago from the time this release was posted, RenderDoc was first released to the public. Initially the source code was not included, that came a few months later in early May 2014.
RenderDoc was a hobby project that I had worked on entirely in my spare time for about 18 months, and I had no idea of what kind of reaction to expect. The positive feedback and hearing how the tool has proven useful to people finding and fixing bugs has been very rewarding, and I really appreciate everyone who has taken the time to try it out, use it, as well as to everyone who has given feedback, reported bugs or contributed to the repository.
RenderDoc has come a long way in the last year, and I know that it has a lot farther to go in many respects. I'm looking forward to seeing where it goes in the future, but I wanted to take this opportunity to thank everyone!
The big push for release v0.22 has been OpenGL support. While it's not quite at feature parity with D3D11 (and there's no linux UI - yet!) it's definitely at a place where I would encourage everyone to use it in anger and give feedback. I've tested it across many modern GL projects and titles between windows and linux and while it still has work to do, it's in a good shape. Please let me know how you get on with it!
RenderDoc supports OpenGL core profile 3.2-4.5 inclusive, which means it has full support for modern GL techniques like persistent mapped buffers, MultiDrawIndirect, and everything in Core OpenGL 4.5.
Note: Only core profile 3.2-4.5 is supported. This means that any old codebases using older versions of GL or the compatibility profile functionality may not capture and replay. For more details on the exact limitations and requirements at the moment check out the wiki page.
I'd like to give particular thanks to Matías N. Goldberg, who tested RenderDoc's early OpenGL support on Ogre3D's 2.1 modern GL branch. Thank you for your endless patience while I fixed all the broken stuff!
While it's not a particularly stable and solid API just yet, RenderDoc does export some functions for use with applications that want to integrate RenderDoc more tightly into their codebases. This is just a warning to those of you who are using this API that there have been some changes since v0.21, and you should be careful to make sure you update properly. I'd recommend always checking
RENDERDOC_API_VERSION as this will allow me to bump the version on any breaking API changes. In future when the API is more finalised and 'official', this should not happen often.
In particular this time, the CaptureOptions structure has changed a little, and
wchar_t * strings are now expected to be
char * UTF-8 strings.
- RenderDoc can now act as a simple image viewer. This is a difficult feature to make obvious, but you can now load images as you would logfiles - either via file -> open, or just dragging into the viewer. The texture viewer controls work as normal. RenderDoc supports .dds, .hdr, .exr, .bmp, .jpg, .png, .tga, .gif, and .psd, and the dds file support should include any DXGI format and any number of slices, cubemap faces or mips - things traditional image viewers have a harder time with. The save tool has also been updated to save .exr files.
- The mesh preview window has had several improvements. Selecting instances in an instanced drawcall should now behave correctly in all circumstances, and choosing how the 3D preview will display is much more flexible. You can now right click on any column headers on input or output to choose which one will be used as position data for rendering, and which will be used as 'secondary' data, to optionally be displayed as a solid colour in the preview.
- When using the pixel history feature, MSAA targets are now fully supported and the sample debugged will be the sample you are currently viewing (if you're viewing the average resolved image, any sample will be chosen). Also when a pixel is overdrawn by several fragments in a single drawcall, you can now select the fragment you want to debug and right click on it to see the result from that fragment, even if it's later overwritten.
- There is now a very rough and early python scripting interface. You can open either an interactive shell or run a script (loaded from disk or edited live), and there is a simple python object that allows access to most of the raw data and control that renderdoc offers, so you can see all textures in the log, browse the drawcalls, cause the UI to jump to a drawcall or view a texture, etc.
- Most overlays now support MSAA targets, so you can see sample-accurate depth-test results etc.
- Most UI windows now have copy-paste handlers, so e.g. in the constant buffer window you can select any number of constants and hit ctrl-c to copy them to the clipboard.
- The D3D11 pipeline state can also now export the entire state to HTML (example exported pipeline) - this can be useful for comparing between two logs or two events to see if anything has changed.
- When capturing an application that spawns child processes (such as a launcher application), the UI in the connection dialog has been improved. It will now show each child process that exists and give you the option to open a new connection to that process instead of the one originally launched. Also if a process only has one child when it exits, the connection will automatically transfer to the child process, in the assumption that it is the one you wish to trace.
- It is now possible to activate a 'global process hook'. Read the documentation before using this feature as it can be dangerous to use without understanding. It will automatically insert a tiny dll into every new process started on the system, and when the target process that you want to inject is launched, this tiny dll will load renderdoc. This can be useful in extreme cases to capture programs that are launched indirectly or via pipes from another launcher process.
- When capturing you can now enable an option to verify Map() overruns. This will activate in the captured frame, and insert a marker value at the end of each Map(). If the marker value is modified a message box will appear letting you know and giving you the option to breakpoint in the debugger to trace the problem.
- While in the application, captured frames now 'decay' from the overlay after a certain length of time. If you're trying to capture some particular frame glitch and you end up with a lot of frame captures that didn't hit it, then this keeps the overlay from having a massive long list of captured frames.
- Although largely untested since it's very rarely used in the real world, RenderDoc should now support DXGI 1.2/1.3 and DX11.2. The exception being tiled resources in DX11.2 as I couldn't find a single sample or example code that used them - if you have anything let me know so that I can write support against a real program.
- The pipeline view has had a few tweaks to make better use of space - in particular rarely used sections like UAVs and shader linkage on D3D11 will vanish if there is nothing bound, to make room for the other sections. Also when moving between drawcalls if at all possible the pipeline view will try to avoid scrolling, so that you can more easily compare higher slots between two drawcalls.
- When running on a system that doesn't have Feature Level 11 hardware, RenderDoc will now fall back to WARP software rendering rather than failing to replay. While slow, for simple cases this might mean it is still usable.
- When shader debugging, hovering over a register in the disassembly will now show a tooltip with all three possible interpretations of the register. This is mostly useful if a register has mixed float and int data and you want to see them both quickly without needing to form complex watch expressions.
- The texture viewer has had a few tweaks. The visible channels and mip/slice selections are now stored per-texture by default. You can revert this behaviour in the options menu if you wish, but this means that if a given texture has useful data in the alpha channel, you don't have to keep toggling the channels if you are moving between it and another texture that you wish to view RGB. The status bar now also includes normalised UV co-ordinates, and has been changed to fixed width font and padded text as much as possible to reduce the churn you get when moving the mouse over a texture.