AMD demonstrates Freesync, G-sync equivalent?

Yeah that's what I meant, support it in drivers. I wouldn't rule it out, it may mean a loss on Gsync R&D but adaptive vsync is a huge selling point and if it's going to be available to AMD users at a much lower cost then that might cost NV sales which may make the loss on Gsync R&D worth it.

Remember that they went "cheaper" route to begin with, using FPGA instead of ASIC, and didn't some NVIDIA G(-Sync)-man say that "everything required for technology like G-Sync is already in the display standards", probably meaning that it really just uses what eDP allowed to begin with and used the FPGA to make it reality on external displays?
 
So the nv hardware is really just a displayport add on for non dp monitors ?

Actually it looks like it's using LVDS, not eDP (Anand)
But I don't see it doing anything big magic there, only way I can figure it out it replacing the displays built-in scaler which doesn't support variable VBLANK with the FPGA that provides that function (but no scaling)
 
About the refresh rate ranges : (“Potential ranges include 36-240Hz, 21-144Hz, 17-120Hz and 9-60Hz")

Some IPS monitors support real 72Hz (1920x1080, single-link DVI I think)
so one that works on 11-72Hz would be damn interesting. More would be better for sure, but it's a good compromise if we still need low refresh rate panels for cheapness, high availability and/or non-TN.
 
My panel supports 75hz according to ccc cant seem to select it though (maybe dsub only ?)

CCC under the propriety of the flat panel, report the max refresh rate and max resolution, but not linked together.

If your monitor is not rated for 75hz at his native resolution, it can support 75hz at a lower resolution, hence why the max reported is 75hz...

Many 60hz 2560x1440 support 75hz at 1280x720 .. but only 60hz at 2560x1440 .. This said you can still try CRU and create an new profile of resolution / refresh rate ( including overclock it if your panel is capable of it ).
 
Last edited by a moderator:
Most LCD support 60-75Hz, at least on VGA input but they simply drop frames so they still display 60Hz in the end. I guess it was historically useful (plug a monitor on an old PC whose software configuration beams 70 or 75Hz output so that the user wouldn't burn their eyes on a CRT. And VGA 80x25 text mode runs at 70Hz)

I remember reports of an IPS one reliably doing real 72Hz though, semi-advertised. To get it running you fiddle with the timings, with the abilities of Powerstrip, or modelines in linux, or some driver tool or other which can do this.
It's known as "overclocking" the monitor, that term is very colloquial of course, and it works on various monitors, on DVI at least. I'm sure many other monitors won't be pleased.
 
Most LCD support 60-75Hz, at least on VGA input but they simply drop frames so they still display 60Hz in the end. I guess it was historically useful (plug a monitor on an old PC whose software configuration beams 70 or 75Hz output so that the user wouldn't burn their eyes on a CRT. And VGA 80x25 text mode runs at 70Hz)

I remember reports of an IPS one reliably doing real 72Hz though, semi-advertised. To get it running you fiddle with the timings, with the abilities of Powerstrip, or modelines in linux, or some driver tool or other which can do this.
It's known as "overclocking" the monitor, that term is very colloquial of course, and it works on various monitors, on DVI at least. I'm sure many other monitors won't be pleased.

Using CRU, My PLS panel list 72hz under some resolution available, same for 70 and 75hz.. but only under low resolution ( lower of 1280x1024 ).. ( note that i have patched the AMD driver with the tools who allow to use higher resolution of the native one .. ( needed too for overclocking the panel ).
Ofc its completely useless to use 75hz if i need to use a resolution of 1280x1080 instead of 2560x1440p.
 
Last edited by a moderator:
Project FreeSync uses DisplayPort Adaptive-Sync protocols to pre-negotiate supported min/max refresh rates during plug’n’play, which means frame presentation to the user will never be delayed or impaired by time-consuming two-way handshakes.
Isn't that the same theory RecessionCone presented? or am I understanding it wrong?

And we pretty much confirmed GCN1.1 as the only capable hardware for gaming with free-sync.

but Project FreeSync will accomplish its goals with open industry standards that don’t require any licensing fees or contracts from participating parties. History has more or less proven that this strategy enables technologies to proliferate faster and cost less .. no licensing fees for adoption, no expensive or proprietary hardware
Isn't this a double standard logic considering the work with Mantle?
 
That's pointing out that that during display initialization the driver can become aware of all available refresh rates.
 
Isn't this a double standard logic considering the work with Mantle?

We badly needed someone to do something about the sorry state of 3D Gfx API in 2013...
MS seemed to be too busy promoting its console business, nVidia likes to add OpenGL extensions... Didn't leave much choice.
OpenGL ES is trying to get a revolution through, dunno whether it will happen.
 
Still don't understand why we can't get a driver to do it on existing multisync LCDs (and tmds interfaces).
 
Still don't understand why we can't get a driver to do it on existing multisync LCDs (and tmds interfaces).
If AMD were able to do that they would have, it would have instantly sunk G-sync; Instead we have to wait 1 year+.
 
Are there any existing multisync LCDs, most of them seem fixed at 60hz
Well there's the ever popular 1440p catleap&co. Most of the 29" ultrawide monitors are multisync (although they won't reach the refresh rates of the 1440p's)
 
1440p is a resolution not a refresh
although there are 3d monitors 120hz/144hz but freesync would need to refresh to sub 60hz mostly
 
Back
Top