Re: [PATCH v5 0/8] MR6467: winex11: Implement vulkan DPI scaling and child window rendering.

[Elizabeth Figura (＠zfigura)]

I don't think this architecture is going to work. It probably isn't evident from games testing, but there is a synchronization problem here. We can't simply do vkQueuePresent() and then copy from the corresponding X11 drawable, because vkQueuePresent() won't guarantee that the bits have reached the X11 drawable yet.

For GLX this approach is fine, assuming we have GLX_OML_sync_control. In that case waiting for SBC is exactly what we need.

Vulkan doesn't have an equivalent extension. VK_KHR_present_wait isn't equivalent, because it signals the event on first pixel out, which is too soon.

This means we probably need to virtualize the whole swapchain, unfortunately, and either create a Vulkan swapchain on the relevant top-level window, or use DRI3 to interop between Vulkan and X11 without a swapchain. In this case vkQueuePresent() would of course not present directly.

We could also try to invent an extension that lets us do what GLX_OML_sync_control does, but I fear that Mesa and/or Khronos will push back on this, and basically tell us to fix it on our end, by virtualizing the swapchain...

There may be reasons we can't virtualize the swapchain that I'm not thinking of. I also have zero knowledge of Wayland and don't know how to fit that into anything.