vkAcquireNextImageKHR is an asynchronous acquire operation, but for RetroArch I want to sync the frame begin to V-Blank, so I just wait on the VkFence to signal anyways to force a synchronous acquire. VkAcquireNextImageKHR will give us new images to render into, and it should be unblocked on V-Blank when new images are flipped onto the display. After we have created the new swap chain, we can delete the old one and query the new (or the same!) swap chain images. If we just change the present mode for the new swap chain, this should give us a seamless transition over to the new present mode. Passing in oldSwapchain will effectively retire the swap chain as well. My understanding of this is that we can “pass over” ownership from one swap chain to the next. We have the option of passing in our “oldSwapchain” when creating a new swap chain. According to the specification, there can only be one non-retired swap chain active at a time. Instead, we need to create a new swap chain. There is no direct way to toggle between FIFO and MAILBOX/IMMEDIATE on a swap chain. There is no magic “framebuffer 0”, or a magic SwapBuffers call which buffers an unknown amount for you. You can request the number of images there should be in the swap chain, and you acquire and present these images directly. Vulkan WSI is a fairly explicit model compared to its predecessors. I’ll also discuss some heinous workarounds I have had to employ to work around the worst implementations. I would like to summarise these, starting from “best” to “worst” for dramatic effect. I have had the “great pleasure” of fighting with many different WSI implementations in the RetroArch Vulkan backend. Windowed mode should be tear-free, without stutter, but is allowed to have a bit more latency than fullscreen because of compositors.
#RETROARCH WINDOWS 10 RANDOM STUTTER FULL#
#RETROARCH WINDOWS 10 RANDOM STUTTER DRIVERS#
Absurd amounts of effort has gone into aiming to reduce input latency by various developers, and all that effort consists of working around false assumption of GPU drivers which have been optimising for “normal game” FPS rather than latency and predictability. The GPU load of retro emulation is usually quite insignificant, but we need full control over the swap chain, when swaps happen, and when we can begin a frame and poll inputs. There’s no reason why we should have more than a millisecond in jitter for low-GPU load scenarios. It also hurts rate control for audio, although the frame pacing can get rather bad before this becomes a real issue. If there is too much variation in frame times, this translates into variable input latency for fixed FPS content, which is not ideal. Unlocked could be either MAILBOX or IMMEDIATE. This is a very emulation specific requirement, but extremely important. Ability to toggle between locked and unlocked (fast forward) frame rates, seamlessly.Essentially VK_PRESENT_MODE_FIFO_KHR when it’s working as intended. Perfect, tear-free 1:1 frame mapping if game frame rate and monitor frame rate are close enough.The problems I’m going to explore in this post can often be glossed over in the common case. Games are written around the assumption of variable frame rates, users can disable V-Sync (especially for fast-paced, reaction based games), etc, and variable refresh rate display standards were introduced to get the best of both worlds. For “normal” games, it seems like this isn’t as much of a concern. These games work on a fixed time step, and we must obey, or the result is borderline unplayable. It is immediately obvious when tearing or skipped frames are observed in retro emulation. For whatever reason, implementations and operating systems always find a way to screw things up.įor emulation, perfection is the only thing good enough. Over the years, it has been an ongoing frustration that good windowing system integration is something we just cannot rely on. Tearing, skipped frames, judder, etc, are all issues which stem from poor window system code. In the world of graphics programming, interacting with the windowing system is not exactly the most riveting subject, but it is of critical importance to the usability of applications.
0 kommentar(er)
