EXCLUSIVE: We have a 480 Hz monitor!

Everything about displays and monitors. 120Hz, 144Hz, 240Hz, 4K, 1440p, input lag, display shopping, monitor purchase decisions, compare, versus, debate, and more. Questions? Just ask!
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by Chief Blur Buster » 18 Aug 2017, 08:41

RealNC wrote:I don't think it was real OD though (no way to boost voltages.) From what I could tell, it calculated a delta between the current and the previous frame and displayed a modified version of it with the colors modified in such a way that it would cancel out trailing/ghosting.
Actually, Radeon Overdrive is almost identical in principle to overdrive. It is possible TCON-level overdrive can do overvoltages to boost below black or above white, but it's not really being done in principle. It was often simply done via reduced dynamic range to allow overshoot room. Once that's removed, there's no difference between a BenQ/Zowie overdrive and a Radeon Overdrive, except for a little more input lag by doing it via the GPU.
RealNC wrote:Sounded better in theory than it worked in practice.
I had it, and it actually worked on one of my monitors. It really looked good on that one. It added better-quality overdrive than some monitor overdrives I have seen. It was, however, useless on LCD displays that already had overdrive and made that worse.

So it was only useful and impressive for a brief time in its history. It wasn't a "didn't work in practice", it was just a happenstance of being introduced in a small window of time when LCDs finally began to introduce overdrive, but wasn't yet widespread.

Mathematically, it's identical. If you need to go from RGB (0,0,0) -> RGB(128,128,128), the next refresh cycle might be temporarily RGB(140,140,140) for one refresh cycle to speed up the transition to RGB(128,128,128). If you time it right, the color never finally reaches RGB(140,140,140) but it reached RGB(128,128,128) faster. That automatically creates extra voltage anyway, so you're doing the same thing.

Today, the best generic common way to do this in a high performance way is to precompute an overdrive lookup table (256x256 or 1024x1024, greyscale) from either a formula or an automated photodiode measurement run, and run the LUT on every subpixel (independent R/G/B separately).

Do that for every pixel, and viola.

Now to improve whites and blacks, you can simply reduce dynamic range a little bit (e.g. squeeze 8-bit into the equivalent of RGB(16,16,16) through RGB(235,235,235) to create the needed headroom. However, many LCDs do achieve transitions very fast to fullwhites and fullblacks without needing overdrive, so the need for expanded dynamic range becomes a little attenuated. Overvoltaging slightly is supported by some LCDs, but it usually applies only to one end of the range (not both ends).

The 480Hz mode I have, seems to do white-to-black very fast (easily 1ms) but very slow in black-to-white. So i'd only reduce dynamic range at the top end, e.g. 0-224 and use the headroom as overdrive overshoot room.

I may create a TestUFO Software Overdrive test to try and milk the 480Hz clarity to its max. Long term, this may let open source modders generate their own overdrive formulas or lookup tables to upload into open-source firmware LCDs (that has enough previous-refresh-cycle memory for lookbehind overdrive)! Web motion tests are getting good enough to help generate overdrive lookup tables. The Zis LCD does not have enough memory for overdrive, but this isn't the final frontier in tweaking of the future.

I prefer overdrive be done at the monitor level as it can be done on a line-buffer-based way with only lookbehind data -- for lagless overdrive. And works in all apps. To do it on the GPU, you need to buffer the current refresh cycle instead of just realtime scanning-out to the GPU right away. That adds at least a frame of lag.
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
sharknice
Posts: 295
Joined: 23 Dec 2013, 17:16
Location: Minnesota
Contact:

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by sharknice » 18 Aug 2017, 13:12

Couldn't you hook in some way to do it in real time on the GPU too?

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

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by Chief Blur Buster » 18 Aug 2017, 13:24

About Software-Based LCD Overdrive via a GPU:
sharknice wrote:Couldn't you hook in some way to do it in real time on the GPU too?
In theory, yes, LCD overdrive could be done via a GPU again today, even NVIDIA.

But with current shader programming workflow, it would only work with perfect frame rate sync (VSYNC ON 480fps @ 480Hz). A single stutter (frame duplicate/drop) ruins the overdrive sequencing. It is precision calculated based on what the previous refresh cycle displayed at what time. (VRR pverdrive is complex due to that).

Needless to say, this would not work properly with VSYNC OFF if done at the full frame level. Overdrive has to be done on the refresh cycle delivery level (post-tearing!), unless you had perfect VSYNC ON. Even better is 2-frame-history overdrive, which improves overdrive based on what the last two refresh cycles showed (and at which time each cycle occured, in the case of VRR) versus current.

3-refresh-cycle overdrive calculations + variable refresh rates = It can turn from a simple lookup table (256x256 = 64 kilobytes) into a horrendous memory monster or FPGA math monster if running formulas on each pixel that gets displayed per refresh cycle. But regardless, must be processed at the refresh level.

Are real time raster stream programming hooks possible on NVIDIA or AMD today?
In theory, it may be possible to attach a raster processing routine to the GPU output, executing realtime ops on the refresh cycle pixel stream (post-tearing) right before it hits the graphics output jack. But GPUs do not usually give programmers access to that. If anyone knows of any APIs that can attach at the refresh cycle level instead of the frame level, let me know. Is this programming workflow available on current NVIDIA cards? In most modern cards, there is usually a tiny line-buffer (pixel row buffer) at the video port transmission level (HDMI, DisplayPort, VGA RAMDAC, etc), one has to do the processing (in GPU shader language) at this post-tearing level to have precision VSYNC-OFF-compatible software overdrive. One would also need to record a pre-torn buffer too (a history of what's being output of the video output, tearing artifacts included). I don't think this programming workflow is accessible, so one would be be forced to use perfect full-framerate VSYNC ON for reliable framebuffer-based GPU-based overdrive.
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!

thatoneguy
Posts: 181
Joined: 06 Aug 2015, 17:16

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by thatoneguy » 19 Aug 2017, 01:22

Chief Blur Buster wrote: Many people don't realize that the only way to get "Blur Reduction without strobing/pulsing/flicker/CRT" is stupendous amounts of Hertz in a sample-and-hold display
Well that and on a good CRT or Strobed Monitor at a very high refresh rate like 120+ hz where most people can't detect flicker. Although you have to sacrifice brightness so that's one benefit for the sample-and-hold method at 480hz.

hammelgammler
Posts: 17
Joined: 16 Mar 2015, 11:32

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by hammelgammler » 19 Aug 2017, 04:40

I would like to know how the 300Hz and 480Hz perform regarding tearing. Do you even need Freesync/G-Sync at this high refreshrates, or is it only less tearing with high fps?

Like 144 FPS/144Hz vs 300 FPS/144Hz vs 144FPS/480Hz vs 300FPS/480Hz?

User avatar
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by lexlazootin » 19 Aug 2017, 07:30

You don't get less tearing at higher refreshrate/frame rates, you get less noticeable tearing.

At 480hz, every screen is displayed for 2.08333... ms total, that means that a new frame will come along and wipe it out before you realize.

At 480fps every frame is 2.08333... ms apart, so that if you are turning the screen with your mouse, the total distance the frame tear can be is quite small and much less noticeable compared to 60fps were the frames are 16.666... ms apart.

hammelgammler
Posts: 17
Joined: 16 Mar 2015, 11:32

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by hammelgammler » 19 Aug 2017, 12:03

Thanks for the response. With less tearing I meant less noticable tearing, but yeah technically you are right. :)

I was thinking if the refreshrate alone makes it less noticable. Like 240 FPS with 120 Hz and 240 FPS with 240Hz. Or is it only higher FPS that help?

That would be a reason to play with 540p for me, but if it doesn't help then I can rather play at 720p if I only get 300 FPS.

Haste
Posts: 326
Joined: 22 Dec 2013, 09:03

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by Haste » 19 Aug 2017, 12:45

Both refresh rate and frame rate have a significant impact on tearing visibility.

In the case of the refresh rate it reduces the amount of time you see tear line(s) in a specific position(s) before it/they either disappear(s) or change position(s) on the next refresh.

At 240Hz, tearline(s) stay(s) static for 4.2 milliseconds.

At 480Hz, tearline(s) stay(s) static for 2.1 milliseconds.
Monitor: Gigabyte M27Q X

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

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by Chief Blur Buster » 19 Aug 2017, 14:11

It's, well, sorta semantics at this stage. :D

Many of our readers meant "less tearing" equals "less visible tearing".

But yes, you're right, you get MORE tearlines, but each tearline is LESS visible.
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!

WolfWings
Posts: 2
Joined: 19 Aug 2017, 22:35

Re: EXCLUSIVE: We have a 480 Hz monitor!

Post by WolfWings » 19 Aug 2017, 22:49

...so it might be worth mentioning in the BlurBusters review that the 39" upgrade is specifically for the panel that was used in the Seiki 39" 4K's. :) Found it on the ZisWorks page that it is, but everywhere here there's no explanation of which '39" VA panel' it's intended for, and 39" panels in general are almost unheard of these days in the US.

Post Reply