baldurk
9876b6e5cb
* Originally when I added the EXT_dsa emuluation, I targeted it specifically to only those functions that I call outside of the replay loop, for internal analysis purposes. For that reason the emulation was only applied to a separate hookset, and only during replay (not during capture). * However this doesn't account for some of the streamlined serialisation of functions like glBufferStorage, glBufferData, etc. To simplify code paths, I 'promote' all variants of these types of functions to the EXT_dsa variant (except ARB_dsa for texture functions which is actually different by not requiring the texture target parameter). * Note: most of these functions were emulated already (except three - glNamedBufferStorageEXT, glTextureBufferEXT and glTextureBufferRangeEXT) but on replay we didn't use the internal hookset, just the normal one, which was not emulated. * Rather than try to decide when these should use the internal hookset and when the regular one, or switch them all over to the internal hookset, instead re-evaluate the reason for a separate hookset in the first place: Emulating functions separately means the original func pointers are returned during capture time, for unsupported extensions. * However mesa has proven that unsupported extensions don't have to return NULL, as it's undefined what they return - they should not be called if the extension isn't available. So in actual fact there's little harm to be done by emulating in-place and returning some different pointers to the application. In the worst case, they get a bit of EXT_dsa emulation themselves.
RenderDoc
RenderDoc - a graphics debugger, currently available for Vulkan, D3D11, D3D12, and OpenGL development on windows.
If you have any questions, suggestions or problems or you can create an issue here on github, email me directly or come into IRC to discuss it.
- Downloads: https://renderdoc.org/builds
- Documentation: renderdoc.chm in builds, https://renderdoc.org/docs, http://www.youtube.com/user/baldurkarlsson/
- Contact: baldurk@baldurk.org, #renderdoc on freenode IRC
- Information for developing/contributing: CONTRIBUTING.md, Compilation instructions, Roadmap
- Code of Conduct: Contributor Covenant
Screenshots
 |
 |
|---|---|
 |
 |
API Support
| Status | Windows | Linux | |
|---|---|---|---|
| D3D11 | Well supported, all features. | ✔️ | ✖️ |
| OpenGL 3.2 core+ | Well supported, most features.* | ✔️ | ✔️ |
| Vulkan | Well supported, most features. | ✔️ | ✔️ |
| D3D12 | Well supported, most features. | ✔️ | ✖️ |
| OpenGL Compatibility, GLES | No immediate plans | ✖️ | ✖️ |
| D3D9 & 10 | No immediate plans | ✖️ | ✖️ |
| Metal | No immediate plans | ✖️ | ✖️ |
- D3D11 has full feature support and is stable & tested. Feature Level 11 hardware is assumed - Radeon 4000/5000+, GeForce 400+, Intel Ivy Bridge, falling back to WARP software emulation if this hardware isn't present.
- *OpenGL is only explicitly supported for the core profile 3.2+ subset of features, check the OpenGL wiki page for details.
- Currently the Qt UI is only used on linux. It is working well with a TODO list of remaining work. Work is on-going for it to replace the .NET UI on windows.
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 master 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.
Contributing & Development
Building RenderDoc is fairly straight forward. See CONTRIBUTING.md for more details.
I've added some notes on how to contribute, as well as where to get started looking through the code in CONTRIBUTING.md.