AMD Fires Back at G-Sync With Non-Proprietary Alternative

[rdc85]

I'm wondering since my monitor has DP (display port) that i read is a VESA standart, Does this means my monitor (will be) able to make this "Freesync" work ?Can we generalize all the monitor with DP will able to use it?

edit: On other thought, to little information in this will just sit back, then wait and see...

 

[Mousemonkey]

I'm wondering since my monitor has DP (display port) that i read is a VESA standart, Does this means my monitor (will be) able to make this "Freesync" work ?Can we generalize all the monitor with DP will able to use it?

From what little I've seen I don't think it's going to be as simple as that.

 

[rdc85]

Yeah, it's puzzling

if it can be used just by firmware/driver update or it needs a new circuit that came along with new standard or it's already in there but they just don't brother to look/use or thinking this "other use" before.......

Again to little info to much Hype (IMO)...

 

[Jaroslav Jandek]

The difference between G-Sync and FreeSync is that G-Sync is the complete solution (and we know it works well). FreeSync will still need a VRR ASIC (very much like the G-Sync board) inside the display.

The Vertical Blanking Interval (AKA VBLANK) is a very old standard that was used for CRT monitors to allow some time for the electron beam to change position from rendering the last frame's last line to the new frame's first line - similarly to a printer's printing head.

I guess you all know about the evil V-Sync? It synchronizes output to VBLANK, which is set to a constant value (eg. 60 fps). That's where we get stuttering and input lag.

FreeSync also uses VBLANK which is set to a dynamic value. I suspect it is a variation of Adaptive V-Sync. If it is, it will only solve stutter but NOT input lag! More info is therefore needed to evaluate it properly.

 

[Djentleman]

FreeSync also uses VBLANK which is set to a dynamic value. I suspect it is a variation of Adaptive V-Sync. If it is, it will only solve stutter but NOT input lag! More info is therefore needed to evaluate it properly.

Good point.
Vblank removes a frame right? Causing the input lag.
Correct me if i'm wrong.

 

[Jaroslav Jandek]

Vblank removes a frame right? Causing the input lag.

It is actually implementation-specific (game engines and their configurations).

A typical game engine loop looks like this (simplified):

while(true) {
  Update();
  Draw();
  Present();   }

The Update method retrieves user input and calculates World, View and Projection matrices (your position and direction).
After that the Draw method draws the actual frame using the above mentioned matrices.
When the Draw is finished, it is time to Present the frame to the display - usually using a Swap Chain. The Swap Chain can be configured to wait for VSYNC using the D3D device presentation interval property.

So, you have a 60 Hz (~16.7 ms) monitor but you can get 200 fps (5 ms) in game. In 5 ms, your PC can Update and Draw everything but with VSYNC enabled, it needs to wait additional 11.7 ms (16.7 - 5) each loop until it is visible on the display. In other words - you move your mouse and it will show after at least 11.7ms.
You can of course screw it more by bad programming skills and decisions of the developers (this is the most optimistic version). Some engines directly support dropping/skipping multiple frames (eg.: Unity3D).

 

[Djentleman]

Vblank removes a frame right? Causing the input lag.

It is actually implementation-specific (game engines and their configurations).

A typical game engine loop looks like this (simplified):

while(true) {
  Update();
  Draw();
  Present();   }

The Update method retrieves user input and calculates World, View and Projection matrices (your position and direction).
After that the Draw method draws the actual frame using the above mentioned matrices.
When the Draw is finished, it is time to Present the frame to the display - usually using a Swap Chain. The Swap Chain can be configured to wait for VSYNC using the D3D device presentation interval property.

So, you have a 60 Hz (~16.7 ms) monitor but you can get 200 fps (5 ms) in game. In 5 ms, your PC can Update and Draw everything but with VSYNC enabled, it needs to wait additional 11.7 ms (16.7 - 5) each loop until it is visible on the display. In other words - you move your mouse and it will show after at least 11.7ms.
You can of course screw it more by bad programming skills and decisions of the developers (this is the most optimistic version). Some engines directly support dropping/skipping multiple frames (eg.: Unity3D).

Awww.
But do those functions such as 'draw()' miss frames? It couldn't be perfect.
Edit: So freesync is used the same way as a game engine? Causing input lagg, considering it's not on a hardware level.

 

[Jaroslav Jandek]

Maybe I should have just said that input lag is caused by waiting (for VSYNC) and leave it at that. It is kind of hard to properly explain to non-programmers.
What we need to know is whether FreeSync can use variable refresh rate without any waiting - it is a power saving feature which makes me suspicious about its performance.

But do those functions such as 'draw()' miss frames? It couldn't be perfect.

Sure. If your real framerate drops below monitor's refresh rate (Update and Draw take too long) or if the game engine has a bad implementation of fixed time step, it can drop a frame.
What VSYNC actually does in that case is dropping to monitor's lower refresh rate. These drops in FPS can happen several times in a second. At 30 Hz, the maximum input lag you can get is 33.3 ms (which is quite significant) and, of course, you get stuttering.

Edit: So freesync is used the same way as a game engine? Causing input lagg, considering it's not on a hardware level.

FreeSync is on the API/Driver level. We need more data on how it works exactly. I was just speculating before (which I have indicated).

btw. in the last post, I was explaining input lag with VSYNC - if that was not clear, I apologize.