Attempt to fix VSync bugs On Nvidia Graphics Cards

[vcmp]

This is similar to the previous PRs I did with the exception of most of the code bloat, nonsense and silly performance hacks removed so the commits are much easier to read/more organised.

Added Features

• Enabled Vsync functionality through use of a separate transfer Queue
  • Fixed accidentally through a separate Transfer Queue which seems to stop the stalling on the main Graphics Queue causing the stuttering
  • As this is a workaround and not a true fix, VSync will still not work if the device/GPU does not support a separate transfer queue family to allow for Asynchronous upload and/or if the GPU lacks the capability to handle this properly
  • Edit: This seems to be a Nvidia exclusive issue as not all graphics card vendors seem to suffer from this issue

Bugs

• Vsync Flicker Bug during switching in Fullscreen: At least on Windows 10 21H2, if Vsync is toggled while in exclusive fullscreen, the screen will flicker slightly as the swapchain is flushed and rebuilt, which does not occur in Vanilla
• Possible client crashes during loading: Due to the changes with the Queue setup with the Transfer Queue workaround for VSync, the Queues may not be setup properly and cause a crash, I can only test with my current hardware so there is a decent chance I made a mistake and messed up the queue setup

[xCollateral]

Thank you for trying to help. There are a lot of changes. Regarding the first point I don't think vsync and transfer queue are related, as you saw in the code the handle for transfer queue was there because i did some testing with it and I did not see any improvement (besides it's not really transfer queue) by using it instead of graphics queue. I suggest you to open different PRs for different features.

[ghost]

Thank you very much for the feedback. I Think your suggestion to split it into separate PRs is extremely reasonable as it is far too large in its current state.

I think what could work is separating some of the performance optimisations and maybe the Debug screen changes into their own separate ones and keeping this one for the VSync stuff only.

[ghost]

I believe the issue with Vsync if any may be hardware specific to Nvidia as I noticed during testing that using a basic form of VSync such as with VK_PRESENT_MODE_FIFO_KHR in exclusive fullscreen causes considerable stutter and poor frame pacing at least on my hardware and on Windows 10 21H1.

(Which is also a very similar bug to a stutter issue that also occurs with chromium if Vulkan is used instead of the default d3d11 backed for Angle. So afaik this has nothing to do with the mod itself and is purely an issue on Nvidia's end.)

I have no idea why or how this happens, but for some reason changing the Queue family type in the TransferQueue class over to a dedicated Transfer only family seems to fix this issue and greatly improves VSync stutter, at least with the GTX 1080 Ti that I have available, which is why I suspect this is Nvidia specific.

I also only have Maxwell/Pascal GTX 900/1000 series Cards and not anything for Turing or newer (i.e. GTX 1600/RTX 2000/3000) and nothing from AMD, So I'm also not sure if this is fixed on Turing or later or if it occurs on AMD/Intel.

(It also seems to improve chunk loading speed as well but this is completely unconfirmed)

(The Screenshot issue seems to be an unrelated Bug/issue where it is saved as BGR and not RGB, and the Odd Framerate is due to using an Overclocked monitor refreshing at 76Hz instead of 60Hz)

[xCollateral]

From what i saw in your code you are probably using transfer queue, that why you're getting better performance. Now the thing is not every device supports transfer queue with the same properties your gpu has. Mine, for example, supports transfer queue with 8 pixels image granularity. Merging your commits would make the mod not compatible. https://vulkan.gpuinfo.org/displayreport.php?id=15926#queuefamilies

[ghost]

(Sorry for being slow to reply)

that makes sense as while I definitely noticed an issue it only occurred if the TransferQueue class was using the Graphics family and if the present mode was set to VK_PRESENT_MODE_FIFO and if the client was in fullscreen, and the issue disappeared when uncapping the Framerate (Changing the present mode to VK_PRESENT_MODE_IMMEDIATE) and/or changing the queue family to Transfer only

GPUInfo report of the GTX 1080 Ti: The weird Video queues are due to using the Vulkan beta driver and does not exist on the normal driver

As there is no evidence to suggest that this occurs on other setups or if this is a Nvidia specific issue I am happy to close this Pull Request if that is the case and it is not a widespread issue and/or if the changes I made would complicate queue management and cause more issues than its worth.

This is also why I incorrectly assumed that it was a fence synchronisation issue when in fact it has nothing to do with the mod at all and is most likely caused by external factors i.e. e.g. Nvidia Hardware Bugs/Driver Bugs so apologies about that.

I uploaded some videos demonstrating what I noticed in case it is useful, with the 1st being on Queue family 0 (Graphics) and the latter on Family 1 (Transfer Only) (these are compressed as AV1 videos to fit within the upload limit however there are uncompressed versions if needed)

https://user-images.githubusercontent.com/43959737/183300069-e1163433-8942-4974-aaf8-6ee1cc83000d.mp4

https://user-images.githubusercontent.com/43959737/183300076-e2810e17-ea9d-4ce6-a30e-d896fc4add6c.mp4

[ghost]

~~After thinking about this for a bit more, I think I will close this Pull request as the current indication is that this is a extremely specific and difficult to reproduce Nvidia driver bug, which would likely be extremely difficult to fix without the dedicated transfer queue workaround to fix the V-Sync stutter and needlessly complicating the structure for Vulkan initialisation and making the mod code more difficult to work with (in terms of Queue management.)~~

~~(In addition this is a rather trivial bug/issue anyway and there are likely many other things that are far more worth the time and effort of paying attention to as this is not a game breaking issue by any means and is little more than a nuisance and I don't want to clutter this repo with another open Pull request)~~

~~I have also recently been more busy IRL and likely won't have as much time to contribute anything of value anyway, so for the time being I think I will keep the above information in case it is useful for reference purposes in case this issue/problem appears again at any point in the future. (As thankfully the fix I found for this at least via the Transfer Queue method is extremely trivial to implement)~~