Granite VS renderdoc

I'm currently writing my first Vulkan rendering abstraction. I'm using Granite as a reference, and following along vulkan tutorial's steps. I deviated from their design by using the Vulkan Memory Allocator and the dynamic rendering extension. I implemented Vertex buffers, index buffers, UBOs, push constants and samplers. The only thing I still need to do is depth buffering.

heh https://github.com/baldurk/renderdoc#readme is all "RenderDoc is intended for debugging your own programs only. Any discussion of capturing programs that you did not create will not be allowed in any official public RenderDoc setting, including the issue tracker, discord, or via email" but the 3 of the 4 screenshots are of dota2 :-D

Still, that looks handy for sure

He's pretty clear about it every time it's asked. Tracing copyrighted games is legally questionable, and tools like RenderDoc are often abused by people to do illegal asset ripping/reselling.

Baldur explains why he won't implement bindless texture support in this issue: https://github.com/baldurk/renderdoc/issues/850

Unfortunately the main developer for Renderdoc is against adding ray tracing support : https://github.com/baldurk/renderdoc/issues/2317

RenderDoc bug report: https://github.com/baldurk/renderdoc/issues/2800

Remember that Renderdoc is open source: https://github.com/baldurk/renderdoc/. This means you can build it with symbols and attach a debugger.

Renderdoc works by inserting itself as a Vulkan layer, which means it can change the output of functions if it so chooses. As you can see in the RenderDoc version of vkEnumeratePhysicalDevices it changes how devices are returned, and this likely is the reason the order changes.