Unable to use Renderdoc

[ezorzin]

Describe the bug

I am unable to use Renderdoc with a python program using wgpu-py.

To Reproduce

Run a program using wgpu-py thrrough RenderDoc and try to capture a frame: it is not possible because it says "API: none", also the capture buttons stays grayed out.

Observed behavior

Using the Renderdoc "Capture Child Processes" option makes a little difference: the Renderdoc text overlays starts on the python's app graphics view but hangs after a few frames. F12 capture feature does not work.

The documentation says:
**You can use adapter.request_device_sync() to provide a directory path where a trace of all API calls will be written. This trace can then be used to re-play your use-case elsewhere (it’s cross-platform).

Also see wgpu-core’s section on debugging: https://github.com/gfx-rs/wgpu/wiki/Debugging-wgpu-Applications**

but I can't find a way to tell to adapter.request_device_sync() to use a such a path.
By inspecting the signature of it by doing:

import inspect
ADAPTER = wgpu.gpu.request_adapter_sync(power_preference = "high-performance")
print(inspect.signature(ADAPTER.request_device_sync))

what I get is:
(*, label: 'str' = '', required_features: 'List[enums.FeatureName]' = [], required_limits: 'Dict[str, Union[None, int]]' = {}, default_queue: 'structs.QueueDescriptor' = {}) -> 'GPUDevice'

which does not help me understanding what to do.

Screenshots

I attach a screenshot of what I see during this process:

Your environment

Windows 11
pygame 2.6.1 (SDL 2.28.4, Python 3.13.5)
NVIDIA RTX 2000 Ada Generation (DiscreteGPU) via Vulkan
Package Version

---

altgraph 0.17.4
cffi 1.17.1
glfw 2.9.0
imageio 2.37.0
numpy 2.3.2
packaging 25.0
pefile 2024.8.26
pillow 11.3.0
pip 25.2
pycparser 2.22
pygame 2.6.1
pyglm 2.8.2
pyinstaller 6.15.0
pyinstaller-hooks-contrib 2025.8
pywin32-ctypes 0.2.3
rendercanvas 2.2.0
setuptools 80.9.0
sniffio 1.3.1
wgpu 0.23.0

Any suggestion is welcome, thanks!

[Vipitis]

Hey there,

I have been looking into making Renderdoc work for a while. I have a PR branch with a renderdoc example ready at #728 however you should be able to just run the minimal example. Even without debug symbols. I believe the documentation might be outdated since tracePath changed in v25 and I haven't tested that ever.

Can you test a few combinations of GUI and BackendAPI? I have a suspicion that Renderdoc might capture the GUI frame but not the rendering context. I have seen something like this with Dx12 (you need to press F10 to cycle there). Try clicking on the Child Process inside the Renderdoc Gui first and then try to do a capture.

Perhaps you can share the script and Renderdoc launcher setup you so I can try this locally on my machine.

[ezorzin]

You can try the standard triangle example

Capture buttons are grayed out, F12 (or F10) not working.

[Vipitis]

I tried on my end with different python versions (3.9 and 3.12) and with the Capture Child Processes check or unchecked, it always picks up the child process. According to the docs it will hook into a single child process automatically. But that hasn't always been the case for me in previous versions.

In those cases I had to click on the python.exe in the child process list (different PID) here

does that make a difference for you?

[ezorzin]

Enabling the Capture Child Processes and then clicking on the PID in the Child Processes panel worked for me for the Triangle example! I did not understand I had to do that.

When I try doing the same to my original application it happens that I am able to use RenderDoc only if I make my window small enough to stay under 99% (monitored with the NVIDIA tools) of GPU usage (it is a raymarching shader, at the moment the bigger the window, the more it has to compute and hence the more GPU consumption):

To me it is reasonable to think there is a problem of memory management, or something like that, that causes my app to crash when I try to use too much GPU resources: when this happens, the GPU goes at 99% for a moment, then my app becomes unresponsive (Not Responding, as the first pictures I sent in this thread says), the GPU goes back at 1-2% but as soon as all this happens then RenderDoc stops working and my app never returns responding.

But I don't think it a problem of my application, because if I run it alone without RenderDoc then it runs fine, maybe slow but still without crashing, also if I make my window big enough to reach 99% of GPU:

For this, I believe there is some kind of problem within RenderDoc while running on low resources.
It would be ideal to figure out what it is, because I was thinking to use RenderDoc on purpose to debug my application: I could not expect it making the latter crashing :)

I have no idea at what level the crash occurs.

[Vipitis]

Good to hear your got it at least working. However the crashing seems odd to me. I am no Renderdoc expert, I can recommend the Renderdoc Discord as the dev is really responsive there(feel free to ping me there too). Raymarching shader shouldn't be a memory issue since you are not creating large resources.
Are you able to share your application so I can give it a go with my hardware?

[ezorzin]

At the moment I am not able to share my entire application, but I appreciate you asked for it in order to help me :)
However, I now realised that in my case RenderDoc is not going to be so useful as I thought in the beginning: in raymarching everything happens inside a single texture mapped onto a single quad made of two triangles, therefore very little graphics information is captured by RenderDoc!

[Vipitis]

If you only have a single full screen renderpass you can even use a single triangle which gives marginally better performance.
Renderdoc can still help to debug and edit the renderpass but it won't directly help you with crashes or performance issues in the shader itself. for such problems you can try profiling tools, I believe the Nvidia one is called Nsight but there might be a couple more. For me on Intel GPU I got familiar with GPA, but that's now discontinued - but it allowed you to profile down to the ISA or get cycles per line.

For crashes I am honestly not sure, my approach is usually to simplify the shader untill it no longer crashes and then recreate a minimal case - file an issue upstream. I have done that for quite a few quirks in the naga glsl front end, but most of them haven't been addressed in years :/ so if you find anything I might be able to at least help file it. I even thought about a little script to automate this bisection.

As for the Renderdoc crash due to resolution - that might be something to file with the devs there as it could be some issue they need a good recreation for.

[ezorzin]

Meanwhile I refactored my original code: now I render my scene inside a (small) texture in a compute shader, then I pass it to the fragment where I do an upsampling. This saves me a lot of computation, and now I have a decent resolution/antialiasing at full screen 30FPS... but this is out of scope here and for the moment I think I will concentrate on my app; eventually I will try asking about RenderDoc among the members of its community, as you suggested.

Thanks