MiniEngine fences and synchronisation

[TNtube]

Hi, after a lot of back and forth around the MiniEngine source code, particularly on the fence and frame synchronisation part, I'm not sure about something.

Does the frame synchronisation of MiniEngine entirely relies on GpuTimeManager::BeginReadBack ? After adding a breakpoint on CommandQueue::WaitForFence, the only call done once per frame after all resource initialisation come from GpuTimeManager::BeginReadBack

From what I've read, waiting for a fence to be completed guaranties that every fence value beforehand are completed too, but I'm might be wrong.

If it is the case, why does GpuTimeManager has the responsability for frame sync ? Why there isn't any similar case than D3D12HelloFrameBuffering usage of fences for MiniEngine, like waiting for a fence only its buffer need to be accessed over again ?

And in general, why MiniEngine seems to care about multiple frame buffers only in Display, where there is the only usage of g_CurrentBuffer ? (even though it doesn't wait for fences here neither).

I hope it'll help me have a better understanding of multiple frame buffering and fences usage.

Thank you

[GameDreamByHuo]

这是来自QQ邮箱的假期自动回复邮件。 你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。

[xuezchuang]

The biggest benefit of this is the use of dynamic constant buffers and descriptor tables, that is, you don't need to worry about fences and frames synchronisation, because it's a circular pool that allocates resource and descriptor handles.

You all see GpuTimeManager: : BeginReadBack and its function of CommandQueue: : WaitForFence, because EngineProfiling read back to buff the resources of performance monitoring, namely BeginReadBack sm_ReadBackBuffer. There is no loop pool to allocate resources, so this requires fence to synchronize.

You can try to make sm_ReadBackBuffer multiple resources and use fence to recycle for monitoring.