AMD Publishes More Open-Source FreeSync Code

[Mystro256]

I don't know about the most recent blobs, but have you checked the repositories of your distribution (or alternative ones)? I know that I could install fglrx (whatever it's called now, Crimson, Radeon Center, ati-drivers...) on Gentoo and also SuSE. Or maybe just try to install the blob? (Don't know if it still needs to recompile something for your kernel or if it already works on top of amdgpu (needs recent kernel, then).) I guess Ubuntu might just be the one "officially supported" and "guaranteed to run", but of course, don't take my thoughts here as a grant for success.

I'm using fedora, I tried just repackaging the files (see my github repo) but it doesn't seem to work (tested with kernel 4.7 with and without the dkms module installed), it just crashes xorg on boot. As for fglrx, I'm pretty sure it only supports up to the volcanic cards, i.e. prior to polaris. I've heard some arch users have had some success with AMDGPU Pro on their setups, but honestly mesa-git + latest kernel is probably your best bet for non-Ubuntu polaris use right now.

You could also compile the amd-staging-4.6 kernel though if you want the DAL code (currently trying to compile it right now with all the fedora patches popped in, I'll probably get it working in a few days if it doesn't give me too much of a hard time).

[juno]

\o/

But, wait...

Why exit freesync mode?
Why can't we have it enabled all the time?
I had the belief that it maybe would work on the desktop, too, on Linux. It could be a power saving feature for notebooks, lowering the refresh rate for static content, to something like ~20 Hz and only update faster when something is in motion (mouse, scrolling, video, e.g). And why does the app need to be 'freesync capable'?

[Evil Penguin]

I would also like to know the answer.

Probably changes in brightness between different refresh rates.
It's not so noticeable while gaming but I'm sure it is while browsing the web.

[M@yeulC]

Probably changes in brightness between different refresh rates.
It's not so noticeable while gaming but I'm sure it is while browsing the web.

I think the "app" in question can also be the compositor. But basically, the subsystem needs to be able to say to the driver "hey, I just finished rendering a frame". AT LEAST THAT'S HOW I see it. I would really like someone more knowledgeable to explain the basics. For example, is there a negotiation between the app and the driver at some point ("OK, let's do 23Hz") or is this automatically handled by the driver/link/receiver? Is there a fixed set of refresh rates available? (like 20,30,40,60,90 Hz and no in between), or is it just a matter of rendering a frame as soon as it is ready? (the later would be more useful, but probably needs to change the way displays communicate.

And most importantly, maybe: This code concerns the X window system. Will it be compatible with Wayland? (And XWayland, for that matter. Probably needs more protocol extensions).

[ssokolow]

or is it just a matter of rendering a frame as soon as it is ready? (the later would be more useful, but probably needs to change the way displays communicate.

That's the point of technologies like FreeSync, DisplayPort Adaptive Sync (the standard based on FreeSync like Vulkan was based on Mantle), and nVidia GSync and monitors do, indeed, need to be designed specifically for them. (FreeSync was first demonstrated by being built upon the Panel Self-Refresh feature specified in Embedded DisplayPort to allow mobile device GPUs to sleep while the user is reading a static image.)

That's also why these sorts of technologies are only offered over DisplayPort. DVI and HDMI are timing-based wire protocols while DisplayPort is a packet-based protocol. (DVI and HDMI enforce vsync-style synchronization by their very design. DisplayPort is sort of like FireWire for monitors, so timing can be flexible.)

The simplest way to think about FreeSync and friends is that it's like double-buffering except that the front buffer is in the monitor rather than the GPU.

[crowen]

I'm using fedora, I tried just repackaging the files (see my github repo) but it doesn't seem to work (tested with kernel 4.7 with and without the dkms module installed), it just crashes xorg on boot. As for fglrx, I'm pretty sure it only supports up to the volcanic cards, i.e. prior to polaris. I've heard some arch users have had some success with AMDGPU Pro on their setups, but honestly mesa-git + latest kernel is probably your best bet for non-Ubuntu polaris use right now.

You could also compile the amd-staging-4.6 kernel though if you want the DAL code (currently trying to compile it right now with all the fedora patches popped in, I'll probably get it working in a few days if it doesn't give me too much of a hard time).

I got something for you, since i am building llvm svn and mesa git on frequent basis:

https://copr.fedorainfracloud.org/coprs/che/llvm/

https://copr.fedorainfracloud.org/coprs/che/mesa/

NOTE: * Both require you to add the 64bit and the 32bit repos.
* Mesa is built with LTO.

WARNING: You use it on your own risk! Do not try to play with it unless you know on your own how to revert to the original state!

[LeJimster]

This is one of the reasons I'm waiting to upgrade my monitor and also why I would prefer to remain an AMD user. Freesync monitors are much cheaper then gsync. Im hoping that quantum dot or oled will make it's way to PCs too.

[Mystro256]

I got something for you, since i am building llvm svn and mesa git on frequent basis:

https://copr.fedorainfracloud.org/coprs/che/llvm/

https://copr.fedorainfracloud.org/coprs/che/mesa/

NOTE: * Both require you to add the 64bit and the 32bit repos.
* Mesa is built with LTO.

WARNING: You use it on your own risk! Do not try to play with it unless you know on your own how to revert to the original state!

Nice! Thanks, much appreciated

I'm actually a fedora dev

[mczak]

That's also why these sorts of technologies are only offered over DisplayPort. DVI and HDMI are timing-based wire protocols while DisplayPort is a packet-based protocol. (DVI and HDMI enforce vsync-style synchronization by their very design. DisplayPort is sort of like FireWire for monitors, so timing can be flexible.)

This isn't quite true any longer. FreeSync is nowadays indeed possible over HDMI, some monitors should be available which support that already.
What you said though about DVI/HDMI having fixed timing whereas DP is packet-based is true. Thus I'm not quite sure how FreeSync is done over HDMI - I suppose maybe you could just extend the vertical blanking interval and the TCON needs to be able to recognize this (so, you'd use for instance nominally an ordinary timing for 90Hz or whatever your upper limit is, but the vblank interval is allowed to be huge so that your actual refresh rate may go down to half or whatever the lower limit is) (I have no idea how it's actually done, that's just how I would do it quick and simple...).

[boltronics]

Can't wait until OpenGL 4.5 and Freesync drop. That (and various bug fixes) are all I want, since those are the only significant advantages Nvidia has over AMD right now.