Blur Busters Forums

MaxiJazz wrote:Another stupid question:
If my game is CPU bound, do i need to lower frame cap to "CPU not hitting 100%" ?
For example - 144hz G-sync, CPU cant reach 141(142) fps cap, GPU is not 99%(100%).

No one tested that yet. Probably not. But I cap my FPS to be closer to the average FPS I'm getting anyway, for consistency.

Does G-SYNC + V-SYNC ON behave like this if you don't give it a proper FPS limiter when FPS hits the Max HZ? Thanks.

It can but usually worse: buffer pile up.

(When there's more framebuffer backpressure than in your diagram.)

Your diagram has only a fraction of a refresh buffer delay. Your situation sort of occurs more frequently with a cap actually: if a cap exists but is too close to refresh rate.

Without a cap - you will usually get more buffer pileup. Then you are almost permanently one or two frames ahead once you have the first moment of several consecutive "fast" frames -- until framerate slows down and the buffer pileup (VSYNC ON) disappears -- (and that makes it go back to GSYNC lag mechanics too)

That said, usually, frametimes usually don't continually fluctuate nearly that much of a percentage in adjacent frames, though - just momentarily (scene changes, loading assets, etc). The rest of the time, frametimes usually modulate smoothly, unless the game is poorly designed.

Two possible examples.
The first one is the best-case uncapped VRR + VSYNC ON scenario.



The second one is unfortunately common with many implementations, creating more lag.
Basically, a common behaviour of laggier 1-extra-frame queue version of uncapped VRR + VSYNC ON.



The longer the arrow, the more lag.

The way the game is programmed & how the drivers are configured, will affect which scenario happens.
There are other possible VSYNC ON workflows, but these would be the most representative of what's out there in the real world.

To avoid this framebuffer pileup effect that can cause dynamic lagfeel changes -- as you framerate fluctuates and slams against the refresh rate limit repeatedly (backpressure lag suddenly appears) and falls below again (backpressure lag suddenly disappears).

It's the game programmer's responsibility to try to delay input read to right before rendering a frame -- rather than right after delivering a previous frame. That way, any delayed frame will have fresher input read (less lag before render), and thus low-input lag despite capped framerate. So game design plays an additional role in helping reduce input lag.

Game design can also help reduce the lagfeel change effect of reaching the VRR limit and falling below the VRR limit -- by designing your game towards a more ideal VSYNC ON implementation which can be slightly more difficult. The deeper frame queue system (instead of traditional, very shallow, double buffering) easily end up occuring on some configurations and rendering pipelines, such as for SLI operation, where you have to multiplex frames from multiple graphics cards into a frame delivery queue for a single display.

Either way, the realtime lagfeel change (of framerate fluctuations hitting the max Hz and falling below) is exactly why you really want to follow prevailing advice to cap your GSYNC or FreeSync framerate a few fps below Hz, and preferably with an in-game cap as advised in GSYNC 101.

Thank you chief. Again, you gave me a lively lesson.

I have a stupid question to ask: When you finished rendering frame 2, you began to render frame 3 without pause, then frame 4, frame 5...untill V-SYNC ON starts. So a framebuffer can hold more than one frame?

KKNDT wrote:I have a stupid question to ask: When you finished rendering frame 2, you began to render frame 3 without pause, then frame 4, frame 5...untill V-SYNC ON starts. So a framebuffer can hold more than one frame?

There's always at least two buffers. Sometimes there's three. Double-buffering vs triple buffering. There's no single-buffering, except in VR, where it's possible to have only one buffer.

In double-buffering, you have the front buffer which contains the frame that is being currently scanned out by the monitor, and the back buffer, which contains the frame that is currently being rendered by the game. If the back buffer is fully rendered but the front buffer is still being scanned out, then that obviously means the game has reached the maximum gsync refresh rate and vsync-on behavior is activated.

In triple-buffering (meaning double-buffer + 1 more buffer, not the fast sync or Windows compositor style of triple buffering), the additional buffer prevents the game from stalling completely during vsync on when it can't fill the back buffer fast enough, which would cut the frame rate in half. With VRR however, or with vsync off, triple buffering is completely useless. It's only useful with no VRR vsync on.

RealNC wrote: In double-buffering, you have the front buffer which contains the frame that is being currently scanned out by the monitor, and the back buffer, which contains the frame that is currently being rendered by the game. If the back buffer is fully rendered but the front buffer is still being scanned out, then that obviously means the game has reached the maximum gsync refresh rate and vsync-on behavior is activated.

Thank you for reply. That was my thought.

Take chief's diagram as an example, frame 3 starts rendering as soon as frame 2 is ready, at this moment, frame 1 is still being scanned out. So, it looks like a framebuffer can hold more than 1 frame, otherwise VSYNC ON will get activated and make a pause between frame 2 and frame 3. That's what I want to confirm.

This might've been answered already, but I cant seem to find anything about it so here goes:

If Im using gsync + vsync, capping fps at 237 (because of 240hz monitor) and then my FPS fluctuates between, say, 180-237, does this influence input lag at all?
What would be most optimal in this case? IF input lag does increase because of the fluctuating FPS, would it be better to use 200hz / 197fps-cap in order to minimize this fps-fluctuation and in the end get better input-lag?

KKNDT wrote:Take chief's diagram as an example, frame 3 starts rendering as soon as frame 2 is ready, at this moment, frame 1 is still being scanned out. So, it looks like a framebuffer can hold more than 1 frame, otherwise VSYNC ON will get activated and make a pause between frame 2 and frame 3. That's what I want to confirm.

Whoa,

It's important to fix your terminology, use the phrases correctly, in the correct language:
An arm is not a leg.
A face is not a foot.
A frame buffer is 1 frame.

GLOSSARY

Frame buffer = one frame
Frame queue = multiple frame buffers. Like a book of frame buffers.
Swap chain = Another common term for a "frame queue". Like a book of frame buffers.
Flipping the framebuffer = Flip to the next frame buffer in the frame queue / swap chain.
Swapping the framebuffer = Same as "buffer flip"
Prerendered frames = One fully completed undisplayed frame waiting in the frame queue / swap chain
Buffering up = The continual adding of more frame buffers to the swap chain.
Double buffering = Two frame buffers
Triple buffering = Three frame buffers (modern definition), although the classical 3Dfx definition of triple buffering (from the late 90s/early 00s) was the low-lag NVIDIA Fast Sync technique.

The Book Metaphor of a Swap Chain
(Coined by Blur Busters)

The Plain English Book Metaphor of a "swap chain" or "frame queue":
- Frames (framebuffers) are simply pages in a book.
- New frames get inserted at the end of the book.
- The GPU is simultaneously the book writer and the book reader.
- The reader is the GPU reading the book out to the display, displaying page after page after page, one line (pixel row) at a time.
- The writing is the GPU creating new frames to insert to the end of the book.
- There can be several pages between the reader (screen) and the end of the book (GPU rendering adding new pages to the book).
- Once a refresh cycle is completed, the previously displayed page (the page before the now-onscreen page) of the book can be safely deleted from computer's memory. So memory only needs to holds only 2 or 3 or 4 pages of a book. (The monitor may hold its own separate copy of the last few pages of the book, e.g. for overdrive processing and other stuff -- basically a display's separate frame queue for its own internal display processing -- but that's optional, it may be synchronous scanout, line-for-line.) It's like an endless infinite book where the beginning of the book is continually deleted, and the end of the book is continually being extended.
- Duplicate refresh cycles is simply re-reading the same page of the book again, while waiting for the GPU to add a new page to the book.
- The GPU "reads out" the page to the monitor (Scan out)
- The reading (scan out) is top-to-bottom, like a common book, one pixel row at a time, left to right, raster-scan fashion.
- Tearing of VSYNC OFF is simply using scissors horizontally on the unread portion of the page, and splicing the bottom part of the new page to the current page that the GPU is reading out to the monitor.
- The more pages of book between the currently-displayed page, and the end of the book, the more input lag. (e.g. 2 frames of lag = you're 2 pages behind).

Metaphorically, the first page is the GPU rendering machine, and the last page is the actual screen display-out. There can be a line-up of waiting buffers in between. Tweaks like "Max Prerendered Frames" in NVInspector will affect how big your book can become -- it can be a big book, especially if the GPU is faster than the display (VSYNC ON).

The swap chain / frame queue is usually 2 or 3 buffers. Basically a book of 3 pages -- since pages are being deleted as fast as being added. But it's actually an infinite book where pages are being added as quickly as being deleted. Pages (new GPU rendered frames) are being added in realtime, and the reader is the GPU scanning out to the display -- and once moved onto the next page, the previous page is deleted (no need to keep it in memory).

The Book Metaphor on Common Graphics Operations

NVIDIA Fast Sync - The newest buffer will overwrite the next page (the page after the currently-being-read page) if there is one.
Essentially ripping that last page out, and replacing that last page. That way, there's only 1 page after the currently-being-read page. This reduces lag, without a tearline.
AMD Enhanced Sync - Same as NVIDIA Fast Sync
VSYNC OFF - Metaphorical scissors on the still-yet-unread portion of the page (on the top-to-bottom scanout) and replace with the bottom portion of your brand new page. This can be repeated multiple times (for multiple tearlines on the same page) -- e.g. stitching multiple fresher frames on the same frame (multiple brand new pages continually stitched on the fly, in the "sentences below what the reader is currently reading") -- imagine reading a book and the author rewriting all sentences (pixel rows) below the sentence you're currently reading! -- That's what VSYNC OFF essentially is; it can interrupt what's currently unread.
Fixed refresh rate - The reader is always reading at an exact top-to-bottom speed. That reading speed never changes. The next page (or repeat-read of current page) begins again at the top edge of a page, at an mandatory fixed exact time amount after finishing the bottom of the page. The reader merrily continues at a constant rate, literally microsecond-exact.
Vertical Refresh Rate - The number of pages read per second
Horizontal Scan Rate - The rate of number of lines read per second
Vertical Blanking Interval - The reader pausing between pages
Horizontal Blanking Interval - The reader pausing between lines (rows of pixels).
Variable refresh rate - The reader will be patient between pages. The reader will be able to pause a variable amount of time between pages (patience abilities will be the VRR range that the display told the GPU that it's patient for). And begin immediately reading the new page of the book, the instant the new page is ready.

RealNC wrote:There's no single-buffering, except in VR, where it's possible to have only one buffer.

Actually, that's not true. You might have slipped on a relativity basis (As Einstein says, it's all relative).

You might be talking about the individual-eye framebuffers (before the merged two-eye framebuffer). If you count both the individual-eye framebuffers and the combined two-eye framebuffer (since many VR headsets are two lens pointed to the same screen) -- it's still always at least 2 frame buffer layers. It's easy to miss these semantics, however.

There's a individual-eye frame queues (from single-GPU or two-GPU), then finally the combined-eyes frame. If you're talking about only the individual-eye framebuffer, or only about the combined framebuffer, then you're right. But if you total all the frames from the render to the display delivery, you are guaranteed a minimum of 2 frames even for VR.

Kimball wrote:This might've been answered already, but I cant seem to find anything about it so here goes:
If Im using gsync + vsync, capping fps at 237 (because of 240hz monitor) and then my FPS fluctuates between, say, 180-237, does this influence input lag at all?
What would be most optimal in this case? IF input lag does increase because of the fluctuating FPS, would it be better to use 200hz / 197fps-cap in order to minimize this fps-fluctuation and in the end get better input-lag?

Short answer: Don't bother.

Long answer: There are many causes of input lag, but 180-237 range is best left fluctuating. That's only a minor variance between 1/180sec to 1/237sec (only a 1.3ms lag-variance range for rendertime lag). If you want MORE lag but CONSTANT lag, you want to cap at a lower framerate, but if you want absolute minimum lag, it's best to let framerates fluctuates.

The exception is when maxing out framerates causes latency effects (it doesn't always -- not measurable in CS:GO) -- e.g. GPU-limited games rather than CPU-limited games. Or that some part of software gets flooded (e.g. 1000Hz mice in the earlier slow-performing-computer days) to the point of creating lag.

That said, for a situation of 180-237fps, if you're playing recreationally, just let the framerates fuctuate. That said, in special situations. capping (e.g. 200fps or 180fps max) may improve lagfeel of certain competitive games where keeping lag-variances at bay is critical. But this won't be useful for Source-engine-powered competitive games (CS:GO) as it is happy uncapped on modern fast-performing systems -- in Jorim's GSYNC-101 for Blur Busters, for CS:GO specifically, uncapped still had about a single millisecond less lag than 1000fps cap -- but this was an offline lag test rather than online gameplay lag test.

Chief Blur Buster wrote:

RealNC wrote:There's no single-buffering, except in VR, where it's possible to have only one buffer.

Actually, that's not true. You might have slipped on a relativity basis (As Einstein says, it's all relative).

I'm talking about front-buffer rendering, where you ride the tearline during rasterisation. That's single-buffered rendering, and it's only possible in VR (unless something changed lately.) It provides near zero latency between the rasterizer and the player's eyes.

There is no second buffer in this scenario like there is for double-buffered rendering.