AMD, Intel & NVidia X graphics driver primer

“Drivers” for the subject brands of GPUs for X, whether Wayland or Xorg, consist of multiple components or layers. This primer discusses only the first two layers, and only for the FOSS types included in the openSUSE installation media and standard repositories.

First layer is the kernel. Each kernel comes with one or more of its own modules for each brand of GPU. For AMD, there is amdgpu for current and recent GPUs/APUs/IGPs, and radeon for older. For Intel there is gma500 for a many SOC configurations, and i915 for the vast majority. For NVidia there is only nouveau. These kernel modules provide Kernel ModeSetting (KMS) functionality that the foundational X driver layer unconditionally depends upon.

These foundational X drivers are traditionally hardware device dependent, and thus are called DDX, for device dependent X (driver). Again, for AMD there is amdgpu for current and radeon for older; for intel there is only intel; and for NVidia there is only nouveau. Each of these is provided by an upstream optional xf86-video-* rpm package. However, there is a newer technology generic driver, now more than six years old, that functions as if it was device dependent, but which is in fact created for supporting AMD, Intel, NVidia (and others), not surprisingly, called modesetting. This modesetting DDX is provided by the X server rpm package rather than a separate rpm, so is not optional, unlike the xf86-video-* rpms. Because it is relatively new, older GPUs (roughly prior to Gen4 for Intel, or 2007 or 2008 for others) are not supported by it.

Even though upstream modesetting is the default DDX, and the xf86-video-* rpms are technically optional, most openSUSE installations include the rpm xorg-x11-driver-video, which is a metapackage that installs every one of the xf86-video-* packages. This metapackage causes older GPUs unsupported by the modesetting DDX to be supported by a default installation, which in effect preempts the upstream default modesetting DDX that supports most non-ancient GPUs that are not too new for standard support.

Because of this preemptive override, most people speaking of video “drivers” don’t even know it exists. And because of the similar naming for kernel modules and DDXes, discussion of graphics “drivers” is often lacking clarity. This is particularly true for those for NVidia GPUs. Discussion of kernel driver is often intended when technically speaking of a DDX, and vice versa.

Those who wish to employ the modesetting DDX can most easily do so by uninstalling the xorg-x11-driver-video package and whichever xf86-video-* package is applicable to the installed GPU(s). Whether the modesetting DDX will perform “better” than a GPU-specific xf86-video-* package can only be determined by trying both and comparing behavior. It is not unusual that tearing or other buggy behavior can be eliminated or reduced by a DDX switch.

For X there are additionally a pair of limited functionality drivers that do not depend on KMS that support AMD, Intel, NVidia and more. These are FBDEV and VESA. These are unaccelerated, and support few, if any, modern widescreen resolutions, typically limited to 4:3 modes 1280x1024, 1600x1200, or less, often only 1024x768. Most find these acceptable only for rescue operations, or for servers where X is in use little to none. Not infrequently it is one of these two that are required for installation to proceed. When this happens, usually the bootloader on the installed system is configured to include nomodeset on each of the linux lines. The result of nomodeset in the bootloader is the competent DDX’s support is precluded, making the user unhappy with graphics performance, or confronted with a black screen where a login greeter is expected, until it is discovered why and how to remove nomodeset from the boot process.

In summary, “drivers” required for competent X operation are:

  • amdgpu (kernel) plus amdgpu (DDX) or modesetting (DDX) for current and recent AMD GPU/APUs/IGPs
  • radeon (kernel) plus radeon (DDX) or modesetting (DDX) for old AMD/ATI GPUs/IGPs
  • gma500 (kernel) or i915 (kernel) plus intel (DDX) or modesetting (DDX) for Intel GPUs/IGPs
  • nouveau (kernel) plus nouveau (DDX) or modesetting (DDX) for NVidia GPUs

Nicely summarised.

Further references that may be of interest (with respect to the ageing Xorg-server):
https://dri.freedesktop.org/wiki/DDX/
https://en.wikipedia.org/wiki/X.Org_Server#2D_graphics_driver
https://keyj.emphy.de/files/linuxgraphics_en.pdf

Very illuminating. I will keep this somewhere for reference. Thanks a lot for taking the trouble to create this.

(I tried the * button, but wasn’t allowed for some silly reason :().

openSUSE made big progress during past years. i915 was a tough experience in August 2016, while amdgpu was smooth as could be this month. :slight_smile:

[second edition]

“Drivers” for the subject brands of GPUs for X, whether Wayland or Xorg, consist of multiple components or layers. This primer discusses only the first two layers, and only for the F.O.S.S.](https://en.wikipedia.org/wiki/Free_and_open-source_software) types included in the openSUSE installation media and standard repositories.

First layer is the kernel. Each kernel comes with one or more of its own modules for each brand of GPU. For AMD, there is amdgpu for current and recent APUs/GPUs/IGPs, and radeon for older. For Intel there is gma500 for a many SOC configurations, and i915 for the vast majority. For NVidia there is only nouveau. These kernel modules provide Kernel ModeSetting (KMS) functionality that the foundational X driver layer unconditionally depends upon.

The foundational X drivers are traditionally hardware device dependent, and thus are called DDX, for device dependent X (driver). Again, for AMD there is amdgpu for current and radeon for older; for intel there is only intel; and for NVidia there is only nouveau. Each of these is provided by an upstream optional xf86-video-* rpm package. However, a newer technology generic driver exists, now more than six years old, that functions as if it was device dependent, but which is in fact created for supporting AMD, Intel, NVidia (and others), not surprisingly, called modesetting. This modesetting DDX is provided by the X server rpm package rather than a separate rpm, so is not optional, unlike the xf86-video-* rpms. Because it is relatively new, it does not support older GPUs (roughly prior to Gen4 for Intel, or 2007 or 2008 for others).

Even though upstream modesetting is the default DDX, and the xf86-video-* rpms are technically optional, most openSUSE installations include the rpm xorg-x11-driver-video, which is a metapackage that installs every one of the xf86-video-* packages. This metapackage causes older GPUs unsupported by the modesetting DDX to be supported by a default installation, which in effect preempts the upstream default modesetting DDX that supports most non-ancient GPUs that are not too new for standard support.

Because of this preemptive override, most people speaking of graphics “drivers” don’t even know the modesetting DDX exists. And because of the similar naming for kernel modules and DDXes, discussion of graphics “drivers” is often lacking clarity. This is particularly true for those for NVidia GPUs. Discussion of kernel driver is often intended when technically speaking of a DDX, and vice versa.

Those who wish to employ the modesetting DDX can most simply do so by uninstalling the xorg-x11-driver-video package and whichever xf86-video-* package is applicable to the installed GPU(s). Whether the modesetting DDX will perform “better” than a GPU-specific xf86-video-* package’s DDX can only be determined by trying both and comparing behavior. It is not unusual that tearing or other buggy behavior can be eliminated or reduced by a DDX switch.

For X there is additionally a pair of limited functionality drivers that do not depend on KMS, which support AMD, Intel, NVidia and more. These are FBDEV and VESA. They are unaccelerated, and support few, if any, modern widescreen resolutions, typically limited to 4:3 modes 1280x1024, 1600x1200, or less, often only 1024x768. Most find these acceptable only for rescue operations, or for servers where X is in use little to none. Not infrequently it is one of these two that are required for installation to proceed. When this happens, usually the bootloader on the installed system is configured to include nomodeset on each of the linux lines. The result of nomodeset from the bootloader is all competent FOSS DDX support is precluded, making the user unhappy with graphics performance, or confronting him with a black screen when the login greeter is expected, until it is discovered why and how to remove nomodeset from the boot process.

In summary, “drivers” required for competent X operation are:

  • amdgpu
    (kernel) plus amdgpu (DDX) or modesetting (DDX) for current and recent AMD GPU/APUs/IGPs
  • radeon
    (kernel) plus modesetting (DDX) or radeon (DDX) for old AMD/ATI GPUs/IGPs
  • gma500
    (kernel) or i915 (kernel) plus intel (DDX) or modesetting (DDX) for Intel GPUs/IGPs
  • nouveau
    (kernel) plus modesetting (DDX) or nouveau (DDX) for NVidia GPUs

Do i understand this correctly:

I should still be able to use my NVIDIA graphics card even when i uninstall xorg-x11-driver-video and xf86-video-nouveau or my INTEL-processor-graphics after uninstalling xorg-x11-driver-video ?

Regards

susejunky

There are no drivers in the (e.g. TW: 10kb) compatibility metapackage:

# rpm -q --filesbypkg xorg-x11-driver-video-7.6_1-19.1.x86_64.rpm
xorg-x11-driver-video     /usr/share/X11/xorg.conf.d/50-device.conf
xorg-x11-driver-video     /usr/share/X11/xorg.conf.d/50-monitor.conf
xorg-x11-driver-video     /usr/share/X11/xorg.conf.d/50-screen.conf
xorg-x11-driver-video     /usr/share/doc/packages/xorg-x11-driver-video
xorg-x11-driver-video     /usr/share/doc/packages/xorg-x11-driver-video/README.meta

Does the order, left to right, indicate a preferred selection?

  • If amdgpu (kernel) then, amdgpu(DDX) is preferred over modesetting (DDX);
  • If radeon (kernel) then, modesetting (DDX) is preferred over radeon (DDX);
  • If gma500 (kernel) or i915 (kernel) then, intel (DDX) is preferred over modesetting (DDX);
  • If nouveau (kernel) then modesetting (DDX) is preferred over nouveau (DDX).

The modesetting DDX driver is used when the other are not explicitly available and specified in Xorg config file to load. So usually best to make sure the relevant DDX driver package is removed to start with. Xorg will then use the modesetting driver.

For example
https://wiki.archlinux.org/index.php/AMDGPU#Xorg_configuration
https://wiki.archlinux.org/index.php/intel_graphics#Xorg_configuration

No. My order changes were intended to remove any such inference by alphabetizing.

Hmmm. OK, I have systems with amdgpu and radeon drivers – I’ll take a look at whether or not getting rid of the AMD specific DDX packages changes the graphics performance of the boxes …

@mrmazda:

Bad news: I removed the packages xf86-video-amdgpu and xorg-x11-driver-video and rebooted. SDDM crashed – KDE Plasma system.

The GRUB command line is as follows:


BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp151.28.52-default root=UUID=1ebd0398-732c-469a-9df5-af28273f743f resume=/dev/disk/by-id/ata-OCZ-VERTEX2_OCZ-HC8068405854W13J-part2 splash=silent quiet showopts elevator=cfq modprobe.blacklist=radeon amdgpu.si_support=1 mitigations=auto

Systemd Journal as follows:


kernel: [drm] amdgpu kernel modesetting enabled.
kernel: fb: switching to amdgpudrmfb from VESA VGA
kernel: [drm] initializing kernel modesetting (OLAND 0x1002:0x6613 0x1043:0x04BB 0x00).
kernel: amdgpu 0000:01:00.0: kfd not supported on this ASIC
kernel: amdgpu 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff
kernel: amdgpu 0000:01:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
kernel: amdgpu 0000:01:00.0: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
kernel: [drm] Detected VRAM RAM=2048M, BAR=256M
kernel: [drm] RAM width 128bits DDR3
kernel: [drm] amdgpu: 2048M of VRAM memory ready
kernel: [drm] amdgpu: 3072M of GTT memory ready.
kernel: [drm] GART: num cpu pages 262144, num gpu pages 262144
kernel: amdgpu 0000:01:00.0: PCIE GART of 1024M enabled (table at 0x000000F4007E9000).
kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
kernel: [drm] Driver supports precise vblank timestamp query.
kernel: [drm] Internal thermal controller without fan control
kernel: [drm] amdgpu: dpm initialized
kernel: fbcon: amdgpudrmfb (fb0) is primary device
kernel: amdgpu 0000:01:00.0: fb0: amdgpudrmfb frame buffer device
kernel: [drm] Initialized amdgpu 3.27.0 20150101 for 0000:01:00.0 on minor 0
 .
 .
 .
sddm[2449]: Failed to read display number from pipe
sddm[2449]: Display server failed to start. Exiting
systemd-coredump[2464]: Process 2449 (sddm) of user 0 dumped core.

Please note that, “kfd not supported on this ASIC” and “Invalid PCI ROM header signature” are normal – even when SDDM doesn’t crash.
I reinstalled the packages and rebooted – everything back to normal …
All the Kernel DRM and amdgpu message noted above, are also those messages which appear for normal operation.

Threads in this subforum deserve to be allowed edits regardless how long since authored!

With which GPU device ID? That’s never happened with mine, but none of mine are newer than GCN1.

Unlike for Intel, whose developers focus their effort on the modesetting DDX rather than the Intel DDX, AMD’s focus is on the amdgpu DDX, so it could well be the modesetting DDX doesn’t get a whole lot of testing on AMD GPUs. I suppose one of those amdgpu-specific cmdline options could be responsible, but regardless, the modesetting DDX shouldn’t be crashing anything, so a bug report is called for if one doesn’t already exist.

It’s an Oland PRO [Radeon R7 240/340] – Southern Islands – and therefore GCN 1st generation.

  • The GRUB CLI option “amdgpu.si_support=1” is present to specifically enable Southern Islands support …

Before submitting a Bug Report, I’ll try again with a check of the SDDM user’s ‘xorg-session.log’ content – it’s currently empty but, may contain something when SDDM crashes.

There’s an “Xorg.0.log.old” in /var/log/ which allows a comparison of what happens.
The amdgpu DDX case loads the modules glx, amdgpu, fb, dri2, glamoregl and ramdac.
The modesetting DDX case loads the modules glx, ati, radeon, modesetting, fbdev, vesa, fbdevhw, fb, dri2, glamoregl and ramdac.

  • Then it unloads the modules modesetting, fbdev, fbdevhw and vesa.

Both mention the following – the Radeon case is the modesetting DDX case:


    24.160] (II) AMDGPU(0): [DRI2] Setup complete
    24.160] (II) AMDGPU(0): [DRI2]   DRI driver: radeonsi
    24.160] (II) AMDGPU(0): [DRI2]   VDPAU driver: radeonsi


    24.241] (II) RADEON(0): [DRI2] Setup complete
    24.241] (II) RADEON(0): [DRI2]   DRI driver: radeonsi
    24.241] (II) RADEON(0): [DRI2]   VDPAU driver: radeonsi

Then the modesetting DDX case reports:


    24.241] (EE) RADEON(0): Failed to initialize surface manager
    24.241] (EE) 
Fatal server error:
    24.241] (EE) AddScreen/ScreenInit failed for driver 0
    24.241] (EE) 
    24.241] (EE)

Yes, the “amdgpu.si_support=1” GRUB CLI option may well be the culprit – I’ll remove it at the next attempt …

@mrmazda:

Nope – even worse, removing “amdgpu.si_support=1” and the DDX packages resulted only in a black screen.

  • Xorg.0.log indicated the following:

  1015.073] (II) AMDGPU: Driver for AMD Radeon:
        All GPUs supported by the amdgpu kernel driver
  1015.084] (II) AMDGPU(0): [KMS] Kernel modesetting enabled.
  1015.084] (EE) AMDGPU(0): amdgpu_device_initialize failed
  1015.084] (II) AMDGPU(1): [KMS] Kernel modesetting enabled.
  1015.084] (EE) AMDGPU(1): amdgpu_device_initialize failed
  1015.085] (II) AMDGPU(G0): [KMS] Kernel modesetting enabled.
  1015.085] (EE) AMDGPU(G0): amdgpu_device_initialize failed
  1015.085] (EE) Screen 0 deleted because of no matching config section.
  1015.085] (II) UnloadModule: "amdgpu"
  1015.085] (EE) Screen 0 deleted because of no matching config section.
  1015.085] (II) UnloadModule: "amdgpu"
  1015.085] (EE) Device(s) detected, but none match those in the config file.
  1015.085] (EE) 
Fatal server error:
  1015.085] (EE) no screens found(EE) 
  1015.085] (EE)

  • Had to remove “modprobe.blacklist=radeon” to get a KDE Plasma GUI up and running.

The systemd Journal offered no helpful indication as to why the graphics system was dead.

No problem with Oland and either DDX here:

> xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
DVI-I-0 connected 1920x1200+2560+0 (normal left inverted right x axis y axis) 519mm x 324mm
   2560x1440     59.95*+  74.92
   1920x1200     59.95*+
> inxi -GSIxxza
System:    Kernel: 4.12.14-lp151.28.48-default x86_64 bits: 64 compiler: gcc v: 7.5.0
           parameters: root=LABEL=s151 ipv6.disable=1 net.ifnames=0 **radeon.si_support=0 amdgpu.si_support=1** noresume
           mitigations=auto consoleblank=0 vga=791 video=1280x720@60 video=1024x768@60 video=1440x900@60 3
           Desktop: Trinity R14.0.8 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM **Distro: openSUSE Leap 15.1**
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] **Oland** [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] vendor: Dell
           driver: amdgpu v: kernel bus ID: 01:00.0 **chip ID: 1002:6611**
           Display: server: **X.Org 1.20.3 driver: amdgpu** unloaded: fbdev,modesetting,vesa alternate: ati display ID: :0
           screens: 1
           Screen-1: 0 s-res: 4480x1440 s-dpi: 132 s-size: 862x277mm (33.9x10.9") s-diag: 905mm (35.6")
           Monitor-1: DisplayPort-0 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27")
           Monitor-2: DVI-I-0 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1")
           OpenGL: renderer: AMD Radeon HD 8500 Series (**OLAND** DRM 3.27.0 4.12.14-lp151.28.48-default LLVM 7.0.1)
           v: 4.5 Mesa 18.3.2 direct render: Yes
Info:      ...Shell: Bash v: 4.4.23 running in: konsole **inxi: 3.1.04**

> xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 16384 x 16384
DVI-I-1 connected 1920x1200+2560+0 (normal left inverted right x axis y axis) 519mm x 324mm
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95*+  74.92
   1920x1200     59.95*+
> inxi -GSIxxza
System:    Kernel: 4.12.14-lp151.28.48-default x86_64 bits: 64 compiler: gcc v: 7.5.0
           parameters: root=LABEL=s151 ipv6.disable=1 net.ifnames=0 **radeon.si_support=0 amdgpu.si_support=1** noresume
           mitigations=auto consoleblank=0 vga=791 video=1280x720@60 video=1024x768@60 video=1440x900@60 3
           Desktop: Trinity R14.0.8 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM **Distro: openSUSE Leap 15.1**
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] **Oland** [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] vendor: Dell
           driver: amdgpu v: kernel bus ID: 01:00.0 **chip ID: 1002:6611**
           Display: server: **X.Org 1.20.3 driver: modesetting** unloaded: fbdev,vesa alternate: ati display ID: :0 screens: 1
           Screen-1: 0 s-res: 4480x1440 s-dpi: 132 s-size: 862x277mm (33.9x10.9") s-diag: 905mm (35.6")
           Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27")
           Monitor-2: DVI-I-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1")
           OpenGL: renderer: AMD Radeon HD 8500 Series (**OLAND** DRM 3.27.0 4.12.14-lp151.28.48-default LLVM 7.0.1)
           v: 4.5 Mesa 18.3.2 direct render: Yes
Info:      ...Shell: Bash v: 4.4.23 running in: konsole **inxi: 3.1.04**

But, I’m not using SDDM.

But, I’m blacklisting the radeon driver and, I’m not turning off the Radeon Southern Islands support.

  • And, I don’t disable IPv6.
  • And, I don’t disable Software Suspend.
  • And, I don’t opt-in for predictable interface names.

I’ll try once again, possibly tomorrow.

Doesn’t look to me like any on your list are relevant. I don’t find it necessary to blacklist anything to have the modesetting DDX or the amdgpu DDX operate though, nor have I made mention of any such need in this primer.

# lsmod | egrep 'deon|amd'
amdgpu               3383296  0
chash                  16384  1 amdgpu
gpu_sched              28672  1 amdgpu
radeon               1613824  2
ttm                   126976  2 amdgpu,radeon
drm_kms_helper        204800  2 amdgpu,radeon
drm                   491520  7 amdgpu,radeon,gpu_sched,ttm,drm_kms_helper
i2c_algo_bit           16384  2 amdgpu,radeon
# rpm -qa | grep xf86-v
xf86-video-vesa-2.4.0-lp151.2.3.x86_64
xf86-video-fbdev-0.5.0-lp151.1.2.x86_64
> xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 2560 x 2640, maximum 16384 x 16384
DVI-I-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
DP-1 connected primary 2560x1440+0+1200 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95*+  74.92
   1920x1200     59.95*+
> inxi -SGxxza
System:    Kernel: 4.12.14-lp151.28.52-default x86_64 bits: 64 compiler: gcc v: 7.5.0
           **parameters: root=LABEL=s151 mitigations=auto**
           Desktop: Trinity R14.0.8 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM **Distro: openSUSE Leap 15.1**
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] **Oland** [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] vendor: Dell
           driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:6611
           Display: server: **X.Org 1.20.3 driver: modesetting**
           unloaded: fbdev,vesa alternate: ati display ID: :0 screens: 1
           Screen-1: 0 s-res: 2560x2640 s-dpi: 120 s-size: 541x558mm (21.3x22.0") s-diag: 777mm (30.6")
           Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27")
           Monitor-2: DVI-I-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1")
           OpenGL: renderer: AMD **OLAND** (DRM 2.50.0 4.12.14-lp151.28.52-default LLVM 7.0.1) v: 4.5 Mesa 18.3.2
           direct render: Yes

I do find it unexpected to see both amdgpu and radeon kernel drivers loaded. Nevertheless, no user need touch the subject of blacklisting to enable either of the FOSS DDX that Oland can run on. Enabling the upstream default modesetting DDX can be as simple as not having xf86-video-amdgpu installed.

I do seem to recall seeing somewhere not too long ago that AMD devs were contemplating removing amdgpu support for GCN1. Whether that meant kernel or DDX or both I have no idea.

# lsmod | sort | egrep 'deon|amdg'
amd_iommu_v2           20480  1 amdgpu
amdgpu               5746688  9
drm                   573440  11 gpu_sched,drm_kms_helper,amdgpu,radeon,ttm
drm_kms_helper        253952  2 amdgpu,radeon
gpu_sched              40960  1 amdgpu
i2c_algo_bit           16384  2 amdgpu,radeon
radeon               1720320  0
ttm                   122880  2 amdgpu,radeon
# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 2560 x 2640, maximum 16384 x 16384
DVI-I-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
DP-1 connected primary 2560x1440+0+1200 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95*+  74.92
   1920x1200     59.95*+
# inxi -SGxxza
System:    Kernel: 5.6.14-1-default x86_64 bits: 64 compiler: gcc v: 10.1.1
           parameters: root=LABEL=sTW ipv6.disable=1 net.ifnames=0 radeon.si_support=0 amdgpu.si_support=1 noresume
           mitigations=auto consoleblank=0 vga=791 video=1280x720@60 video=1024x768@60 video=1440x900@60 5
           Desktop: KDE Plasma 5.19.3 tk: Qt 5.15.0 wm: kwin_x11 dm: N/A **Distro: openSUSE Tumbleweed 20200717**
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] **Oland** [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] vendor: Dell
           **driver: amdgpu** v: kernel bus ID: 01:00.0 chip ID: 1002:6611
           Display: x11 **server: X.Org 1.20.8** compositor: kwin_x11 **driver: modesetting** display ID: :0 screens: 1
           Screen-1: 0 s-res: 2560x2640 s-dpi: 120 s-size: 541x558mm (21.3x22.0") s-diag: 777mm (30.6")
           Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2") diag: 686mm (27")
           Monitor-2: DVI-I-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1")
           OpenGL: renderer: AMD Radeon HD 8500 Series (**OLAND** DRM 3.36.0 5.6.14-1-default LLVM 10.0.0) v: 4.6 Mesa 20.1.2
           direct render: Yes

The amdgpu DDX also works in TW.

@mrmazda:

Yep! That did it! – Only “radeon.si_support=0 amdgpu.si_support=1” in the GRUB command line.


 > zypper search --installed-only xf86-video
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name             | Zusammenfassung                                     | Typ
---+------------------+-----------------------------------------------------+------
i+ | xf86-video-fbdev | Framebuffer-Videotreiber für den Xorg-X-Server      | Paket
i+ | xf86-video-vesa  | Generischer VESA-Videotreiber für den Xorg-X-Server | Paket
 > 
> inxi -SGxxza
System:    Kernel: 4.12.14-lp151.28.52-default x86_64 bits: 64 compiler: gcc v: 7.5.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp151.28.52-default 
           root=UUID=1ebd0398-732c-469a-9df5-af28273f743f 
           resume=/dev/disk/by-id/ata-OCZ-VERTEX2_OCZ-HC8068405854W13J-part2 splash=silent quiet showopts 
           elevator=cfq radeon.si_support=0 amdgpu.si_support=1 mitigations=auto 
           Desktop: KDE Plasma 5.12.8 tk: Qt 5.9.7 wm: kwin_x11 dm: SDDM Distro: openSUSE Leap 15.1 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Oland PRO [Radeon R7 240/340] vendor: ASUSTeK driver: amdgpu 
           v: kernel bus ID: 01:00.0 chip ID: 1002:6613 
           Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver: modesetting unloaded: fbdev,vesa 
           alternate: ati display ID: :0 screens: 1 
           Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") s-diag: 582mm (22.9") 
           Monitor-1: DVI-D-1 res: 1920x1080 hz: 60 dpi: 94 size: 521x293mm (20.5x11.5") diag: 598mm (23.5") 
           OpenGL: renderer: AMD Radeon HD 8500 series (OLAND DRM 3.27.0 4.12.14-lp151.28.52-default LLVM 7.0.1) 
           v: 4.5 Mesa 18.3.2 direct render: Yes 
 > 


 # lsmod | grep -iE 'adeo|mdgp'
amdgpu               3383296  38
chash                  16384  1 amdgpu
gpu_sched              28672  1 amdgpu
radeon               1613824  0
i2c_algo_bit           16384  2 amdgpu,radeon
drm_kms_helper        204800  2 amdgpu,radeon
ttm                   126976  2 amdgpu,radeon
drm                   491520  19 amdgpu,radeon,gpu_sched,ttm,drm_kms_helper
 # 

And, in the systemd Journal, the amdgpu driver is being used:


Jul 22 18:48:44 xxx kernel: [drm] radeon kernel modesetting enabled.
Jul 22 18:48:44 xxx kernel: radeon 0000:01:00.0: SI support disabled by module param
Jul 22 18:48:45 xxx kernel: [drm] amdgpu kernel modesetting enabled.
 .
 .
Jul 22 18:48:45 xxx kernel: [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit
Jul 22 18:48:45 xxx kernel: amdgpu 0000:01:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used)
Jul 22 18:48:45 xxx kernel: amdgpu 0000:01:00.0: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
Jul 22 18:48:45 xxx kernel: [drm] Detected VRAM RAM=2048M, BAR=256M
Jul 22 18:48:45 xxx kernel: [drm] RAM width 128bits DDR3
Jul 22 18:48:45 xxx kernel: [TTM] Zone  kernel: Available graphics memory: 4071460 kiB
Jul 22 18:48:45 xxx kernel: [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
Jul 22 18:48:45 xxx kernel: [TTM] Initializing pool allocator
Jul 22 18:48:45 xxx kernel: [TTM] Initializing DMA pool allocator
Jul 22 18:48:45 xxx kernel: [drm] amdgpu: 2048M of VRAM memory ready
Jul 22 18:48:45 xxx kernel: [drm] amdgpu: 3072M of GTT memory ready.
Jul 22 18:48:45 xxx kernel: [drm] GART: num cpu pages 262144, num gpu pages 262144
Jul 22 18:48:45 xxx kernel: amdgpu 0000:01:00.0: PCIE GART of 1024M enabled (table at 0x000000F4007E9000).
Jul 22 18:48:45 xxx kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Jul 22 18:48:45 xxx kernel: [drm] Driver supports precise vblank timestamp query.
Jul 22 18:48:45 xxx kernel: [drm] Internal thermal controller without fan control
Jul 22 18:48:45 xxx kernel: [drm] amdgpu: dpm initialized
Jul 22 18:48:45 xxx kernel: [drm] AMDGPU Display Connectors