Long stall before present when adding shadow pass

[DGriffin91]

I have a renderer that does shadow pass > main pass > blit to swapchain > present.
All the passes use the same graph, and the main pass depends on the depth texture output of the shadow pass.
When I add the shadow pass I end up stalled at "wait for presentation" (assuming waiting on fences) for around 1ms. It seems like during this time both the CPU and GPU are fairly idle. This is with vsync disabled. Total cpu frame time without the shadow pass is around 1.8ms vs 3ms with it (when measuring without nsight/tracy).

If I remove the shadow pass, the stall seems to completely go away.

Any thoughts on what to look at or try to see what could be causing the stall?

Here's tracy:

And nsight

nsight just shows this barrier

and then the next thing is present

[attackgoat]

There are some improvements to swapchain synchronization in #75 (see src/driver/swapchain.rs). That branch changes winit app handling though and might take a tiny bit of effort to switch to (use the new screen_13_window::Window in place of screen_13::EventLoop).

Try adding lots of profiling::scope!("blah") first and also check how many swapchain images the event loop was created with:

 INFO  screen_13::driver::swapchain                > Swapchain 1024x1024 B8G8R8A8_UNORM FIFO_RELAXEDx3

You've probably already found those though. I'll see if I can learn anything from these screenshots over the next few days.

[DGriffin91]

Tried a swapchain count of 8, in tracy it looks about the same as 3 and the overall time is about the same too.

I was using Image::create but only for loading the initial assets. All the other buffers and images appear to be using the pool, and I just setup the initial image asset loading to also use the pool. Overall frame rate seems the same, but startup time is maybe faster now. I'm not using AliasPool currently.

vtune isn't aware of frames and just looks at the whole execution. The libloading/hassle_rs stuff is just during startup. I'm not sure what specific thing you are referring to with record_subpass, is it the record_node_passes? It does seem like that reorder step take a long time.

[attackgoat]

It does seem like that reorder step take a long time.

I was mistaken; I saw all the iterator stuff and thought it was coming from one of those callbacks but it appears to be the iterator functions called by reorder. I need to make another pass at making the reorder step more efficient or allowing it to be skipped (you could comment out the line which calls it, but it is unrelated).

I would try running your program on multiple graphics cards from different vendors and see if you get the same behavior. I'm more than happy to help debug your code if you could provide it; I keep a small collection of machines and cards for this purpose. My email is [email protected] and I sign NDAs and can do this at no cost to you. Whatever I learn might improve Screen 13.

However, I also wouldn't try to fix 1ms unless it was visible in builds during the polish portion of your project. This might disappear as you build out the rendering portion of your project and stuff more into the GPU pipeline.

[DGriffin91]

Thanks for the offer! That would be awesome! I'll send over an email when I have the opportunity.

[DGriffin91]

@attackgoat Just a heads up. I'm taking brief break from this to participate in https://itch.io/jam/bevy-jam-5. I'll be back working on this next week!

[DGriffin91]

So it looks like the wdm.exe stalls go away if I use full screen instead of windowed. In both cases things are looking a lot better now. I'm not sure exactly what changed, I've updated lots of things, but if I go back to an old commit I still don't see the same huge stall at the end, but a much smaller one.

Fullscreen:

Windowed: