Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

Pre-rendered frames etc. (continued from G-Sync 101 article)

Talk about NVIDIA G-SYNC, a variable refresh rate (VRR) technology. G-SYNC eliminates stutters, tearing, and reduces input lag. List of G-SYNC Monitors.

Pre-rendered frames etc. (continued from G-Sync 101 article)

Postby pegnose » 29 Dec 2018, 08:13

@jorimt: Thank you very much for your reply to my questions!

Here is what I had asked:

I know I am a little late to the party, but I would like to ask something. I find it a little sad that G-Sync just as V-Sync allows for excessive frames to stack up. I have a powerful GPU and so I am (luckily) very often at the top limit of my monitor’s G-Sync range. I feel that I should disable V-Sync with G-Sync and accept some minor tearing for getting the best performance, particularly as I have an IPS display which I love color-wise but which already is far more laggy than my previous 1 ms G-Sync display (TN panel). I would rather not accept the 1 additional frame added by RTSS.

Here comes the question: does the NVCP option “Max. pre-rendered frames” not work? Or not all of the time with all of the games? Should it not do exactly what we all want: disable frame stacking and remove the need for a frame limit? I can’t find this setting being mentioned in your article at all.

I would also like to know whether the respective option in Overwatch does work well. If yes, does it not solve this issue at least for this game? You also stated that this option was ON for all your tests. If it works, you couldn’t have observed frame stacking with Overwatch, right?

And finally I would like to ask whether the 1 frame lag introduced by RTSS only applies when near the set threshold, or whether the limiter is active all of the time and the lag also occurs if operating far below the limit.

Thanks for you time!

EDIT: Out of curiosity, excessive frames stacking up would be limited by VRAM size, right?



And here is what you had replied:

First off, you’re IPS doesn’t necessarily have more input lag than your TN; in fact, it could be the same in that respect, or have even less. What the IPS does have is more motion blur. The 1ms number advertised by your TN is what is called GtG (gray-to-gray), which measures how fast pixels on the display transition from black to white and back. The lower the number, the lower the motion blur.


That is true, motion blur is a bigger thing on IPS. However, I read that input latency is usually higher with IPS than TN. And I found this confirmed reading the Prad reviews for both of my displays, which differentiates between GtG and input lag:
https://www.prad.de/testberichte/test-m ... sverhalten
https://www.prad.de/testberichte/test-m ... Latenzzeit
(sorry, both in German; ~2 ms vs. ~19 ms of mere input lag)
In any case for me motion blur adds to perceived latency and now with IPS I really have the desire to get this as low as possible.


With that bit out of the way, in part 11 of my article, I never said RTSS added 1 frame of lag over an uncapped framerate within the G-SYNC range. If you go back and read it carefully, I only said RTSS had 1 more frame of lag over an in-game limiter. And as I’ve clarified in the comments section here multiple times before, RTSS can actually have less input lag than uncapped at the same framerate, even within the G-SYNC range (more on this further down).


From what you have written below I take it that this "1 more frame of lag" applies only if the RTSS limiter kicks in, i.e. if actually hitting the set limit. Specifically, it is 1 more frame of lag than in-game limiters would create at this point. But as lag cannot be negative, it is still 1 more frame (as compared to the best case scenario).

Now I have read through all the comments to the original article, as I felt I was missing out on prior information.

My current understanding is this: It is actually best if you are using an in-game FPS limiter AND you are constantly hitting that limit. If you don't use a limiter with G-Sync, you might end up piling up multiple pre-rendered frames. If you are constantly below your FPS limiters value, e.g. you are GPU-limited and constantly well withing G-Sync range, you are at something like pre-rendered frames of "1". Only if you are constantly hitting your set FPS limit below the monitor's refresh rate you are at something like pre-rendered frames of "0". However, if you are using RTSS, this benefit gets sort of eaten up by the one additional frame of lag (as opposed to in-game limiters).

Does that mean it would be beneficial to set the FPS limit even lower in some GPU-intense games in order to make sure that you are always constantly hitting that limit? Purely speaking from a lag perspective.


As for NVCP’s Maximum pre-rendered frames setting, I do have a paragraph on that in part 14 of my article (under “Maximum Pre-rendered Frames: Depends”), and, to be clear here, the pre-rendered frames queue has nothing to do with the need to limit the framerate 3 FPS below the given max refresh rate with G-SYNC enabled. As I stated in a comment a few below yours (when sorted by “NEWEST”): “You need the FPS limit because G-SYNC works by dynamically adjusting the refresh rate, and when the refresh rate is maxed out, it no longer has anything to adjust.”


I apologize, I should have read to the end of the article first.

I sort of get what you said in the last sentence. My current understanding is: If running G-Sync with V-Sync on and if FPS are reaching the displays max refresh rate, G-Sync effectively switches to V-Sync behavior allowing for pre-rendered frames to pile up.

Now my reasoning was: the GPU will not do anything if no frame data (character positioning etc.) is provided by the CPU. Therefore, if "Max. pre-rendered Frames" is set to the lowest possible value, the GPU won't stack up frames because there is nothing to process.


In simplified terms, unlike the “over-queuing of frames” (which is caused by certain syncing methods’ frame buffers continually overfilling when the framerate is above the max refresh rate, and prevented with an appropriate FPS limit), the Maximum pre-rendered frames setting determines how much “breathing room” the CPU has before it hands frames off to the GPU for display; the larger the queue (say “4”), the less potential there is for frametime spikes (but the higher the input lag), and the smaller the queue (say “1”), the more potential there is for frametime spikes (but the lower the input lag).


Hm. So the CPU does not actually pre-compute frame-related game info but just sort of "waits" longer or has a longer grace period for coming up with the necessary data the GPU needs? This stuff really confuses me, I apologize.


The pre-rendered frames queue is typically required to keep frame delivery as uninterrupted as possible, since there is no guaranteed frametime from frame to frame with a fluctuating framerate. However, if the framerate is limited by an FPS cap at all times (and doesn’t drop below it), there is now a constant, predicable frametime, and the pre-rendered frames queue effectively becomes “0” until the framerate drops below the cap again, at which point said queue resumes. For that reason, even if there isn’t an in-game limiter available, an RTSS limit actually has potentially lower input lag than uncapped at the same framerate within the G-SYNC range.


My understanding has grown, see above.


As for Overwatch’s “Reduced Buffering” option, that’s their equivalent of NVCP’s Maximum pre-rendered frames at “1.” However, again, you still need the -3 FPS limit on top of that to stay within the G-SYNC range. And I do recommend the Overwatch FPS limiter over RTSS for that specific game.


I seem to understand now that constantly hitting the limit of an FPS limiter is beneficial and is what you want, preferably an in-game limiter.

I still don't quite understand the purpose of the max pre-rendered frames. If G-Sync transitions to V-Sync, multiple frames can stack up, of course. You prevent this via a limiter. And constantly hitting this limit is even better, you achieve a pre-rendered frames state of "0". If you fall below the limit, you are back at "1". But if you set pre-rendered frames to "1" in NVCP or in-game, and you don't use a limiter, shouldn't that have the same effect as being below your FPS limit? A maximum of 1 frame will pile up?

I understand that if you play Overwatch or CS competitively, and you have framerates of 300 FPS all the time, and you are playing on a 240Hz display with a limiter set to 237 FPS, you will constantly hit this limit and you have the perfect lag-free and tear-free solution on a G-Sync display.

But if you play something like Far Cry 5 of Battlefield V or whatever, and you are constantly dropping below the 237 FPS (or 163 FPS on a 166 Hz screen as in my case), you will basically never sit in that sweet spot of pre-rendered frames of "0", but you will always be at "1". And at this point you could as well _not_ use a limiter. Because with Max Pre-Rendered Frames set to "1" in NVCP you will "pile up" the same amount of 1 frame even if you reach/exceed your monitors refresh rate. And then you would not constantly switch between "0" and "1" depending on whether you hit the limit or not, but you would have a constant lag of 1 pre-rendered frame all the time, which some people might find more pleasing.

Of course, you could also set a much lower limit to make sure you hit it all the time. But who wants to limit the framerate unnecessarily.


And yes, the RTSS limiter is only active when the framerate is at or above the set limit; whenever the framerate drops below the set limit, the RTSS limiting function is not active.


Good to know, thank you.


Finally, no, your VRAM size has nothing directly to do with either the over-queuing of frames or the pre-rendered frames queue. VRAM is primarily there for games to access textures and other assets, as it typically has much faster access times than system RAM or hard drives.


So neither over-queuing of frames nor pre-rendered frames actually mean that the GPU has computed anything. It is just data prepared by the CPU and nothing is really rendered. Is that it? Because fully rendered frame buffers would probably not get stored in system RAM as that would be very slow, as you also stated. They have to be stored in the VRAM. Unless the GPU has some additional hardware for storing the frame buffer(s), which is not my understanding at least.


Again, thank you very much for spending all this time answering all or our questions, jorimt!


EDIT: I really wonder why NVidia doesn't give us the option to have "0" pre-rendered frames all the time, if that is what most of us want.
pegnose
 
Posts: 15
Joined: 29 Dec 2018, 04:22

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby jorimt » 29 Dec 2018, 11:43

pegnose wrote:That is true, motion blur is a bigger thing on IPS. However, I read that input latency is usually higher with IPS than TN. And I found this confirmed reading the Prad reviews for both of my displays, which differentiates between GtG and input lag:
https://www.prad.de/testberichte/test-m ... sverhalten
https://www.prad.de/testberichte/test-m ... Latenzzeit
(sorry, both in German; ~2 ms vs. ~19 ms of mere input lag)
In any case for me motion blur adds to perceived latency and now with IPS I really have the desire to get this as low as possible.

It depends on how the input lag is measured (methods can vary heavily from site to site), and it can also depend on the IPS panel type (AHVA IPS-type vs. traditional IPS, etc).

pegnose wrote:My current understanding is this: It is actually best if you are using an in-game FPS limiter AND you are constantly hitting that limit.

It is, but that's obviously not always possible (I'll touch on more of this further down).

pegnose wrote:If you don't use a limiter with G-Sync, you might end up piling up multiple pre-rendered frames.

Again, no. You end up over-queuing rendered frames; unlike the aforementioned, which is an unintended limitation of traditional syncing technology, the pre-rendered frames queue actually serves a purpose.

pegnose wrote:If you are constantly below your FPS limiters value, e.g. you are GPU-limited and constantly well withing G-Sync range, you are at something like pre-rendered frames of "1".

Yes, but only if the game is set to an equivalent of "Maximum pre-rendered frames" at "1"; the queue may be set higher.

pegnose wrote:Only if you are constantly hitting your set FPS limit below the monitor's refresh rate you are at something like pre-rendered frames of "0". However, if you are using RTSS, this benefit gets sort of eaten up by the one additional frame of lag (as opposed to in-game limiters).

When directly compared to in-game, limiters, yes, but that isn't the whole story. Read my off-the-record tests here:
viewtopic.php?f=5&t=3441&start=110#p26975

RTSS actually reduces input lag over uncapped, even within the G-SYNC range, so it technically doesn't add; If anything, it's neutral.

pegnose wrote:Does that mean it would be beneficial to set the FPS limit even lower in some GPU-intense games in order to make sure that you are always constantly hitting that limit? Purely speaking from a lag perspective.

For that reason, yes, but obviously there could be some downsides if you could otherwise reach higher framerates a good percentage of the time without the lowered FPS limit; increased visual fluidity/lower possible motion blur and lower overall frametimes vs. slight input lag reduction trade off (often not worth it).

pegnose wrote:My current understanding is: If running G-Sync with V-Sync on and if FPS are reaching the displays max refresh rate, G-Sync effectively switches to V-Sync behavior allowing for pre-rendered frames to pile up.

Again, pre-rendered frames and over-queuing of rendered frames are two different things.

pegnose wrote:Hm. So the CPU does not actually pre-compute frame-related game info but just sort of "waits" longer or has a longer grace period for coming up with the necessary data the GPU needs? This stuff really confuses me, I apologize.

The frame delivery process is a manufacturing chain. We created a graphic a while back that may make some of it clearer for you:

Image
pegnose wrote:I still don't quite understand the purpose of the max pre-rendered frames. If G-Sync transitions to V-Sync, multiple frames can stack up, of course. You prevent this via a limiter. And constantly hitting this limit is even better, you achieve a pre-rendered frames state of "0". If you fall below the limit, you are back at "1". But if you set pre-rendered frames to "1" in NVCP or in-game, and you don't use a limiter, shouldn't that have the same effect as being below your FPS limit? A maximum of 1 frame will pile up?

No, because, again, with uncapped frames (even within the refresh rate) that means there is no guaranteed framerate, and where there is no guaranteed framerate, there in no guaranteed frametime.

So if the system can't keep up at any point, and the framerate plummets, without a pre-rendered frame as a fallback, you're going to get a heavily reduced average framerate as the system tries to catch up, and/or increased frametime spikes.

Pre-rendered frames are basically a safety mechanism to account for all performance levels of all computers, and ensure there is always a "next" frame to present, regardless of performance level. That's why people with weaker PCs often report that their overall performance increases with pre-rendered frames set to a higher value.

As we've already established, if your system can sustain a constant FPS above a set FPS limit, the pre-rendered frames queue no longer factors in.

But since that isn't always possible, and they can't account for every single system spec in existence, pre-rendered frames are a necessary mechanism, else many weaker systems couldn't play more demanding games smoothly at any framerate at all.

pegnose wrote:I understand that if you play Overwatch or CS competitively, and you have framerates of 300 FPS all the time, and you are playing on a 240Hz display with a limiter set to 237 FPS, you will constantly hit this limit and you have the perfect lag-free and tear-free solution on a G-Sync display.

But if you play something like Far Cry 5 of Battlefield V or whatever, and you are constantly dropping below the 237 FPS (or 163 FPS on a 166 Hz screen as in my case), you will basically never sit in that sweet spot of pre-rendered frames of "0", but you will always be at "1". And at this point you could as well _not_ use a limiter. Because with Max Pre-Rendered Frames set to "1" in NVCP you will "pile up" the same amount of 1 frame even if you reach/exceed your monitors refresh rate. And then you would not constantly switch between "0" and "1" depending on whether you hit the limit or not, but you would have a constant lag of 1 pre-rendered frame all the time, which some people might find more pleasing.

Of course, you could also set a much lower limit to make sure you hit it all the time. But who wants to limit the framerate unnecessarily.

Yes, but without an FPS limit, at any point the framerate may exceed the refresh rate in those instances, over-queued frames often have much higher lag (anywhere from 2-6 frames) than pre-rendered frames; 1 frame of input lag at 144Hz+ refresh rates is relatively insignificant in comparison.

Also, again, I would like to make clear that pre-rendered frames and over-queued frames are separate, individual occurrences, so they can stack on each other, so to speak.

pegnose wrote:So neither over-queuing of frames nor pre-rendered frames actually mean that the GPU has computed anything. It is just data prepared by the CPU and nothing is really rendered. Is that it? Because fully rendered frame buffers would probably not get stored in system RAM as that would be very slow, as you also stated. They have to be stored in the VRAM. Unless the GPU has some additional hardware for storing the frame buffer(s), which is not my understanding at least.

I'm not an expert on every aspect of the entire chain (including pre-rendered frames, really), but what I can say is that the G-SYNC module on the monitor has enough onboard RAM to hold a single frame at a time (which, granted, is just to facilitate it's own functionality).

One of the reasons I suggested you post more questions here on the forum, is that some of our regulars here can discuss some of this in more depth with you, as I'm primarily a G-SYNC guy.

pegnose wrote:EDIT: I really wonder why NVidia doesn't give us the option to have "0" pre-rendered frames all the time, if that is what most of us want.

To add to what I already said earlier, mainly because there is no guarantee your system can keep up 100% of the time, and if it can't, pre-rendered frames "0" may mean a reduced average framerate of, say, 100 FPS when you could otherwise be getting 170 FPS with pre-rendered frames at "1" or more.

In other words, there is already a pre-rendered frames "0" setting: it's the framerate constantly being limited by an FPS cap. Otherwise, I don't believe it's possible to "set" separate of that scenario, even if they allowed it.

Finally, I'm sure others here can further clarify points in your questions that I was not able to, and who knows, they may have some corrections or clarifications for me (specifically on pre-rendered frames), because while I know enough about it to explain it in direct relation to G-SYNC/V-SYNC and FPS limiters, it's not my area of expertise.
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro (1903) MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz
User avatar
jorimt
 
Posts: 729
Joined: 04 Nov 2016, 10:44

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby RealNC » 29 Dec 2018, 14:24

Prad used two latency tests in the linked review of the LG. Leo Bodnar through HDMI at 60Hz, and their own method. The LB results were 11.2ms, 14ms and 17.1ms for the upper, center and lower region of the display respectively.

Their own latency test is done on DisplayPort at the highest refresh rate. Their description is vague: they are measuring the delay between image and audio. Not sure what that means exactly. It seems they have software that generates audio at the same time as images. Since the audio latency is a known value, I assume that by measuring the delay between the audio signal and the light sensor that watches the display, you get the display latency. That test gives 23.2ms. That latency value includes all overhead by the OS (OS scheduling, DirectX, GPU driver) not just the display's latency. So it's more similar to a "button to pixels" test.

For the XB270HAbprz TN panel, ̶t̶h̶e̶y̶ ̶o̶n̶l̶y̶ ̶u̶s̶e̶d̶ ̶t̶h̶e̶i̶r̶ ̶o̶w̶n̶ ̶a̶u̶d̶i̶o̶-̶t̶o̶-̶i̶m̶a̶g̶e̶ ̶t̶e̶s̶t̶, which gave 2.8ms.

It's worth noting that the Acer test was done in 2015, and the LG test in 2018. I assume OS and driver updates will influence the results.

EDIT:

I was wrong. Their 2015 review does NOT say what methodology they used. In their review of the Asus IPS display, they got 5.6ms:

https://www.prad.de/testberichte/test-m ... -pg279q/7/

I would say you can not compare their past reviews with their modern ones. They use completely different latency tests. You can compare their 2015 review of the Acer TN to their 2015 review of the Asus IPS (2.8ms vs 5.6ms), but not to the 2018 review of the LG.
TwitterSteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
User avatar
RealNC
 
Posts: 2775
Joined: 24 Dec 2013, 18:32

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby pegnose » 29 Dec 2018, 14:50

RealNC wrote:Prad used two latency tests in the linked review of the LG. Leo Bodnar through HDMI at 60Hz, and their own method. The LB results were 11.2ms, 14ms and 17.1ms for the upper, center and lower region of the display respectively.

Their own latency test is done on DisplayPort at the highest refresh rate. Their description is vague: they are measuring the delay between image and audio. Not sure what that means exactly. It seems they have software that generates audio at the same time as images. Since the audio latency is a known value, I assume that by measuring the delay between the audio signal and the light sensor that watches the display, you get the display latency. That test gives 23.2ms. That latency value includes all overhead by the OS (OS scheduling, DirectX, GPU driver) not just the display's latency. So it's more similar to a "button to pixels" test.

For the XB270HAbprz TN panel, they only used their own audio-to-image test, which gave 2.8ms.

It's worth noting that the Acer test was done in 2015, and the LG test in 2018. I assume OS and driver updates will influence the results.



RealNC, thank you for detailing this a bit more. I actually only took one value from their text. Which was enough for me when I decided to buy the display. For my job in a research group I did photo LED based presentation lag tests (my own circuitry) on various displays for visual experiments myself. I know a little bit about those things. But I wasn't able to completely understand what Prad describes, a lot of info is missing, and so I went with a rough approximation.

Initially I even decided against the display and IPS technology in general for gaming because of this high latency value. Later I opted that I can live with it, particularly because of the great image this display delivers as compared to my old TN.

Now I can say that the increased perceived latency with my new IPS is actually noticable to me. With the old TN I never could detect any latency. As I got that one a couple of years ago together with a set of 1000 Hz "1 ms" input devices, for a short time I even had the impression that my PC responds _before_ I had clicked a button or pressed a key. ;)

Long story short, I can feel the lag now, of course depending on FPS and whether I play with G-Sync/V-Sync on or just everything off. And so try to minimize lag wherever possible.
pegnose
 
Posts: 15
Joined: 29 Dec 2018, 04:22

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby RealNC » 29 Dec 2018, 15:05

pegnose wrote:Initially I even decided against the display and IPS technology in general for gaming because of this high latency value. Later I opted that I can live with it, particularly because of the great image this display delivers as compared to my old TN.

I updated my post though. I was wrong about their 2015 test. They were completely different.

Gaming IPS vs TN latency is not always higher. Prime example here is the Asus 165Hz TN vs their 165Hz IPS. The IPS model actually had less latency than their TN.

You'd need to search Prad for a test of a TN gaming display done in 2018 too, to see what values they get, since they completely changed their latency test since 2015. The current test includes all OS and software overhead, their 2015 one clearly did not.

Now I can say that the increased perceived latency with my new IPS is actually noticable to me. With the old TN I never could detect any latency. As I got that one a couple of years ago together with a set of 1000 Hz "1 ms" input devices, for a short time I even had the impression that my PC responds _before_ I had clicked a button or pressed a key. ;)

Long story short, I can feel the lag now, of course depending on FPS and whether I play with G-Sync/V-Sync on or just everything off. And so try to minimize lag wherever possible.

It could be that the LG indeed buffers a full frame for image processing. I don't know. My own IPS display (XG2703-GS) does not though. It was tested to have about the same latency as any gaming TN out there (to within 2 or 3ms.) So not all IPS displays are equal when it comes to latency. (Not all TN ones are equal either, for that matter.)
TwitterSteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
User avatar
RealNC
 
Posts: 2775
Joined: 24 Dec 2013, 18:32

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby pegnose » 29 Dec 2018, 16:22

Again thank you so much for the incredible amount of time you put into answering my questions! And for all the additional information you have given me (including the off the record tests of frame limiters). I also understand that you have your particular areas of expertise and that others might be able to contribute to eliminating my ignorance, too. I would highly appreciate that!


jorimt wrote:
pegnose wrote:If you don't use a limiter with G-Sync, you might end up piling up multiple pre-rendered frames.

Again, no. You end up over-queuing rendered frames; unlike the aforementioned, which is an unintended limitation of traditional syncing technology, the pre-rendered frames queue actually serves a purpose.


Thank you for making this perfectly clear now. I apologize for mixing these two up all the time.

Before I read your article I never knew about the over-queuing of rendered frames. I myself had only worked with simple front/back buffer flips, one per unit. I would be particularly interested in
- whether this is an intended feature (it is probably not a bug; and as it costs memory, it likely is not a mere ignored side-effect) and why it cannot be disabled; does it come from the console side where a smoother game experience might be more important than latency?
- whether it is unique to DirectX (I have mainly worked with OpenGL so far)
- how it happens in the first place: the front buffer gets scanned out while the back buffer is being rendered to, and if that is done the buffers swap pointers; unlike with triple buffering, there is no idle buffer around; so there must be a hidden queue for the front buffer where complete frames from the back buffer get stored if rendering occasionally takes a much shorter time than the current frame is displayed. it would seem reasonable to me then that only the most recently queued frame would be selected, which is what triple buffering of fast sync do. the whole concept of piling up rendered frames when in double-buffer mode does not make sense to me yet, tbh
- and where those queued frames get stored (if in VRAM, then VRAM size must limit the amount of frames piling up)


jorimt wrote:
pegnose wrote:If you are constantly below your FPS limiters value, e.g. you are GPU-limited and constantly well withing G-Sync range, you are at something like pre-rendered frames of "1".

Yes, but only if the game is set to an equivalent of "Maximum pre-rendered frames" at "1"; the queue may be set higher.


Ok, then I should hope that the NVCP setting works with my games.


jorimt wrote:
pegnose wrote:Only if you are constantly hitting your set FPS limit below the monitor's refresh rate you are at something like pre-rendered frames of "0". However, if you are using RTSS, this benefit gets sort of eaten up by the one additional frame of lag (as opposed to in-game limiters).

When directly compared to in-game, limiters, yes, but that isn't the whole story. Read my off-the-record tests here:
viewtopic.php?f=5&t=3441&start=110#p26975

RTSS actually reduces input lag over uncapped, even within the G-SYNC range, so it technically doesn't add; If anything, it's neutral.


Thank you, that is very interesting and helpful!


jorimt wrote:
pegnose wrote:Hm. So the CPU does not actually pre-compute frame-related game info but just sort of "waits" longer or has a longer grace period for coming up with the necessary data the GPU needs? This stuff really confuses me, I apologize.

The frame delivery process is a manufacturing chain. We created a graphic a while back that may make some of it clearer for you:

Image
pegnose wrote:[...]

No, because, again, with uncapped frames (even within the refresh rate) that means there is no guaranteed framerate, and where there is no guaranteed framerate, there in no guaranteed frametime.

So if the system can't keep up at any point, and the framerate plummets, without a pre-rendered frame as a fallback, you're going to get a heavily reduced average framerate as the system tries to catch up, and/or increased frametime spikes.

Pre-rendered frames are basically a safety mechanism to account for all performance levels of all computers, and ensure there is always a "next" frame to present, regardless of performance level. That's why people with weaker PCs often report that their overall performance increases with pre-rendered frames set to a higher value.


Would it be valid to say that what pre-rendered frames are for the CPU, piling-up rendered frames are for the GPU? A somewhat hidden queue making sure there is always new data to work with or to present?


jorimt wrote:As we've already established, if your system can sustain a constant FPS above a set FPS limit, the pre-rendered frames queue no longer factors in.


So the "safety buffer" on the CPU side - as opposed to the one on the GPU side - is able to always pick the most recent set of data?


jorimt wrote:But since that isn't always possible, and they can't account for every single system spec in existence, pre-rendered frames are a necessary mechanism, else many weaker systems couldn't play more demanding games smoothly at any framerate at all.


Thank you, that was always my understanding. What I did not understand in the beginning was that pre-rendered frames and piled-up rendered frames were two completely independent mechanisms. Particularly, I thought limiting pre-rendered frames could prevent frames rendered by the GPU from piling up.


jorimt wrote:
pegnose wrote:So neither over-queuing of frames nor pre-rendered frames actually mean that the GPU has computed anything. It is just data prepared by the CPU and nothing is really rendered. Is that it? Because fully rendered frame buffers would probably not get stored in system RAM as that would be very slow, as you also stated. They have to be stored in the VRAM. Unless the GPU has some additional hardware for storing the frame buffer(s), which is not my understanding at least.

I'm not an expert on every aspect of the entire chain (including pre-rendered frames, really), but what I can say is that the G-SYNC module on the monitor has enough onboard RAM to hold a single frame at a time (which, granted, is just to facilitate it's own functionality).

One of the reasons I suggested you post more questions here on the forum, is that some of our regulars here can discuss some of this in more depth with you, as I'm primarily a G-SYNC guy.


I think it is clearer for me now. Queued rendered frames (by the GPU) are complete "frame buffers". Pre-rendered frames by the CPU are actually a queue of multiple complete sets of game logic. Initially I though the CPU might just compute 1 set ahead and then usually wait longer for delivering it to the GPU (for being able to respond faster occasionally). But that does not make any sense, because after this one set is delivered, the CPU might get into trouble if unexpectedly busy.

What might have thrown me off is the term "pre-rendered". It might not mean "rendered in advance" but rather frames before ("pre") rendering. Or it uses "rendering" more in the literal sense of "creating".


jorimt wrote:
pegnose wrote:EDIT: I really wonder why NVidia doesn't give us the option to have "0" pre-rendered frames all the time, if that is what most of us want.

To add to what I already said earlier, mainly because there is no guarantee your system can keep up 100% of the time, and if it can't, pre-rendered frames "0" may mean a reduced average framerate of, say, 100 FPS when you could otherwise be getting 170 FPS with pre-rendered frames at "1" or more.

In other words, there is already a pre-rendered frames "0" setting: it's the framerate constantly being limited by an FPS cap. Otherwise, I don't believe it's possible to "set" separate of that scenario, even if they allowed it.


Makes perfect sense. Only it takes a lot of "insider" knowledge to apply this workaround.


jorimt wrote:Finally, I'm sure others here can further clarify points in your questions that I was not able to, and who knows, they may have some corrections or clarifications for me (specifically on pre-rendered frames), because while I know enough about it to explain it in direct relation to G-SYNC/V-SYNC and FPS limiters, it's not my area of expertise.
pegnose
 
Posts: 15
Joined: 29 Dec 2018, 04:22

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby pegnose » 29 Dec 2018, 16:33

RealNC wrote:
pegnose wrote:Initially I even decided against the display and IPS technology in general for gaming because of this high latency value. Later I opted that I can live with it, particularly because of the great image this display delivers as compared to my old TN.

I updated my post though. I was wrong about their 2015 test. They were completely different.


I saw that, thank you for the additional information!

RealNC wrote:Gaming IPS vs TN latency is not always higher. Prime example here is the Asus 165Hz TN vs their 165Hz IPS. The IPS model actually had less latency than their TN.


Interesting! Or a little disappointing that my particular display is rather slow. But then it is ultra-wide, maybe that factors in.

RealNC wrote:You'd need to search Prad for a test of a TN gaming display done in 2018 too, to see what values they get, since they completely changed their latency test since 2015. The current test includes all OS and software overhead, their 2015 one clearly did not.


As I said before, I perceive the lag now as compared to the TN. Perceptually it makes sense to me that it is in the area of ~20 ms because it lags ever so slightly with G-Sync/V-Sync off. What do you get with your display?

RealNC wrote:
Now I can say that the increased perceived latency with my new IPS is actually noticable to me. With the old TN I never could detect any latency. As I got that one a couple of years ago together with a set of 1000 Hz "1 ms" input devices, for a short time I even had the impression that my PC responds _before_ I had clicked a button or pressed a key. ;)

Long story short, I can feel the lag now, of course depending on FPS and whether I play with G-Sync/V-Sync on or just everything off. And so try to minimize lag wherever possible.

It could be that the LG indeed buffers a full frame for image processing. I don't know. My own IPS display (XG2703-GS) does not though. It was tested to have about the same latency as any gaming TN out there (to within 2 or 3ms.) So not all IPS displays are equal when it comes to latency. (Not all TN ones are equal either, for that matter.)


Unfortunately, there is no fast/direct mode in the OSD for my display. I also don't know what kind of pre-processing would require such buffering. I don't think a black equalizer or the built-in overclocking to 166 Hz would make that necessary.
pegnose
 
Posts: 15
Joined: 29 Dec 2018, 04:22

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby RealNC » 29 Dec 2018, 16:44

pegnose wrote:As I said before, I perceive the lag now as compared to the TN. Perceptually it makes sense to me that it is in the area of ~20 ms because it lags ever so slightly with G-Sync/V-Sync off. What do you get with your display?

I perceive no latency at all. It's the same IPS panel as the Asus 165Hz. In reviews, both monitors show low latency.

Compared to my previous 144Hz TN monitor (G2770PF,) it feels exactly the same. Weirdly, it has less ghosting than the TN panel (but that's probably down to AOC's really bad overdrive.)
TwitterSteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
User avatar
RealNC
 
Posts: 2775
Joined: 24 Dec 2013, 18:32

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby jorimt » 29 Dec 2018, 17:28

pegnose wrote:Before I read your article I never knew about the over-queuing of rendered frames. I myself had only worked with simple front/back buffer flips, one per unit. I would be particularly interested in
- whether this is an intended feature

As far as I know, it's exclusive to double buffer V-SYNC, as well as "faked" triple buffer V-SYNC (basically double buffer with a third buffer; no relation to true, traditional triple buffer). G-SYNC is also based on a double buffer, as it is only meant to work within the refresh rate that it adjusts to do it's magic.

And no, over-queuing isn't intended, it's simply a limitation of syncing the GPU’s render rate to the fixed refresh rate of the display. Others here can probably breakdown the "why" for you in more details, as my explanation would likely come across more conceptual than technical.

pegnose wrote:Ok, then I should hope that the NVCP setting works with my games.

Right, because while rare, it is possible for some games to not respect the NVCP setting, though it's very difficult to tell which they are.

pegnose wrote:Would it be valid to say that what pre-rendered frames are for the CPU, piling-up rendered frames are for the GPU? A somewhat hidden queue making sure there is always new data to work with or to present?

So the "safety buffer" on the CPU side - as opposed to the one on the GPU side - is able to always pick the most recent set of data?

As far as I currently understand it myself (anyone is free to chime in with corrections), think of the pre-rendered frames queue as less of a direct input lag modifier (which is actually a peripheral effect of it's primary function), and more as a CPU-side throttle for regulating the average framerate.

The less powerful the CPU is in relation to the paired GPU, the larger the queue needs to be in order to keep a steady flow of information being handed off from the CPU to the GPU, which in most cases, equals a lower average framerate.

This is why in instances where the CPU is more of a match to the GPU, you'll find people reporting that a pre-rendered frame queue setting of "1" actually increases their average framerate (if only ever so slightly) when compared to higher queue values, as the higher queue values actually begin to throttle the average framerate (a.k.a slow CPU hand off to the GPU) unnecessarily. Whereas for the weaker systems (where the CPU is less of a match to the GPU), lower values may decrease performance and/or cause more frametime spikes (complete absence of frames for a frame or frames at a time).

So like my article already states, the effects of the "Maximum pre-rendered frames" setting truly "Depends" on the given system, the given game, the given queue setting, and the interaction between the three.

pegnose wrote:I think it is clearer for me now. Queued rendered frames (by the GPU) are complete "frame buffers". Pre-rendered frames by the CPU are actually a queue of multiple complete sets of game logic.

What might have thrown me off is the term "pre-rendered". It might not mean "rendered in advance" but rather frames before ("pre") rendering. Or it uses "rendering" more in the literal sense of "creating".

As far as I know, yes, pre-rendered frames aren't actually complete frames, but simply CPU-side instructions necessary to complete a fully rendered frame (per) that can be finally delivered to the display after they have been handed off and completed by the GPU.

And I agree, the naming is poor.
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro (1903) MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz
User avatar
jorimt
 
Posts: 729
Joined: 04 Nov 2016, 10:44

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Postby RealNC » 29 Dec 2018, 18:59

jorimt wrote:
pegnose wrote:Before I read your article I never knew about the over-queuing of rendered frames. I myself had only worked with simple front/back buffer flips, one per unit. I would be particularly interested in
- whether this is an intended feature

As far as I know, it's exclusive to double buffer V-SYNC, as well as "faked" triple buffer V-SYNC (basically double buffer with a third buffer; no relation to true, traditional triple buffer). G-SYNC is also based on a double buffer, as it is only meant to work within the refresh rate that it adjusts to do it's magic.

And no, over-queuing isn't intended, it's simply a limitation of syncing the GPU’s render rate to the fixed refresh rate of the display. Others here can probably breakdown the "why" for you in more details, as my explanation would likely come across more conceptual than technical.

The reason this happens is rather simple. In the past, doing the flip would block. Meaning the API function that you call to do the flip would not return until the flip was performed. With vsync, it meant it would block until the next vblank.

Now, this function (usually a present() related function) does not block. It returns immediately and will schedule the submitted frame to be asynchronously presented "later." This creates so-called vsync backpressure, which adds latency. The asynchronous nature of today's graphics APIs allows the game to sample player input early. Too early. When the present() call doesn't block, the game will sample new input, prepare a couple frames to be rendered, then try to render, then try to present, at which point the call will actually block because push came to shove and blocking is the only thing to do, since the flip still hasn't occurred. But now the game is sitting on very old player input, and it's not getting any younger. By the time the frames make it to the screen, they're old and thus with lots of lag.

This is why an FPS cap gets rid of vsync lag. It blocks the game in the same way as flipping did in the past. Thus the game is always being forced to wait and as a result new frames are based on fresh player input.
TwitterSteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
User avatar
RealNC
 
Posts: 2775
Joined: 24 Dec 2013, 18:32

Next

Return to G-SYNC

Who is online

Users browsing this forum: No registered users and 5 guests