
Linux kernel maintainer rejects patch for AMDGPU

On December 8, 2016, AMD uploaded the latest version of the AMDGPU-PRO 16.50 proprietary driver for Linux-based operating systems for download . This driver is based on the free AMDGPU kernel module. It implements DirectGMA support for OpenGL and FreeSync technology , which in some AMD hybrid and GPUs solves the communication problem between the processor and the monitor and eliminates image tearing, especially in games. AMDGPU-PRO 16.50 supports some models of the GNC 1.0 AMD graphics cards of the Southern Islands series, namely the Radeon R7 M465X, AMD Radeon R7 M370 and AMD Radeon R7 M350. Scripts have been published for installation on RedHat Enterprise Linux 7.3, CentOS 7.3, CentOS 6.8, and SLED / SLES 12 SP2.
At the same time, AMD representative Harry Wentland turned to the Linux kernel developers mailing list with a proposal to include in the kernel a modest patch of about 100,000 lines of code with a layer of hardware abstractions. Kernel maintainer Dave Airlie readily explained to an AMD representative why such a patch would not be accepted into the kernel. Although the maintainer did not recall Linus’s famous phrase about Nvidia , many people remember those words. AMD was also sent on foot, albeit not in such a rough form.
New driver
The AMDGPU-PRO 16.50 driver provides support for OpenGL 4.5, GLX 1.4, OpenCL 1.2, Vulkan 1.0, VDPAU API, as well as support for Vulkan in the Dota 2 game. It includes basic graphics and power management functions, a GPL-compatible kernel module, is compatible with ADF (Atomic Display Framework) and KMS (Kernel Mode Setting) technologies.
The new driver implemented FirePro features, such as EDID Management and 30-bit color, support for 64-bit versions of Red Hat Enterprise Linux 7.3, Red Hat Enterprise Linux 6.8, CentOS 7.3, CentOS 6.8, SUSE Linux Enterprise Desktop 12 Service Pack 2 , SUSE Linux Enterprise Server 12 Service Pack 2, and Ubuntu 16.04 LTS.
List of supported graphics cards with the AMDGPU-PRO 16.50 driver
Radeon RX 480 Graphics
Radeon RX 470 Graphics
Radeon RX 460 Graphics
AMD Radeon R9 Fury X Graphics
AMD Radeon R9 Fury Graphics
AMD Radeon R9 Nano Graphics
AMD Radeon R9 390X Graphics
AMD Radeon R9 390 Graphics
AMD Radeon R9 380X Graphics
AMD Radeon R9 380 Graphics
AMD Radeon R9 M395X Graphics
AMD Radeon R9 M385 Graphics
AMD Radeon R9 M380 Graphics
AMD Radeon R9 M270X Graphics
AMD Radeon R9 360 Graphics
AMD Radeon R9 290X Graphics
AMD Radeon R9 290 Graphics
AMD Radeon R9 285 Graphics
AMD Radeon R9 M485X
AMD Radeon R7 M400 Series
AMD Radeon R7 M370
AMD Radeon R7 M350
AMD Radeon R7 260X Graphics
AMD Radeon R7 260 Graphics
AMD Radeon Pro WX-series
AMD FirePro W-Series
AMD FirePro S-Series
Radeon RX 470 Graphics
Radeon RX 460 Graphics
AMD Radeon R9 Fury X Graphics
AMD Radeon R9 Fury Graphics
AMD Radeon R9 Nano Graphics
AMD Radeon R9 390X Graphics
AMD Radeon R9 390 Graphics
AMD Radeon R9 380X Graphics
AMD Radeon R9 380 Graphics
AMD Radeon R9 M395X Graphics
AMD Radeon R9 M385 Graphics
AMD Radeon R9 M380 Graphics
AMD Radeon R9 M270X Graphics
AMD Radeon R9 360 Graphics
AMD Radeon R9 290X Graphics
AMD Radeon R9 290 Graphics
AMD Radeon R9 285 Graphics
AMD Radeon R9 M485X
AMD Radeon R7 M400 Series
AMD Radeon R7 M370
AMD Radeon R7 M350
AMD Radeon R7 260X Graphics
AMD Radeon R7 260 Graphics
AMD Radeon Pro WX-series
AMD FirePro W-Series
AMD FirePro S-Series
Developers warn of some known bugs of the new driver. For example, the possibility of complete freezing when the display is hot connected when the computer is turned on, the inability to determine the operation mode (modeset) when the monitor is connected hot in Red Hat Enterprise Linux 7.3, as well as incompatibility with the EnSight 10 benchmark. Binary
links:
- AMDGPU-Pro Driver Version 16.50 for RHEL 7.3
- AMDGPU-Pro Driver Version 16.50 for RHEL 6.8 / CentOS 6.8
- AMDGPU-Pro Driver Version 16.50 for Ubuntu 16.04
- AMDGPU-Pro Driver Version 16.50 for SLED / SLES 12 SP2
No HAL in the core!
Along with the release of the driver, AMD representative Harry Wentland turned to the kernel developers mailing list with a proposal to include a patch for the AMDGPU module included with the Linux kernel, redesigning the Display Core code to support future generation GPUs (uGPUs) ), as well as adding a number of innovations, such as tools for organizing audio output via HDMI and DisplayPort.
There was a big discussion around this proposal. AMD representative first softly and then hardexplained that such a patch will not be accepted into the kernel because AMD is trying instead of using a unified interface for all drivers to integrate its own layer of hardware abstractions (HAL) to interact with the equipment.
The core maintainer Dave Airlie explained very simply: “No HAL. We do not embed layers of hardware abstractions in the kernel. In DRM (Direct Rendering Manager), we also do not accept such patches if the maintainers are not sleeping. They may be convenient for AMD, but for the Linux kernel they offer no advantages and make code support difficult. "I have been maintaining this codebase for more than 10 years, and over the years, the patch has been stained only once for semi-political reasons (it was exynos), and that thing required a lot of effort to clean up, and I really don't want to agree to this again."
Dave Airlie said that she’s definitely not going to undermine Linus’s trust and merge 100,000 lines of hardware abstractions into the kernel, and she’s not going to rewrite this code on her own either.
The maintainer expressed the hope that AMD will not threaten to leave the latest versions of AMD video cards without support if this HAL is not included in the kernel. In this case, a large number of users will have to be left on the sidelines, but Linux will survive this and will develop further, Airlie said: "The kernel is larger than any of us, and it has standards for what is acceptable and what is not." The maintainer recommended AMD colleagues to read all threads of the discussion about mac80211, which was several years ago when vendors wrote their own 80211 layers inside their drivers.
According to Airlie, if AMD needs to provide support for additional functionality, such as FreeSync or new HDMI features, this should be done together by expanding existing interfaces, rather than coming up with new levels of abstraction and creating driver-specific ioctl. Airlie reproached AMD for staying away from the graphics community by closing in its own bunker.
December 9, 2016, one of the leading Linux developers at AMD Alexander Deucher wrote a great answerto the core maintainer. He said that in this discussion, the reasons for which many people are tired of working with upstream Linux are well manifested. He considers it inappropriate in a technical discussion to attack the company and its corporate culture. This is probably due to the fact that Dave Airlie himself spent too much time in the isolated Red Hat bunker (Dave is the chief lead programmer for Red Hat, a LinkedIn profile ).
An AMD representative said that they have a very small team of Linux developers who have been working on this topic for a long time. They do everything they can - the Linux drivers are almost as good as the drivers for Windows, and as for the universal Linux kernel interfaces, they always broke several drivers with each kernel update. If we rewrite the current HAL from AMD using a universal interface, you will have to sacrifice stability and limit the functionality of the equipment.
Apparently, the discussion on the Linux kernel developers mailing list continues today.