Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
tynman wrote:Well, I ended up abandoning the Liquorix kernel because at some point I noticed kernel 4.15 was available for Buster. The biggest pain in the butt was that I had to add four boot parms to "enable" the support for Kaveri video:
and that was well outside of my comfort zone, although I did get it working eventually. So what I'm using now may or may not be applicable to whatever kernel you are trying to use.
To answer your actual question, the version of the xserver-xorg-video-amdgpu package I'm using is 18.0.1.
Thank you! Turns out, previously I had only set the parameters for SI, not for CIK. Doing BOTH (as you have done), did the the trick. But since the Xorg AMDGPU display driver is so primitive, display can be a bit glitchy at times. But I'm not willing to mess up the system with testing packages, so I will live with that (for now, anyway), and hope Debian would backport Xorg packages for Stretch soon. Rest works (as far as I could see).
P. S. I'm not really uncomfortable with setting these boot parameters. And yes, 4.16 branch (possibly from 4.13 onward) has SI and CIK support turned on, as per /boot/config-4.16.0-0.bpo.2-amd64.
Okay, so for anyone else trying to use the AMDGPU driver instead of Radeon for Southern Islands and Sea Islands on Debian 9, here is the summary:
1. Enable backports.
2. (Recommended) Upgrade Mesa and OpenGL related packages from backports.
3. Install kernel and related packages from backports.
4. Add boot parameters. The simplest way to do so is to edit /etc/default/grub. GRUB_CMDLINE_LINUX_DEFAULT should have the following options:
radeon.cik_support=0 amdgpu.cik_support=1 radeon.si_support=0 amdgpu.si_support=1
in essence: make it look like this:
4.17.2 is currently in Debian Experimental, I'm running the MX Linux version of that one backported to Stretch, or Liquorix just added one based on 4.17.3. (also backported to MX)
I'll maybe head over to Liquorix again By the way, Mesa 18 improves Kaveri performance a lot, according to this article: https://www.phoronix.com/scan.php?page= ... 2018&num=1 Another thing to eagerly wait for. Love the kind of hardware that grows faster with time!
Sajjad Kabir Joy wrote:I'll maybe head over to Liquorix again By the way, Mesa 18 improves Kaveri performance a lot, according to this article: https://www.phoronix.com/scan.php?page= ... 2018&num=1 Another thing to eagerly wait for. Love the kind of hardware that grows faster with time!
The upstream Debian kernel is now up to 4.17.3 in Sid, so I'm backporting that to MX 17 Linux on a vanilla Stretch pbuilder. Mesa 18.X can also be backported to Stretch, but that requires more backports first, notably the "heavy" build of the llvm-6.0 toolchain. But llvm-6.0 is already in stretch-backports, so a lot of the heavy lifting is done.
stevepusser wrote:The upstream Debian kernel is now up to 4.17.3 in Sid, so I'm backporting that to MX 17 Linux on a vanilla Stretch pbuilder. Mesa 18.X can also be backported to Stretch, but that requires more backports first, notably the "heavy" build of the llvm-6.0 toolchain. But llvm-6.0 is already in stretch-backports, so a lot of the heavy lifting is done.
OK, the Stretch backport of the Sid upstream 4.17.3 kernel is done. Besides the adaption to use gcc-6, which stretch-backports also does, I also bumped the kernel context switch frequency from 250 to 1000 Hz, so this one is not as good for server use as the standard Debian builds, but maybe better for desktops. DKMS packages from stretch-backports may be required if your vanilla versions' builds fail.
The new kernel packages are now available to you, but won't be seen as upgrades of any packages, just like the backported kernel in stretch-backports. So you'll have to search for 4.17 linux packages that are now available.
It displays Gallium 0.4 AMD HAINAN as an OpenGL string for R5 330m. Some errors about loading the correct firmware on boot, most likely nothing important.
So far, it worked good. But I had to switch to Wayland because rendering on Totem and friends is abysmal using Xorg (same thing as with linux 4.14).
0.A.D plays nicely, maybe even a bit faster.
It displays Gallium 0.4 AMD HAINAN as an OpenGL string for R5 330m. Some errors about loading the correct firmware on boot, most likely nothing important.
So far, it worked good. But I had to switch to Wayland because rendering on Totem and friends is abysmal using Xorg (same thing as with linux 4.14).
0.A.D plays nicely, maybe even a bit faster.
isn't this going to be a similar issue as nvidia cards that are based on intel but need optirun/optimus to specifically use the dedicated nvidia driver?
i ask because i see card 1 as intel and card 2 as amd. or is amdgpu meant to have figured a way to switch between the two when needed?
i ask because on the nvidia cards where card 1 is intel and card 2 in nvidia, as far as i know an outside solution (optirun/optimus) still needs to be run.
sorry for not answering your question directly.
Desktop: A320M-A PRO MAX, AMD Ryzen 5 3600, GALAX GeForce RTX™ 2060 Super EX (1-Click OC) - Sid, Win10, Arch Linux, Gentoo, Solus
Laptop: hp 250 G8 i3 11th Gen - Sid
Kodi: AMD Athlon 5150 APU w/Radeon HD 8400 - Sid
^AMD+Intel hybrid cards use kernel switcheroo and PRIME tachnology for switching. You can use the terminal command DRI_PRIME=1 foo (where foo is the program command) to manualy switch to a dedicated card.
GNOME as of 3.24 can switch to dedicated AMD card using a right-click menu option on a program icon. Intel card is always used by default, and there is no automatic, dynamic switching yet.