Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
- Windows and linux support is as complete as it gets, not quite on par with D3D11 yet but approaching it as things improve.
- OS X support does not exist yet, but in theory is not far beyond Linux support.
- RenderDoc supports all of OpenGL 3.2 - 4.5 core.
- Only Core profile 3.2+ is supported - there are a couple of simple concessions to compatibility mode like using VAO 0 and LUMINANCE textures, but by and large the compatibility profile will not be supported.
- If you create your GL context via CreateContextAttribs, I assume that the subsequent rendering is Core compatible (even if you create a compatibility profile). This is to err on the side of being tolerant, but any use of compatibility profile code will break, or at best won't be captured. If you don't use CreateContextAttribs RenderDoc will refuse to capture. This should catch most old GL2 and before programs.
- We assume that the replay application can create a Core 3.2 profile and have a few extensions available. This is on top of any extensions used in the captured frame itself.
- EXT extensions are supported case-by-case depending on ease of implementation and how commonly used they are. Things like EXT_direct_state_access, EXT_texture_compression and other common ones are supported.
- RenderDoc modifies the extension glGet* results, so unsupported extensions are not returned to the program. You can see a full list of supported, planned, and will-not-support extensions (assuming driver support also, of course) in the code.
- Vendor extensions probably will not be supported unless there's heavy demand, and will be supported case-by-case if so.
I'm currently testing as many programs as I can get my hands on to get application compatibility improved. If you have a Core 3.2 application (or even compatibility that mostly only uses core) please test it out and let me know how it goes!
- Multiple contexts used simultaneously on different threads.
- Shader debugging. This will be implemented by compiling GLSL to SPIR-V using glslang, and then debugging SPIR-V. This way the SPIR-V debugging will also be usable for Vulkan captures.
- Pixel history
There's also plenty of optimisation to do, there are a lot of slow functions that could be vastly sped up.
I've had to work around a few weird or inconsistent behaviours, or bugs (confirmed or otherwise) on different vendors. I'm listing them here although they're all centrally located in the code, just for visibility.
- GL_VERTEX_BINDING_BUFFER isn't recognised on AMD, but fortunately there's another bug that means GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING behaves incorrectly and does what we want.
- Known/reported bug.
- Detected by doing this query and checking for error. To work around use GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING instead.
- I've seen a case where querying for the compressed size of GL_TEXTURE_CUBE_MAP_POSITIVE_X will return the size of the whole cubemap, not just that face. I haven't seen this recently so I'm not sure if it was a bug in my code, but I was fairly sure it happened. It's harmless to have the check in, so I've left it.
- Not reported until I can reproduce consistently.
- Detected by querying for the size of a known dimension cubemap, and looking at the returned size. If it's returned the cubemap size, divide by 6 whenever doing future queries.
- GL_POLYGON_MODE is incorrectly reported as removed from core profile on AMD.
- Known/reported bug.
- Detected by doing this query and checking for error. To work around just assume GL_FILL always instead (pretty safe assumption, but could be wrong in rare circumstances).
- Doing a glCopyImageSubData on compressed mips less than the block size throws GL_INVALID_VALUE on AMD. I'm not sure based on the spec exactly how you should copy these, but the only sane way seems to be to specify their size in texels even when it's not a whole block size.
- Known/reported bug.
- Detected by doing a copy on a 1x1 compressed texture and checking for error. If detected we do a slow readback to the CPU and reupload to GPU for those mips. Maybe there's another way to copy on the GPU.
- Note that compressed cubemaps also fail to copy properly with this function (possibly a related bug)
- On some implementations, FBOs or VAOs are shared between contexts. This might not be a bug but just a weird quirk of EXT_framebuffer_object specifying them as shared.
- Not reported, might be valid.
- We detect this by creating shared contexts and seeing if glIs returns true on the shared context for FBOs/VAOs created on the main context. To work around we just treat them as shared objects, like we do for textures etc.
- On nvidia, copying a D32_S8 texture with glCopyImageSubData can cause extreme problems.
- Reported (via email 2014/12/05).
- We can't detect this given the nature of the problems, so for now we don't copy these textures until I can find a workaround.
- On nvidia at least (not tested the others much) mixing and matching old style glVertexAttrib*Pointer functions and new vertex attrib + vertex buffer binding functions seems buggy.
- Not reported (need solid repro and at the moment it's just 'in renderdoc').
- Can't easily be detected, so we just use the spec definition of those functions in terms of the new vertex attrib + vertex buffer semantics, and apply that definition ourselves manually.
- AMD doesn't report entry point glVertexArrayVertexAttribDivisorEXT for EXT_direct_state_access + ARB_vertex_attrib_binding.
- Not reported (trivial, easy to work around)
- If the function isn't present just do it manually by push/popping VAO binding.
- AMD throws an error when calling glGetProgramPipelineiv with pname=GL_COMPUTE_SHADER.
- Known/reported bug.
- We just detect if this query fails on startup, and skip doing it. It's only used to find the program to fetch uniform subroutine values and no-one uses them anyway. If we needed to, we could fetch the program for that stage ourselves from our cached data.
- On nvidia there are several issues with glClearNamedFramebufferfi. On 32-bit the function actually seems broken as it causes VS to throw an exception that ESP wasn't properly saved, either buggy assembly or wrong calling convention. On either 32 or 64-bit, calling the function can sometimes throw invalid errors.
- Reported (via email 2015/02/25).
- We always enable the workaround for this one, as it's too risky to leave the buggy behaviour on 32bit.
- g_truc sample pack. All working, windows and linux tested.
- Superbible 6 samples. All working, windows and linux tested.
- bgfx samples. All working aside from bkaradzic/bgfx#209. Windows tested.
Uses currently unsupported functionality
- RAGE - uses compatibility functions, fails to start - possibly due to functions it needs not being returned by renderdoc.
- Wolfenstein: The new Order - uses a couple of compatibility functions. A few allowances were made for luminance/alpha/intensity functions, but loading up in game shows completely black (before capturing), so something else is broken.
Captures & replays, no known problems
- Ogre3D 2.1 Modern GL branch - Captures & replays successfully, tested on windows.
- Tropico 5 - Captures & replays successfully, tested on windows.
- Metro Redux - captures & replays successfully. Captured from linux as it's unknown if the opengl back end is usable on windows. Linux captures replay on linux & windows.
- Starbound - Tested on windows.
- Planetary Annihilation - captures & replays successfully. Tested on windows.
- UE4 - captures & replays successfully. Elemental demo tested, windows and linux tested. (Linux captures replay on linux & windows). - Currently UE4 uses coherent persistent maps, which are very slow by their nature. I recommend you disable OpenGL.UBODirectWrite and OpenGL.UseStagingBuffer to bypass persistent map usage.
- Clockwork Empires - captures & replays successfully, windows tested.
- Build A World EDU and IrrlichtBAW - captures & replays successfully, windows and linux tested. Likes to use coherent persistent maps, especially on Intel HD Graphics, so capture is extremely slow.