You are not logged in.
Yep. I have and I re-checked and reinstalled all those packages. I also tried without amdvlk (no change) and with aco-patched mesa (X.org doesn’t even start).
Offline
Maybe try specifying the vulkan icd loader manually? Also, don't bother with aco for now, it doesn't support navi
Offline
Sure. How would I do that? In particular, it seems only worth while to enforce amdvlk, since removing it didn’t solve the problem.
Offline
OK folks, I think I’ve figured it out—commenting out
Option "VariableRefresh" "true"
in my X.org config seems to give me the performance I desired. Further testing commencing, but what I’ve seen so far seems to be working OK.
EDIT: further testing on a few games confirm that without FreeSync both amdvlk and radv are capable of maintaining reasonable framerate.
Last edited by Althorion (2019-10-01 09:39:39)
Offline
I bought myself some new computer parts. Now that there is the kernel and the firmware in core, is it possible to run Radeo RX 5700 with vesafb without AUR, just thenormal repos? Sure, games and other openGL stuff isn't working, but I want to build and install my new computer NOW!
Offline
Console part should work fine now, for X you can try to use modesetting .
just don't install any xf86-video drivers.
Make sure you have xinit & xorg-server installed, then startx should use the modesetting driver.
Only if modesetting driver fails you should try xf86-video-vesa .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
For whom interested: "aur/linux-mainline 5.4rc1-1" works fine for me (also regarding idle power consumption). And "core/linux-firmware 20190923.417a9c6-1" contains Navi10 firmware files now.
Offline
I still have freezes from time to time with linux-mainline 5.4rc1. And I cannot use magic sysrq. Anybody experiencing this?
Offline
Now also mesa seems to be in the official repos: https://www.archlinux.org/packages/extra/x86_64/mesa/
Is there a way to see why llvm 9 is still only in the staging repo?
Offline
I had X and Sway (wayland) working with the packages from the repo (kernel 5.3), excepting the firmware blobs that I manually installed. Performance was so-so, but enough until problems are fixed.
Today I upgraded, mesa bumped from 19.1 to 19.2, and firmware was updated too (I had to force for it to overwrite the files I manually installed). Result: when I start X or Sway (startx or sway commands), the PC freezes ¬_¬.
I have tried building aur/linux-mainline: same result. I am tempted to restore the old firmware blobs, but as the latest firmware package is supposed to have the correct ones, I would like hearing advice here...
Offline
Now also mesa seems to be in the official repos: https://www.archlinux.org/packages/extra/x86_64/mesa/
Is there a way to see why llvm 9 is still only in the staging repo?
If I'm correct, you don't need LLVM 9. LLVM 9 is only needed to build the latest Mesa, but that's unnecessary when you pull the package from the Arch repos, because those packages are already built.
Offline
FriedrichNietzsche wrote:Now also mesa seems to be in the official repos: https://www.archlinux.org/packages/extra/x86_64/mesa/
Is there a way to see why llvm 9 is still only in the staging repo?If I'm correct, you don't need LLVM 9. LLVM 9 is only needed to build the latest Mesa, but that's unnecessary when you pull the package from the Arch repos, because those packages are already built.
Mesa 19.2 requires a minimum version of LLVM 3.3 to build [1] . As arch builds mesa with radeonsi support it requires LLVM >= 7.0 [2].
Building with LLVM 8 as mesa 19.2.0-2 is means build time detection such as [3] will disable features that require LLVM 9 or LLVM 10.
[1] https://github.com/mesa3d/mesa/blob/mes … uild#L1252
[2] https://github.com/mesa3d/mesa/blob/mes … uild#L1246
[3] https://github.com/mesa3d/mesa/commit/f … 87b29335e1
Offline
Some related news:
- AMDGPU Submits LRU Bulk Moves Support As A Linux 5.4 "Fix" For Better Performance: https://www.phoronix.com/scan.php?page= … es-5.4-Fix
- RADV Vulkan Driver Picks Up Several GFX10/Navi Fixes, Including To Address Random Hangs: https://www.phoronix.com/scan.php?page= … Hangs-19.3
- AMDGPU Performance In Linux 5.4 Is Now Faster With "Bulk Moves" Landed: https://www.phoronix.com/scan.php?page= … oves-Lands
- The ACO Radeon Compiler Alternative To AMDGPU LLVM Looks Good But Work Isn't Done Yet: https://www.phoronix.com/scan.php?page= … RADV-State
Last edited by jokeyrhyme (2019-10-05 00:43:38)
Offline
marmalade wrote:FriedrichNietzsche wrote:Now also mesa seems to be in the official repos: https://www.archlinux.org/packages/extra/x86_64/mesa/
Is there a way to see why llvm 9 is still only in the staging repo?If I'm correct, you don't need LLVM 9. LLVM 9 is only needed to build the latest Mesa, but that's unnecessary when you pull the package from the Arch repos, because those packages are already built.
Mesa 19.2 requires a minimum version of LLVM 3.3 to build [1] . As arch builds mesa with radeonsi support it requires LLVM >= 7.0 [2].
Building with LLVM 8 as mesa 19.2.0-2 is means build time detection such as [3] will disable features that require LLVM 9 or LLVM 10.[1] https://github.com/mesa3d/mesa/blob/mes … uild#L1252
[2] https://github.com/mesa3d/mesa/blob/mes … uild#L1246
[3] https://github.com/mesa3d/mesa/commit/f … 87b29335e1
So what does that mean for just using the mesa package? Do I still need llvm9? The mesa package has llvm in its dependencies.
Offline
So what does that mean for just using the mesa package? Do I still need llvm9? The mesa package has llvm in its dependencies.
mesa 19.2.0-2 has llvm-libs in its dependencies but not llvm. Having llvm installed is not required and will have no effect.
Certain features will not be available due to the package not being built with LLVM 9 or LLVM 10.
Offline
FriedrichNietzsche wrote:So what does that mean for just using the mesa package? Do I still need llvm9? The mesa package has llvm in its dependencies.
mesa 19.2.0-2 has llvm-libs in its dependencies but not llvm. Having llvm installed is not required and will have no effect.
Certain features will not be available due to the package not being built with LLVM 9 or LLVM 10.
I don't really get it. You mean it should be possible right now with the standard repos to setup an X11 with an RX5700(XT)? Only certain things are missing?
It does not work here so far. I have the following packages:
- linux 5.3.1
- linux-firmware 20190923.417a9c6-1
- xorg-server, xorg-xinit
- mesa 19.2.0
- vulkan-radeon, lib32-vulkan-radeon for vulkan
- libva-mesa-driver, lib32-libva-mesa-driver for VA-API
- mesa-vdpau, lib32-mesa-vdpau for VDPAU
When I start I have a nice modesetting tty. When I start X11 (startx /usr/bin/startxfce) the system freezes, I can't even switch to another tty, it only reacts to the ACPI event of the powerbutton and shuts down after 90 seconds waiting for something.
The log just shows that it is trying to load X11 with modesetting (what was expected), last message is about loading GLAMOR without any error. I tried to install xf86-video-vesa, xf86-video-fbdev and xf86-video-amdgpu, but every time the same
freezing.
Normally everything should work now, or am I wrong? Do I have to wait for llvm 9 for some reason or is there another error?
EDIT: Okay, maybe it is the same error mentioned here: https://bbs.archlinux.org/viewtopic.php?id=249639
Some other things I don't understand (the wiki is not really straightforward there):
Do I need the kernel parameters cik_support= and si_support=? And do I have to blacklist the radeon module? Anything else I may missed?
Last edited by Murray_B (2019-10-05 10:29:12)
Offline
I don't really get it. You mean it should be possible right now with the standard repos to setup an X11 with an RX5700(XT)? Only certain things are missing?
For the package mesa that is what I mean. Does linux 5.3.2.arch2-1 from testing also have the issue?
Assuming you do not need the kernel headers:
# pacman -U https://archive.archlinux.org/packages/l/linux/linux-5.3.2.arch2-1-x86_64.pkg.tar.xz
If not please post the kernel messages extracted from the journal and the contents of Xorg.0.log from a boot with the issue.
Do I need the kernel parameters cik_support= and si_support=? And do I have to blacklist the radeon module?
5700 is not southern island or sea islands so no. Is the radeon module loaded on the system?
Offline
Okay, the newer Kernel did not help. I tried again with
a) modesetting: http://www.thschuetz.de/amddebug/Xorg.0-modeset.log
b) amdgpu with autoload of xorg: http://www.thschuetz.de/amddebug/Xorg.0-amdgpu.log
c) amdgpu configured with conf-file: http://www.thschuetz.de/amddebug/Xorg.0-amdgpu_conf.log
dmesg: http://www.thschuetz.de/amddebug/dmesg.txt
and journalctl -k: http://www.thschuetz.de/amddebug/journalctl-k
For me everything looks perfect, but when I get the start messages of xorg (configuration, logfile, etc.) it stops and does not switch over to X11.
I recognized that there are no input drivers loaded in the xorg-logs.
Any idea?
Offline
https://archive.archlinux.org/packages/ … pkg.tar.xz is now in testing if that is also affected:
linux-amd-staging-drm-next-git or linux-mainline I would wait for 5.4-rc2 of mainline which should be released Sunday/Monday.
You could also test mesa-git.
Offline
Recovered a working X desktop. I had to:
* Go back to latest kernel 5.3 from repository.
* Use the latest linux-firmware from repository.
* Downgrade vulkan-radeon, lib32-vulkan-radeon, mesa to version 19.1 and libglvnd, lib32-libglvnd to version 1.1.1.
If I upgrade libglvnd, mesa and vulkan-radeon, I have exactly the same problem Murray_B describes.
EDIT: I would like to add that previously I had everything running using mesa-git, and performance was much better than the one I have right now with mesa 19.1. I removed mesa-git to test mesa 19.2 from official repos. Unfortunately at least for me it is not working.
Last edited by doragasu (2019-10-05 18:23:47)
Offline
@doragasu can you test mesa-git please.
Offline
@ Murray_B
[ 371.479] (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID = 0x731f)
$ modinfo amdgpu | grep 731F
alias: pci:v00001002d0000731Fsv*sd*bc*sc*i*
$
The stock kernel does recognize that ID, it may be the X driver that doesn't.
Try xf86-video-amdgpu-git from the mesa-git unoffical repo.
Last edited by Lone_Wolf (2019-10-05 18:34:25)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Lone_Wolf I believe that message is only cosmetic [1] and is not present in git master either [2].
[1] https://bbs.archlinux.org/viewtopic.php … 4#p1864504
[2] https://gitlab.freedesktop.org/mesa/drm … amdgpu.ids
Offline
So, using everything from the currently available stable set, (no -git anything, meaning LLVM 8) I can't run games, but I do get display - however, for some reason I can no longer set refresh rates for my monitor. It appears that there's now an EDID issue:
$ sudo get-edid -m 0 > edid.bin
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
Looks like no busses have an EDID. Sorry!
Attempting to use the classical VBE interface
Performing real mode VBE call
Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Function supported
Call successful
VBE version 300
VBE string at 0xc030c "AMD ATOMBIOS"
VBE/DDC service about to be called
Report DDC capabilities
Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful
Looks like no busses have an EDID. Sorry!
Attempting to use the classical VBE interface
Performing real mode VBE call
Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Function supported
Call successful
VBE version 300
VBE string at 0xc030c "AMD ATOMBIOS"
VBE/DDC service about to be called
Report DDC capabilities
Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful
Monitor and video card combination does not support DDC1 transfers
Monitor and video card combination supports DDC2 transfers
0 seconds per 128 byte EDID block transfer
Screen is not blanked during DDC transfer
Reading next EDID block
VBE/DDC service about to be called
Read EDID
Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
Function supported
Call failed
The EDID data should not be trusted as the VBE call failed
Error: output block unchanged
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>.
Offline