Presenting blocks other operations with VSync on

[LaylBongers]

Because of CommandQueue::present_surface blocking for VSync in swap_chain_present, the function will keep various resources locked for up to 16ms on 60Hz displays.

[LaylBongers]

I've looked through various documentation and things written on this specific issue, and it seems like to properly fix this, multiple queues may be required.
Since the queue is used while presenting, it cannot be concurrently used to present two windows at the same time, or even record another window's rendering commands.

Some improvements to the current system may be possible to reduce the amount of resources locked at the same time, but this is still likely going to cause a stall.

[LaylBongers]

The key issue seems to be that specifically the NVIDIA driver blocks on present. This doesn't seem to happen on AMD which blocks on acquire. (I've been told this, I haven't been able to verify this)

I've discussed the current issue with various people and have come to the current possible solutions. I won't be working on any of these right now but I wanted to write them down for reference:

1. Don't use VSync, externally figure out when you need re-drawing if you need multiple windows. This can be done right now without any changes to WGPU. Right now this is the approach I'll be taking in my own application.
2. Add multi-queue support to WGPU. This would solve the issue by simply allowing the user to have one queue per window, rendering separately. There's some lack of clarity on how this would affect performance, and this would require significant changes to WGPU that may not be completeable in the near future yet.
3. Add Present Queues to WGPU. This would be a stopgap solution that would allow a multi-window application to submit presenting on a separate queue. This would be significantly easier to synchronize than a complete multi-queue API. By allowing the user to just block this separate queue on present, other threads waiting on locks can be avoided.

[cwfitzgerald]

Multi-queue is on the radar here: #1066

[cwfitzgerald]

Nvidia blocks on acquire in one of two cases: you've run out of swapchain images (this won't happen on modern wgpu) or you're using gsync. This is unfortunately just kinda how it does it, and part of our motivation for #2719.

Going to close this as this issue is represented various other issues.