AMD Is Trying To Make It Easier To Update Radeon Linux Graphics Drivers

[phoronix]

Phoronix: AMD Is Trying To Make It Easier To Update Radeon Linux Graphics Drivers

It looks like AMD developers have an initiative underway to make the process easier of updating the Radeon Linux graphics drivers whether it be the fully open-source driver stack or the hybrid AMDGPU-PRO driver...

http://www.phoronix.com/scan.php?page=news_item&px=Radeon-Unified-Linux-Updates

[Serafean]

Looking forward to their unified system for updating on Slackware, Gentoo, Archlinux, Debian, Redhat... </sarcasm>
Just go upstream, and do it early enough.

[OneBitUser]

It is very easy to update amdgpu driver now. DKMS drivers are much complicate, you need headers and compatible kernel. With nvidia driver you must work without X running. No thanks anything else than update Oibaf ppa
[...]
What Amd could do is to sync the Linux mainline kernel and above git repo. It would be nice if Amd and Intel produce latest Mesa packages for distributions. There is no guarantee how long Oibaf will continue his great work.

The whole point of the original comment and this article was to state that they want to make AMDGPU-PRO as easy to install as Mesa by better sharing the foundations.
If I understood it correctly, that is.

[FireBurn]

Looking forward to their unified system for updating on Slackware, Gentoo, Archlinux, Debian, Redhat... </sarcasm>
Just go upstream, and do it early enough.

They do try and get their stuff upstream as early as possible, and the time taken for each generation is getting less. We on Gentoo are always able to run the latest code, either released or directly from git. The same goes for Archlinux and other rolling releases. They'll no doubt provide RPMs and Debs and source code for everyone else's distros

[vsteel]

Someone please explain this to me. If AMD works on their driver and also works on the open source driver, why have two different driver stacks? I get Nvidia where they work on their stack and only give a nod once in a while to the open source effort, but AMD, by my guesstimates really puts work into the open source driver. It seems to me like AMD is driving a forked effort, why not combine the effort into a single driver?

[Michael]

Someone please explain this to me. If AMD works on their driver and also works on the open source driver, why have two different driver stacks? I get Nvidia where they work on their stack and only give a nod once in a while to the open source effort, but AMD, by my guesstimates really puts work into the open source driver. It seems to me like AMD is driving a forked effort, why not combine the effort into a single driver?

The AMDGPU kernel driver is shared by both the fully-open and AMDGPU-PRO hybrid driver... No duplication of effort there.

The only real duplicate is the AMDGPU-PRO OpenGL user-space code and RadeonSI. But the AMDGPU-PRO OpenGL driver is shared with Windows OpenGL code-base and they need to maintain that code for workstation users needing OpenGL compat profiles, etc.

[OneBitUser]

Someone please explain this to me. If AMD works on their driver and also works on the open source driver, why have two different driver stacks? I get Nvidia where they work on their stack and only give a nod once in a while to the open source effort, but AMD, by my guesstimates really puts work into the open source driver. It seems to me like AMD is driving a forked effort, why not combine the effort into a single driver?

bridgman and others have explained that enterprise distributions and pro users often need a certified driver, while consumers can get the open-source stack easily and painlessly as part of their distribution. The two stacks already share a lot (for instance the kernel module), but they are targeted at different users and use-cases. Try and think of them as Firepro and Radeon drivers.
I would hazard a guess that in the long run the fully open stack can replace the closed one in nearly all use-cases.

Meanwhile nVidia shares its drivers across multiple platforms if I understood their model correctly. Something similar-ish is in the works at AMD as well, with cross-platform shared code among different drivers baing a goal.

[Dremor]

I'm no kernel specialist, but maybe they could make a open-source kmod-based driver. Like this they can bring all the interesting stuff without having to wait for Linus to mainline their code.

[Peter Fodrek]

12th Lesson of basic Linux course teached by myself is named Buildtools(Autotools), rpm,deb package production, Own repository building and using and some litle additions. I think this is solution here. Maybe kGraft will be helpfull
in Czech

https://www.root.cz/clanky/zaplatovani-jadra-za-behu-kgraft-to-zvladne-bez-vypadku/

In English(less informational)

https://unix.stackexchange.com/questions/193809/linux-kernel-live-patching-whatis-and-howto

[bridgman]

It is up to the Amd developers what they send to the mainline Linux kernel. Now they send very few patches compared what they have in git wip repositories. That is why the mainline kernel amdgpu driver is partially implemented and buggy.

Huh ?

Commits in the internal trees are sorted into three buckets:

- major changes, which get queued in drm-next-<whatever the next kernel is> for the next drm merge window (typically Dave does this starting rc5)

- bug fixes, which get sent to drm-fixes-<whatever the current kernel is>

- WIP changes not ready for upstream yet (new display code is the main one IIRC)

Where do you get the idea that the developers are sending "very few patches" ? Are you sure you are looking at both drm-next and drm-fixes ?