Only out of date and a lost surface recreated one, so a TV whose mode
changed without a resize (MoltenVK reports SUBOPTIMAL when the layer's
size no longer matches) kept a stretched picture. Like the main
swapchain, it's now recreated after a few SUBOPTIMAL presents in a row.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Swapchains other than the main one are VKRSwapchains, owned by the
render manager, each with its own surface, image views, framebuffers
and depth buffer, in the main swapchain's format so the backbuffer render
pass and pipelines work for all of them. A render step with no
framebuffer can name one.
They don't pace the frame: acquiring doesn't wait, and the pass is
skipped if there's no image. The frame's last submit waits on and
signals the semaphores of every swapchain acquired that frame, and each
is presented after the main one. When one goes out of date, it's
recreated at the start of the next frame.
The main swapchain's path is unchanged; frametests on Vulkan match.
VulkanContext::CreateSurface is the old per-platform surface code, now
also used for the extra ones.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The OLD_DATA_OK readback cache was keyed by framebuffer and size only, so
two equal-size rects of one framebuffer shared a buffer and each read got
whichever was copied last. Add x, y and the aspect to the key.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This extension is not available on Android, there they have
VK_GOOGLE_display_timing, which they also have an abstraction library
for, so will look at that later.
Early part of work on #17685
Multi-threaded rendering is good for smoothing out performance spikes
and increasing performance on low-power devices. However, the way we use
it it doesn't benefit latency (input lag) at all, rather the opposite.
So make it an option.
