Blur Busters Forums

.

The "buffer concept" an still be siloed that way, but I don't tend to silo that way in mentally --

At the driver level, "pre-rendered frames" and "buffer" are essentially the same format, so I consider them one and the same. There are many buffering workflows, and there's two kinds of triple buffering -- where laggy triple buffer is one extra frame in a queue -- and less-laggy triple buffer pre-empts the buffer prior to the front buffer.

However, it does make it easier to conceptualize for some people to silo the first few buffers as a queue and the final buffer (or two) as the traditional workflow.

Chief Blur Buster wrote: ↑

18 May 2020, 16:37

At the driver level, "pre-rendered frames" and "buffer" are essentially the same format, so I consider them one and the same.

Correct; conceptual, oversimplified wording on my part. They are indeed essentially part of the same thing.

Probably a better way for me to have put it while retaining simplicity, is that the pre-rendered frames queue and the double/triple buffer are, in a way, typically "partitioned" for distinct usage along the rendering chain, and thus can be considered separate when talking about the LLM setting's specific impact.

Thanks for the answers, Chief, Jorimt!

Chief Blur Buster wrote: ↑

17 May 2020, 13:05

Even if average absolute lag is identical for a perfect 60Hz monitor and for a perfect 240Hz monitor, the lagfeel is lower at 240Hz because more pixel update opportunities are occuring per pixel, allowing earlier visibility per pixel.

I intuitively grasp this but doesn't the first on-screen reaction measure "absolute" input lag rather than lagfeel? Imagine for example infinite framerate situation on 60 hz instant response screen and let's ignore any input lag (mouse, engine, etc) except for scanout related. Shouldn't there be instant moving of vertical line in jorimt's CS:GO test map starting in place where display was scanning out right now? What is the situation where there would be a 1/60s delay in first on-screen reaction?

jorimt wrote: ↑

17 May 2020, 13:35

Technically, yes, but to add to what the Chief said, this would more be the case if I had tested by making the camera continually spin in place. Instead, I was testing for randomized user input based on my clicking of the mouse approximately every 1 second.

Could you elaborate, please, how would those testing methods differ in this situation?

jorimt wrote: ↑

17 May 2020, 13:35

Could you elaborate, please, how would those testing methods differ in this situation?

Because with the camera continually spinning in place, there would be no way to test for "input" lag, as now the screen is constantly visibly updating with no way to tell when input started or stopped, and instead, you're effectively just watching a non-interactive video loop rendering in real-time. And as we all know, with videos and movies, input lag doesn't matter in the least, only audio/video sync.

In fact, the whole subject of input lag makes evident that modern display technology is based on an original technology (top to bottom, left to right scanout) that was never directly intended for interactive media. Amazing it works as well as it does come to think of it.

hmukos wrote: ↑

19 May 2020, 08:25

Shouldn't there be instant moving of vertical line in jorimt's CS:GO test map starting in place where display was scanning out right now? What is the situation where there would be a 1/60s delay in first on-screen reaction?

The same tearlines are effectively being drawn in the same places, but since the 60Hz scanout is slower, it reveals them more slowly than it does at 240Hz.

In this very specific context (because it does not work in any other context for this subject), take a single static image of a game scene containing multiple tearlines frozen in motion across a single, complete scanout cycle, now print it out, once with a fast printer, once with a slow printer. Both will ultimately print the same image, but one will print it faster. That's effectively what you're seeing in those 60Hz vs. 240Hz V-SYNC off graphs.

I'm sure the Chief can elaborate with more technical detail further, but that's the conceptual "word picture" version.

.

jorimt wrote: ↑

19 May 2020, 09:02

take a single static image of a game scene containing multiple tearlines frozen in motion across a single, complete scanout cycle, now print it out, once with a fast printer, once with a slow printer. Both will ultimately print the same image, but one will print it faster. That's effectively what you're seeing in those 60Hz vs. 240Hz V-SYNC off graphs.

Doesn't this example require that an already teared image was stored somewhere before scanout? I thought tearing happens when new frame was rendered while panel was scanning out.

So looking at this picture, shouldn't we see some reaction on first scanout right when "Draw 1" happened? This is how I see it: at first we had some frame in the buffer and the panel was scanning it out, but then GPU drew a new frame based on last input and panel is right away continuing the scanout but with new frame. How can input lag in this situation be longer than the time it took to render last frame?

BTRY B 529th FA BN wrote: ↑

19 May 2020, 11:37

Just so this is clear, by "Non-G-SYNC" do you mean G-Sync + Vsync Off, or (monitor technology) Fixed Refresh + Vsync Off? Or are they the same thing?

Fixed refresh. E.g. any scenario that doesn't use VRR.

hmukos wrote: ↑

19 May 2020, 11:56

Doesn't this example require that an already teared image was stored somewhere before scanout? I thought tearing happens when new frame was rendered while panel was scanning out.

So looking at this picture, shouldn't we see some reaction on first scanout right when "Draw 1" happened? This is how I see it: at first we had some frame in the buffer and the panel was scanning it out, but then GPU drew a new frame based on last input and panel is right away continuing the scanout but with new frame. How can input lag in this situation be longer than the time it took to render last frame?

I'm not sure whether I'll be able to make it much clearer for you at this point, but...

The graph you embedded as an example is 1) measuring in 16ms intervals (aka 60Hz; for 240Hz, that same graph would be measured in 4ms intervals), and 2) at what looks to be 60 FPS (single tearline per frame scan).

Pointing back to the scenario in your original question, with 2000 FPS V-SYNC off @60Hz, there are parts of multiple frames being delivered in the span of a single scanout cycle.

Say you have 5 tearlines in a single frame scan on a 60Hz display; it's still going to take 16.6ms to reveal them all. That's what I meant with my slower/faster printer example.

That aside, a framerate that causes 5 tearlines @60Hz will cause less @240Hz, as it scans in individual frames faster, regardless of framerate, which gives V-SYNC off less of a chance to "defeat" the scanout.

Have you read this part of my article per chance?
https://blurbusters.com/gsync/gsync101- ... ettings/6/

jorimt wrote: ↑

19 May 2020, 14:15

The graph you embedded as an example is 1) measuring in 16ms intervals (aka 60Hz; for 240Hz, that same graph would be measured in 4ms intervals), and 2) at what looks to be 60 FPS (single tearline per frame scan).

Pointing back to the scenario in your original question, with 2000 FPS V-SYNC off @60Hz, there are parts of multiple frames being delivered in the span of a single scanout cycle.

Yes, I'm aware, but I couldn't find better picture to illustrate what I was trying to say.

jorimt wrote: ↑

19 May 2020, 14:15

Say you have 5 tearlines in a single frame scan on a 60Hz display; it's still going to take 16.6ms to reveal them all. That's what I meant with my slower/faster printer example.

But wouldn't the first/second tearline since input reveal changes already (considering other factors don't increase lag)? What is the case where we should wait for all 5 tearlines to be scanned to get the on-screen reaction since input?

jorimt wrote: ↑

19 May 2020, 14:15

Have you read this part of my article per chance?
https://blurbusters.com/gsync/gsync101- ... ettings/6/

Yes, I have read it. I think that is where my misunderstanding started. I can't understand how does VSYNC OFF in this case defeat G-SYNC. Isn't the moment in time when lower part of "frame 2" in VSYNC OFF starts to appear (left image) the same as moment when the G-SYNC starts to scan the "frame 2" (right image)? Cause both situations in my understanding happen right when the "frame 2" was rendered.