AMDGPU-PRO 16.50 Rolls Out With GCN 1.0 Support, FreeSync

[bridgman]

Though having to enter this command every restart is kind of a pain in the rear.

Someone asked "why is it FreeSync 1.0 ?" - this might be part of the answer

[mokurai82]

Ok I spoke too soon. I did a fresh install of Mint 18 MATE 64 bit and get the following error after entering this command into the terminal:

xrandr --output DisplayPort-0 --set "freesync" 1
X Error of failed request: BadName (named color or font does not exist)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 11 (RRQueryOutputProperty)
Serial number of failed request: 43
Current serial number in output stream: 43

I also tried to add an option to usr/share/X11/xorg.conf.d/10-amdgpu-pro.conf - this is my current state of it. (I got the idea from TearFree option):

Section "OutputClass"
Identifier "amdgpu-pro"
MatchDriver "amdgpu"
Driver "amdgpu"
EndSection

Section "Files"
ModulePath "/opt/amdgpu-pro/lib/xorg/modules"
ModulePath "/usr/lib/xorg/modules"
EndSection

Section "Device"
Identifier "Card0"
Driver "amdgpu"
BusID "PCI:1:0:0"
Option "DRI3" "1"
Option "TearFree" "on"
Option "freesync" "on"
EndSection

Nothing worked. My monitor refresh rate is not changing in the monitors OSD menu, when testing with the Witcher 2 or Metro 2033 Redux on steam.
If you can help I'd really appreciate it.

[bridgman]

The "TearFree" option struck me as something that would be worth removing from the conf file (along with freesync)... that's just a guess though.

[Ardje]

So far what I think we are seeing is that full-die chips (eg 270X) are working well but harvest chips (eg 270) are having problems.

What exactly is the difference? I bought a 270 instead of a 270X especially for the wattage. The 270X seems newer though.

[bridgman]

What exactly is the difference? I bought a 270 instead of a 270X especially for the wattage. The 270X seems newer though.

Just that a full-die chip uses all the hardware blocks on the (at least all the blocks meant to be used at the same time) while a harvest chip has some of the blocks fused off, typically just CUs and associated texture logic but occasionally things like memory channels as well. This can both reduce power (and performance) and allow us to ship more products from a given number of wafers given the imperfect yields of typical fab processes.

The harvest configurations are chosen based on (a) what would be a good product positioning relative to the full-die part, and (b) what would be an expected number of CUs etc... to be defective. The driver needs to set the chip up a bit differently (we have logic on the die to handle fusing off blocks) and power is not consumed by the fused-off blocks, but otherwise they work exactly the same.

I'm only guessing so far that the issue is full-die vs harvest configs; that's just the best-fitting pattern from the test results we have so far.

[Kombatant]

Please also bear in mind that the driver was never meant to be the "support all GCN 1.0/SI" release, at least to my knowledge. The full extend of what hardware is supported is in the release notes, as always. Same goes for newer Kernels; don't forget that it's the Pro driver, hence it supports the stock kernel of the latest Ubuntu LTS release. That's always been the case thus far, and 16.50 was never going to be any different.

As for new features (like Freesync, for instance), we're working on ways to be more transparent and informative about what they are, how they work, how you can enable them (when it's not a matter of "always on") and if they have any limitations in their current implementations.

I also didn't realise I only have two posts in here after almost 10 years

[dungeon]

OK, found it:

Enable/Disable FreeSync:

To enable FreeSync, run the following command:

DISPLAY=:0 xrandr --output DisplayPort-# --set "freesync" 1 (the "DISPLAY=:0" part is normally not required)

Where # is your display's number (e.g., DisplayPort-0).

You can check what enumeration your FreeSync display receives before hand by entering the same command used to check FreeSync status. (not sure what that command is, but will find out)

Limitations for FreeSync 1.0 for Linux:

For FreeSync to work in OpenGL and Vulkan applications, V-Sync must be turned ON. If V-Sync is OFF, flipping may not occur hence FreeSync will not be engaged. If the individual application does not have V-Sync options, you can set it globally by modifying /etc/amd/amdrc (change the parameter from 1 to 3)

FreeSync should not be engaged on desktop or video playback

FreeSync enable setting is set on a per-display connection basis

FreeSync enable setting does not retain after display hotplug or system restart (e.g., need to manually re-enable FreeSync via terminal command)

In multi-display configurations, FreeSync will NOT be engaged (even if both FreeSync displays are identical)

FreeSync via HDMI is not supported for this feature. Only DP FreeSync displays will work.

Also probably people need to make sure compositor isn't running if compositor is not one of the following:

Cinnamon, Compiz, Steamcompmgr, Nautilus, Unitygreeter, Metacity, Kwin and GnomeShell

Since all that is FreeSync disabled in profiles and profiles package is recommended to be installed since that control some behaviors, but is optional it seems... Now, not sure what mokurai82's MATE compositor is? Is that Marco or something, not sure how XFCE's one is called and i know people might use Compton also... so likely amdgpu-pro need to disable more of these next time

[ernstp]

Thank You! That was exactly what I was looking for. Though having to enter this command every restart is kind of a pain in the rear.

Put it in .xsessionrc.

[mokurai82]

I gave up on trying to make this work for now. I used Marco+Compton, then Compiz. It did not work. I'll wait for more information on the internet on this subject before I reinstall on a spare drive. Thank You for Your help.

[whitecat]

I just installed a fresh CentOS 7.3 for my system with RX470 (MSI brand).
yum update && reboot
Installed the EPEL7 repository.
Executed "amdgpu-pro-preinstall.sh --check" => OK
Then installed the amdgpu-pro 16.50 package => everything downloaded/installed perfectly.
Reboot
Starting... GNOME3 crash!


Well done AMD...
I wonder if you really perform some minimal QA before releasing a driver.