NVIDIA G-Sync Pulsar monitor - Asus ROG Strix XG27AQNGV

[Angel Soler]

Yeah, it’ll be good to see the actual numbers.

One thing that seemed odd in that review is that the reviewer said the 60 Hz mode dimmed the screen as if he couldn’t adjust brightness with the pulse width. On my Acer I can adjust it just fine, and I’ve seen others can too. I’m not sure if that’s a limitation specific to the MSI model.

To be honest, I have no idea. I’m not familiar with the differences between the MSI model and the Asus one. I also wasn’t aware that there was a difference in brightness between them.

[Discorz]

How on Earth are the graphs for the higher refreshes so bad?! If both the up and down transitions can be essentially fully complete within 0.9ms, and we assume that's the fastest it can do these transitions, then sure, 360Hz may be bottlenecked. But the 120Hz graphs (and even 240Hz) should look way better than that, no?

Like, the 120Hz PW 10 has the rising and falling "edges" taking a full 2ms each, the voltage not even reaching -6V (much less -12V), with really jagged internal peaks and valleys... What is going on? This has to be a bug, right? I, like many of you, were shocked to see how good the 60Hz mode looked compared to the other modes, and with this data it definitely seems much more likely the backlight performance IMO than it is any sort of limitation on pixel transition times.

Good question! I'm still solving the rolling edge-lights puzzle, but so far these are some of my theories:

Light dispersion/diffusion:
The minimum pulse width is restricted by the light dispersion. I look at it as a kind of backlight GtG response. Similar to how CRTs used to have phosphors. If you try to flash each dispersed zone for the same amount of time, you're essentially getting multiple pulses with different intensities across the screen. That's where the staircase/stepped look of the pulse comes from - the zones abruptly switch from one to the other.

Pulse width method #1 (the classic method):
Now if u try to strobe the same zone for a very short period, the aforementioned stepping turns into multi-strobe-stepping. This happens whenever zone is flashed for less than "refresh time / number of vertical zones = X" amount of time. This basically shortens multiple small pulses within one larger pulse. This is nicely demonstrated on "PW 10 oscillographs" and some of the pursuit shots. On the opposite, when pulse time is greater than "X", the lengthening of the larger pulse happens. This is also visible in PW 100 oscillographs.
...examples

Pulse shortening method #2 (the superior, dispersion-optimized method):
The above is describing standard-timing resolutions. Beyond that, a clever workaround for dispersion can be achieved by using a form of QFT which scans the pulse faster down the screen. This trick perceptually squashes/shortens the same pulse (pixels are illuminated for a shorter period) which helps with the dispersion. When the scan speed is doubled, the pulse duration is halved, and the brightness decreases proportionally. This implies that the pulse needs to be taller/wider to compensate for the brightness loss. The squashing is evident on these high-speed camera frames of DyAc 2, and examples of pulses going taller/wider can be found in this Discord server discussion. The same effect also appears in 60 Hz ULMB oscillographs.

"Backlight QFT" vs QFT as we know it
If QFT is the real reason for 60 Hz looking better, than that means PW setting is adjusting the scan-out speed factor. And this is where I start to doubt my theories because this normally doesn't happen without screen blackouts (just like when changing resolutions/refresh rates). However, maybe they've separated the backlight layer control from the pixel layer to avoid that. This way scaler limitations are avoided and pulse speeds can be manipulated more effectively. The only remaining limitation would be the pixel GtG response and its scan speed (actual QFT). They'd only have to make sure the pulse doesn't enter/touch the GtG zone during the process.

The general rule for strobing still applies here. For least amount of crosstalk pulse needs to happen when GtG transitions are most complete - at the back of the frame as Nvidia stated, or for large headroom situations, somewhere sooner between GtG zones for better latency.

The thing with QFT is that it normally can't be used at max refresh rate, because what QFT essentially does is utilizing maximum scan-down speed (of max Hz) at reduced refresh rates. So as refresh rate goes up, QFT benefits reduce. Once it reaches max Hz there is none. Find out more here.

Looking at the graphs, I realized the backlight scan boost (or even QFT) factor can likely be derived if zones were counted. Holding onto my theories, anything above 10 zones would indicate that QFT is in use - At 360 and 240 Hz, there are ~10 zones (no QFT), while at 120 Hz there are ~13 (a rather insignificant ~1.3× or ~150 Hz scan boost). At 60 Hz, the situation is a bit different but it aligns with my theories. For PW 100 I counted about 25 "zones" (~2.5x, ~150 Hz); for PW 50 around 50 (5x, ~300 Hz); and for PW 10 the exact number is unclear, but it’s likely in the triple digits. PW 10 far exceeding a 360 Hz boost is what initially led me to the idea of "backlight control separation", because I don’t see another way this could be achieved. There is a possibility for an overclock of sort, but then the question is why wasn't it used for higher rates.

Professor Chief, can you help with homework! Does any of this make sense?

Would it be worth asking NVIDIA to give the 120/240/360 Hz ULMB2 modes the same full adjustable pulse width range as the 60 Hz mode? Even if brightness drops at very low PW settings, many of us would like the option for maximum clarity at high frame rates.

I'm not entirely sure why they didn't do it in first place. If my theories here are going right direction, what all this would translates to is: I believe 360-120 Hz is doing method #1 (for the most part), and 60 Hz is doing #2+1. So 120 Hz can probably be improved a bit, 240 Hz significantly less so, and 360 Hz by none.

What also crossed my mind is what if consoles can't do very large QFT ratios like PCs can, so they were unable to maximize the boost and limited it to ~150 Hz, leaving 120-240 Hz on the PC in the dust. I'm not familiar with that kinda stuff, so I won't go into it.

Finally, I wasn’t even aware there was now a user-customizable overdrive slider (0–400 gain). What benefits does this actually give in practice? I’m curious how much it helps with overdrive tuning across different frame rates.

When overdrive is implemented this well, gain doesn't offers many benefits beyond temperature compensation and allowing users to adjust to their liking. They nailed it so well this time that they could've just made it on/off toggle or even leave it on permanently. But generally it's good to have it just in case manufacturer tuned something wrong.

[brownvim]

Thanks for your theories, it's interesting, helps get an idea why we're seeing such a big difference between the modes.

I did ask Baddass on the Overclockers forum to pass this feedback on to his NVIDIA contact. He mentioned his contact is currently on holiday, so we're waiting for a response.

It would also be really nice to see the 60 Hz ULMB2 mode (and the higher ones for comparison) recorded in slow motion with a Samsung phone that can do 960 fps or a newer GoPro that can do 480 fps. That would give us a much clearer visual idea of exactly what's going on with the rolling scan and pulse width behaviour.

If they could get the 120 Hz (and higher) ULMB2 modes to perform as well as the 60 Hz mode, that would be amazing. For me, 120 Hz feels like the sweet spot for a really nice balance of latency and smoothness — especially now that more games are using path tracing.

What's also interesting is how well the new x6 Dynamic Frame Generation pairs with Pulsar. It forces most games into a tight frame rate window, so nearly all supported titles can hit the sweet spot for best clarity. For example, I tested Resident Evil Requiem at full settings with path tracing by setting target to 350 fps — the frames generally stay around 330-360 and it looks smooth and very clear. I need to test it more between the fixed rate 60hz mode but its nice to be able to do both as they have their pros and cons.

[liquidshadowfox]

If you can pass to the nvidia people the following suggestion it would be great
1. In nvidia control panel, Allow the "Monitor Technology" to select between Gsync, Fixed, ULMB2 or Pulsar per game/program profile and globally.
2. In nvidia control panel, Add a "Max Monitor Refresh" setting to select Monitor Max Hz refresh rate per game/program profile and globally

^as much as I love using scripts as the next person, I think these 2 very small quality of life changes would give these nvidia Gsync monitors massive adaptability. The average user isn't going to want to use scripts (me included) in order to activate features when they should be implemented in either the nvidia app or the nvidia control panel that's more than capable. I know we can go through the monitor OSD to activate it but this would also reduce wear and tear on those menu joysticks and buttons! I mean they already have their "Project G-Assist" AI Assistant program already has the capability to turn on/off Gsync pulsar using voice commands or text prompt, why wouldn't they enable this on the control panel or the nvidia app?

I really hope they update and fix Gsync pulsar between 100 hz - 240 hz because that's my sweet spot in terms of fps for all my games and where the majority of the clarity gains are. As disappointing as 326 and 360 hz is with gsync pulsar on, I can live with it but I think they can do better below 240 hz.

Wouldn't they have been able to use QFT to greater effect if they had full bandwidth display port 2.1 and hdmi 2.1 ports? I feel like that's a big missed opportunity if so, over 400 nits of brightness while strobing is already plenty bright imo, I would be really happy if they allowed to use QFT to bring the motion clarity higher at half the brightness around 200 nits (I'd even be happy with 150 nits tbh) and just have it as a "toggle" option like they did for 60 hz ULMB 2.

[edgintheledge]

Lag testing 60Hz ULMB mode

I should preface this with what exactly is being measured and why you are seeing these numbers. If you didn't see my previous post about the device, it is a lossless adapter (for gamecube controllers), which has a lag tester specifically for smash melee setups on PC. The tests are all done ingame with the adapter sending button presses and recording transition times with a sensor. The measurements are averaged together and the end result is scored on 0-80% transition completion for 0-255/black to white. The companion software lets you see more detailed results with different transition averages, percentiles, etc. listed in the screenshots

You may find the "lag breakdown" sections in each screenshot of interest. The software will essentially try to breakdown the entire pipeline of expected latency and show you the "unattributed lag" of the setup. This is any system latency not accounted for which will include the PC's time to build a frame and the monitor's actual display lag. Because the PC is a part of this, the exact ms value can vary a little per run.

The most important thing to know is that we are comparing against a Wii plugged into a CRT TV running melee with poll drift fix mod measured at the center of the screen. That latency is 58.2ms. A "lagless" 60hz CRT setup should score ~58ms on this test, NOT 0ms.

Test 1: 360hz no VRR, no strobing, OD normal
This is the best case scenario latency on my system. I can also test with VRR later if you guys want. In my experience with previous monitors, VRR averages out to the same lag. (Tearline above sensor = faster, tearline below = slower. Averages out to the same lag over 100s or 1000s of measurements) Fun fact, this is why melee players on modern high hz gaming displays often need to purposely make their system's latency worse. The tournament standard is a 60hz CRT, but these displays (Yes, even LCD without instant GtG) are quite literally too fast in comparison.

slippi lag test 360hz no vrr no strobing.png (142.94 KiB) Viewed 1381 times

Test 2: 60hz no VRR, no strobing, OD normal
This is a very good result, the pulsar IPS at 60hz over an average of 1116 measurements completed an average 0-80% transition at the center of the screen only 1.01ms slower than a 60hz CRT would be expected to. I can later test this against my actual CRT running at 60hz to compare if you'd like.

slippi lag test 60hz no vrr no strobing.png (146.01 KiB) Viewed 1381 times

Test 3: 60 hz ULMB PW10
Looks like about a 10ms jump in lag. When reading this lag breakdown, remember that the adapter is making assumptions about the lag pipeline based on what it's measuring. It thinks the monitor's response time is 0.5ms (it can't see the actual panel transitions happening when the backlight is off), so it is increasing the unattributed lag a bit more than it should (about 2ms). CRTs are still king for having both low lag and clear 60hz motion together.

slippi lag test 60hz ULMB PW10.png (149.29 KiB) Viewed 1381 times

[edgintheledge]

Lag testing 60Hz ULMB mode cont.

Test 4: 60hz ULMB PW100
I also ran a test with PW100 just to see how it would change. Looks like a tiny bit of latency gets shaved off, so presumably the pulse starts slightly earlier making the 0-80% transition register earlier.

slippi lag test 60hz ULMB PW100.png (147.36 KiB) Viewed 1368 times

Bonus: 60Hz PW10 and PW100 graphs side by side.
I only did PW10 vs. my CRT before.

PW100 and PW10 60hz ULMB side by side.png (147.52 KiB) Viewed 1368 times

I want to investigate a little more with this device and test the "latency gradient" across different modes when I get a chance. If the 60hz mode really rolls as it's supposed to, I should be able to consistently measure that latency difference. If the top and bottom of the screen in 60hz mode give me the exact same latency, while 120+hz strobing all give me reliable top to bottom differences, I really can't see any way the 60hz mode wouldn't be a global strobe. My eyes still feel like something this mode does behaves differently than a straight 60hz roll.

[brownvim]

Thanks for the detailed results! 10 ms with 60 Hz ULMB2 on is actually pretty good — it feels like less than a frame in practice.

I’m curious what a true rolling strobe looks like in slow motion. Could the 60 Hz ULMB2 mode be doing something closer to the ShaderBeam-style rolling strobe that Chief has mentioned? It definitely doesn’t feel as harsh or flickery as typical OLED BFI, so it seems like NVIDIA did something different here.

Also, if it were a simple global strobe, wouldn’t we expect a much bigger brightness penalty? At PW 100 we’re still getting around 500 nits, whereas a true 50% global strobe would be closer to 250 nits (like how BFI on OLEDs halves brightness by turning the panel off for half the time). The fact we’re retaining this much brightness makes me think the 60 Hz mode is using a more sophisticated approach.

Appreciate the testing! I would never have thought an LCD could be faster than a CRT.

[Angel Soler]

Lag testing 60Hz ULMB mode

I should preface this with what exactly is being measured and why you are seeing these numbers. If you didn't see my previous post about the device, it is a lossless adapter (for gamecube controllers), which has a lag tester specifically for smash melee setups on PC. The tests are all done ingame with the adapter sending button presses and recording transition times with a sensor. The measurements are averaged together and the end result is scored on 0-80% transition completion for 0-255/black to white. The companion software lets you see more detailed results with different transition averages, percentiles, etc. listed in the screenshots

You may find the "lag breakdown" sections in each screenshot of interest. The software will essentially try to breakdown the entire pipeline of expected latency and show you the "unattributed lag" of the setup. This is any system latency not accounted for which will include the PC's time to build a frame and the monitor's actual display lag. Because the PC is a part of this, the exact ms value can vary a little per run.

The most important thing to know is that we are comparing against a Wii plugged into a CRT TV running melee with poll drift fix mod measured at the center of the screen. That latency is 58.2ms. A "lagless" 60hz CRT setup should score ~58ms on this test, NOT 0ms.

Test 1: 360hz no VRR, no strobing, OD normal
This is the best case scenario latency on my system. I can also test with VRR later if you guys want. In my experience with previous monitors, VRR averages out to the same lag. (Tearline above sensor = faster, tearline below = slower. Averages out to the same lag over 100s or 1000s of measurements) Fun fact, this is why melee players on modern high hz gaming displays often need to purposely make their system's latency worse. The tournament standard is a 60hz CRT, but these displays (Yes, even LCD without instant GtG) are quite literally too fast in comparison.
slippi lag test 360hz no vrr no strobing.png


Test 2: 60hz no VRR, no strobing, OD normal
This is a very good result, the pulsar IPS at 60hz over an average of 1116 measurements completed an average 0-80% transition at the center of the screen only 1.01ms slower than a 60hz CRT would be expected to. I can later test this against my actual CRT running at 60hz to compare if you'd like.
slippi lag test 60hz no vrr no strobing.png


Test 3: 60 hz ULMB PW10
Looks like about a 10ms jump in lag. When reading this lag breakdown, remember that the adapter is making assumptions about the lag pipeline based on what it's measuring. It thinks the monitor's response time is 0.5ms (it can't see the actual panel transitions happening when the backlight is off), so it is increasing the unattributed lag a bit more than it should (about 2ms). CRTs are still king for having both low lag and clear 60hz motion together.
slippi lag test 60hz ULMB PW10.png

Thank you so much, Edgintheledge, for the time and effort you put into taking those measurements — I really appreciate it

A result of around 10 ms with ULMB enabled at 60 Hz is fantastic

After seeing these results, I’ve decided to order the monitor — it should be arriving in the next few days.

Thanks again, I truly appreciate it.

[Discorz]

I did ask Baddass on the Overclockers forum to pass this feedback on to his NVIDIA contact. He mentioned his contact is currently on holiday, so we're waiting for a response.

This is just my thinking process and few theories after all.

I think they should focus on improving Pulsar, though it would be nice to see ULMB sorted out. I’d rather they prioritize flickerless, high-quality, lagless frame generation

[t2na]

What's the recommendation now for anyone using these Pulsar monitors on the latest firmware? Stick to a locked 90fps for any games that might fluctuate too much between 120-200fps because of the frame skips/ghosting that @brownvim flagged to TFT Central/Nvidia.

I'm playing AC Shadows at the moment and if I play it without any FG it'll sit nicely at an 85fps avg - but with frame gen 2x it can run at 140ish. I typically cap it at 120fps - but I can always cap it at 90fps here to take advantage of Pulsar.

--

For any game that runs nicely above 200fps (i.e. I play the Finals typically at a locked 260fps) is it best to stick with regular Pulsar usage?

I've updated to the latest firmware so will also try out the 60hz ULMB2 mode on the PS5 Pro, I tend to use that console for most of my single player titles so it'll be nice to see how that looks and feels with the 60hz games there. A huge thanks for @edgintheledge for those latency tests, really useful to read through.