After I saw Chief talking about the Quick Frame Transport (QFT) from Vesa 2.1 and how it is available today I tried to do a few tests and was able to achieve 576p using the scanout speed of 480hz (by setting 480hz at CRu and then fixing the pixel clock and raising the vertical total until I reach 1201).
Here are the results (Alienware AW2518hf):
The default 576p @ 240hz:
https://www.youtube.com/watch?v=fAiAaNqw7ig
The 576p @ 240hz with VT 1201 (scanout speed of 480hz freq):
https://www.youtube.com/watch?v=EFBP6LFrDJs
Macbook Pro 2017 @ 60hz for reference:
https://www.youtube.com/watch?v=mYToT70hNHg
The video starts and ends at normal speed and then slows down to 960fps in the middle.
What is strange is that at the default the image seems perfectly static at naked eyes while the image at VT 1201 is flickering ultra-fast. In fact I thought the javascript was bugged before I tried to record and thats is perceptible at the start of each video befere the slowmotion kicks in.
Could someone explains this effect and verify if it the scanout is really twice as fast?
240hz using the scanout speed of 480hz?
-
Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: 240hz using the scanout speed of 480hz?
That's pretty neat, 2ms quick frame transport of a refresh cycle!
(See Quick Frame Transport FAQ for speeding up HDMI/DisplayPort cable delivery of individual refresh cycles, via Large Vertical Totals)
From the high speed videos, it does seem that the panel scanout is lagging behind (taking more than 2ms). However, if the monitor is beginning scanout earlier because refresh cycles got delivered quicker - then, yes, it will reduce input lag even if the panel scan sweep isn't faster. Unfortunately, testing this will require something like a modified mouse LED (e.g. like the high speed video of GSYNC monitor, etc).
To better take advantage of this, don't forget to use RTSS Scanline Sync to synchronize to end-of-VBI rather than beginning-of-VBI. Basically very small negative indexes -- where the tearline position is calibrated closer to right above the top edge of the screen, than closer to right below the bottom edge of the screen. This will reduce your VSYNC ON input lag, helped via the lag reduction of your homebrew Quick Frame Transport (QFT).
<TECH SIDENOTE FOR SOFTWARE DEVELOPERSS>
With ultralarge blanking intervals (faster transmits of frames + longer pauses between frames) -- Microsoft's default Present() unblocks at the end of a refresh at beginning of VBI. Which is not the correct way to reduce VSYNC ON lag for many games that begins the next input read immediately after the Present() unblock. You want the GPU drivers to unblock a Present() near the end of the VBI instead.
</TECH SIDENOTE FOR SOFTWARE DEVELOPERS>
(See Quick Frame Transport FAQ for speeding up HDMI/DisplayPort cable delivery of individual refresh cycles, via Large Vertical Totals)
From the high speed videos, it does seem that the panel scanout is lagging behind (taking more than 2ms). However, if the monitor is beginning scanout earlier because refresh cycles got delivered quicker - then, yes, it will reduce input lag even if the panel scan sweep isn't faster. Unfortunately, testing this will require something like a modified mouse LED (e.g. like the high speed video of GSYNC monitor, etc).
To better take advantage of this, don't forget to use RTSS Scanline Sync to synchronize to end-of-VBI rather than beginning-of-VBI. Basically very small negative indexes -- where the tearline position is calibrated closer to right above the top edge of the screen, than closer to right below the bottom edge of the screen. This will reduce your VSYNC ON input lag, helped via the lag reduction of your homebrew Quick Frame Transport (QFT).
<TECH SIDENOTE FOR SOFTWARE DEVELOPERSS>
With ultralarge blanking intervals (faster transmits of frames + longer pauses between frames) -- Microsoft's default Present() unblocks at the end of a refresh at beginning of VBI. Which is not the correct way to reduce VSYNC ON lag for many games that begins the next input read immediately after the Present() unblock. You want the GPU drivers to unblock a Present() near the end of the VBI instead.
</TECH SIDENOTE FOR SOFTWARE DEVELOPERS>
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
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!
Re: 240hz using the scanout speed of 480hz?
I was actually able to reach the scanout of 560hz using 640x480. Do you think it is best to use the s-sync over the VRR when you have large v-blank? Same answer for vrr with vsync on/off?
Here is the test:
https://www.youtube.com/watch?v=tZpAitvfAHE
I do not have the LED so I used the humanbenchmark to compare with myself (I know that it's very imprecise and depends on a lot of physiologic variables but given enough trials it should stochastically point the input lag). Notice how easy it is to average 160-170 ms.
Here is the test:
https://www.youtube.com/watch?v=tZpAitvfAHE
I do not have the LED so I used the humanbenchmark to compare with myself (I know that it's very imprecise and depends on a lot of physiologic variables but given enough trials it should stochastically point the input lag). Notice how easy it is to average 160-170 ms.