NVIDIA's G-Sync Is VSync Designed For LCDs (not CRTs)

Phopojijo writes "A monitor redraws itself top to bottom because of how the electron guns in CRT monitors used to operate. VSync was created to align the completed frames, computed by a videocard, to the start of each monitor draw; without it, midway through a monitor's draw process, a break (horizontal tear) would be visible on screen between the two time-slices of animation. Pixels on LCD monitors do not need to wait for above lines of pixels to be drawn, but they do. G-Sync is a technology from NVIDIA to make monitor refresh rates variable. The monitor will time its draws to whenever the GPU is finished rendering. A scene which requires 40ms to draw will have a smooth 'framerate' of 25FPS instead of trying to fit in some fraction of 60 FPS." NVIDIA also announced support for three 4k displays at the same time. That resolution would be 11520×2160.

Comments

In English

[girlintraining]

Okay, can someone who isn't wrapped up in market-speak tell us what the practical benefit is here? The fact is that graphic cards are still designed around the concept of a frame; the rendering pipeline is based on that. 'vsync' doesn't have any meaning anymore; LCD monitors just ignore it and bitblt the next frame directly to the display without any delay. So this "G-sync" sounds to me like just a way to throttle the pipeline of the graphics card so it delivers a consistent FPS... which is something we can do since DirectX9.

So what, then, is the tangible benefit realized? Because I smell marketing, not technology, in this PR.

Re:In English

[Reliable Windmill]

For starters it reduces memory contention because the display device doesn't have to read and send the display data over the wire 60 times a second, while rendering the next frame. Theoretically, if there's nothing happening on the screen, such as an idle desktop, the display device won't consume x*100 Mbyte of bandwidth just to show a still image on the screen.

Re:In English

[LazyBoot]

Vsync still tend to add noticeable input lag even in games today. And some games still have issues with tearing even on lcd screens. So I'm guessing this is what they are trying to fix.

Re:In English

[CastrTroy]

The only advantage I see is that you see the image as soon as possible after it's done rendering. If your graphics card is done rendering the scene, but you monitor just refreshed 1 ms before that, you're going to have to wait another .016 seconds (assuming 60 hz) to see that frame, because that's the next time the screen refreshes. If you can make the refresh of the monitor exactly match the rate at which frames are produced, there's minimal lag between the frame being rendered, and the frame being shown to the person playing the game.

Re:In English

[The MAZZTer]

No marketspeak here, but if you're not familiar with the technical details you might be a bit lost. First of all, in order to understand the solution, you need to identify the problem.

The problem is that, currently, refresh rates are STATIC. For example, if I set mine to 60Hz, the screen redraws at 60fps. If I keep vsync disabled to allow my gfx card to push out frames as fast as it can, my screen still only draws 60fps, and screen "tearing" can result as the screen redraws in the middle of the gfx card pushing out a new frame (so I see half-and-half of two frames).

As described, let's say my gfx card is pushing out 25fps. Currently the optimal strategy is to keep vsync off, even though this can result in screen "tearing", because with low fps bigger problem emerges even though screen "tearing" is fixed, with vsync on.

Every time my gfx card pushes out a frame, since vsync is on, it waits to ensure it will not be drawing to the screen buffer while the screen is updating. Since it waits, the screen only draws complete frames. So at 60fps the screen updates in 1/60 second intervals, and the gfx card render at 1/25 second intervals. So, at the beginning of a frame render, the gfx card renders... and the screen redraws twice, and then the gfx card has to wait for the third opportunity to draw before syncing up again. Since it is waiting instead of rendering, I am now rendering at 20fps (since I lose 2/3 refresh opportunities) instead of the optimal 25fps. If I disable vsync, I get tearing, but now 25fps.

This "G-sync" claims to solve that issue by making refresh rates DYNAMIC. So if my gfx card renderas at 25fps, the screen will refresh at that rate. It will be synchronized. No tearing or gfx card waiting to draw.

Re:In English

[ultrasawblade]

Images where there's a low difference of changes can operate at a much higher framerate.

I think this opens up interesting possibilities.

Of course I think the physical response time of the display will be a bottleneck, capping the rate at a maximum below what the GPU can pump out.

Also it can save power. If the GPU is creating frames lower than 60hz then that's less power it needs to spend to do it.

Re:In English

[jones_supa]

LCD monitors absolutely do not ignore VSync. Now let's not forget that the primary function of a VSync signal is to tell the monitor (CRT or LCD) where the start of the picture begins. There's also HSync to break the picture into scanlines. VSync always takes a certain amount of time which the monitor will "take a breath" (CRT will also move the gun back to top). At this time, it is the perfect moment for the GPU to quickly swap its framebuffers in the video memory. The "scratch" draw buffer will be moved as the final output image and then the GPU can begin drawing the next one in the background. At the same time the completed image is sent to the monitor in the normal picture signal when the monitor gets back to work to draw a frame. If the buffers are swapped in the process of the monitor drawing the frame, the halves of two frames will get shown together which leads to the video artifact called "tearing".

If we are a good citizen and swap buffers only during the VSync period we can get a nice tear-free (typically 60fps) image. However if instead it takes more than the time of one picture (which about 16ms) to draw the next one, we have to wait a long time for the next VSync and that means that we also slide all the way down to a 30fps frame rate. Now if the game runs fast at some moments but slower at some others, the bouncing back between 60fps and 30fps (or even 15fps) makes this annoying jerky effect. NVIDIA's G-Sync tries to solve this problem by making the frame time dynamic.

Re:In English

[AvitarX]

I think worse than 20 FPS even, some frames will last longer than others, causing jerky motion. it won't be a smooth 20 FPS, it will be 20ish, but some frames lasting extra draws vs others.

Re:In English

[Nemyst]

Actually, it's the reverse. Instead of forcing the GPU to wait for the screen's refresh rate (as is the case with V-sync), potentially causing some pretty bad frame drops, G-sync makes the monitor wait for the GPU's frames. Whenever the GPU outputs a frame, the monitor refreshes with that frame. If a frame takes longer, the screen keeps the old frame shown in the meantime.

Remember, V-sync forces the GPU to wait for the full frame's duration, regardless of how long it's taken to render the frame. If the GPU renders the frame in 3ms but V-sync is at 10ms per frame, the GPU waits around for 7ms. Flip side, if the GPU takes 11ms, it's "missed" a frame (lag) and still has to wait 9ms until it can start drawing the next frame. G-sync is supposed to make it so as soon as the GPU's done rendering a frame, it pushes it to the monitor, and as soon as the monitor can refresh the display to show that new image, it will.

In theory, this could effectively give the visual quality of V-sync (no screen tearing) with a speed similar to straight rendering without V-sync.

Re:In English

[dow]

Indeed. I have a 144hz screen, and I noticed as soon as I went from 60hz to 144hz that even when the frame rate was below 60fps, it was still smoother than before. It was obvious that it would be smoother when getting over 60fps, but this surprised me. Thinking about it I came to the same conclusion.

I have also been wondering what would the picture be like if using a high refresh rate when the graphics card cannot render enough frames for one every refresh, what if it only rendered half the pixels every update. Not like an old interlaced picture, but rendered half the odd numbered pixels on one line and half the even number on the next line. Would it look blurred or odd? Would the way the eye works adapt to this better than rendering full screens at half the framerate?

I was also wondering whether such a display method would be useful for pre-rendered low frame rate applications such as video playback? (This is where a +1 informative comment says 'Yes, they've been doing it for years already...' heh)

Re:In English

[ericloewe]

That's not quite the angle they're going for, but there are such solutions, involving a special "no refresh" signal (I assume) and an LCD controller with a framebuffer that is used to refresh the panel if there is no change, allowing the GPU to be idled.

Re:In English

[Guspaz]

G-Sync enforces a 30Hz minimum refresh rate (the monitor will never wait longer than 33ms to refresh, or in the 144Hz demo monitors, it will never wait less than 7ms), so your example wouldn't work, but apart from that, yeah :)

Re:In English

[Lucky75]

Yup, it's called Panel Self Refresh (PSR)

http://www.anandtech.com/show/7208/understanding-panel-self-refresh

Re:In English

[Anonymous Coward]

Well I don't want to be "that guy", but I am "that guy". The real reason for vsync in the days of CRTs is to give time for the energy in the vertical deflection coils to swap around. There is a tremendous amount of apparent power (current out of phase with voltage) circulating in a CRT's deflection coils.

Simply "shorting out" that power results in tremendous waste. They used to do it that way early on, they quickly went to dumping that current into a capacitor so they could dump it right back into the coil on the next cycle. That takes time.

An electron beam has little mass and can easily be put anywhere at all very quickly on the face of a CRT. It's just that the magnetic deflection used in TVs is optimized for sweeping at one rate one way. On CRT oscilloscopes they used electrostatic deflection and you could, in theory, have the electron beam sweep as fast "up" as "left to right".

So why didn't they use electrostatic deflection in TVs? The forces generated by an electrostatic deflection system are much smaller than a magnetic system, you'd need a CRT a few feet deep to get the same size picture.

Ta dah! The wonders of autism!

Re:In English

[VortexCortex]

So, it's 1970's era Double Buffering?

Re:In English

[Chemisor]

Currently the optimal strategy is to keep vsync off, even though this can result in screen "tearing"

No, the optimal strategy is to keep vsync on and throttle your redraws exactly to it. To make it work you must set up an event loop and a phase-lock timer (because just calling glFinish to wait for vsync will keep you in a pointless busywait all the time). Unfortunately, game programmers these days are often too lazy to do this and simply ignore vsync altogether. While this may result in smoother animation, it also heats up my very expensive video card, shortening its life for no reason. Thankfully, there are tools on Windows (but sadly, not on Linux) to force vsync on any such insensitive games, at which point the video card cools down to 40 degrees or so, illustrating just how much power they are wasting.

Re:In English

[Hsien-Ko]

It seems strange that they didn't call it nSync....

Re:Basic math

[Tuidjy]

11520 = 3 x 3840

If _you_ had read the damn article, you would have noticed that the resolution is for THREE 4K monitors, side to side.

I'm not saying it's a graceful turn of phrase, or particularly clear, but most people would have been able to tell where he got it from...

Finally

[Reliable Windmill]

Now we just wait until they finally figure out to employ a smarter protocol than sending the whole frame buffer over the wire when only a tiny part of the screen has changed. It would do wonders for APUs and other systems with shared memory.

Re:Finally

[CastrTroy]

On one hand, I see where this could be a good idea. On the other hand, I kind of like dumb displays. Stuff like displays and speakers should really just display/play the signal sent to them. They should be as simple as possible, because they are expensive, and this allows them to last for longer and be cheaper. If TVs were smart, I would probably have to upgrade my TV every time they came up with a new video encoding standard. Luckily, TVs just understand a raw signal, and I can much more easily upgrade my computer to interpret the encoded videos than I can upgrade my TV.

Re:Makes no sense.

[Richy_T]

According to TFA, that's exactly what you'll be seeing.

This technology will be available soon on Kepler-based GeForce graphics cards but will require a monitor with support for G-Sync; not just any display will work. The first launch monitor is a variation on the very popular 144 Hz ASUS VG248QE 1920x1080 display

Re:Carmack on VR Latency

[Rockoon]

Well there goes the power savings...

So why are you considering doing this again?

The fact is that the bandwidth between video card and monitor must be enough to handle the worst case scenario or else its not fit for purpose, and the hardware cost difference between fully utilizing this link and greatly under utilizing this link is very very small. There are power savings if you can under-utilize the link without sacrifice, but...

Meanwhile there are large up-front costs associated with performing real-time video compression techniques, and the needed computation itself also uses a lot of power. So there would be large power costs in actually successfully under-utilizing the link using video compression techniques.

So no, not really a smart idea. The reason nVidia (who I am currently not a fan of) is proposing this g-sync idea is because currently the full technical capabilities of lcd hardware arent being exploited because of old the paradigms of a frame buffers being sent at constant fixed intervals. It would be very low cost to add logic to lcd displaces to sit and wait for new frames rather than what they currently do.

Its win-win-win because....
o) the video card would only have to transmit new frames, rather than constantly transmit frames even when they havent changed.
o) The lcd can spring into action updating pixels as soon as the video card has a new frame ready, rather than at fixed intervals.
o) In low frame-rate situations, there are power savings on the link, in the video card, and in the monitor (although the monitors power savings would be very minor as the back-light uses 99% of the power already)

I imagine this sort of thing would be adopted in laptops long before desktops.

Re:Why does 25fps on a computer game seem slow?

[jandrese]

Because you have been trained by films for your entire life to think that blurry stuttery 24fps is smooth and cinematic. If you ever watch a movie where lots of action is happening on the screen at once, you'll probably get slightly lost because everything turns into an unrecognisable blur. For an example of this, watch any of the Michael Bay transformers movies and try to figure out which Transformer is on the scene during any random action shot.

Unfortunately upgrading to 60fps actually causes people to complain, because the action becomes so smooth that it feels cheap, like it was recorded on a camcorder. Yes this is retarded, but it's the truth.

Re:Why does 25fps on a computer game seem slow?

[Miamicanes]

Actually, the problem is even bigger. Somewhere around 200fps, you start flying into "uncanny valley" territory. 200fps is faster than your foveal cones can sense motion, but it's still less than half the framerate at which your peripheral rod can discern motion involving high-contrast content. When it comes to frame-based video, Nyquist makes a HUGE mess thanks to all the higher-order information conveyed by things like motion-blur. That's why so many people think 24fps somehow looks "natural", but 120fps looks "fake". Motion-blurred 24fps video has higher-order artifacts that can be discerned by BOTH the rods AND cones equally. It's "fake", but at least it's "consistent". 120fps video looks flawless and smooth to the cones in your fovea, but still has motion artifacts as far as your peripheral rods are concerned. Your brain notices, and screams, "Fake!"