Gsync review [from board won in competition]
Posted: 05 Feb 2014, 02:59
Sorry for being slow on this.
Installation:
Took me about 5 minutes of work, plus about an hour inspecting things .
Overall rating here: low difficulty, but I REALLY don't like how nvidia just bends the board, especially around the DP connector. Sorry, but having a latching surface-mount connector (it does have through-hole lugs for the mounting posts) is bad enough (though common), but to have it actually bending the board to mount flush is just poor design and practically begging for damage to happen. Also, seriously, breaking off a standoff? The board is huge, should have moved the module over and made a hole in the board. :/
https://picasaweb.google.com/1129081983 ... 9395640866
There are lots of other pics of installation, no sense beating a dead horse there.
The assembled monitor has 3 modes of operation.
1) normal scanout, constant backlight brightness
2) ULMB (Ultra Low Motion Blur).
What is ULMB? Here, the gsync kit reads in the video data, tosses it into ram and simultaneously writes it out to the screen, flashes the backlight, and repeats the process.
ULMB uses a fast scanout (I measured ~1/175th of a second) so the added latency should be around 2ms at the top of the frame, 0 at the bottom. The dead time at the beginning of the input frame is used to strobe the backlight for a brief duration (I measured 1.8ms). Extended dead-times between frames are needed to give the pixels at the bottom of the panel time to complete their transitions before the backlight is turned on.
An oscilloscope capture of this process is shown here:
This picture shows the active data region in blue with the LED - side in red. The backlight is on when the red line is LOW. The display is updating when the blue line appears noisy.
https://picasaweb.google.com/1129081983 ... 1192396818
This mode is great for reducing motion blur, but is not perfect. It is essentially lightboost that can be enabled and disabled at the press of a button. Images in the lower third of the screen tend to have after-shadows from the last frame. Compare the non-ulmb mode with the two ulmb pictures. Motion clarity is GREATLY enhanced. For example, the moving images tests at testufo, such as
http://www.testufo.com/#test=photo&phot ... 0&height=0
are perfectly clear when moving. Street names are readable!
no ulmb:
https://picasaweb.google.com/1129081983 ... 2828371810
ulmb at the top of the screen:
https://picasaweb.google.com/1129081983 ... 0287927938
ulmb at the bottom of the screen:
https://picasaweb.google.com/1129081983 ... 6967487746
There are three downsides to ULMB.
A) Overdrive is tuned such that the perceived light output averages out to converge to the desired pixel value faster, but with a strobing backlight, we perceive a single sample of this process. I suspect that this mismatch is what causes the normally minor overdrive artifacts to be visible as multiple afterimages which can be clearly seen in the images.
B) Many people, me included, find flickering light sources irritating and uncomfortable to use. If really cheap improperly ballasted fluorescent lights or low-frequency PWM dimming strain your eyes, then ULMB is not going to be for you.
C) GSYNC is incompatible with ULMB in it's current incarnation. Each pulse of the LED is at a set current level, controlled by the brightness setting. The duration of each pulse is constant (1.8ms). This means that the brightness of the screen would go down with framerate, and with gsync, would be jumping all over the place. If nvidia wanted to get really fancy, they could pulse the LEDs harder during lower framerate scenarios to obtain constant perceived brightness, but that would require that the LEDs could handle it. I suspect not, so the solution was to disable ULMB under GSYNC mode or go to ~20% of the already-dim light output.
3)GSYNC mode: In a sentence: pretty frigging sweet. Here, the display is driven at a variable framerate to match what the gpu has finished rendering. The resulting video looks significantly smoother. To best explain, load up a game and configure it to run at ~40-50fps (assuming a 60Hz monitor). Now fly around the map and look at the movement of objects in front of each other. Even though your motion in the game is along a constant path, objects do not move smoothly, they judder around as if the camera was riding on a slightly bumpy road (the bumpy road analogy would be positional noise and not temporal, but if looking at a single object, the effect is pretty close). GSYNC paves this road. Motion is smoothed out. Having tearing removed is a nice benefit too .
For games running at framerates significantly higher than what the monitor can do, tears are generally pretty small and motion is smooth enough to make it hard to notice if running in gsync mode or not. For framerates around or under what the monitor can do is where gsync shines. The distracting nature of the jumpy motion is eliminated, so the downside of running at these speeds is primarily responsiveness and not fluidity. This can make some newer games (battlefield) significantly better
Overall, would I recommend the gsync kit? Not really. It is an overall expensive solution for something that is just a 24" 1080p tn panel, even though it can do some pretty cool stuff. Would I recommend gsync for your next monitor? Absolutely, variable refresh rate displays are awesome!
As a side note: I was unable to test my just-in-time rendering shim layer for some other reasons.
https://picasaweb.google.com/1129081983 ... 8580186674
https://picasaweb.google.com/1129081983 ... 6250361698
1) gsync does not work with windowed applications now
2) my hooks aren't implemented very well and break under resizing, including going to full-screen :/
Installation:
Took me about 5 minutes of work, plus about an hour inspecting things .
Overall rating here: low difficulty, but I REALLY don't like how nvidia just bends the board, especially around the DP connector. Sorry, but having a latching surface-mount connector (it does have through-hole lugs for the mounting posts) is bad enough (though common), but to have it actually bending the board to mount flush is just poor design and practically begging for damage to happen. Also, seriously, breaking off a standoff? The board is huge, should have moved the module over and made a hole in the board. :/
https://picasaweb.google.com/1129081983 ... 9395640866
There are lots of other pics of installation, no sense beating a dead horse there.
The assembled monitor has 3 modes of operation.
1) normal scanout, constant backlight brightness
2) ULMB (Ultra Low Motion Blur).
What is ULMB? Here, the gsync kit reads in the video data, tosses it into ram and simultaneously writes it out to the screen, flashes the backlight, and repeats the process.
ULMB uses a fast scanout (I measured ~1/175th of a second) so the added latency should be around 2ms at the top of the frame, 0 at the bottom. The dead time at the beginning of the input frame is used to strobe the backlight for a brief duration (I measured 1.8ms). Extended dead-times between frames are needed to give the pixels at the bottom of the panel time to complete their transitions before the backlight is turned on.
An oscilloscope capture of this process is shown here:
This picture shows the active data region in blue with the LED - side in red. The backlight is on when the red line is LOW. The display is updating when the blue line appears noisy.
https://picasaweb.google.com/1129081983 ... 1192396818
This mode is great for reducing motion blur, but is not perfect. It is essentially lightboost that can be enabled and disabled at the press of a button. Images in the lower third of the screen tend to have after-shadows from the last frame. Compare the non-ulmb mode with the two ulmb pictures. Motion clarity is GREATLY enhanced. For example, the moving images tests at testufo, such as
http://www.testufo.com/#test=photo&phot ... 0&height=0
are perfectly clear when moving. Street names are readable!
no ulmb:
https://picasaweb.google.com/1129081983 ... 2828371810
ulmb at the top of the screen:
https://picasaweb.google.com/1129081983 ... 0287927938
ulmb at the bottom of the screen:
https://picasaweb.google.com/1129081983 ... 6967487746
There are three downsides to ULMB.
A) Overdrive is tuned such that the perceived light output averages out to converge to the desired pixel value faster, but with a strobing backlight, we perceive a single sample of this process. I suspect that this mismatch is what causes the normally minor overdrive artifacts to be visible as multiple afterimages which can be clearly seen in the images.
B) Many people, me included, find flickering light sources irritating and uncomfortable to use. If really cheap improperly ballasted fluorescent lights or low-frequency PWM dimming strain your eyes, then ULMB is not going to be for you.
C) GSYNC is incompatible with ULMB in it's current incarnation. Each pulse of the LED is at a set current level, controlled by the brightness setting. The duration of each pulse is constant (1.8ms). This means that the brightness of the screen would go down with framerate, and with gsync, would be jumping all over the place. If nvidia wanted to get really fancy, they could pulse the LEDs harder during lower framerate scenarios to obtain constant perceived brightness, but that would require that the LEDs could handle it. I suspect not, so the solution was to disable ULMB under GSYNC mode or go to ~20% of the already-dim light output.
3)GSYNC mode: In a sentence: pretty frigging sweet. Here, the display is driven at a variable framerate to match what the gpu has finished rendering. The resulting video looks significantly smoother. To best explain, load up a game and configure it to run at ~40-50fps (assuming a 60Hz monitor). Now fly around the map and look at the movement of objects in front of each other. Even though your motion in the game is along a constant path, objects do not move smoothly, they judder around as if the camera was riding on a slightly bumpy road (the bumpy road analogy would be positional noise and not temporal, but if looking at a single object, the effect is pretty close). GSYNC paves this road. Motion is smoothed out. Having tearing removed is a nice benefit too .
For games running at framerates significantly higher than what the monitor can do, tears are generally pretty small and motion is smooth enough to make it hard to notice if running in gsync mode or not. For framerates around or under what the monitor can do is where gsync shines. The distracting nature of the jumpy motion is eliminated, so the downside of running at these speeds is primarily responsiveness and not fluidity. This can make some newer games (battlefield) significantly better
Overall, would I recommend the gsync kit? Not really. It is an overall expensive solution for something that is just a 24" 1080p tn panel, even though it can do some pretty cool stuff. Would I recommend gsync for your next monitor? Absolutely, variable refresh rate displays are awesome!
As a side note: I was unable to test my just-in-time rendering shim layer for some other reasons.
https://picasaweb.google.com/1129081983 ... 8580186674
https://picasaweb.google.com/1129081983 ... 6250361698
1) gsync does not work with windowed applications now
2) my hooks aren't implemented very well and break under resizing, including going to full-screen :/