New Nvidia driver Gsync support - Gsync Ceilling problems

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.
Notty_PT
Posts: 551
Joined: 09 Aug 2017, 02:50

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by Notty_PT » 21 Jan 2019, 07:53

jorimt wrote:
Notty_PT wrote:All these inconsistencies are the reason I said the best experience with this driver enabled gsync are:

- capping fps to 120 on a 144hz monitor
- capping fps to 50 on a 60hz

Otherwise I assure everyone will have tearing. Even at 130fps. And if you use Vsync you will have input lag.
FYI, this is normal even on a genuine G-SYNC monitor with G-SYNC + V-SYNC "Off"; if the framerate can be sustained at the max refresh rate, say 144Hz with a 141 FPS cap, for instance, bottom screen tearing (due to frametime variances in the upper range) can only be (in my testing) removed with about a 120 FPS cap. Anything above that will make the tearing in that area return.

So we know that even if the G-SYNC driver implementation on FreeSync monitors was perfected, it will still retain this issue in that scenario.

What is wrong with this driver implementation (at least according to user reports thus far), is that the V-SYNC option appears to be functioning as plain old V-SYNC (instead of a frametime compensation mechanism), and LFC isn't working, or isn't working well, even on officially supported monitors.

Granted, software LFC is hard to get right. In fact, all of this is hard to get right solely through software, especially with the nearly infinite variations of setup and monitor combinations this feature has to run with.
Notty_PT wrote:Another thing I found: this software Gsync adds input lag.. Just by toggling it OFF and ON on the desktop I immediatly notice it in my mouse. More noticeable in game.
Very possible, but you're right, it would have to be tested.

Again, I don't have access to a FreeSync display, but the Chief did say he may be doing some basic high speed tests with this driver feature in the coming months.

Suffice to say, while it's a fun little novelty to play with if you already have an Nvidia GPU paired with a FreeSync monitor, this driver feature isn't currently something that should be the motivation to buy a FreeSync monitor to pair with your existing Nvidia GPU to save on the cost of a genuine, standalone G-SYNC or FreeSync setup...at least yet; time will tell...
Had no idea that even with gsync module you could only get rid of the tearing when vsync OFF at 120fps! Thanks for that clarification!

I am avoiding Gsync + Vsync ON + 141fps ca because it adds even more input lag. 120fps + Vsync ON is doable tho but almost pointless because at 120fps I barely get tearing (or I cant notice it).

At 240hz this problem is not as bad because is hard to notice tearing at that refresh rate. 240hz problem has more to do with the huge framerate fluctuations due to current day hardware being unable to deliver steady 200-240fps. Gsync + 240hz works well tho. But one big 240hz advantage is lost: input lag.

So if Im using 240hz Gsync, everytime Im at 160fps the refresh rate will go down to 160hz right? And I end up with 1/160*1000 during that time correct?

At least I notice the increased input lag.

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

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by jorimt » 21 Jan 2019, 10:37

lexebidar wrote:Frametimes seemed consistent and LFC indeed worked but the range was WRONG. The vsync behaviour was not the same as with gsync indeed but I could not put my finger on it. It behaved different on ag251fg when I had it

The frame doubling started below 60fps and doubling stayed enabled until 70fps at least. I felt that the monitor stayed in LFC doubling mode for far too much than it was necessary.
Other than that, the experience was fine.
Hmm, I got a similar report in a comment on my article.

It's very possible (in fact, likely) that LFC with G-SYNC on FreeSync is kicking in earlier on LFC-supported monitors when compared to standalone G-SYNC/FreeSync 2. Regardless, it would have to be tested with something like an oscilloscope to confirm.

Were you going solely by the monitor OSD's refresh rate meter?
Notty_PT wrote:Had no idea that even with gsync module you could only get rid of the tearing when vsync OFF at 120fps! Thanks for that clarification!
Yup, this is explained in the "Range" section of my article:
https://www.blurbusters.com/gsync/gsync ... ettings/2/

Users tend to have a really funny idea that just because their system may be able to sustaining an average framerate (say 141 FPS @144Hz), that their frametimes are also constant or near constant from frame to frame as well, which is almost never the case.

See, the average framerate is simply an average of all those individual frametimes added up per second. The frametimes from frame to frame can vary a little or wildly at any given time while sustaining a relatively stable average framerate.

You can't even really 100% go by programs such as MSI/RTSS to read your frametimes, because the polling (update/report) rate is usually anywhere between 500-1000 milliseconds at default, which means the graphs are only charting your frametime status in half second to one second intervals; a lot of info can get lost in there, seeing as each frame is rendered in the low milliseconds, and at 144Hz, for instance, that's up to 144 of them per second.

These rapid frametime variances in the upper FPS range are what cause the bottom screen tearing with G-SYNC + V-SYNC "Off."'

This may end up being a really stupid (crude, non-technical, and incomplete) analogy (I'll risk it), but think of a frame from the top to the bottom of the screen as a single knitted scarf, with the tearing near the bottom of the screen being an unfinished edge.

Now think of the G-SYNC module/functionality as the knitter. The knitter has to complete 144 scarves (aka frames) per day (aka second). Each complete scarf is an identical length (1 frame per 1 fixed scanout = 1 complete frame with no tearing).

Without distractions (aka perfect frametimes), the knitter can complete all 144 scarves (frames) in 1 day (second) without leaving any unfinished edges (tearing).

However, as we all know, daily distractions (aka frametime variances) are common.

So what happens when the knitter encounters these distractions throughout the day (second)?

With G-SYNC + V-SYNC "Off," The knitter completes as much as each scarf (frame) as possible, and then leave each scarf (frame) they don't have time to finish in varying degrees of unfinished states (aka tearing), as to move onto the next, since 144 unfinished scarves (frames) in a day (second) are better than 120 finished scarves (frames) in a day (second), at least if the employer (aka the user in this case; higher average framerate desired over no tearing) requires it.

With G-SYNC + V-SYNC "On," (the behavior of which I'm about to explain I can only guarantee applies to a genuine G-SYNC module; "G-SYNC on FreeSync" functionality is still up in the air) you get to retain the higher average framerate while avoiding the partial tearing by letting it hold onto the frame (typically for fractions of milliseconds) until that "fringe" is finished.

The analogy is harder to make accurate in the G-SYNC + V-SYNC "On" scenario, but let's just say when the knitter encounters a distraction, they hand the unfinished scarf over to a helper (aka module holding the unfinished frame), who is slightly slower than the knitter, but not enough to prevent 144 individual scarves from being completed that day (virtually no input lag increase).
Notty_PT wrote:I am avoiding Gsync + Vsync ON + 141fps ca because it adds even more input lag. 120fps + Vsync ON is doable tho but almost pointless because at 120fps I barely get tearing (or I cant notice it).
G-SYNC + V-SYNC "Off" (within the refresh rate/G-SYNC range), is only reducing your input lag over G-SYNC + V-SYNC "On" when you see tearing. If you don't, then they're virtually identical input lag-wise.

The irony, is that you're actually trying to get rid of the input lag advantage you think you want (the tearing at the bottom) by removing it with a lower FPS cap in the first place. Visible tearing IS your literal input lag reduction in this case.
Notty_PT wrote:So if Im using 240hz Gsync, everytime Im at 160fps the refresh rate will go down to 160hz right? And I end up with 1/160*1000 during that time correct?
If you're at 240Hz G-SYNC + 160 FPS, you still have a 4.2ms scanout speed, with the scanout repeating 160 times per second, whereas, say on a 165Hz monitor with G-SYNC, you'd have a 6.1ms scanout speed, with the scanout repeating 160 times per second.

So, no, because the scanout speed remains constant with G-SYNC, you're still getting faster frame delivery on a 240Hz monitor than you would be on a monitor with a lower native refresh rate, even at the same framerate.

Wrote about this in my article as well:
https://www.blurbusters.com/gsync/gsync ... ttings/13/
(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)

lexebidar
Posts: 83
Joined: 15 Sep 2017, 18:58

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by lexebidar » 21 Jan 2019, 12:00

Yes, I was using only monitor refresh counter which can be enabled from OSD paired with steam fps counter, so i could see when it's doubling. is there other way?
I am so unsure what monitor to get next... There is a lot of choice. Ultrawides, Ips... even supposedly good va's. Everything is made with high refresh rate now. And Freesync compatibility made the choice much more wider.
Although, from what I've seen nothing comes remotely close to ag251fg with 144hz ulmb strobing. That monitor was crisp as crt but I couldnt stand the iq

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

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by jorimt » 21 Jan 2019, 12:11

lexebidar wrote:Yes, I was using only monitor refresh counter which can be enabled from OSD paired with steam fps counter, so i could see when it's doubling. is there other way?
Again, unless you have an oscilloscope or the like, not really:

phpBB [video]


It could be a simple readout glitch, the LFC kicking in too early with current G-SYNC driver implementation on FreeSync monitors, or a combo of both.

If you want guaranteed proper LFC functionality, a standalone G-SYNC/Nvidia GPU or FreeSync 2 (LFC-supported)/AMD GPU setup is your only choice, at least until the "G-SYNC on FreeSync" driver functionality matures (and/or LFC is confirmed to work properly on supported monitors); early days.

FYI, there is an ongoing user-generated "G-SYNC on FreeSync" monitor compatibility list (sourced from reddit):
https://docs.google.com/spreadsheets/u/ ... g&sle=true
(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)

Notty_PT
Posts: 551
Joined: 09 Aug 2017, 02:50

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by Notty_PT » 21 Jan 2019, 13:11

jorimt wrote:
lexebidar wrote:Frametimes seemed consistent and LFC indeed worked but the range was WRONG. The vsync behaviour was not the same as with gsync indeed but I could not put my finger on it. It behaved different on ag251fg when I had it

The frame doubling started below 60fps and doubling stayed enabled until 70fps at least. I felt that the monitor stayed in LFC doubling mode for far too much than it was necessary.
Other than that, the experience was fine.
Hmm, I got a similar report in a comment on my article.

It's very possible (in fact, likely) that LFC with G-SYNC on FreeSync is kicking in earlier on LFC-supported monitors when compared to standalone G-SYNC/FreeSync 2. Regardless, it would have to be tested with something like an oscilloscope to confirm.

Were you going solely by the monitor OSD's refresh rate meter?
Notty_PT wrote:Had no idea that even with gsync module you could only get rid of the tearing when vsync OFF at 120fps! Thanks for that clarification!
Yup, this is explained in the "Range" section of my article:
https://www.blurbusters.com/gsync/gsync ... ettings/2/

Users tend to have a really funny idea that just because their system may be able to sustaining an average framerate (say 141 FPS @144Hz), that their frametimes are also constant or near constant from frame to frame as well, which is almost never the case.

See, the average framerate is simply an average of all those individual frametimes added up per second. The frametimes from frame to frame can vary a little or wildly at any given time while sustaining a relatively stable average framerate.

You can't even really 100% go by programs such as MSI/RTSS to read your frametimes, because the polling (update/report) rate is usually anywhere between 500-1000 milliseconds at default, which means the graphs are only charting your frametime status in half second to one second intervals; a lot of info can get lost in there, seeing as each frame is rendered in the low milliseconds, and at 144Hz, for instance, that's up to 144 of them per second.

These rapid frametime variances in the upper FPS range are what cause the bottom screen tearing with G-SYNC + V-SYNC "Off."'

This may end up being a really stupid (crude, non-technical, and incomplete) analogy (I'll risk it), but think of a frame from the top to the bottom of the screen as a single knitted scarf, with the tearing near the bottom of the screen being an unfinished edge.

Now think of the G-SYNC module/functionality as the knitter. The knitter has to complete 144 scarves (aka frames) per day (aka second). Each complete scarf is an identical length (1 frame per 1 fixed scanout = 1 complete frame with no tearing).

Without distractions (aka perfect frametimes), the knitter can complete all 144 scarves (frames) in 1 day (second) without leaving any unfinished edges (tearing).

However, as we all know, daily distractions (aka frametime variances) are common.

So what happens when the knitter encounters these distractions throughout the day (second)?

With G-SYNC + V-SYNC "Off," The knitter completes as much as each scarf (frame) as possible, and then leave each scarf (frame) they don't have time to finish in varying degrees of unfinished states (aka tearing), as to move onto the next, since 144 unfinished scarves (frames) in a day (second) are better than 120 finished scarves (frames) in a day (second), at least if the employer (aka the user in this case; higher average framerate desired over no tearing) requires it.

With G-SYNC + V-SYNC "On," (the behavior of which I'm about to explain I can only guarantee applies to a genuine G-SYNC module; "G-SYNC on FreeSync" functionality is still up in the air) you get to retain the higher average framerate while avoiding the partial tearing by letting it hold onto the frame (typically for fractions of milliseconds) until that "fringe" is finished.

The analogy is harder to make accurate in the G-SYNC + V-SYNC "On" scenario, but let's just say when the knitter encounters a distraction, they hand the unfinished scarf over to a helper (aka module holding the unfinished frame), who is slightly slower than the knitter, but not enough to prevent 144 individual scarves from being completed that day (virtually no input lag increase).
Notty_PT wrote:I am avoiding Gsync + Vsync ON + 141fps ca because it adds even more input lag. 120fps + Vsync ON is doable tho but almost pointless because at 120fps I barely get tearing (or I cant notice it).
G-SYNC + V-SYNC "Off" (within the refresh rate/G-SYNC range), is only reducing your input lag over G-SYNC + V-SYNC "On" when you see tearing. If you don't, then they're virtually identical input lag-wise.

The irony, is that you're actually trying to get rid of the input lag advantage you think you want (the tearing at the bottom) by removing it with a lower FPS cap in the first place. Visible tearing IS your literal input lag reduction in this case.
Notty_PT wrote:So if Im using 240hz Gsync, everytime Im at 160fps the refresh rate will go down to 160hz right? And I end up with 1/160*1000 during that time correct?
If you're at 240Hz G-SYNC + 160 FPS, you still have a 4.2ms scanout speed, with the scanout repeating 160 times per second, whereas, say on a 165Hz monitor with G-SYNC, you'd have a 6.1ms scanout speed, with the scanout repeating 160 times per second.

So, no, because the scanout speed remains constant with G-SYNC, you're still getting faster frame delivery on a 240Hz monitor than you would be on a monitor with a lower native refresh rate, even at the same framerate.

Wrote about this in my article as well:
https://www.blurbusters.com/gsync/gsync ... ttings/13/
I have a hard time understanding it! If Im using VRR and my fps drops from 141 to 80, doesnt it switch the monitor rate to 80hz? So How can I mantain the 144hz 6,9 ms scanout if the monitot isnt at that rate anymore?

User avatar
RealNC
Site Admin
Posts: 3730
Joined: 24 Dec 2013, 18:32
Contact:

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by RealNC » 21 Jan 2019, 13:27

Notty_PT wrote:I have a hard time understanding it! If Im using VRR and my fps drops from 141 to 80, doesnt it switch the monitor rate to 80hz? So How can I mantain the 144hz 6,9 ms scanout if the monitot isnt at that rate anymore?
At 80FPS, frames will arrive every 12.5ms. The monitor will scan out the frame at full 144Hz speed, which is 6.9ms. Then it will just wait until the next frame is ready. At 80FPS, it means it will wait for 5.6ms after scanning out the current frame (6.9 + 5.6 = 12.5).
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

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

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by jorimt » 21 Jan 2019, 14:02

Notty_PT wrote:I have a hard time understanding it! If Im using VRR and my fps drops from 141 to 80, doesnt it switch the monitor rate to 80hz? So How can I mantain the 144hz 6,9 ms scanout if the monitot isnt at that rate anymore?
Yes and no.

To add to what RealNC stated, at 144Hz, each scanout cycle completes at 6.9ms. This scanout cycle number does not change when G-SYNC "adjusts" the refresh rate. So at 144Hz, each frame is being delivered in 6.9ms, but G-SYNC adjusts the amount of times this 6.9ms scanout cycle repeats in a second.

Thus, at 141 FPS/144Hz, G-SYNC is repeating the scanout cycle 141 times (render frametime of 7.1ms) and delivering each completed frame at 6.9ms per (144Hz), and when it drops to 80 FPS/144Hz, G-SYNC is then repeating the scanout cycle 80 times (render frametime of 12.5ms) per second, but still delivering each frame at 6.9ms per (144Hz).

If there were such a thing as an 80Hz retail monitor, 80 FPS at 80Hz would be delivered/scanned in at 12.5ms per frame. at 144Hz, G-SYNC can effectively deliver that same 80 frames (on average) faster, due to the increase in base scanout (frame delivery) speed per (144Hz).

In other words, G-SYNC doesn't adjust the actual native max refresh rate of the monitor, but only adjusts how many times it repeats per second; each one of those repetitions inside that second remain at the frame delivery speed of the current max refresh rate, regardless of current framerate/G-SYNC refresh rate.

Regarding your question in the other thread, as for why it still feels like you're getting increased input lag or judder at much lower frame/refresh rates with G-SYNC (even with variable overdrive in place), that's just the nature of lower frame/refresh rates; the lower the average framerate is, the longer the intervals are between each frame delivered, which makes everything just feel more sluggish. Something that G-SYNC (or any syncing method, for that matter) can do nothing about.

That, and to specifically address your experience with the Asus XG248Q (which is a FreeSync panel, now with software-level G-SYNC support, I believe), it's very possible LFC (low framerate compensation) isn't working as well as it does on a genuine G-SYNC monitor, and could either be going into LFC too early, not at all (at which point it would just revert to standalone v-sync on or off), or have some other issue.

It's basically all up to Nvidia as to how far they go in supporting and updating this new "G-SYNC on FreeSync" feature over time. Even at it's best, it will likely never be as complete or feature-robust as a certified G-SYNC monitor containing an actual hardware module.
(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: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by Chief Blur Buster » 21 Jan 2019, 19:47

Here's a visual explanation.

Variable refresh rate varies the size of the blanking interval (pauses) between refresh cycles. Here's a diagram of 100fps at 144Hz

Scan diagram (Created with the assistance of Jorim):

Image

Even though it is only running at 100fps (100Hz), the top-to-bottom sweep is in 1/144sec.

First, watch high speed videos of display scan out. And then you'll find it much easier to interpret the scan diagrams.

phpBB [video]


(Yes, I know this one is an OLED, but it's easier to understand because the GtG mathematics doesn't fuzzy trying to interpret the high speed videos correctly)

Now imagine inserting (varying) delays between the scanout sweeps this high speed video, and now you understand VRR. The scanout sweep is always at a constant velocity, but the time interval between scanout sweeps can vary.

That's also why 30fps at 240Hz GSYNC is much lower lag than 30fps at 60Hz, because the "30Hz" refresh cycle is scanned-out in a 1/240sec sweep.

When framerates are maxed out, the interval between the scanout sweeps, can't go negative since max Hz is the minimum VBI size. Now, the mode has to go into VSYNC ON (queue subsequent frames for the next refresh cycle) instead of beginning the scanout sweep the moment the frame is delivered.

If you are a software developer, then read this thread -- the software developer is timing the refresh cycles. The completed-frame Present() API immediately triggers the scanout sweep instantly on the spot, right at that instant -- if the monitor is not already busy mid-scanout of a previous refresh cycle. Otherwise, it has to wait (e.g. add 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
jorimt
Posts: 2479
Joined: 04 Nov 2016, 10:44
Location: USA

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by jorimt » 22 Jan 2019, 10:07

Chief Blur Buster wrote:Here's a visual explanation [...]
Picture is worth a thousand words :)

<offtopic>
Chief Blur Buster wrote:Yes, I know this one is an OLED, but it's easier to understand because the GtG mathematics doesn't fuzzy trying to interpret the high speed videos correctly
Sheesh, that sweep fade clarity when compared to LCDs; OLED's near 0ms pixel response really makes a difference.

I can't find the refresh rate for the Tab S4, but I'm assuming it's 60Hz. Imagine it at 120Hz or up :o
</offtopic>
(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)

Notty_PT
Posts: 551
Joined: 09 Aug 2017, 02:50

Re: New Nvidia driver Gsync support - Gsync Ceilling problem

Post by Notty_PT » 22 Jan 2019, 10:48

That oled motion is porn!! Cant wait for Joled Burning Core 144hz Oled. Would a 144hz oled provide better motion clarity than TN 240hz due to the near 0ms response time? I can only imagine! Plus perfect contrast.

Post Reply