[TechPowerUp article] FreeSync explained in more detail

[BallaTheFeared]

It's obviously a joint effort by the Axis of Evil (Intel/Nvidia) to attack AMD and their righteous non profit business model.

 

[VulgarDisplay]

Is it different though? I'm trying to think of things that AMD didn't deliver on. Such as. DX9/CF and eyefinity/CF Frame pacing fixes on 79xx and earlier cards, that was supposed to be fixed in 2012. Oh but wait. We'll fix it in 2013. Then it was Jan 2014. AMD seemed to tell us originally that they would deliver a frame pacing fix for CF DX 9 and CF eyefinity on Tahiti and older cards in 2012. Lemme look at my calendar again. Seems to say 2014. I could be wrong though. Someone add the number of months up here that eyefinity CF was broken all Tahiti and earlier cards.

Let's see what else. Did AMD possibly deliver on HD3D? Well there's the fact that they abandoned it. After they pitched it as a free API for developers. (sound familiar? Free and open standards anyone? Did I hear that during the free-sync press tech thingy? Someone remind me). Oh yeah. Free and open standards with HD3D. Open to all developers. But now , you gotta pay tri-def for HD3D. AMD doesn't provide the gaming driver, and doesn't support it. Whoops.

I dunno bro. Some would argue that there's no possible way AMD could deliver on free-sync based on their prior history of....never delivering. Definitely not in 2014. There's always faith and hope though while playing the AMD waiting game. Like, I have faith and hope in keys' GPU being released in Q4.

This has less than nothing to do with what we are talking about.

Also did amd ever publicly put any release dates on the stuff you brought up?

 

[SirPauly]

Is it different though? I'm trying to think of things that AMD didn't deliver on. Such as. DX9/CF and eyefinity/CF Frame pacing fixes on 79xx and earlier cards, that was supposed to be fixed in 2012. Oh but wait. We'll fix it in 2013. Then it was Jan 2014. AMD seemed to tell us originally that they would deliver a frame pacing fix for CF DX 9 and CF eyefinity on Tahiti and older cards in 2012. Lemme look at my calendar again. Seems to say 2014. I could be wrong though. Someone add the number of months up here that eyefinity CF was broken all Tahiti and earlier cards.

Let's see what else. Did AMD possibly deliver on HD3D? Well there's the fact that they abandoned it. After they pitched it as a free API for developers. (sound familiar? Free and open standards anyone? Did I hear that during the free-sync press tech thingy? Someone remind me). Oh yeah. Free and open standards with HD3D. Open to all developers. But now , you gotta pay tri-def for HD3D. AMD doesn't provide the gaming driver, and doesn't support it. Whoops.

I dunno bro. Some would argue that there's no possible way AMD could deliver on free-sync based on their prior history of....never delivering. Definitely not in 2014. There's always faith and hope though while playing the AMD waiting game. Like, I have faith and hope in keys' GPU being released in Q4.

One doesn't have to pay for native Hd3d support and always had to pay for third party solutions like Tri-def and IZ3d!

 

[Kronvict]

It's obviously a joint effort by the Axis of Evil (Intel/Nvidia) to attack AMD and their righteous non profit business model.

HAHAHA this really had me rolling. It really does seem like some people see things that way.

 

[dacostafilipe]

Nvidia's system also releases an existing refresh to start a new one.

So, they just stop the VBLANK? Or how are they starting a "new refresh" ? I'm just asking, because I did not find anything explaining this.

Maybe I did not have all the details ...

 

[Mand]

So, they just stop the VBLANK? Or how are they starting a "new refresh" ? I'm just asking, because I did not find anything explaining this.

Maybe I did not have all the details ...

http://www.anandtech.com/show/7582/nvidia-gsync-review

G-Sync works by manipulating the display’s VBLANK (vertical blanking interval). VBLANK is the period of time between the display rasterizing the last line of the current frame and drawing the first line of the next frame. It’s called an interval because during this period of time no screen updates happen, the display remains static displaying the current frame before drawing the next one. VBLANK is a remnant of the CRT days where it was necessary to give the CRTs time to begin scanning at the top of the display once again. The interval remains today in LCD flat panels, although it’s technically unnecessary. The G-Sync module inside the display modifies VBLANK to cause the display to hold the present frame until the GPU is ready to deliver a new one.

With a G-Sync enabled display, when the monitor is done drawing the current frame it waits until the GPU has another one ready for display before starting the next draw process. The delay is controlled purely by playing with the VBLANK interval.


You can only do so much with VBLANK manipulation though. In present implementations the longest NVIDIA can hold a single frame is 33.3ms (30Hz). If the next frame isn’t ready by then, the G-Sync module will tell the display to redraw the last frame.

So, yes. If you hold VBLANK, then the image on the screen just doesn't update. The pixels are still the same color they were told to be the last time the scan passed over them, and they'll stay that way until and unless a new scan comes along to tell them to do something else.

And no, it will not interrupt a scan with a new scan. If the GPU is rendering frames faster than the display can refresh (say, 80 FPS on a 60 Hz display), then G-Sync just does what VSync does. The difference is that while VSync works great when your GPU is reliably above your display's refresh rate, if you ever drop below it - even slightly - then you have huge lag periods due to the "missed" start of the frame. G-Sync doesn't do that. If the GPU is updating faster than the display can refresh, then the GPU waits for the display (what VSync tells it to do). If the GPU is updating slower than the display can refresh, then G-Sync tells the display not to refresh until the GPU is done rendering the frame.

The core awesomeness of G-Sync, though, is that it switches between the two on a per frame basis, so you have the best of all worlds and the drawbacks of none. You get the lack of tearing that VSync provides, but without the stutter and lag that it also provides when you're below your monitor's refresh rate.

As someone who hates screen tearing enough so that I turn VSync on all the time, in every game, regardless of performance, I can't wait for G-Sync to come and alleviate the pain of stutter and lag that I've had to put up with because I hate tearing even more.

 

[dacostafilipe]

http://www.anandtech.com/show/7582/nvidia-gsync-review

So, yes. If you hold VBLANK, then the image on the screen just doesn't update. The pixels are still the same color they were told to be the last time the scan passed over them, and they'll stay that way until and unless a new scan comes along to tell them to do something else.

You quote does not explain my question, it does just explains what VBLANK is (by copy/pasting wikipedia btw).

G-Sync doesn't do that. If the GPU is updating faster than the display can refresh, then the GPU waits for the display (what VSync tells it to do). If the GPU is updating slower than the display can refresh, then G-Sync tells the display not to refresh until the GPU is done rendering the frame.

An how does G-Sync know how long the display should wait?

Edit: You edited your post after I read it, so I edited mine too

 

[Mand]

I didn't copy/paste wikipedia, I copy/pasted anandtech's review, and provided you the link where the quote came from. Because you asked for more information. If you really do want more information, it helps to not get snippy when people try to answer you.

I'm not clear why you would ever set VBLANK to 33ms. VBLANK, currently, is extremely short. Historically, it was the time it took to physically aim the electron gun of a CRT back from the bottom corner of the last frame to the top corner of the new frame. That was only ever very rapid. G-Sync works by extending VBLANK, not contracting it.

The GPU polls the G-Sync module to check if it's in VBLANK only because it wants to not start scanning the new frame if the display is not in VBLANK. This happens if the GPU is going faster than the display refresh rate (e.g. 80 FPS on a 60 Hz display). Without polling for VBLANK, you would have tearing as the GPU would start spitting out the next frame before the display was finished. Both normal VSync and G-Sync tell the GPU to not do this. "Force refreshing" would do the same, cause tearing if the display isn't in VBLANK. The polling is only required because as G-Sync is set up, it has a thing that says "if GPU is ready, scan out and update display" that's required for the other side, where the GPU is rendering slower than the display refresh rate.

Nvidia themselves said the polling aspect isn't strictly required and they're working to eliminate it, but for now it's the solution. Which is actually in the article I linked, if you kept reading.

 

[dacostafilipe]

I didn't copy/paste wikipedia, I copy/pasted anandtech's review, and provided you the link where the quote came from. Because you asked for more information. If you really do want more information, it helps to not get snippy when people try to answer you.

Oh no, I was talking about the article, not you. Sorry if it was not clear :/

... "if GPU is ready, scan out and update display" ...

No, you can't interrupt VBLANK, you said it yourself.

Nvidia themselves said the polling aspect isn't strictly required and they're working to eliminate it, but for now it's the solution. Which is actually in the article I linked, if you kept reading.

I did read that article, and I also did post the part you are mentioning here in the thread.



What I'm trying to understand, it how does the G-Sync know how long the next VBLANK should be. I think they are predicting it (based on the last frames) but some people here said it's not the case. Then, please somebody explain to me how they do it.

 

[Mand]

It...doesn't know how long the next VBLANK should be. It also doesn't care. It holds VBLANK until the GPU is finished rendering, and when the GPU is finished rendering, then it sends out the frame along with the command to refresh the display. I'm not clear why you think there needs to be prediction. As long as the display is in VBLANK, the GPU can tell it, through the G-Sync module, to start a refresh scan. It's not adjusting a set value for VBLANK, it's dispensing the idea of a set value of VBLANK altogether by changing it for each individual frame based on how the GPU is doing. That's the key innovation in G-Sync - no longer is the display operating in a cyclical fashion at whatever rate is predetermined, it's refreshing each and every single frame as if it were just going to do it once and then stop.

It will hold and hold and hold VBLANK, waiting for the GPU to finish rendering the new frame, until it gets to the upper limit of 33.3ms, at which point it gives up and tells the display to scan with the previous frame. It only does this if your GPU is running at below 30 FPS, and for all intents and purposes G-Sync is not functional at this point, and it works just like if you were V-Syncing to 30 Hz, which is awful. Do not use G-Sync if your GPU is running below 30 FPS.

Then again, if your GPU is running below 30 FPS, you need to turn down some settings...

 

[dacostafilipe]

It will hold and hold and hold VBLANK, waiting for the GPU to finish rendering the new frame, until it gets to the upper limit of 33.3ms, at which point it gives up and tells the display to scan with the previous frame. It only does this if your GPU is running at below 30 FPS, and for all intents and purposes G-Sync is not functional at this point, and it works just like if you were V-Syncing to 30 Hz, which is awful. Do not use G-Sync if your GPU is running below 30 FPS.

VBLANK is an interval ( == time). You have to specify the time how long your VBLANK will run.

What you are saying is that you can interrupt the VBLANK?

 

[Mand]

That's the whole point of G-Sync, in that you don't need to specify how long VBLANK will run. It takes the VBLANK which starts off extremely short, extends it as needed, and then stops it when the GPU is done rendering the frame and then the display scans the new frame. That's largely why they need a custom control board to be able to do it, as yes, standard displays have VBLANK as just an interval that has to be set ahead of time, and not dynamically.

Here's some examples, with made up numbers for convenience:

Display refresh is 15ms. Game is relatively idle, and GPU only takes 10ms to render the frame. Instead of pushing out the new frame 2/3 through the display refresh, the GPU holds the frame until the display is done, instead of sending it out right away and causing a frame tear. It polls the display, and once it's done and it detects VBLANK, you have both conditions met: 1) display is in VBLANK and 2) GPU is ready with the next frame. Both are synchronized, and the frame is pushed to the display, and everyone is happy. No tearing, no stutter, minimal lag.

Display refresh is 15ms. Game hits a spot with a lot of stuff going on, and takes 20ms to render the frame. With V-Sync set to 15ms refreshes, the GPU goes "ah, crap, I missed it" once it hits 15ms, and waits for 30ms to send out the new frame. Which means the existing frame was there for 30ms, with 10ms of that defined as lag. With G-sync, the control board is checking both the GPU and the display. At 15ms, when the display hits VBLANK at the end of its cycle, the GPU isn't done yet so G-Sync holds the display in VBLANK, which leads to a static image. It does this for the next 5ms, while waiting for the GPU to finish. It doesn't know ahead of time how long the GPU is going to take, it just waits patiently until it's done. And at 20ms, the GPU is done, and with a valid G-Sync poll saying the display is in VBLANK, the frame is sent from the GPU to display and the display refreshes. No stutter, no tearing, minimal lag, just a 20ms interval between frames. Not ideal, sure, since you'd want 15ms, but your GPU can only do 20ms so you take what you can get. But what you get is a smooth transition at 20ms intervals, rather than some of the frame intervals you see being 15ms and some of them being 30ms, causing stutter and jumpiness and awful bad things.

 

[dacostafilipe]

...

What you say makes sense ... but I still have some problems with it.

It they can interrupt the VBLANK, then why have the memory on the controller? Why not just set VBLANK it to max time (min LCD frequency in this case == 33ms). Is it really only because of the below 30fps problem?

 

[Mand]

You're starting to hit the limit of my knowledge of how it works, unfortunately. All I've got is this, from the above article:

The G-Sync board itself features an FPGA and 768MB of DDR3 memory. NVIDIA claims the on-board DRAM isn’t much greater than what you’d typically find on a scaler inside a display. The added DRAM is partially necessary to allow for more bandwidth to memory (additional physical DRAM devices). NVIDIA uses the memory for a number of things, one of which is to store the previous frame so that it can be compared to the incoming frame for overdrive calculations.

Apparently, all current display scalers have memory on them. Didn't know that, but I suppose it makes sense. Frame information's got to be stored somewhere on the display, I suppose.

As far as setting VBLANK to max time, keep in mind that the vast bulk of the 16.67ms refresh interval on a 60 Hz display is the display itself actually refreshing, and only a miniscule portion of that is the VBLANK interval (technically, VBLANK could be zero, but apparently isn't for what seems to be pointless historical reasons).

I get the sense that it would be possible to do it the way you describe, and there may or may not be anything preventing it from working that way - it's just not the way Nvidia has described how it works.

 

[f1sherman]

What you say makes sense ... but I still have some problems with it.

It they can interrupt the VBLANK, then why have the memory on the controller? Why not just set VBLANK it to max time (min LCD frequency in this case == 33ms). Is it really only because of the below 30fps problem?

This might help

I have no idea why this has 768MB of memory. A 1440p frame is only 4Mpixel * 4 bytes (30bit) color = 16MBytes. They have enough memory for 48 frames? *Confused*


mdrejhon
OCT 22
12:24 PM
+-+5
xColor maintenance during variable-rate overdrive algorithms are hard:
-- 144Hz vs 120Hz vs 60Hz creates different colors/gamma!
-- Imagine fluctuating colors during variable refresh rates!
-- Imagine fluctuating overdrive problems during variable refresh rates!

To fix all of this, you need lots of ultrahighspeed processing memory. This sort of stuff needs multi-frame history (past refreshes) and complex algorithms to try and make the LCD pixels stay stable and at a known color during variable-rate refreshes, to make variable-refresh-rate look proper without side effects.

And since G-SYNC has an optional strobe mode, you've got the additional pandora's box of using Y-axis compensated overdrive algorithms required for strobe backlights, (this is obvious in motion tests, when doing motion at top/center/bottom edges of screen while using LightBoost; there's more ghosting along the bottom edge) due to different pixel freshnesses from top-to-bottom of screen by the time the whole screen is strobed at once. When viewing full-screen flicker tests on a LightBoost display, the "zones" of the different overdrive bands reveals themselves as sharp bands that contains different intensities of overdrive for different vertical region of the screen. This is a dead-giveaway for including the Y-axis on the screen to overdrive calculations. And a researcher in Europe found this out, too: http://display-corner.epfl.ch/index.php/LightBoost

 

[bystander36]

Interesting info. This sounds far more complex than I'm sure most of us thought.

 

[Lonbjerg]

Interesting info. This sounds far more complex than I'm sure most of us thought.

It's more complex than AMD would want people to think for sure ^^


Enough of the thread crapping. This adds no value to the discussion and baits others.

-Rvenger

 

[dacostafilipe]

An great article from hardware.fr that talks about FreeSync and G-Sync.

http://www.hardware.fr/news/13545/amd-freesync-proposition-dp-1-2a.html

Here de document somebody (AMD?) send to VESA for DP 1.2a

Summary
Extend the "MSA TIMING PARAMETER IGNORE" option to DisplayPort to enable source based control of the frame rate similar to embedded DisplayPort.

Intellectual property rights
N/A

Benefits as a result of changes
This enables the ability for external DisplayPort to take advantage of the option to ignore MSA timing parameter and have the sink slave to source timing to realize per frame dynamic refresh rate.

Assessment of the impact
The proposed change enable per frame dynamic refresh rate for single stream devices that expose dynamic refresh rate capability in EDID for DisplayPort interface. The source will be able to enable this with an SST interface or MST hub with physical ports. Logical MST port support of the feature is not included as part of this SCR. A generic framework to enable such feature for logical port is required that can accommodate other feature where stream related configuration is programmed in DPCD.

Analysis of the device software implication
SST device which support "MSA TIMING PARAMETER IGNORE" option will be able to expose the capability in EDID and DPCD to let source enable dynamic refresh rate.
Source driver would have to be updated to parse EDID and enable "MSA TIMING PARAMETER IGNORE" feature when source want the sink to be refreshed based on its update rate.

Analysis of the compliance test and interop implications
Currently this feature is tested as part of eDP CTS. New test would have to be added as part of DP LL CTS and EDID CTS.

Interesting part:

Although very brief, this demonstration highlighted an identical result then that of G-Sync, de cause being that the operation is exactly the same: from the maximum refresh rate of the screen and adjust the length of VBLANK (space between 2 images on the video signal) to force the screen to "wait" that the GPU offers a new image to display.

 

[Imouto]

Well, it was pretty clear from the start that Nvidia just tried to reinvent the wheel here.

 

[sontin]

So, AMD copied nVidia's idea and sent it to VESA?

Lol.

 

[Imouto]

So, AMD copied nVidia's idea and sent it to VESA?

Lol.

No, AMD asked VESA to extend to DP an already existing eDP capability.

 

[Skurge]

This is awesome news. If VESA does add it to display port and monitor makers adopt it. It should cost them much. Then you can have so many more options. IPS users will get the benefit and won't have to switch over. 4k support. I can't imagine why this would not excite anyone. Nvidia users benefit by not having to shell out 300 for a gsync kit. AMD users get the same benefit.

I think AMD can get this going. This is not the AMD of old. If you look at how they have turned around the last 24months. They have been executing very well. This is AMDs GPU division. They've delivered on their promises since RR took over. So I'm crossing fingers I can get a cheap, tear free, stutter free experience no matter the GPU or monitor.

 

[Noctifer616]

Nvidia users benefit by not having to shell out 300 for a gsync kit.

According to AMD the reason G-sync exists in the first place is because NVidia GPU's don't have the monitor sync tech integrated like AMD GPU's do.

If this is true, NVidia GPU's can't get Freesync, just G-sync.

But keep in mind, that's what AMD is thinking, I don't think there was any official word from NVidia weather they support the tech or not.

 

[BrightCandle]

I think the split between Gsync and Freesync is mostly about responsibility. In Nvidia's world they poll the display to confirm its ready for another frame, and the monitor itself is responsible for refreshing itself when it needs to. That is the vblank period on todays monitors is set at 30hz and once 33.3ms has been held the monitor self refreshes and the card can't send the signal.

In the case of Freesync without that capability the graphics card would have to do that. It would need to know that the monitors minimum refresh was something and resupply the image for a refresh at that threshold.

This is why I say DRRS and image repetition technology are the combination necessary, its not just about about dynamic refresh rate. This is also one of the reasons why the monitor needs enough memory to hold an entire frame of information (the other is presumably to calculate overdrive between two images).

 

[krumme]

Well, it was pretty clear from the start that Nvidia just tried to reinvent the wheel here.

lol. Yeaa, ofcource they wrap it in all kinds if marketing nonsense, but you have to give them credit for showing it is usefull the use the wheel.
Amd have been sitting on this tech for years and didnt use it, how stupid is that?

But G-synch is, in its current form, except for the few early adopters 2014, now dead for sure.