You are not logged in.
AMDGPU PRO from the AUR depends on binfmt-support which no longer exists. The comments mention a replacement package which... also doesn't exist (edit: It has been brought to my attention that systemd-binfmt isn't a package, but is part of systemd)
What does one have to do to install AMDGPU PRO on Arch now?
Last edited by bozaloshtsh (2018-11-19 23:21:22)
Offline
https://aur.archlinux.org/packages/amdgpu-pro/
Regarding dependency "binfmt-support", it was deleted on 2/28/2018. See https://lists.archlinux.org/pipermail/a … 22626.html
This is because systemd-binfmt replaces its functionality.
Previous comments saying they couldn't find "binfmt-support" on the AUR, but with a link that got to its files will no longer work. I asked about how those files were still accessible but searching for "binfmt-support" didn't find anything at https://bbs.archlinux.org/viewtopic.php?id=241075 and those files were deleted. If that messes anything up, sorry about that, wasn't my intention.
That said, I'm assuming the dependency of "binfmt-support" can just be removed, since "systemd" is in "base". I haven't tried it, and probably won't be, because downgrading kernels is a no-go for me.
If I'm right, perhaps a 17.40.492261-2 could be released, removing it as the only change.
Did you try this?
Edit:
It would also be useful if you indicate what kernel(s) you are targeting and what userspace interface(s) you require OGL, OCL, Vulkan etc.
Last edited by loqs (2018-11-11 18:24:17)
Offline
Yeah, I realized my mistake and just removed the dependency from the PKGBUILD. Now I'm dealing with several issues that I'll describe below.
I'm using the standard kernel package:
Linux doa 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20 22:06:45 UTC 2018 x86_64 GNU/Linux
I don't really have any requirements except being able to start X.
So, the issue I'm facing is that the AMDGPU PRO drivers introduce various replacements for certain packages I already have. One of these packages that needs to be removed is libglvnd. However, mesa depends on this, and I can't just get rid of mesa because gtk depends on it.
I saw a potential solution to this in replacing mesa with mesa-noglvnd (and lib32-mesa with lib32-mesa-noglvnd) but those packages simply failed to build.
Is there a better way to install these drivers without uprooting my entire system?
Offline
Does X not start with the packages in the repositories or you want to compare performance of Pro OpenGL which is libglvnd incompatible with the OpenGL supplied by mesa?
Offline
mesa-noglvnd / lib32-mesa-noglvnd just need to be updated to latest versions.
That will only solve part of the issues though.
What does one have to do to install AMDGPU PRO on Arch now?
The main problem is the OSes targeted by amdgpu-pro .
Compatible 64-bit Operating Systems
RedHat Enterprise Linux 7.5
RedHat Enterprise Linux 6.10
CentOS 7.5
CentOS 6.10
Ubuntu 18.04.1
Ubuntu 16.04.5
SLED/SLES 15
Archlinux package versions are many versions ahead of the ones used in those systems.
It seems since late 2017 no one with sufficient skills AND motivation to do the work needed to keep amdgpu-pro functional on archlinux has come forward.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Do you have a good reason for preferring amdgpu-pro over the open-source amdgpu?
As time goes on more and more of the -pro stack is being replaced by it's open-source equivalents. AFAIK the only remaining difference between the two is that -pro uses a proprietary shader compiler, the rest of the stack is just older versions of mesa, llvm, etc...
Offline
Do you have a good reason for preferring amdgpu-pro over the open-source amdgpu?
As time goes on more and more of the -pro stack is being replaced by it's open-source equivalents. AFAIK the only remaining difference between the two is that -pro uses a proprietary shader compiler, the rest of the stack is just older versions of mesa, llvm, etc...
Well, I'm not sure, and I now realize that this may be a classic case of the XY problem. When I start X with xf86-video-amdgpu only, I see horizontal flickering lines across the screen (RX 480). Under Windows, I see no such issues. My assumption was that using AMDGPU PRO would resolve this issue.
Last edited by bozaloshtsh (2018-11-14 01:42:28)
Offline
What kind of flickering? Constant or only when moving windows around? Which environment are you starting? if the latter, either use a compositor, or enable the TearFree option, if the former, try setting
amdgpu.dc=0
in your kernel params.
Edit: Looking some more, this might simply be a regression in 4.19 - https://bugs.freedesktop.org/show_bug.cgi?id=108671 FWIW try out the previous 4.18.16 kernel.
Last edited by V1del (2018-11-14 13:18:21)
Offline
I will try these in a bit, after I get some work done. In the mean time, I greatly appreciate this help. Thank you.
Offline
Here is my best description of the issue. When the screen is being redrawn (so not when everything is stationary), there are horizontal lines or bars flickering right before the screen update completes. The bug linked seems to match my description.
I was hoping at least one of these would work, but none of them have.
1) I tried amdgpu.dc = 0. This screwed up my resolution even before X started, squishing all text.
2) I set the TearFree option in my Xorg config. No effect.
3) I started compton after X, no effect.
4) I downgraded to 4.18, 4.17, and LTS. Still experienced the issue on 4.18 and 17, and using LTS caused the same issue as setting amdgpu.dc=0 in any of these newer kernels. Weird.
edit:
I fixed it by following this: https://wiki.archlinux.org/index.php/AM … cy_problem. I set the power setting to "high," and the issue disappears even on the latest kernel. If I use the "auto" power management setting, it flickers. If I use "low" or "high", it works fine.
It strikes me as odd because the wiki mentions 120+hz monitors and my monitor is only 75 hz. Since this isn't a laptop, I should be able to slap it on high all the time with a script run from xinit and call it a day, right?
Last edited by bozaloshtsh (2018-11-17 20:01:01)
Offline