Gfx: [Help] performance about wait_for_fence

[Michael-Lfx]

Here' my requirements:

• output texture of draw call 1 is the input texture of draw call 2
• output texture of draw call 2 is the input texture of draw call 3
• output texture of draw call 3 is the input texture of draw call 4
• …
• output texture of draw call N draw to screen (using inflight = 3 commit of @termhn )finally

I'm using device. wait_for_fence() in every draw call and it's killing the performance. It will cause black flash screen when I comment out them and left the one inside drawing to screen. Every device. wait_for_fence() cost 1.x ms in iPhone 8. So I want to avoid to call them if it can output the right result. How to handle the situation efficiently? @omni-viral @grovesNL @msiglreith

[msiglreith]

Waiting on fences introduces synchronization with the CPU which should be avoided and is not needed here. A pipeline barrier would be enough here. If the draw calls are in the same renderpass, use the output texture as color attachment in the one subpass and use it as input attachment in a following subpass.

[zakarumych]

You don't need to wait for fence to sync one GPU access to another GPU access.
Use subpass dependencies and pipeline barriers to sync ops performed on single queue (I guess this is your case).

[zakarumych]

@msiglreith If I understand his case correctly, subpass dependencies alone could do the trick.
Even if they span multiple render passes

[zakarumych]

@Michael-Lfx if you want I can explain what dependencies you need to specify.

[Michael-Lfx]

Thank you! Please give me some code snippet to make it more clarified. I am stuck in it. @omni-viral

[zakarumych]

It would be easier if you give me a link to your code so I could see how you access your resources ;)

[Michael-Lfx]

I am home now and I can push to github tomorrow. @omni-viral

[kvark]

@Michael-Lfx there are different types of synchronization primitives in Vulkan: fences, semaphores, and events (not exposed in gfx-hal yet). There are also commands to set pipeline barriers as well as record them into a render pass.

Fences are for CPU vs GPU synchronization. They are needed to know when things are done processing by the GPU, in order to re-use, read, or destroy some GPU resource. Semaphores are for GPU synchronization between queues and presentation. I assume your library only needs a single queue for now, so you'd only keep some of the semaphores for the presentation synchronization.

The case that you described: "output texture of draw call X is the input texture of draw call Y" is a GPU-GPU synchronization on the same queue. It doesn't need any sync primitives, it only needs proper transitions (pipeline barriers) set up. I.e. when something ends being a render target and starts being a texture (that is sampled from), you need to transition it to the appropriate layout and access flags. This can be done with either an explicit pipeline barrier, or by specifying the layouts to start/end and intermediate ones for the render pass where a texture is used as an attachment.

Please check out the documentation of Vulkan synchronization, including these:

• https://gpuopen.com/performance-tweets-series-barriers-fences-synchronization/
• https://gpuopen.com/vulkan-barriers-explained/

[zakarumych]

Pipeline barriers are sync primitives. They are used to sync commands on the same queue.
They have 3 purposes:

• Stage flags make later command wait on earlier commands to complete.
• Access flags on memory/buffer/image barriers control cache flushes and invalidation.
• Image layout transition can be requested to happen in between synchronization.

[kvark]

@omni-viral thank you for correction! I was excluding them from "primitives" because they aren't separate objects you create and destroy. It looks like the documentation still considers them to be primitives though.

[zakarumych]

@kvark In this sense, yeah. I just worried your suggestion does not include actual synchronization (stage flags) :)