[Frame Looping] Rework solution for looped descriptor set allocations

[nickdriscoll-lunarg]

In my original solution, the code tracks which pools have been allocated from during the looping frame, and resets them after vkQueuePresent(). This solution has a flaw.

Example: Descriptor Pool 1 is used to allocate set A before the looping frame, then it allocates set B during the looping frame. Pool 1 will have been marked for reset because of set B's allocation, but when it is reset, set A goes along with it. If set A is used during the looping frame, this is invalid usage.

I realized that I was overthinking this, and we can simply skip allocating descriptor sets during repetitions of the looping frame in order to solve this issue in a simpler way, and without the flaw described above.

That's also to say, Process_vkAllocateDescriptorSets() can eventually just be generated like the rest of the resource allocating functions.

[antonio-lunarg]

I wonder.. what if descriptors are originally created and freed within the same frame?

I think we should have some way of tracking whether descriptors are still alive before skipping creation after the first iteration.

[antonio-lunarg]

Same reasoning for "destroy" calls. If a frame uses a resource (that has been created in previous frames), we might want to skip any destroy call otherwise the next iteration of the loop would attempt to use a resource that has been destroyed.

[nickdriscoll-lunarg]

So I think I have a new implementation that covers what you brought up:

Here are the possible cases for descriptor pool/set creation/destruction

• Created before loop range but destroyed in the loop range
  • Omit destruction enitrely
• Created before loop range but destroyed after loop range
  • No special handling
• Created during loop range, destroyed after
  • Only create on first iteration
• Created during loop range, destroyed during
  • No special handling

The solution here is to track all "dangling" pools/sets, then ignore their destruction entirely, and only create them on the first iteration of the loop range.

A "dangling" resource is one that was either
- Created during the loop range but destroyed after it
or
- Created before the loop range but destroyed during it

Please let me know what you think @antonio-lunarg

[antonio-lunarg]

That's a great approach, I wonder if we would be able to unit test this logic in some way.

[antonio-lunarg]

It's starting to look good!

[antonio-lunarg]

Once last comments are addressed, this is good to go IMO. 👍