Vizio M651d-A2R 120hz [HDTV overclocking success]

[trey31]

you only need about 3-4 consecutive squares highlighted in order to confirm a successful 120Hz overclock of a normally 60Hz HDTV.

Totally makes sense for 60hz/120hz. However, now I've got a weird one for you. 88hz. This is 2880x1620p@88hz. Everything looks great as far as the eye test goes. But then I get these weird extra bright frames with the 88hz refresh rate. I didn't notice any issues in real time, only after trying to confirm the refresh rate via photograph. Instead of dropping frames, it appears the panel might be duplicating them? Like instead of 1 square per cycle (1/88 of a second), some squares are being lit up and are staying lit up while the next one becomes lit up (1/44 of a second on some squares?). Or so it would appear from the photographs anyway. Can you help me figure out what I'm seeing here? Every other confirmation photo I've taken shows up uniform with the same amount of brightness in each one of the squares, or like the 240hz one it shows an obvious black square in-between each lit square. As in each of those black frames are missing because the monitor didn't display them.

Chrome has no 120Hz limitation. I only mention that at the bottom of TestUFO as "120Hz+". cirthix tells me he successfully tested Chrome at 240Hz with no frame skipping on his custom-modified 240Hz LCD, with a green VALID. At 240fps, it does push the limits of Chrome performance, though!

Internet Explorer is reliable up to 105Hz, Opera is as reliable as Chrome (240Hz), while FireFox is still too stuttery to do reliable frameskipping testing. Chrome is the best browser I can reliably detect perfect VSYNC with monitor (and detect browser-skipped frames as opposed to display-skipped frames). That way, if you photographed with a green VALID (confirming validity of photo), and Chrome is currently GPU accelerated in Aero mode on the primary monitor, it's virtually guaranteed to be the monitor that's frame skipping if you see black gaps. That's why i currently recommend Chrome, closely followed by Opera (which now uses the Chrome engine), when doing TestUFO motion tests.

Ok that makes sense. I should have re-read as I somehow missed the "+" when I read it before. Chrome also gave me the green Valid rating at 240hz, but even in real-time I could tell it was dropping every other frame which is why I went ahead and snapped the photo and moved on.

If you are using Windows 8.1, that is because of mouse fluidity issues. You should be aware of the Gaming Mouse fix for Windows 8.1 before judging the window drag test. Give it a try!

Still on W8 Pro (8.0). After testing and validating a bunch more resolutions and refresh rates, I'm convinced it was just a placebo effect on my behalf.

Another question. Hypothetically speaking, if turning V-Sync off caused screen tearing above 120hz (say, at 190fps with a 120hz refresh), would setting the resolution to 240hz resolve the screen tearing? I know that 240hz on this TV is dropping every other frame, but even so it still looks as smooth and accurate as 120hz does when moving items around on the desktop.

Aero is always VSYNC ON; it is not currently possible to turn off VSYNC using Aero, so this is a moot question.
That said, if running full screen apps, you will still see tearing even if you get frameskipping. Tearing is refresh-specific, unrelated to frameskipping. Yes, it means half of tearlines become invisible, but the other half of tearlines will still be in the visible non-skipped refreshes. ("Frameskipping" is actually really "refreshskipping" as it's not frameskipping on the GPU framebuffers / videogame framebuffers, but frameskipping on the displays' own internal framebuffer used for refreshes).

Oh -- from the perspective of the display, it is not game-framebuffer-skipping, it's refresh-framebuffer-skipping. Display do not ever know how many frames per second your game is running at! It's just "dumbly" refreshing synchronously at some exact rate (e.g. 120 cycles per second -- 120Hz), and the GPU is sometimes splicing the new frame into the existing refresh as the display scans out -- creating the tearline artifact.

(GSYNC is smarter than this, but that's a separate topic altogether...)

Yes, you do get less input lag at 240Hz (even if frameskipped to 120Hz) than you do at 120Hz (non-frame-skipped).
However, tearing will still be there. Tearing is intrisinically embedded into the refreshes, and thus tearing gets recorded into the monitor's internal frame buffers. It's like multiple videogame frames spliced-above-each-other, into one refresh, and that refresh is buffered into the monitor, and that some buffered refreshes might be frameskipped (ignored).

Yes, that's correct. You can get less input lag with frameskipped 240Hz->120Hz. Each frame is transmitted in 1/240sec, so your input lag is reduced by 1/240sec (4ms) which is actually noticeable to some people -- 4 milliseconds means getting 4 pixels ahead in motion during moderate 1000 pixels/second motion -- or 16 pixels ahead during fast 4000 pixels/second turning motion. These ultra-subtle differences can surprisingly be noticeable to some very sensitive people in some fighter games, FPS games, even emulation).

Although lots of people say sub-20ms differences are not felt (and this is very true for most of population), this isn't true for 100% of population. Remember the 100 meter olympics races; sometimes people cross the finish line only 1ms or 2ms faster than the 2nd place! Mere inches, mere centimers. And likewise, for displays, mere pixels. So, milliseconds actually matter for some elite players...

The faster frame-transmission time is also seen on other displays capable of 240Hz input (frameskipped to 120Hz), such as the SEIKI 4K 50" HDTV, which can display 120 out of 240 when 720p@240Hz is input. Someone on HardForum confirmed they were able to feel the difference during fast-twitch FPS games. As Chief Blur Buster, I certainly believe them!

Great info! I really appreciate your help. I'm not a pro gamer by any means, but I definitely notice when some panels/monitors have excessive amounts of lag. Not sure I could notice 4ms between 120hz and 240hz though.

[Chief Blur Buster]

Totally makes sense for 60hz/120hz. However, now I've got a weird one for you. 88hz. This is 2880x1620p@88hz. Everything looks great as far as the eye test goes. But then I get these weird extra bright frames with the 88hz refresh rate. I didn't notice any issues in real time, only after trying to confirm the refresh rate via photograph. Instead of dropping frames, it appears the panel might be duplicating them?

What you are seeing is a case of frame duplication, yes.
If you have a contiguous series of squares but some of them are at different intensities, that's refresh duplication.
This is quite a strange behaviour, because duplication is something that usually occurs at lower refresh rates -- I'm not sure if this is being caused by the GPU or by the display. It's possible the display is refreshing at 120Hz.

Do you have a camera with a high speed video mode of at least 240fps+?
Examples include GoPro Hero3 (240fps), Casio EX-FC200S (1000fps), Casio EX-ZR200 (1000fps), EX-F1 (1000fps),Fuji HS10 (1000fps), Nikon1 J1 (1200fps), Nikon1 J2 (1200fps), Nikon1 V2 (1200fps).

If you have one of the above cameras, can you point it at http://www.testufo.com/flicker (running Height -> Full Screen) (Epilepsy warning!), record video containing the full screen height, and upload the video to youtube? I'd love to see high speed video of this frame duplication behavior. It might actually be doing 1/120sec scanouts of each refresh, which would be rather interesting. And while you're at it, also do a high speed video of the flicker test 720p@240Hz. I think it's doing 1/120sec refresh scanouts, not 1/240sec refresh scanouts, though.

[Chief Blur Buster]

On the subject of "milliseconds matter"... There are two factors at play:

Not sure I could notice 4ms between 120hz and 240hz though.

A good example is a fast-flick 180 degrees immediately followed by quickly center crosshairs on a target as accurately and as quickly as possible, and shooting. If two competitive players do this at the same time, in a "draw!" type situation, and shoot at the same time, the one that successfully centers the crosshairs quicker (due to less lag interfering), will get that frag. This example use case exercises precise mouse deceleration on cue -- a 4ms latency difference in eye-hand coordination translates to a 16 pixel overshoot at a 4000 pixel/second mouse panning (a typical speed for a moderate-speed 180 degree flick) versus a 0 pixel overshoot at a 4000 pixel/second mouse panning. Ultra-seasoned players will actually feel the mouse becoming more accurate/less accurate when you inject latency in single-digit milliseconds. It's quite surprising.

In addition, there's also an unfelt, but still competitively beneficial "cross-the-finish-line-first" effect: Two players shoot at the same time, the one that has lower latency will get the frag. The players may not feel this, but during the elite competitive leagues where reaction times are already uber-fast and uber-close, and well balanced, this can pull someone ahead by a smidgen (Say, winning with 9 vs 7 frags instead of tieing 8 versus 8 frags). The game engine can't compensate/handicap for display latency, as that's a factor beyond a game engine's ability to detect (unlike network latency, etc).

The top league competitions unify to the same displays and systems, to prevent system-level differences from giving people an advantage, so this doesn't show up in those events. However, at ad-hoc LAN parties, where people bring their own systems and displays, these milliseconds can add up.

[trey31]

Vizio M651d-A2R list of confirmed resolutions/refresh rates:

3360x1890@23hz

3200x1800@65hz* (minor issue with Vizio source/menu flicker for 3-4 seconds, actual desktop does not flicker at all)
3200x1800@60hz

2880x1620@88hz*** (opposite of frame skipping, this resolution appears to be frame duplicating; caused odd results in photographs of frame skipping test, some frames are brighter than others.)

2560x1440@100hz

2400x1350@106hz
2400x1350@100hz

1920x1080@108hz
1920x1080@100hz
1920x1080@96hz (set to 95.904hz, a custom refresh rate exactly 4 times the NTSC format's refresh rate of 23.976)

1760x990@120hz

1600x900@120hz

1280x720@120hz

Photo Confirmations:
720p@120hz:

1600x900@120hz:

1760x990@120hz:

1080p@108hz:

2400x1350@106hz:

2560x1440@100hz:

***2880x1620@88hz:

3200x1800@65hz:

3360x1890@23hz:

[trey31]

What you are seeing is a case of frame duplication, yes.
If you have a contiguous series of squares but some of them are at different intensities, that's refresh duplication.
This is quite a strange behaviour, because duplication is something that usually occurs at lower refresh rates -- I'm not sure if this is being caused by the GPU or by the display. It's possible the display is refreshing at 120Hz.

Do you have a camera with a high speed video mode of at least 240fps+?
Examples include GoPro Hero3 (240fps), Casio EX-FC200S (1000fps), Casio EX-ZR200 (1000fps), EX-F1 (1000fps),Fuji HS10 (1000fps), Nikon1 J1 (1200fps), Nikon1 J2 (1200fps), Nikon1 V2 (1200fps).

If you have one of the above cameras, can you point it at http://www.testufo.com/flicker (running Height -> Full Screen) (Epilepsy warning!), record video containing the full screen height, and upload the video to youtube? I'd love to see high speed video of this frame duplication behavior. It might actually be doing 1/120sec scanouts of each refresh, which would be rather interesting. And while you're at it, also do a high speed video of the flicker test 720p@240Hz. I think it's doing 1/120sec refresh scanouts, not 1/240sec refresh scanouts, though.

My wife is an avid photographer, so I will ask her tomorrow if she has a high speed camera or has access to one. I may want a Hero 3 for myself though, so if we don't, I might pick one up.

[trey31]

On the subject of "milliseconds matter"... There are two factors at play:

Not sure I could notice 4ms between 120hz and 240hz though.

A good example is a fast-flick 180 degrees immediately followed by quickly center crosshairs on a target as accurately and as quickly as possible, and shooting. If two competitive players do this at the same time, in a "draw!" type situation, and shoot at the same time, the one that successfully centers the crosshairs quicker (due to less lag interfering), will get that frag. This example use case exercises precise mouse deceleration on cue -- a 4ms latency difference in eye-hand coordination translates to a 16 pixel overshoot at a 4000 pixel/second mouse panning (a typical speed for a moderate-speed 180 degree flick) versus a 0 pixel overshoot at a 4000 pixel/second mouse panning. Ultra-seasoned players will actually feel the mouse becoming more accurate/less accurate when you inject latency in single-digit milliseconds. It's quite surprising.

In addition, there's also an unfelt, but still competitively beneficial "cross-the-finish-line-first" effect: Two players shoot at the same time, the one that has lower latency will get the frag. The players may not feel this, but during the elite competitive leagues where reaction times are already uber-fast and uber-close, and well balanced, this can pull someone ahead by a smidgen (Say, winning with 9 vs 7 frags instead of tieing 8 versus 8 frags). The game engine can't compensate/handicap for display latency, as that's a factor beyond a game engine's ability to detect (unlike network latency, etc).

The top league competitions unify to the same displays and systems, to prevent system-level differences from giving people an advantage, so this doesn't show up in those events. However, at ad-hoc LAN parties, where people bring their own systems and displays, these milliseconds can add up.

Woooah...

Wow. I don't mean to sound sarcastic in any way whatsoever, but this is a perfect example of why I love the internet. You sir, just blew my mind. I knew lag could be an issue for pro gamers, but I honestly had no idea that anyone had done the math on an example like you described. I have noticed varied amounts of lag on different displays over the years, but I never really researched it much. Thank you for enlightening me! I'm going to read more into this in the morning. I am off to bed, but have since added "search input lag" and "compare gaming mice" to my to-do list for tomorrow!

[trey31]

What you are seeing is a case of frame duplication, yes.
If you have a contiguous series of squares but some of them are at different intensities, that's refresh duplication.
This is quite a strange behaviour, because duplication is something that usually occurs at lower refresh rates -- I'm not sure if this is being caused by the GPU or by the display. It's possible the display is refreshing at 120Hz.

Ok so I forgot to update, I tested 2880x1620 again with 100hz, and 120hz refresh rates and both say they're successful within the NVIDIA Control Panel, however they will not show up after I click yes to save them. But during the 20 seconds they're being used while clicking the "test" button in NVIDIA Control Panel, the frame skipping test recognizes the 100hz & 120hz resolutions as only being 88hz, which it then validates as being at 88hz/88fps. I assume its still doing the frame duplication after validating, but it reverts back to 1080p after the 15 or 20 seconds timer is up so I didn't get any photos of those test resolutions.

Very strange.

[trey31]

I just edited the post with the confirmed resolutions/refresh rates.

Added 1600x900@120hz to the list with photo.

Added 1760x990@120hz to the list with photo.

[trey31]

Also I have some findings that might be helpful to someone else doing custom resolutions with NVIDIA Control Panel. When creating a new resolution and testing with default timings, it will use your TV's/Monitor's current resolution timings as the default auto timing, and just adjust the displayed pixels, not the active pixels.

So for example I was able to create a custom resolution of 1904x1071@120hz and photo confirm it was working with the frame skipping test. The problem was that I had 720p@120hz set as the current resolution when I created the 1904x1071@120hz resolution, and used auto timings. The result was a blurry image because the active pixels being used in the timings was well below the panel's native resolution. So as a result 1904x1071 was actually significantly more blurry (displaying text on a webpage) than 3200x1800 is (slightly blurry in small areas only).

When I adjusted the current resolution to 1920x1080@108hz, then tried to re-create the 1904x1071@120hz resolution with auto timings, it would not display properly. The reason was the auto timings were the same as 1920x1080@108hz, which was not successful in displaying 120hz despite numerous tinkering with the timings at 1080p. I also attempted to get 120hz at 1600x900, 1760x990, 1824x1026, 1840x1035 using auto timings with the current resolution at 1920x1080@108hz. None were successful. However, I was able to set manual timings for 1600x900@120hz that uses active pixels greater than the displayed pixels. The result is zero blurring at 900p@120hz. Very sweet.

Next I tried 1760x990@120hz using manual timings, but that wouldn't display properly. So I then set the current resolution to 1600x900@120hz, and then created a custom resolution for 1760x990@120hz with auto timings, which was successful. There is no blur at 1760x990, because the 1600x900 manual timing has active pixels set to 1760 horizontal pixels. So the new custom resolution of 1760x990@120hz with auto timings (when using the current resolution of 1600x900@120hz which used successful manual timings) experiences zero blurring because it is within the range of active pixels (1760 horizontal).

I suppose that I could then use that resolution to create a 1920x1080@120hz with auto timings (which would use the same timings as 1600x900@120hz) that would most likely pass the frame skipping test as well, however it would most likely experience blurring like the earlier resolutions did with the auto timings of 720p@120hz. I will probably try anyway and report back. However, I expect blurring even if it is successful.

[trey31]

1920x1080@120hz with 1600x900@120hz auto timings:


So to confirm the last post, indeed the 1080p@120hz resolution passed, however it has very minor blurring as expected. I will continue using 108hz due to it having zero blur. If a 5% blur (rough estimate) of textures doesn't bother you, you could achieve 120hz at 1080 with this panel. I however would not consider this a successful test of 120hz at 1920x1080, as that would be misleading due to the blur and using auto timings from 900p.

What is interesting is why this doesn't happen (or at least not anywhere near as much) with the 1920x1080 timings used on the larger resolutions. Perhaps it is an issue with the TV downscaling from its native resolution (from native 1080p to the 720p or 900p resolution timings), then having to upscale/stretch those back to a larger resolution? I'm no expert but I would guess its something along those lines.

Also I was able to get 3840x2160@23hz and 3600x2025@24hz using auto timings with the current resolution set at 1920x1080@60hz when creating them. Was not able to get either of those when I had resolution set to 1920x1080@108hz when testing them. Also of note, both of those UHD resolutions are clearer than the 900p timings with 1080. I think this is because the active pixels are native, and all the display has to do is scale them down to 1080, rather then down and then up again.