On December 8, 2016, AMD unveiled the latest version of the proprietary AMDGPU-PRO 16.50 driver for operating systems on the Linux kernel. This driver is based on the free AMDGPU core module. It provides DirectGMA support for OpenGL and FreeSync technology, which in some hybrid and AMD graphics processors solves the problem of communication between the processor and the monitor and eliminates image gaps, especially in games. AMDGPU-PRO 16.50 supports some models of GNC 1.0 graphics accelerators AMD Series Southern Islands, namely the Radeon R7 M465X, AMD Radeon R7 M370 and AMD Radeon R7 M350. Published scripts for installation on RedHat Enterprise Linux 7.3, CentOS 7.3, CentOS 6.8, and SLED / SLES 12 SP2.

At the same time, AMD spokesman Harry Wentland addressed the Linux kernel developers mailing list with a proposal to include a modest patch of about 100,000 lines of code with a layer of hardware abstractions into the kernel. Maintainer core Dave Airlie (Dave Airlie) clearly explained to an AMD representative why such a patch would not be accepted into the core. Although the maintainer did not recall Linus' famous phrase to Nvidia , many people remember those words. AMD was also sent on foot, albeit not in such a rough form.

')

New driver

AMDGPU-PRO 16.50 driver provides support for OpenGL 4.5, GLX 1.4, OpenCL 1.2, Vulkan 1.0, VDPAU API, and Vulkan support in Dota 2. It includes basic graphics and power management features, a GPL-compatible kernel module, compatible with technologies ADF (Atomic Display Framework) and KMS (Kernel Mode Setting).

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.


Developers warn about some known bugs of the new driver. For example, the possibility of a complete freeze when the display is hot-plugged in while the computer is turned on, the inability to determine the mode of operation (modeset) when the monitor is hot-plugged in Red Hat Enterprise Linux 7.3, and incompatibility with the EnSight 10 benchmark.

Links to binaries:

• 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!

Simultaneously with the release of the driver, AMD representative Harry Wentland (Harry Wentland) addressed the kernel developer mailing list with a proposal to include a patch for the AMDGPU module supplied as part of the Linux kernel, reworking the display control code (Display Core) to provide support for the next generation GPU (uGPU ), as well as adding a number of innovations, such as tools for organizing audio output via HDMI and DisplayPort.

There is a big discussion around this proposal. At first , a representative of AMD was gently and then firmly explained that such a patch would not be accepted into the core, because AMD is trying to integrate its own hardware abstraction layer (HAL) instead of using a uniform interface for all drivers.

Maintainer core Dave Airlie explained very simply: “No HAL. We do not embed layers of hardware abstractions into the core. In DRM (Direct Rendering Manager), we also do not accept such patches if the maintainers do not sleep. They may be convenient for AMD, but for the Linux kernel they offer no advantages and make it difficult to maintain code. I have been supporting this code base for more than 10 years, and in all the years only the smerdzhil patch has been done 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 settle for that again. ”

Dave Airlie said that he was definitely not going to undermine Linus' trust and merge 100,000 lines of hardware abstractions into the core, and Airlie is also not going to rewrite this code.

Maintainer hoped that AMD would not threaten to leave the latest versions of AMD video cards without support if this HAL is not included in the core. 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, said Airlie: “The kernel is larger than any of us, and it has standards of what is acceptable and what is not.” Maintainer recommended to colleagues from AMD 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 jointly by expanding existing interfaces, rather than inventing new levels of abstraction and creating driver-specific ioctl. Airlie reproached AMD for keeping aloof from the graphic community, closing in "its own bunker."

On December 9, 2016, AMD Deucher, one of AMD's leading Linux developers, wrote a great answer to the kernel maintainer. He said that in this discussion, the reasons why many people are tired of working with upstream Linux are well manifested. He considers it inappropriate to attack a company and its corporate culture in a technical discussion. This is probably due to the fact that Dave Airlie himself spent too much time in an isolated Red Hat bunker (Dave is the chief lead programmer for Red Hat on LinkedIn ).

The representative of AMD said that they have a very small team of Linux-developers who have been working in 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 interfaces of the Linux kernel, with each update of the kernel they always break several drivers. If you rewrite the current HAL from AMD on a universal interface, you will have to sacrifice stability and limit the functionality of the equipment.

Apparently, the discussion on the Linux kernel developer mailing list will continue today.