Blur Buster's G-SYNC 101 Series Discussion

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.
hmukos
Posts: 30
Joined: 16 Apr 2020, 15:41

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by hmukos » 21 May 2020, 09:45

jorimt wrote:
21 May 2020, 08:43
E.g. the 0.5ms number only comes in once the input finally triggers a render.
By "system reaction" I meant exactly the time when new position after all the delays (system/game engine/etc) is rendered (and not yet scanned out). So if we ignore the display at all, we get about "12-14ms" between click and time when updated camera position has been rendered and placed into buffer, right?
jorimt wrote:
21 May 2020, 08:43
Firstly, not sure if you meant to say there are 2000 frameslices at 2000 FPS @60Hz in a single scanout, but there's actually about 33 (0.5 x 33.2 = 16.6), and that's if we're talking a perfect, constant 2000 FPS; the slice count could fluctuate a bit at any given point in reality.
Not in a single scanout of course but in 1 second. I mean that if we take the same period of time there will be the same number of frameslices and every frameslice would take the same amount of time to be scanned from start to finish regardless of refresh rate.
jorimt wrote:
21 May 2020, 08:43
So yes, at 2000 FPS, the screen is updating around 33 times in a single scanout with V-SYNC off @60Hz, but that 33 times is across a fixed (and linear) 16.6ms, and only one of those updates is going to contain our sample, and said sample may appear right near the beginning of that scanout or right near the end. The higher it appears, the less "delay," the lower it appears the more "delay" within that scanout.

However, at 240Hz, 2000 FPS, the screen is only updating around 8 times (0.5 x 8.4 = 4.2) in a single scanout, so the span between top of scanout and bottom of scanout is reduced. As such, the possible difference in "delay" between the input appearing at the top or bottom of the scanout is smaller, thus a reduced min/max range.
But if we take 240hz and look at the same 16.6ms interval we will get the same 33 frameslices (but now during 4 scanouts). How do 60hz and 240hz differ in this regard if during the same amount of time the same frameslices are shown at exact same times? The only difference I see is that same frameslices take up 1/8 of screen each and not 1/33 but every timestep for start and end of each frameslice shoud be the same between 60hz and 240hz, isn't that so?

User avatar
jorimt
Posts: 2479
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorimt » 21 May 2020, 10:16

hmukos wrote:
21 May 2020, 09:45
But if we take 240hz and look at the same 16.6ms interval we will get the same 33 frameslices (but now during 4 scanouts). How do 60hz and 240hz differ in this regard if during the same amount of time the same frameslices are shown at exact same times?
Because with this measurement method, we only have one tearline representing one sample occurring within one tear slice of one scanout cycle.

- The possible offset of the tearline (containing reflection of the input) within a single refresh cycle at 60Hz = 0 - 16.6ms
- The possible offset of the tearline (containing reflection of the input) within a single refresh cycle at 240Hz = 0 - 4.2ms

So with ~2000 FPS V-SYNC off, at 60Hz, the input is going to reflect in 1 of 33 of those slices of that single 16.6ms scanout, but at 240Hz, the input is going to reflect in 1 of 8 of those slices of that single 4.2ms scanout.

I'm not sure what's so difficult to understand about that. You as the player are only seeing a single scanout cycle at a time, with any individual input update only occurring in that cycle.

For this particular min/max difference (excluding all other factors), it doesn't matter how many scanouts have occurred before it, or how many tear slices are contained within that single scanout, only in what tear slice of that scanout that single input appears.

E.g. with all other factors (but the scanout) being equal, you're indeed seeing the same information, but you're ultimately seeing it at a more delayed rate at 60Hz than you are at 240Hz.

Also, I'm not giving you my theory here, I'm just looking at the results. Take it up with physics.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

hmukos
Posts: 30
Joined: 16 Apr 2020, 15:41

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by hmukos » 22 May 2020, 19:02

jorimt wrote:
21 May 2020, 10:16
Also, I'm not giving you my theory here, I'm just looking at the results. Take it up with physics.
I understand. I'm not trying to argue with the results, I'm just trying to connect the theory with them (at least in my head).
jorimt wrote:
21 May 2020, 10:16
So with ~2000 FPS V-SYNC off, at 60Hz, the input is going to reflect in 1 of 33 of those slices of that single 16.6ms scanout, but at 240Hz, the input is going to reflect in 1 of 8 of those slices of that single 4.2ms scanout.

I'm not sure what's so difficult to understand about that. You as the player are only seeing a single scanout cycle at a time, with any individual input update only occurring in that cycle.

For this particular min/max difference (excluding all other factors), it doesn't matter how many scanouts have occurred before it, or how many tear slices are contained within that single scanout, only in what tear slice of that scanout that single input appears.

E.g. with all other factors (but the scanout) being equal, you're indeed seeing the same information, but you're ultimately seeing it at a more delayed rate at 60Hz than you are at 240Hz.
I would understand this if multiple frameslices to be scanned out in this cycle would be somehow preremembered and scanned only after as a whole. But doesn't scanout happen in realtime and show frame as soon as it is rendered?

Let's step from another angle. Suppose that we are connected to 60hz and 240hz monitors simultaneously. Every frame is different color and as soon as frame is rendered it is being scanned out. Would this picture be correct? If so than what if now the frames are the CS:GO test and we know for sure that exactly at "Frame 7" the position of camera has updated. Wouldn't seeing "Frame 7" being scanned out happen at the same time for both screens?
EDIT: forgot to mention - the framerate in the picture example is 480 fps.
Frameslices.png
Frameslices.png (51.92 KiB) Viewed 8259 times

User avatar
jorimt
Posts: 2479
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorimt » 22 May 2020, 20:38

hmukos wrote:
22 May 2020, 19:02
Let's step from another angle. Suppose that we are connected to 60hz and 240hz monitors simultaneously. Every frame is different color and as soon as frame is rendered it is being scanned out. Would this picture be correct? If so than what if now the frames are the CS:GO test and we know for sure that exactly at "Frame 7" the position of camera has updated. Wouldn't seeing "Frame 7" being scanned out happen at the same time for both screens?
This is not something that occurs across multiple scanout cycles. The sample only appears within one cycle, and is positioned proportionately to the time span of the display's scanout:

Image

^ There's you're possible max difference with the same positioning of the same sample right there.

In fact, in the context of our conversation (e.g. difference in possible max readings between the two), the amount of "input" lag doesn't even matter, just at what point in the scanout the sample ultimately appears.

Also, regarding your latest image, you can't quite "scale" 240Hz to 60Hz literally like that in this context; there are 180 more refreshes occurring per second. There's a reason they call it a "higher" "refresh" "rate."

The difference between the two isn't height, it's time.

So the frame count in the below image in this context for 240Hz would actually not be frame 1, frame 2, frame 3, etc. It would be frame 1 (or more accurately, "tear slice" 1), frame 2 (tear slice 2), frame 1 (tear slice 1), frame 2 (tear slice 2), repeat, as again, the sample we're taking with this "first reaction" method only occurs in one scanout per, thus each scanout is a reset in this context; a new opportunity for a new sample to appear:

Image

As for how to compare a single 240Hz scanout against a single 60Hz scanout proportionately in this visual format, the above isn't right.

This isn't right:

Image

This isn't right either:

Image

It's more like this (like my example depicted at the top of this post):

Image

E.g. if you have two identical 1920x1080 monitors running next to each other, but one is in 60Hz mode and the other is in 240Hz mode, they're both refreshing the same amount of pixel rows (top to bottom, left to right), but 240Hz is completing each cycle faster, so the physical "height" of the display the scanout occurs across is the same between the two.

The only difference is time.

So if everything but refresh rate was equal in the last image (which isn't quite logistically possible in reality where aligning the individual cycles of the two refresh rates is concerned, as 240Hz is always "ahead" of 60Hz, but let's go theoretical here), and a "bottom-of-frame" sample appeared within tear slice #8 at 60Hz, an identically positioned sample (in direct, proportionate relation to the given scanout time of a single cycle at the given max refresh rate) would instead appear within tear slice #2 at 240Hz.

And thus, in this particular case, the 60Hz sample would appear at the ~15(ish)ms position, while that same sample at 240Hz would appear at the ~3(ish)ms position. AKA, you see that same sample at 240Hz sooner.

TLDR; When compared to lower refresh rates, individual updates, at higher refresh rates, regardless of framerate or sync/no sync have the potential to be seen sooner within the individual scanout cycle they appear in, as individual scanout cycles become progressively shorter in duration the higher the refresh rate becomes.

Anyway, that's all I've got. Hope it's clearer for you.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

User avatar
jorimt
Posts: 2479
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorimt » 25 May 2020, 19:28

hmukos wrote:
22 May 2020, 19:02
I would understand this if multiple frameslices to be scanned out in this cycle would be somehow preremembered and scanned only after as a whole. But doesn't scanout happen in realtime and show frame as soon as it is rendered?
To expound on my last post and answer this specifically, The tear slices in this ~2000 FPS scenario aren't "preremebered," but all ~33 of them aren't revealed all at once at 60Hz, but gradually from top to bottom in 16.6ms, thus the word "scan" in "scanout."

Again, the test method I used isolates user input by keeping a scene visually static until the point of input. This doesn't mean the display or the system are static in the meantime though; even without input or visible on-screen movement, the display, at 60Hz, is still refreshing 60 times per second in intervals of 16.6ms per cycle, and, at ~2000 FPS, new frame information is being delivered to the display at ~0.5ms per (aka the 33 frame slices, which are also always present, so long as the framerate is sustained at ~2000, with or without visible on-screen movement).

But the start of the input doesn't appear in all the tear slices, only one, and that's what I sampled: "first" on-screen reaction. All the activity that occurs before and after it is moot (until the next new input) with this method.
hmukos wrote:
22 May 2020, 19:02
Wouldn't seeing "Frame 7" being scanned out happen at the same time for both screens?
No, and correct me if I'm wrong here, but I think I now know what you're misunderstanding...

Am I right in assuming you think since four 240Hz scanout cycles can fit in the span of a single 60Hz cycle, that this is what the two refresh rates look like when directly compared?

Image

Because if so (as I hinted in my last post), that's not correct; just because four 240Hz scanout cycles can fit in the span of a single 60Hz scanout cycle doesn't mean they scale that way in practice.

So what does it actually look like then? Well, while the below isn't 100% accurate/to scale (none of this is really, just a conceptual visual aid), it's more like this, and should give you better idea on why 240Hz (or any higher-than-60hz refresh rate) has less delay and a lower min/max average than 60Hz, even at the same framerate with V-SYNC off:

Image

^ 240Hz has already had nearly four complete scanout cycles before 60Hz is even on its second.

And then we're back to why 60Hz has a higher possible min/max reading range (along with higher averaged readings) when the sample finally appears (using the "first reaction" method):

Image

Does that make it any clearer?

Again, the point is, both refresh rates in like-for-like situations are showing the same information in sequence, but one is behind. It's similar to how V-SYNC with framerate above the refresh rate causes increased delay; you're seeing the information in perfect sequence, but it's more behind your input than if you had V-SYNC off.

E.g. scanout time can also ultimately be considered a form of additive latency when directly comparing a lower refresh rate to a higher one.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by Chief Blur Buster » 28 May 2020, 11:45

hmukos wrote:
22 May 2020, 19:02
I would understand this if multiple frameslices to be scanned out in this cycle would be somehow preremembered and scanned only after as a whole. But doesn't scanout happen in realtime and show frame as soon as it is rendered?
There's a cable scanout and a panel scanout, and they both can be higher/lower than each other.

Jorim nailed most of it for the panel scanout level, though there should be two separate scanout diagrams to help understand context (scanout diagram for cable, scanout diagram for panel) whenever the scanout are different velocities.

However, there are some fundamental clarifications that is needed.

The frameslices are still compressed together because the frameslices are injected at the cable level, but the monitor motherboard is buffering the 60Hz refresh cycle to scanout in 1/240sec.

Fixed-Scanrate Panels

Fixed-scanrate panels create input lag at refresh rates lower than max-Hz, unless Quick Frame Transport is used to compensate.
I would bottom-align the 60Hz like this, however:

Image

Scaler/TCON scan conversion "compresses the scanout downwards" towards the time delivery of the final pixel row. So about 3/4ths of 60Hz scanout is delivered before the panel begins refreshing at full 1/240sec velocity.

Flexible Scanrate Panels

However, some panels are scanrate multisync, such as the ASUS XG248, which has excellent low 60Hz console lag:

Image

Learn more about Quick Frame Transport

For more information about compensating for buffering lag, you can use Quick Frame Transport (Large Vertical Totals) to lower latency of low refresh rates on 240Hz panels: Custom Quick Frame Transport Signals.

The Quick Frame Transport creates this situation:

Image

This can dramatically reduce strobe lag, but Microsoft and NVIDIA needs to fix their graphics drivers to use end-of-VBI frame Present(). Look at the large green block, so frame Present() needs to be at the END of the green block, to be closer to the NEXT refresh (less lag!).

Microsoft / NVIDIA Limitation Preventing QFT Lag Reductions

Unfortunately, Quick Frame Transport currently only reduces lag if you simultaneously use RTSS Scanline Sync (with negative number tearline indexes) to move Present() from beginning of VBI to the end of VBI. So hacks have often been needed.

This simulates a VSYNC ON with a inputdelayed Present() as late as possible into the vertical blanking interval.

The software API, called Present(), built into all graphics drivers and Windows, to present a frame from software to the GPU. Normally Present() blocks (doesn't return to the calling software) until the blanking interval. But Present() blocks until the very beginning of VBI (after the final scan line) before releasing. Many video games does the next keyboard/mouse read at that instant right after Present() returns. So it's in our favour to delay returning from Present() until the very end of the VBI: That delays input reads closer to the next refresh cycle! Thus, delayed Present() return = lower input lag because keyboard/mouse input is read closer to the next refresh cycle.

A third party utility, called RTSS, has a new mode called "Scanline Sync", that can be used for Do-It-Yourself Quick Frame Transport.

Image

Then that dramatically reduces VSYNC ON input lag (anything that's not VSYNC OFF) on both fixed-scanrate and flexible-scanrate panels, because the 60Hz scanout velocity is the same native velocity of 240Hz.

Great for reducing strobe lag, too!

(Not everyone at Microsoft, AMD, and NVIDIA fully understand this.)

We successfully reduced the input lag of ViewSonic XG270 PureXP+ by 12 milliseconds less input lag, while ALSO reducing strobe crosstalk, with this technique. ViewSonic XG270 120Hz PureXP+ Quick Frame Transport HOWTO.

Earlier, I tried large Front Porches, hoping that Microsoft inputdelayed to the first scanline of VBI before unblocking return from Present() API call. But unfortunately, Microsoft/NVIDIA unblocks Present() during VSYNC ON at the END of visible refresh (before first line of Front Porch). Arrrrrrgh. Turning Easy QFT, into Complex QFT. :(

But Wait! G-SYNC and FreeSync are Natural Quick Frame Transports

Want an easier Quick Frame Transport? Just use a 60fps cap at 240hz VRR. All VRR GPUs always transmit refresh cycles at maximum scanout velocity. Present() immediately starts delivering the first scanline at that instant (if monitor not currently busy refreshing or repeat-refreshing) since the monitor slaved to the VRR.

Image

Present() is already permanently connected to the end of VBI during VRR operation. Unless the monitor is still busy refreshing (frametime faster than max Hz) or the monitor is busy repeat-refreshing (frametime slower than min Hz). As long as frametimes stay within the panel's VRR range, software is 100% controlling the timing of the monitor's refresh cycles!

This is why emulator users love high-Hz G-SYNC displays for lower emulator lag.

60fps at 240Hz is much lower latency than a 60hz monitor, because of the ultrafast 1/240sec scanout already automatically included with all 60fps material on all VRR monitors! The magic of delivering AND refreshing a "60Hz" refresh cycle in only 4.2 milliseconds (both cable and panel), means ultra-low latency for capped VRR

This is why VRR is is the world's lowest latency "Non-VSYNC-OFF" sync technology.

It doesn't help when you need to use fixed-Hz (consoles, strobing, non-VRR panels).

This Posts Helps you to:
- Understand Flexible-Scanrate LCD panels (most 1080p 144Hz panels, few 1080p 240Hz panels)
- Understand Fixed-Scanrate LCD panels (most 1080p 240Hz panels, most 144Hz 1440p panels)
- Understand Quick Frame Transport
- Understand Quick Frame Transport's ability to workaround low-Hz lag on Fixed-Scanrate Panels
- Understand VRR
- Understand How VRR is similar to Quick Frame Transport
- If you are a software developer, Understand that software controls triggering variable refresh monitor's refresh cycle via Present()
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by Chief Blur Buster » 28 May 2020, 12:28

<For Software Developers>

Revevant to VSYNC OFF tearline control, I have good understanding the scanout mathematics fully (QFT, non-QFT, high-Hz, low-Hz, VRR, non-VRR). This allows me to have complete cable scanout-knowledge for all monitor technologies and sync technologies.

About programmatic control of VSYNC OFF tearlines (raster interrupt like precision control of tearing) -- Some of you might have seen my Tearline Jedi demo at Pouet.NET page.

phpBB [video]


Microsecond-precision Present() allows exact placement of VSYNC OFF tearlines.

I'm looking for additional volunteer software developers to help me complete this for a submission to the next Assembly competition, since this stuff should become a bit more publicized as
(A) A training tool for scanout latencies
(B) Input lag reductions
(C) Emulators that want to synchronize emulator raster to real raster (beamraced sync)

Aside: I wish more manufacturers would 60Hz single-strobe for strobe backlights (very flickery), because some of the new 240Hz 1ms IPS panels make excellent MAME arcade cabinet panels -- so vastly superior with things like 120Hz hardware strobe + 60hz software BFI (built into RetroArch or GroovyMAME). Blur Busters opinion is that all refresh rates should be strobeable (it's only a 1 line monitor firmware change), most manufactures prevent strobing at low Hz thinking they're too flickery (yes, for Windows) but they're perfect for darker arcade games.

Email me mark [at] blurbusters.com if you have C# experience along with some understanding of rasters, and would like to help incubate this. This would be an open source project.

</For Software Developers>
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
jorimt
Posts: 2479
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorimt » 28 May 2020, 13:10

Chief Blur Buster wrote:
28 May 2020, 11:45
there should be two separate scanout diagrams to help understand context (scanout diagram for cable, scanout diagram for panel) whenever the scanout are different velocities.
Correct, admittedly conceptual/incomplete, and only addresses panel aspect. There are indeed exceptions as you've laid out.
Chief Blur Buster wrote:
28 May 2020, 11:45
The frameslices are still compressed together because the frameslices are injected at the cable level, but the monitor motherboard is buffering the 60Hz refresh cycle to scanout in 1/240sec.

[...]

Fixed-scanrate panels create input lag at refresh rates lower than max-Hz, unless Quick Frame Transport is used to compensate.
Somewhat on this note, it should be mentioned here that the physical 60Hz mode on the 240Hz monitor I was testing may have possibly caused a larger input lag difference vs 240Hz than it would in other situations for the above reasons. Though I wonder if there is an exception if you're running at a physical 60Hz in VRR mode on a 240Hz monitor (maybe, maybe not)?

That said, it didn't matter for the subject of the article, because the primary intent was to only test syncing methods/FPS limiters against each other at the same refresh rate, and not to directly test differences between refresh rates (which was just an unintended bonus of testing multiple refresh rates side-by-side).

That said, to be clear to @hmukos and others reading this, 60Hz still typically has slower overall delivery (and thus higher possible min/avg/max readings using the test method in the article), with or without sync, when directly compared to 240Hz at the same FPS (more or less depending on the cable method) due to the raw difference in scanout time between the two.
Chief Blur Buster wrote:
28 May 2020, 11:45
I would bottom-align the 60Hz like this, however:
Yup; the only reason I depicted it that way was because he and I were talking about input made during the previous cycle showing in the next, so I showed it over two (partial) cycles (starting with 60Hz and 240Hz theoretically aligned) instead of one.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

hmukos
Posts: 30
Joined: 16 Apr 2020, 15:41

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by hmukos » 31 May 2020, 15:25

First, thank you for your answers, jorimt, Chief! I apologize if the reply was late, that was unintentional. So I think I got it. jorimt's final explanations almost made me understand however only after Chief's answer I understood what was exactly going on and only after that I finally got what jorimt was trying to tell me (rereading answers now and it's clearer where my misunderstanding was).
jorimt wrote:
25 May 2020, 19:28
Am I right in assuming you think since four 240Hz scanout cycles can fit in the span of a single 60Hz cycle, that this is what the two refresh rates look like when directly compared?
pic
Yep! That's exactly how I imagined it.
jorimt wrote:
25 May 2020, 19:28
pic
^ 240Hz has already had nearly four complete scanout cycles before 60Hz is even on its second.
I understand now what this picture was about but first time I saw it I couldn't wrap my head on the scales. The problem was that I didn't understand that "16.6ms" was about cable scanout and that panel in this case was scanning out at 1/240s speed.
Chief Blur Buster wrote:
28 May 2020, 11:45
I would bottom-align the 60Hz like this, however:
pic

Scaler/TCON scan conversion "compresses the scanout downwards" towards the time delivery of the final pixel row. So about 3/4ths of 60Hz scanout is delivered before the panel begins refreshing at full 1/240sec velocity.
So this is what made my mind finally click. Thank you. By the way interesting read as always.
That said, to be clear to @hmukos and others reading this, 60Hz still typically has slower overall delivery (and thus higher possible min/avg/max readings using the test method in the article), with or without sync, when directly compared to 240Hz at the same FPS (more or less depending on the cable method) due to the raw difference in scanout time between the two.
Yes, I understand now. So I assume it is correct that the 12-13ms Min and Max input lag variation comes from mismatch between cable scanout and panel scanout? Would Min and Max be much closer if the test was made on pure 60hz monitor with 1/60s cable and panel scanout?

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by Chief Blur Buster » 31 May 2020, 16:09

hmukos wrote:
31 May 2020, 15:25
jorimt wrote:
25 May 2020, 19:28
pic
^ 240Hz has already had nearly four complete scanout cycles before 60Hz is even on its second.
I understand now what this picture was about but first time I saw it I couldn't wrap my head on the scales. The problem was that I didn't understand that "16.6ms" was about cable scanout and that panel in this case was scanning out at 1/240s speed.
Yes, normally scanout is identical on cable and panel. It's the divergence that muddies the confusion.

Glad I helped clear this up!
Chief Blur Buster wrote:
28 May 2020, 11:45
So this is what made my mind finally click. Thank you. By the way interesting read as always.
You're welcome. Probably going to convert this into an article as soon as I have spare time.
Chief Blur Buster wrote:
28 May 2020, 11:45
Yes, I understand now. So I assume it is correct that the 12-13ms Min and Max input lag variation comes from mismatch between cable scanout and panel scanout? Would Min and Max be much closer if the test was made on pure 60hz monitor with 1/60s cable and panel scanout?
For VRR 60Hz on 240Hz, the interactions get a bit complex since we're now doing three interactions (sync technology versus cable scanout versus panel scanout).

But yes, for 60Hz native, Min/Max will narrow for VSYNC OFF latency, since no buffering is occuring, the frame will tear-into the scanout at a constant time offset from the signal (tiny, sometimes sub-1ms), for realtime cable-to-panel scanouts. With tiny rolling-window buffer processing.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply