"Dynamic" swapchain

[Try]

Current swap-chain api is designed mostly of DX12. It's ok, but not the best in convenience and requires extra blit in case of Metal.
DX-like is also very hard to model on top of vulkan, requires forest of fences and semaphores.

New api idea, to make it metal-like:

Attachment img = swapchain.next(); // point of failure for VK_ERROR_OUT_OF_DATE_KHR/VK_SUBOPTIMAL_KHR

// render as usual

device.present(std::move(img)); // destructive from application side

For error handling:

• present can deffer failure, in case of VK_ERROR_OUT_OF_DATE_KHR.
• next can implement recovery, that is invisible to application
  • or "fail-fast" without wasting time on command recording of unusable frame

vulkan:

should be similar to conventional acquire/release flow under the hood.
'discard' is an issue - probably just hold to imageIndex.

metal:

matches metal api

dx12:

adds constraint: only one image at time can be taken from swapchain

note1:
This design, unintentionally, defined frame-discard operation: application can simply abandon image.

note2:
Is reset no longer useful? can be hidden inside next call.

[tryk016]

I’ve opened #116 with a first Metal implementation for review:

Attachment img = swapchain.next(); // acquire drawable

// Record rendering into img.
auto fence = device.submit(cmd);
device.present(std::move(img)); // consume img

It renders directly into the drawable, without the extra copy. The image stays alive until the GPU finishes, even if the game drops it.

[Try]

Thanks for the prototype @tryk016 !
However final design is still up for discussion.

Does landing if swapchain patches for metal block you in any way with you iOS port, or it can be taken slowly?

Asking specifically, because changing swapchain api is quite a big one, and will require me to adjust Vulkan, Android and DX12

[Try]

Some update on programmer-art:

1. Starting idea

Attachment a = swapchain.acquire();
render(a);
device.present(swapchain, std::move(a));

2. Reference + explicit acquire

Attachment& a = swapchain.acquire();
render(a);
device.present(swapchain);

3. Iterator-like design (probably no, as no explicit acquisition point)

render(*swapchain);
device.present(swapchain);

Maybe 2 is better:

• also has explicit acquisition point
• short life-time of the image is more articulated
• no way to present wrong image by accident

[tryk016]

It’s not blocking the iOS port, so no rush. I can keep working on the other parts of the port in the meantime.
I’d lean towards option 2 as well. What about an explicit discard for frames we don’t present?

Attachment& a = swapchain.acquire();
if (render(a)) {
  device.present(swapchain);
} else {
  swapchain.discard();
}

The reference would be valid until present, discard or reset. Resources still needed by the GPU would stay alive internally.

[Try]

Discard was not intended - it was accidental effect of RAII based design. Now there is no way to abandon a frame (well, you can still destroy swapchain, but that's all) and no practical use-case to purposely abandon frame.

and for error-resolution case, acquire will return same image, if one already acquired. That can make recovery path simpler:

// frame 1
Attachment& a = swapchain.acquire();
render(a); // throw here or some other early-out
device.present(swapchain); // not reached

// frame 2
Attachment& a = swapchain.acquire(); // still same image
render(a);
device.present(swapchain); // may hit suboptimal