3 ms·

That's what vsync is for. And despite what some people and games seem to think, vsync isn't an optional feature that you can turn on or off, it's something tha

by devit 4y ago

That's what vsync is for. And despite what some people and games seem to think, vsync isn't an optional feature that you can turn on or off, it's something that must always be enabled since it's essential to display correct graphics.

dxuh 4y ago
Sadly VSync is not all upside and it increases input latency significantly, so it might be a deal breaker depending on what you play or just the person playing. Despite their age GSync and FreeSync are not that ubiquitous yet. I agree that for most single player games it is simply correct to enable it, but people often don't do it, because they paid lots of money for their gaming computers and want to see the FPS numbers go way up to justify their expense.
- jsmith45 4y ago
  Assuming a fixed monitor display, and a separate faster than framerate game update loop, then the ideal way to render is to sleep until you just barely have enough time and then start rending, finishing just time for the card to read out the data. But obviously that is hard, since render time is not the same for every frame. [1] But if we could pull this off, it would obviously have latency that is as low as possible given the hardware in question, with the frame actually output always containing the latest possible data without screen tearing. (If you allow for screen tearing by swapping buffers mid scan-out, then you can get even less input latency for the lower parts of the screen with the render as fast as possible techniques.) The continuously render new frames as fast as possible approach (with triple buffering) is somewhat of a crude approximation of this. It works, and is potentially better than vsync, but is not ideal. It can give impressive framerate numbers though. Variable refresh rate (gsync, freesync) can avoid this, and are best, at least as long as you can't render frames faster than the maximum refresh rate of the monitor. If you can render frames faster, then all these considerations apply again. Footnotes: [1] I seem to recall was some technology that tried to simulate this (without the sleep) by making render calls for "frames" that are too early be no-ops, and only once we are close to when the frame needs to start being actually drawn do the draw calls do anything. This obviously yielded absurd framerate numbers.
  - kcexn 4y ago
    A solution like this isn't portable and will fall over as soon as you change any piece of hardware in the system. Separating responsibilities creates systems that are more robust.
    - jsmith45 4y ago
      I was never suggesting that starting a render run at the last possible second to ensure the frame renders in time to be scanned out was actually a viable approach. Only that it was theoretically optimal. But hardware changeout would not meaningfully affect people attempting such an approach, because it would obviously be based on actually timing how long a render pass took, adding a small buffer margin, and using that as the timing. Which does mostly work, except when there is a rapid change in render time, like due to switching on a giant particle effect changing the camera from pointing at the ground to pointing out at the open world, getting close enough to an complex object to swap from a lower LOD mesh to a higher one, etc. These would likely cause meaningful lag spikes as the system tries to adapt.
singron 4y ago
The situation I'm describing is with vsync enabled. This problem is not solved by vsync and mostly goes away if you turn vsync off, since then it acts more like mailbox present mode at the expense of 100% utilization. Vsync solves tearing.

by devit 4y ago

dxuh 4y ago

Sadly VSync is not all upside and it increases input latency significantly, so it might be a deal breaker depending on what you play or just the person playing. Despite their age GSync and FreeSync are not that ubiquitous yet. I agree that for most single player games it is simply correct to enable it, but people often don't do it, because they paid lots of money for their gaming computers and want to see the FPS numbers go way up to justify their expense.

jsmith45 4y ago
Assuming a fixed monitor display, and a separate faster than framerate game update loop, then the ideal way to render is to sleep until you just barely have enough time and then start rending, finishing just time for the card to read out the data. But obviously that is hard, since render time is not the same for every frame. [1] But if we could pull this off, it would obviously have latency that is as low as possible given the hardware in question, with the frame actually output always containing the latest possible data without screen tearing. (If you allow for screen tearing by swapping buffers mid scan-out, then you can get even less input latency for the lower parts of the screen with the render as fast as possible techniques.) The continuously render new frames as fast as possible approach (with triple buffering) is somewhat of a crude approximation of this. It works, and is potentially better than vsync, but is not ideal. It can give impressive framerate numbers though. Variable refresh rate (gsync, freesync) can avoid this, and are best, at least as long as you can't render frames faster than the maximum refresh rate of the monitor. If you can render frames faster, then all these considerations apply again. Footnotes: [1] I seem to recall was some technology that tried to simulate this (without the sleep) by making render calls for "frames" that are too early be no-ops, and only once we are close to when the frame needs to start being actually drawn do the draw calls do anything. This obviously yielded absurd framerate numbers.
- kcexn 4y ago
  A solution like this isn't portable and will fall over as soon as you change any piece of hardware in the system. Separating responsibilities creates systems that are more robust.
  - jsmith45 4y ago
    I was never suggesting that starting a render run at the last possible second to ensure the frame renders in time to be scanned out was actually a viable approach. Only that it was theoretically optimal. But hardware changeout would not meaningfully affect people attempting such an approach, because it would obviously be based on actually timing how long a render pass took, adding a small buffer margin, and using that as the timing. Which does mostly work, except when there is a rapid change in render time, like due to switching on a giant particle effect changing the camera from pointing at the ground to pointing out at the open world, getting close enough to an complex object to swap from a lower LOD mesh to a higher one, etc. These would likely cause meaningful lag spikes as the system tries to adapt.

singron 4y ago

The situation I'm describing is with vsync enabled. This problem is not solved by vsync and mostly goes away if you turn vsync off, since then it acts more like mailbox present mode at the expense of 100% utilization. Vsync solves tearing.