The Exciting Features Of The Linux 4.9 Kernel

[speculatrix]

a useful summary, thanks.

[dungeon]

debian stable has llvm 3.5/kernel-3.16 so probably it's impossibru forever

That does not matter Debian stable has backports repo, with that mesa 12.0.3 llvm 3.8 including amdgpu is there... altough not those SI/CIK experimental enabled of course
But if AMD say, hey we are dropping support beware... then we can advice users to switch to backports or even new stable

Those who use stock things like distro 3.16 kernel, stock distro mesa, etc... likely will stay where that is, so it is not a problem at all - anyone know things can break on any upgrade

[dungeon]

It is simple as that in Debian stable, if you are afraid something will break then do not upgrade it and that is user choice *only* as default does not upgrade nothing of that kind anyway.

[dungeon]

Yeah and if someone think on distro upgrade problems, then we can write errata for that if needed... so even that is not a problem

[frosth]

😉 i am not afraid about debian.

[frosth]

Nor xfce, ofc

[dungeon]

There is not what to be afraid of as this is not about some DE, nor Debian nor any distro at all.

People ask AMD to made some sort of clarification but they usually can't clarify or even speak about this or that and then throw something even worse than that

[agd5f]

Some notes:

- You just wrote that userspace is unable to tell to which kernel driver it is talking to.

I never said that. Consider the following case. A user has an old distro, etc. that has usermode drivers (ddx, mesa) that only have radeon support (no amdgpu support). They build a new kernel and amdgpu gets loaded on their device rather than radeon as a kernel driver. X tries to start and fails since the amdgpu kernel driver has a different interface than the radeon kernel driver. User ends up with no X.

- xorg-server and Mesa are compatible with either kernel driver. It's just a matter of one line in xorg.conf to tell xorg-server which display driver to use: radeon, amdgpu, or modesetting.

- The 'userspace' can edit a file like /etc/modprobe.d/blacklist.conf or alternatively, if blacklist.conf is too late, the 'userspace' can put "modprobe.blacklist=radeon" or "modprobe.blacklist=amdgpu" on the kernel command line in /boot/grub/grub.conf.

In summary, I do not agree that making amdgpu the default driver will break the userspace. The userspace may be capable of handling the situation.

Sure, there are all sorts of ways to work around it, but it breaks an existing set up which is generally not allowed; user updates kernel, X breaks. If you are going to jump through all of these hoops, you can just as easily explicitly enable CI support in amdgpu in the kernel on your system.

[dungeon]

Is that new Ubuntu Unity effect? 8 panels corruption

[dungeon]

Better spot a point that someone posted of intel breaking userspace on some Atom, X started but user can't see obvious ... how that bug is differ then breaking userspace i don't know. People will reboot there and start old kernel anyway

GPU drivers are full of bugs and can't work everywhere every time, so even breaking userspace is a normal thing there.