Here is a list of commonly asked questions about RenderDoc. Feel free to contact me if you have another question that isn't covered here or in this document.

Many specific tasks or functions are detailed in the "How Do I... ?" sections. These sections each take a feature or element of a workflow and explain how it fits into the program as a whole as well as any details of how it works. If the task you have in mind isn't listed there you might find something similar, or you might find a related feature which can be used to do what you want. If the feature you want doesn't seem to exist at all you might want to check the to see if it's coming soon - if it's not on that list please feel free to contact me and request it! Baldur Contact. It has often been that simple features are very quick to implement and the prioritisation and scheduling of features is fairly fluid at this stage in development.

Although several tools do already exist for graphics debugging, none of them quite suited the functionality I desired and I would often find myself wishing for a feature of one in another and vice versa. In addition to this, although the functionality overlaps to some degree many of these tools were primarily designed around the profiling of applications rather than debugging. While being able to inspect the state and contents of resources does often suffice for debugging, it's not necessarily the ideal workflow and often it can become cumbersome. In principle I didn't see any reason why I couldn't write a home-brew graphics debugger with some fairly simple operating principles. While there were a whole lot of caveats and little stumbling blocks along the way, the original design has pretty much stayed consistent since the project was started back in July 2012. If you're interested you might want to read about .

All of the good names were taken :-(.

At the moment there's just me at the wheel - feel free to contact me at Baldur Contact if you have anything you'd like to ask or suggest. I use a github repository Issues on github https://github.com/baldurk/renderdoc/issues for tracking bugs and feature requests so that's the best place to file an issue. I work on RenderDoc in my spare time but I will do my best to get back to you and work with you if you have any issues that need attention. If you have a question or something to discuss you can also post on the forums Forums on CryDev.net http://www.crydev.net/viewforum.php?f=379 .

If you installed RenderDoc via the installer package rather than the zip folder, the option is available there to associate RenderDoc's file extensions with the program. Otherwise you can set them up from the . RenderDoc will elevate itself to set up these file associations, but otherwise will not hold on to administrator permissions. RenderDoc associates .rdc and .cap with itself when desired. The .rdc files are the logfiles output when you capture inside an application. .cap files describe the set up of a particular capture, and can be used to quickly re-launch a capture preset. If .rdc files are associated with RenderDoc a thumbnail handler is set up, so that in explorer you'll get thumbnail previews for your captures. Note that if you move the directory that RenderDoc is you will need to re-configure the file associations as the registry entries contain absolute paths.

Currently RenderDoc only supports D3D11 (including the D3D11.1 extensions where available). In future API support is planned for at least OpenGL and D3D9 as soon as time and scheduling allows - OpenGL support is under development. Support for Mantle would be nice but I can't promise it just yet until the API is public. Other APIs could be supported once the source is open as I've tried to structure things such that different back-ends can be slotted in without significant code changes.

Everything RenderDoc relies upon is stored in %APPDATA%\RenderDoc. You can back up and restore this directory at will as nothing stored in there is machine specific aside from things like recent file lists. Deleting this folder will also reset RenderDoc to the defaults - if you uninstall RenderDoc this folder will not be deleted. RenderDoc doesn't install any registry keys aside from those to set up file associations.

RenderDoc uses TCP and UDP ports 38920-38927 consecutively for remote access and control (ie. capturing remotely) for each new program that is opened on a machine. Note that even if you initiate a capture locally these ports are still opened for listening. These are the ports that are probed on a remote host to see if a connection exists. RenderDoc also uses TCP and UDP ports 39920 for remote replay connections, for when a remote host is used to replay and analyse the log.

RenderDoc is licensed under the MIT license so that it can very naturally be open-sourced at a later date. Currently the precise timescale is not defined, but if you'd like more information you can always get in contact to find out how things are looking. In general the source will be opened up once the codebase has stabilised and is more feature complete. Currently it's not in final shape and still changing a lot on a day-to-day basis so it isn't really in a condition where patches could practically be accepted.

Currently RenderDoc only supports Feature Level 11.0 and above for D3D11. Lower levels may capture successfully but if uou can't create a FL11.0 device they will not replay.

At the moment RenderDoc only begins capturing deferred command lists at the point that you trigger a capture. If you replay command lists from before this, RenderDoc will fail to capture the frame and try again next frame (and eventually give up after a few retries). To change this behaviour, enable the Capture all cmd lists option - see that page for more details. This will capture all command lists from the start of the program, ready for when you decide to capture a frame. This currently has a fair overhead but it's something I want to improve in future

If you start a Map() before a Present() call then call Unmap() after the Present() during the frame RenderDoc wants to capture, RenderDoc won't have intercepted this call and so will fail to capture this frame and try again next time. This usually only invalidates the first frame you try to capture, but if you Map() many resources, and Unmap() them one by one in subsequent frames, you could hit this failed capture scenario many times in a row. Currently the only solution to this is to change the pattern of Map()/Unmap() such that they are contained within a frame.