Welcome Stranger to OCC!Login | Register

Serious Statistics Pt. 2: The Sync Encounter

Category: Gaming
» Discuss this article (2)


The short of it is, I have not quite left 'new toy' mode since I did the Serious Statistics article, but this time instead of looking at the performance of different APIs, I am taking a look at the impacts of different vertical sync methods. You see, I asked myself the question; could I use the PresentMon data OCAT captures to look at the frame latency v-sync can introduce? I had to think on it some, then work through some weird results, until I got a really weird result that actually brought clarity (I think), but I believe the answer is yes.

There have been some changes since the previous article, so I want to cover those. On the software side, R and the libraries I use saw some updates, but the most significant changes here are those I made to the graphs themselves, in how they are formatted and present the data. PresentMon and OCAT have also seen some updates to them, and somewhat significant too, but none of these changes will affect you or the data, just how I collect and process it. (If anyone is curious, the data is in 43 CSVs totaling some 186 MB.)

There have been some driver updates as well, but probably the most significant change is that I am now rocking more than just a GTX 1080 for driving my display, but also a reference RX Vega 64 I purchased. Thanks to this purchase, I am able to collect data on the driver-side options both AMD and NVIDIA offer for achieving vertical sync and frame rate control. Here are my computer's specs now:

  • Processor: AMD A10-5800K @ 4.40 GHz (44.0x100)
  • Cooling: Corsair H110
  • Motherboard: ASUS F2A85-M PRO
  • GPU (AMD): AMD RX Vega 64 (Core @ 0.95 V)
  • Drivers (AMD): Radeon Software 17.8.1
  • PhysX (NVIDIA): NVIDIA GTX 1070 8 GB
  • Drivers (NVIDIA): GeForce 382.53
  • Memory: G.Skill Ripjaws 4x8 GB (32 GB total) at 1866 MHz 10-10-10-27
  • PSU: OCZ Fata1ty 750 W
  • OS: Windows 10 Pro 64-bit
  • OCAT: Version

I am still running at the Ultra preset for the graphics settings and I am using the same Hatshepsut run I used in Serious Statistics.


As this article is going to look specifically at v-sync, or vertical sync, it would probably be a good idea to explain it. When a GPU sends a frame to your monitor to be displayed, it scans from the top to the bottom of the frame buffer, and it completes a scan in a certain amount of time. Most monitors today update or refresh at a rate of 60 times per second (60 Hz), and when your GPU is scanning out at 60 Hz as well, we have vertical sync. A GPU is not always going to have one frame ready in the 16.667 milliseconds window of time this allows, but may get done faster or slower. This can cause a kind of artifact called a screen tear, which results from a new frame being placed into the frame buffer while the GPU is scanning it out to the display, so content from two frames are displayed. To prevent this, different methods of encouraging or forcing v-sync have been developed.

Perhaps the most basic v-sync method is double buffering, which means there are two frame buffers instead of just one. While one buffer is being scanned out to the display, the other can be rendered to by the GPU, ensuring it is only a completed frame being sent out. This method, however, keeps the monitor's refresh rate and the rate the game engine can render at connected, possibly causing the engine to stall if both buffers are full. To address this issue, triple buffering was developed, as it has three frame buffers: one to scan out; one to hold a complete frame; and one to render a new frame into. The buffer being scanned is called the front buffer while the others are back buffers, and the back buffers can be flipped between, if the engine is able to render frames especially fast. This ability to flip between the back buffers allows the engine to render as quickly as it wishes, while still ensuring there is always a complete frame to be scanned out. (While it is called 'flipping' the actual operation is just to change the memory address reference. The data within any of the buffers does not actually move, which would waste time. If the front buffer is at 1, and the back buffers are at 2 and 3, flipping a back buffer and the front buffer would mean the front buffer is at 2 and the back buffers are at 1 and 3, for example.)

Another way to achieve, or nearly achieve, vertical sync is to impose a limit on the rate the engine will render frames at. This will minimize the likelihood of screen tearing, but cannot guarantee it without a buffer to protect a completed frame. However, while additional buffers protect against screen tearing, they introduce frame latency because the frame in the front buffer was sitting in the back buffer for some amount of time before being scanned out. By their nature, the back buffer(s) will hold the newest frame(s). This difference in time between a frame being rendered and displayed I call the frame latency and is what we are going to look at. PresentMon/OCAT records MsUntilDisplayed and MsUntilRenderComplete data and it is the difference here that I am considering to be the frame latency. There are undoubtedly other factors that go into the frame latency you may experience, but I do not have the means of measuring them. I am also going to be sharing display time, which is a measurement of when a frame is sent to the display, which I feel is relevant to this analysis.

Serious Sam Fusion 2017 supports a few different kinds of v-sync methods, and there are some outside of it as well. The game offers a V-Sync option that I believe is double buffering, triple buffering, and a frame rate limiter. Separate from the game there is the double buffering of the Desktop Windows Manager (by the way, developers can set a flag to disable this feature). Then there are the different options available in AMD and NVIDIA drivers, but these have some limitations, such as what APIs and windows they can work on. Both offer the ability to force v-sync, likely double buffering, while NVIDIA also has Fast Sync, what I consider inelegant triple buffering, and AMD offers Enhanced Sync, its response to Fast Sync, and Frame Rate Target Control, a driver-side frame rate limiter. All of these we are going to look at, though presently it appears AMD's v-sync is not working for me and I am unsure if Enhanced Sync was properly activating. (Either Enhanced Sync is working perfectly or is not engaging for some reason, but after some testing in other games, it appears it was working for them. I could not confirm the basic v-sync option was working in another game.)

While I am running two competing GPUs in this article, please understand this is not meant to be a test of their capabilities.

With all of that covered, time to dive into the data!

Related Products
Random Pic
© 2001-2018 Overclockers Club ® Privacy Policy
Elapsed: 0.0324089527   (xlweb1)