Renderdoc, tokio, cargo run

Does anyone have renderdoc working with tokio ?

My problem:

qrenderdoc => cargo run -- wgpu app runs, but no overlay (no capture happening) ?

qrenderdoc => .../debug/app_name -- tokio runtime error

Does anyone have an example of renderdoc + tokio working ?

If not, does anyone have renderdoc + non-tokio-rust working? The app is not huge, I can rip out the tokio async dependency.

this is the wrong way, because you are running cargo through renderdoc, which doesn't make draw calls itself.

this is the correct way to load an executable through renderdoc, but you gotta solve the runtime error.

I don't think renderdoc has anything to do with tokio or anything rust specific. what's the tokio runtime error exactly?

renderdoc only intercepts graphics API calls and records the parameters and states for later analysis. it does this transparently and the application shouldn't notice a behavior difference (except for performance impact).

I guess maybe it's some environment dependency in your program. i.e. loading resources relative to current directory.

1 Like

I no longer have the error. Switched over to async_std, and I appear to have captured a frame via F12.

How do I pick a pixel and get all the pixel shader info ?

https://renderdoc.org/docs/how/how_inspect_pixel.html#pixel-history

this is amazing.

you found it!

yeah, the first time I use renderdoc, it feels magic. you can even edit shaders and see the effect immediately! have fun with the shaders!

btw, if you use the DebugPrintf extension, the output messages is also captured by renderdoc, you can find them by the side of drawcalls in the event viewer. I think the pipeline states can also show shader messages, I can remember now.

1 Like

Can you tell me a bit more about your Renderdoc workflow ?

I have something working, but it is a bit tedious (something like 20+ clicks to forward chrome/webgl2 to local/wgpu to renderdoc to capture to debug shader). Are you using python / rust to script renderdoc, or doing everything manually ?

sorry, I don't have a workflow either, as I said, I was using vulkan natively, not web stuff, and my program is really simple, I didn't really do much of debugging. I just setup renderdoc to automatically capture the first frame, and my program renders one frame and quite.

I think unless you need to change the pipeline layout, you can capture once and just edit the shader code directly in renderdoc. you don't need to do the whole edit compile debug cycle all again if you just change the shader code.

1 Like

Is your wgpu code in Rust ? How are you compiling your shaders ?

In my case, for the vertex/pixel shaders, I get disassembled code -- which is far better than nothing, but has lots of temporary variables inserted -- which makes it rather non trivial to edit.

oh, that's bad. I'm not using wgpu, I'm using native vulkan API via the ash crate.

I don't know exactly how it works, but I think the shader might contain debug symbol or something, because in my case I can see the source code in renderdoc. I'm compiling vulkan flavored .glsl shader into .spv using the the glslc compiler from the vulkan sdk.

again, I don't really know wgpu. for graphics APIs I only have limited experience on vulkan (and very little on directx).

1 Like

Thanks for all your help. "no renderdoc" => "renderdoc" is the higher order bit; the rest is rounding errors. Cheers!

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.