AMDGPU On Linux 4.18 To Offer Greater Vega Power Savings, DisplayPort 1.4 Fixes

[phoronix]

Phoronix: AMDGPU On Linux 4.18 To Offer Greater Vega Power Savings, DisplayPort 1.4 Fixes

There are more AMDGPU improvements just sent in to DRM-Next for landing in the Linux 4.18 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.18-AMDGPU-3

[Chewi]

My new Ryzen 2700U-powered Acer laptop freezes several times a day. I found a bug report from someone else with the same hardware just the other day and they were lucky enough to grab some kernel debug logging. I had thought it was CPU-related, much like the problems we've seen with Ryzen on the desktop, but the logging indicates a graphics-related issue so I'm praying a fix will make it in soon. He had already tested drm-next-4.18-wip but there's been plenty more since. The power-related improvements to Vega 10 sound relevant.

[cybertraveler]

Does anyone know if the Open Source driver supports FreeSync for the Vega series cards or any cards yet?

[Brisse]

Does anyone know if the Open Source driver supports FreeSync for the Vega series cards or any cards yet?

Nope, still no Freesync regardless of what card you have.

[Chewi]

To prevent random kernel lock ups with Ryzen, enable RCU_NOCB_CPU and boot the kernel with the rcu_nocbs=0-X command line parameter. X is the cpu thread count -1. Use Mesa git like Oibaf ppa and amd-staging-drm-next kernel. My distribution uses these: https://www.youtube.com/watch?v=fKJ-IatUfis

Well aware of the RCU_NOCB_CPU workaround, I'm the one who discovered it. That isn't the recommended fix now, you should disable the C6 Package state either via the BIOS, if yours supports it, or using ZenStates.py. I do the former on my desktop, which works. The laptop doesn't have the BIOS option and the latter option has no affect. As I said, the kernel debug logging also indicates that this is a different issue entirely.

The issue might be in Mesa and 18.2 helps for better performance on Vega 10 anyway. This laptop runs OpenSUSE and I am already using a repository providing recent git builds. My money is on it being a kernel issue though. I'm currently using OpenSUSE's "stable" kernel repository that has the latest 4.16 but I did try 4.17 previously. 4.18 might carry a fix now but it didn't a few weeks ago.

[makam]

For me, on Debian Testing with 4.16... Well the PC does boot into a graphical environment, but there are occasional glitches, As for gaming, I can play democracy 3 but I can't play Crusader kings 2. Crusader kings 2 does load but it goes at around 0.5 FPS.

A couple of weeks ago when I was on Manjaro with 4.17, Crusader Kings 2 did work on 4.17, so I am hoping that when Debian testing updates to 4.17 it will start to work normally. I would prefer to not have to hack it otherwise.

p.s. Vega 8 on AMD Ryzen 2200ge

[Unklejoe]

To prevent random kernel lock ups with Ryzen, enable RCU_NOCB_CPU and boot the kernel with the rcu_nocbs=0-X command line parameter. X is the cpu thread count -1. Use Mesa git like Oibaf ppa and amd-staging-drm-next kernel. My distribution uses these: https://www.youtube.com/watch?v=fKJ-IatUfis

I've seen this suggested before and I'd like to learn more about this issue. Is this a bug in the CPU or the kernel? My first thought is that you shouldn't have to modify a valid program to prevent lockups unless there's a hardware bug. That said, the fact that this setting can be controlled via the command line indicates that perhaps they kind of expected issues.

[tildearrow]

Raden Ridge GFXOFF support

[starshipeleven]

Partially implement amdgpu driver in mainline kernel again. More patches in 4.19-wip kernel: https://cgit.freedesktop.org/~agd5f/...-next-4.19-wip

FIY: as long as they keep working on it, mainline will always lag behind a WIP branch. You know, Work In Progress.

[starshipeleven]

I've seen this suggested before and I'd like to learn more about this issue. Is this a bug in the CPU or the kernel? My first thought is that you shouldn't have to modify a valid program to prevent lockups unless there's a hardware bug. That said, the fact that this setting can be controlled via the command line indicates that perhaps they kind of expected issues.

There is a bugreport in the kernel bugtracker about it but I don't remember what it is called. Chewi maybe knows.

The issue seems to be in hardware, and it seems to be triggered by going in C6 states, which is a low-power state the CPU cores enter when idling. It seems that it was not catched before as Windows never idles so hard as Linux can.

AMD blamed PSU not being able to keep up with this behaviour, and in most updated (desktop) UEFI firmwares they added an option called PSU something, which among other unknown things disables C6 states. Laptops get shafted as is tradition of crappy firmware support for laptops by most OEMs, even when the device itself should have the same features of the desktop APUs for the very least.