[TechPowerUp article] FreeSync explained in more detail

[blastingcap]

http://www.techpowerup.com/196557/amd-responds-to-nvidia-g-sync-with-freesync.html

Mods, the OP of the last thread requested it to be locked, rather than mods locking it. If however you want to lock this thread too, go ahead, I just thought people would appreciate a different perspective on FreeSync than what was presented at http://www.anandtech.com/show/7641/amd-demonstrates-freesync-free-gsync-alternative-at-ces-2014

Edit to add: TechReport added even more info on this topic: http://techreport.com/news/25867/amd-could-counter-nvidia-g-sync-with-simpler-free-sync-tech?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+techreport%2Fall+%28The+Tech+Report%29

Edited again to add: NVidia responds to AMD's demo, validating my suspicions that if it were easy to do on desktop, AMD would have shown it on desktop monitors as well as laptops... apparently it is NOT trivial to do this on desktop monitors: http://techreport.com/news/25878/nvidia-responds-to-amd-free-sync-demo

 

[Stuka87]

Some good details in the TPU article. Notably the difference between each implementation.

 

[Paul98]

How often can VBLANK time change? When do you chose to change it, and if you sent a time that wasn't long enough and the frame isn't ready can you set another time that is shorter than monitor refresh rate?

I am wondering if there is a way around or a way to minimize changes that could really add smoothness.

 

[wand3r3r]

That article sounds pretty reasonable. So NV requires extra hardware, but gains an advantage when AMD is forced to try calculate how long to hold that frame for. To me it seems like in (crossfire) framepacing it could more accurately estimate the next frames time, but it still might be pretty hard and could be the hardest thing to do especially when the frametimes are see-sawing rapidly.

 

[96Firebird]

Seems like extrapolating the refresh rate will work best when the framerates are fairly constant, but I can't really imagine what it would look like otherwise.

Can't wait for some side-by-side comparisons with the different types of "sync" modes, ie. (no) Vsync, Adaptive Vsync, TB Vsync, G-sync, and FreeSync.

 

[MaestroQuark]

When framerates are fairly consistent, the need for variable refresh decreases. It's most apparent during framerates that are jumpy.

 

[jj109]

When framerates are fairly consistent, the need for variable refresh decreases. It's most apparent during framerates that are jumpy.

No, constant 45 fps at 60 Hz is bad, if not worse than average 45 fps at 60 Hz. With constant fps, it's going to result in a very predictable judder.

 

[Rvenger]

As long as this doesn't get out of hand I will keep this thread open. Please stay on topic and avoid attacking other members.


-Rvenger

 

[sushiwarrior]

That article sounds pretty reasonable. So NV requires extra hardware, but gains an advantage when AMD is forced to try calculate how long to hold that frame for. To me it seems like in (crossfire) framepacing it could more accurately estimate the next frames time, but it still might be pretty hard and could be the hardest thing to do especially when the frametimes are see-sawing rapidly.

Correct me if I'm wrong, but G-sync would also hold onto a frame, and therefore add an extra frame worth of delay in the pipeline? Might be an issue for competitive gamers.

 

[BallaTheFeared]

Correct me if I'm wrong, but G-sync would also hold onto a frame, and therefore add an extra frame worth of delay in the pipeline? Might be an issue for competitive gamers.

You would be wrong.

G-Sync will hold a frame on the monitor until a new one is presented to it by the GPU.

 

[blackened23]

Correct me if I'm wrong, but G-sync would also hold onto a frame, and therefore add an extra frame worth of delay in the pipeline? Might be an issue for competitive gamers.

Since you had mentioned a few weeks ago (in a post) that you are employed by or affiliated with AMD, many questions for you. Since you're right there in the thick of it at AMD, I assume you could give us answers.

First, I was just curious as to whether you had any insider information on what AMD plans to do in terms of getting panel makers on board for this. Since monitor firmware is not user replaceable, i'd assume some type of upgrade system would need to be in place for users to "upgrade" their firmware to variable vblank - or better yet, get monitor manufacturers on board to produce such panels. Panel manufacturers would have to of course write the firmware to support such. That would of course be the first step, and then perhaps users could have an upgrade system to RMA their panel for a newer firmware. Additionally, why was the implementation as presented tied to vsync? It seems to be that vsync introduces input lag. Actually it DOES introduce input lag. So are there any workarounds to avoid this with the freesync implementation being worked on?

I know you've thrown us inside information on Hawaii a few times, given your AMD affiliation and ability to gain inside info. So throw us a bone here. Does AMD have any concrete plans? Is AMD talking to monitor manufacturers about this? What AMD users don't want is an HD3D situation - "hey guys, here's our API , go forth and use it". HD3D is no longer supported, obviously. So i'm most curious about what steps AMD is taking to get this to market while avoiding that type of situation.

 

[Despoiler]

What I find promising is that because dynamic refresh is already supported in AMD hardware and drivers, a program like RaedonPro could expose it. It already can force triple buffering. Boom no waiting for AMD.

 

[sushiwarrior]

Since you had mentioned a few weeks ago (in a post) that you are employed by or affiliated with AMD, many questions for you. Since you're right there in the thick of it at AMD, I assume you could give us answers.

First, I was just curious as to whether you had any insider information on what AMD plans to do in terms of getting panel makers on board for this. Since monitor firmware is not user replaceable, i'd assume some type of upgrade system would need to be in place for users to "upgrade" their firmware to variable vblank - or better yet, get monitor manufacturers on board to produce such panels. Panel manufacturers would have to of course write the firmware to support such. That would of course be the first step, and then perhaps users could have an upgrade system to RMA their panel for a newer firmware. Additionally, why was the implementation as presented tied to vsync? It seems to be that vsync introduces input lag. Actually it DOES introduce input lag. So are there any workarounds to avoid this with the freesync implementation being worked on?

I know you've thrown us inside information on Hawaii a few times, given your AMD affiliation and ability to gain inside info. So throw us a bone here. Does AMD have any concrete plans? Is AMD talking to monitor manufacturers about this? What AMD users don't want is an HD3D situation - "hey guys, here's our API , go forth and use it". HD3D is no longer supported, obviously. So i'm most curious about what steps AMD is taking to get this to market while avoiding that type of situation.

AMD is a large company. I have never heard about "FreeSync" until now. And I wouldn't know any more regardless of if AMD is on board with it or not. Just not my area.

 

[blackened23]

AMD is a large company. I have never heard about "FreeSync" until now. And I wouldn't know any more regardless of if AMD is on board with it or not. Just not my area.

Oh, I see. Since you're clearly interested in G-sync's implementation and made a few comments on how G-sync is doing things, I thought you would be equally curious about how AMD was handling things, given your employment status. But like you said AMD is a large company. You don't get the same information as what other departments get. Understandable.

I'm sure that if you're a PC gamer that you're excited about these new technologies. I sure am. Personally if I had any type of affiliation with nvidia or AMD I would be asking anyone and everyone what's up with it. Because it's an exciting technology for an actual PC gamer like myself. Sadly i'm not affiliated or employed by either. So no dice there. But if I were employed by either company you better believe i'd ask around. I'd be the annoying guy digging for information. Bugging engineers. That sort of thing. That's just me though. I'm pretty stoked for this.

Oh well. It sounds like you're really interested in it since you've read up quite a bit on G-sync. If you find anything out about free-sync, let us know. Just thought i'd ask, I was thinking you'd have something. Thank you for entertaining the question in any case.

 

[Arkadrel]

I'd be the annoying guy digging for information. Bugging engineers.

You and me both. Would be fun knowing what the early stuff thats like 4-5 years away looks like so far. Even without the tech demos ect, just the concepts and stuff.

@Sushiwarrior

You should try pokeing around for stuff on FreeSync Give us all the goodies on it.

 

[sontin]

When framerates are fairly consistent, the need for variable refresh decreases. It's most apparent during framerates that are jumpy.

You need to synchronize the refreshrate with the frames and use V-Sync to stay in sync with the display.

That's the reason why G-Sync and Freesync are like day and nicht. G-Sync makes the display a slave to the gpu and allows it only to refresh when a new frame is ready.
Freesync changes the current refresh rate through VBLANK but it's still not synchronize with the display. For that you need V-Sync. And it's only working when you now the time between the frames.

You can do this even today with any card. Create a custom resolution with a certain Hz and use it in games. No need for DP or VESA standards.

 

[Abwx]

You need to synchronize the refreshrate with the frames and use V-Sync to stay in sync with the display.

That's the reason why G-Sync and Freesync are like day and nicht. G-Sync makes the display a slave to the gpu and allows it only to refresh when a new frame is ready.
Freesync changes the current refresh rate through VBLANK but it's still not synchronize with the display. For that you need V-Sync. And it's only working when you now the time between the frames.

You can do this even today with any card. Create a custom resolution with a certain Hz and use it in games. No need for DP or VESA standards.

Ask the knowledgeable...

http://www.hardware.fr/news/13517/ces-amd-freesync-g-sync-gratuit.html

 

[sontin]

nVidia supports and uses VBLANK for G-Sync. In the Techreport article the AMD rep said he doesn't know what nVidia is acutally doing with G-Sync. They even compared it to "triple buffering". I dont know if this was on purpose to make it sound bad or because they are really in the dark.

 

[dacostafilipe]

That article sounds pretty reasonable. So NV requires extra hardware, but gains an advantage when AMD is forced to try calculate how long to hold that frame for. To me it seems like in (crossfire) framepacing it could more accurately estimate the next frames time, but it still might be pretty hard and could be the hardest thing to do especially when the frametimes are see-sawing rapidly.

nVidia has to do the same, but it uses the controller to do so. G-Sync uses VBLANK to delay the draw. But you don't know how long the next draw will take, so you try to guess. If VBLANK is finished but your frame is not, you use "old" frame as placeholder.

G-Sync and FreeSync are kinda close in the way they work, it's just an other implementation.

 

[96Firebird]

If VBLANK is finished but your frame is not, you use "old" frame as placeholder.

Are you sure about this? Why not just hold the frame for an indefinite amount of time (assuming above min. refresh rate) until the new frame is sent? That is the benefit of having the GPU in control and the display be the slave. The display doesn't have to change anything until the next frame is ready.

 

[dacostafilipe]

Are you sure about this? Why not just hold the frame for an indefinite amount of time (assuming above min. refresh rate) until the new frame is sent? That is the benefit of having the GPU in control and the display be the slave. The display doesn't have to change anything until the next frame is ready.

I've posted on the other thread, but here again:

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.

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

G-Sync is not a LCD Controller, it does not drive the LCD matrix directly, it's in between the LCD logic and the GPU. That's way nVidia has to use VBLANK in the first place, because they are limited to what the LCD logic can do. The G-Sync controller is just a buffer with logic. Nothing that can't be done in software.

 

[sontin]

nVidia has to do the same, but it uses the controller to do so. G-Sync uses VBLANK to delay the draw. But you don't know how long the next draw will take, so you try to guess. If VBLANK is finished but your frame is not, you use "old" frame as placeholder.

G-Sync knows excatly how long it takes. As long as the next frame doesn't need more than 33,3ms the G-Sync module will prevent the display from refreshing. There is no refresh rate for G-Sync monitor until you hit the maximum Hz.
And if it takes longer than 33,3ms the G-Sync module will send the current frame again.

 

[Abwx]

That article sounds pretty reasonable. So NV requires extra hardware, but gains an advantage when AMD is forced to try calculate how long to hold that frame for. To me it seems like in (crossfire) framepacing it could more accurately estimate the next frames time, but it still might be pretty hard and could be the hardest thing to do especially when the frametimes are see-sawing rapidly.

Actualy with Freesync the GPU display engine has several
possibilities including interpolation , other than that VBLANK
period can be of variable length..

 

[dacostafilipe]

G-Sync knows excatly how long it takes.

Okay, and how does G-Sync know this?

 

[96Firebird]

I've posted on the other thread, but here again:


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

G-Sync is not a LCD Controller, it does not drive the LCD matrix directly, it's in between the LCD logic and the GPU. That's way nVidia has to use VBLANK in the first place, because they are limited to what the LCD logic can do. The G-Sync controller is just a buffer with logic. Nothing that can't be done in software.

I get that, what I meant by min. refresh rate was 30Hz. I wouldn't try to run any games below that anyways, so that is a moot point to me.

Just seems to me that Gsync is a more elegant solution than extrapolating and guessing what refresh rate the monitor should be.