5 ms·

Depending on the graphics api, something needs to sleep somewhere to get decent latency. E.g. in vulkan, if the present mode is fifo, then rendering frames as f

Depending on the graphics api, something needs to sleep somewhere to get decent latency. E.g. in vulkan, if the present mode is fifo, then rendering frames as fast as possible will fill the swapchain with stale frames that won't be presented for a while. It can be a lot better to sleep and render the frame right before it can be presented. But if you sleep a little too long, you will miss the frame, so you need a better sleep function like this.

bsder 4y ago
The problem with all the modern graphics APIs isn't sleep()--the graphics card generally can be filled to 100%, and you kick off another render when the swapchain releases a frame. The problem is knowing how long the actual render is going to take. Scenes can vary vastly in complexity and predicting how long they will take to render a priori is extremely difficult.
- 10000truths 4y ago
  Not an expert in graphics rendering, but could you estimate the render time by calculating (a priori) the number of draw calls needed to render the frame?
  - kevingadd 4y ago
    Unfortunately no - the cost will depend on the number of visible pixels, and worse, there are secondary costs depending on the arrangement of those visible pixels on screen, what part of the texture happens to be there, whether any sparse textures need to get paged in from system memory, whether GPU occlusion culling is going to cull certain things it wouldn't normally cull, etc. And other things are competing for GPU time like your OS compositor
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.

bsder 4y ago

The problem with all the modern graphics APIs isn't sleep()--the graphics card generally can be filled to 100%, and you kick off another render when the swapchain releases a frame. The problem is knowing how long the actual render is going to take. Scenes can vary vastly in complexity and predicting how long they will take to render a priori is extremely difficult.

10000truths 4y ago
Not an expert in graphics rendering, but could you estimate the render time by calculating (a priori) the number of draw calls needed to render the frame?
- kevingadd 4y ago
  Unfortunately no - the cost will depend on the number of visible pixels, and worse, there are secondary costs depending on the arrangement of those visible pixels on screen, what part of the texture happens to be there, whether any sparse textures need to get paged in from system memory, whether GPU occlusion culling is going to cull certain things it wouldn't normally cull, etc. And other things are competing for GPU time like your OS compositor

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.