Linux Kernel LTS release is now for 6 years instead of 2(arstechnica.com)
arstechnica.com
Linux Kernel LTS release is now for 6 years instead of 2
https://arstechnica.com/gadgets/2017/09/android-users-rejoice-linux-kernel-lts-releases-are-now-good-for-6-years/
5 comments
The future dates you are quoting were recently updated to those dates, see eg. http://web.archive.org/web/20170501160354/https://www.kernel... (also they're just from an unexplained column called "projected EOL")
Last year the announced commitment was just 2 years: https://www.linux.com/news/44-linux-kernel-long-term-support...
Last year the announced commitment was just 2 years: https://www.linux.com/news/44-linux-kernel-long-term-support...
I'm not sure I get your point.
> The future dates you are quoting were recently updated to those dates
Nope, I see same dates there (except 4.4 which I didn't quote in my above comment contrary to what you seem to be claiming)
> also they're just from an unexplained column called "projected EOL
Just like the current page: https://www.kernel.org/category/releases.html
> Last year the announced commitment was just 2 years
My post quoted other kernels, not 4.4, which this news article is about. My point is that a kernel version doesn't get 6 year treatment for the first time thing as this PR/news piece paints it out.
> The future dates you are quoting were recently updated to those dates
Nope, I see same dates there (except 4.4 which I didn't quote in my above comment contrary to what you seem to be claiming)
> also they're just from an unexplained column called "projected EOL
Just like the current page: https://www.kernel.org/category/releases.html
> Last year the announced commitment was just 2 years
My post quoted other kernels, not 4.4, which this news article is about. My point is that a kernel version doesn't get 6 year treatment for the first time thing as this PR/news piece paints it out.
Ok, my mistake about the quoting.
About the substance, I think the public commitment for 6 years for 4.4 has more relevance than just PR.
About the substance, I think the public commitment for 6 years for 4.4 has more relevance than just PR.
I have mixed feelings. The modus operandi should be to get upgrades to the current stable kernel frequently enough, not to backport bugfixes to 6 year old kernels.
Integrating a new kernel into an embedded device can be quite time consuming, and new kernels may introduce new bugs.
For example, back when I was working with Sheevaplugs, I found that, say, kernel whatever.13 worked really well, but whatever.14 and later would provide significant glitching in USB audio.
Each new kernel can require a lot of time configuring for the use case at hand, building, testing, etc. And then if a significant new subsystem is added (systemd-related features, for example) or internal kernel architecture changes, it would be incredibly time consuming to update the rest of the toolchain and on-device software to match the new kernel, and then validate the device performance again.
So it is better to have LTS versions with minimal changes. This makes security updates more likely on critical embedded devices, since manufacturers can updare the kernel without being forced to retool a ton of unrelated software.
For example, back when I was working with Sheevaplugs, I found that, say, kernel whatever.13 worked really well, but whatever.14 and later would provide significant glitching in USB audio.
Each new kernel can require a lot of time configuring for the use case at hand, building, testing, etc. And then if a significant new subsystem is added (systemd-related features, for example) or internal kernel architecture changes, it would be incredibly time consuming to update the rest of the toolchain and on-device software to match the new kernel, and then validate the device performance again.
So it is better to have LTS versions with minimal changes. This makes security updates more likely on critical embedded devices, since manufacturers can updare the kernel without being forced to retool a ton of unrelated software.
This side-steps the question of why these smartphones, with more computing power than desktop computers 15 years ago, can't use new mainline kernels, while desktop computers 15 years ago, and desktop computers today, can.
It's few different factors, like: Smartphones are harder to reverse-engineer, because of the smaller parts and greater integration and fewer common interconnects. Smartphones are more diverse, and each SoC "architecture" is significantly changed or replaced after just a year or two.
There's never enough time and mindshare for third-parties or the vendor itself to write high-quality base system drivers for these things. There's just crappy vendor "BSP" code that's never good enough to maintain support for multiple generations in the same code tree. It's always "fork and add messy hacks until it works". There's never enough time and motivation to make any of this support code good enough to be reused.
Some kernel maintainers have tried for some time to convince "enterprise" linux distros to keep up with newer kernels, and apply more of their testing and validation effort to newer kernels, instead of just maintaining one old kernel on their own for most of a decade. This enables more sharing of this effort between multiple distros and other users of the linux kernel. To some extent they have succeeded. But where they have failed, at least the "enterprise" distros did maintain the old kernels they distribute.
But these smartphone SoC vendors don't even do that. They really give zero fucks about software quality. It seems to work, ship it, move on to the next iteration because it has to make it to market in X months to keep up with the competition. At that rate, third-parties can't even come close to keeping up and justifying the investment of effort in reverse-engineering (which has been done for a lot of desktop hardware).
It's few different factors, like: Smartphones are harder to reverse-engineer, because of the smaller parts and greater integration and fewer common interconnects. Smartphones are more diverse, and each SoC "architecture" is significantly changed or replaced after just a year or two.
There's never enough time and mindshare for third-parties or the vendor itself to write high-quality base system drivers for these things. There's just crappy vendor "BSP" code that's never good enough to maintain support for multiple generations in the same code tree. It's always "fork and add messy hacks until it works". There's never enough time and motivation to make any of this support code good enough to be reused.
Some kernel maintainers have tried for some time to convince "enterprise" linux distros to keep up with newer kernels, and apply more of their testing and validation effort to newer kernels, instead of just maintaining one old kernel on their own for most of a decade. This enables more sharing of this effort between multiple distros and other users of the linux kernel. To some extent they have succeeded. But where they have failed, at least the "enterprise" distros did maintain the old kernels they distribute.
But these smartphone SoC vendors don't even do that. They really give zero fucks about software quality. It seems to work, ship it, move on to the next iteration because it has to make it to market in X months to keep up with the competition. At that rate, third-parties can't even come close to keeping up and justifying the investment of effort in reverse-engineering (which has been done for a lot of desktop hardware).
Because Linux doesn't maintain stable kernel API/ABIs, which requires either a shim to the more stable driver (a "midlayer") and ongoing development that's unlikely to get mainlined or a shim to a binary blob for the numerous hardware developers who don't want to open-source details of their hardware.
Linus is also incapable of dealing with these companies in a way that they care about (see the middle finger to nVidia) so it's unlikely there's going to be any real progress. This is a fact: no company wants to spend resources chasing after every new kernel development if it doesn't specifically suit their needs. Windows solved this by having stable APIs that only rarely change. OS X solved this by making it basically unnecessary -- most of the hardware that needs drivers is either built-in or works over something generic like USB -- and even then has nice interfaces for drivers that are well documented and don't change that often.
Linux attempts to have the freedom of the former without any kernel developer burden, and the outcome is that no HW vendor cares much to contribute upstream since it requires a lot of time and effort that's mostly just a cost
Linus is also incapable of dealing with these companies in a way that they care about (see the middle finger to nVidia) so it's unlikely there's going to be any real progress. This is a fact: no company wants to spend resources chasing after every new kernel development if it doesn't specifically suit their needs. Windows solved this by having stable APIs that only rarely change. OS X solved this by making it basically unnecessary -- most of the hardware that needs drivers is either built-in or works over something generic like USB -- and even then has nice interfaces for drivers that are well documented and don't change that often.
Linux attempts to have the freedom of the former without any kernel developer burden, and the outcome is that no HW vendor cares much to contribute upstream since it requires a lot of time and effort that's mostly just a cost
Linux has built-in support for way more hardware than OS X and full support for generic USB devices (and then some, with "quirks tables" for many standard-but-glitchy devices) so it's hard to say it's worse than OS X in that respect.
You'll also find that there are devices that had decent drivers for Windows XP when they were released, but never had Vista or Windows 7 or later drivers made. Those devices worked well on linux a couple years after they worked on windows with reverse-engineered drivers, and then (ironically) kept working for a decade or more, whereas the windows drivers did not. This includes a variety of printers, sound cards, non-standard usb devices, and more.
It's definitely true that many hardware companies which have modeled their driver development and support around the windows model can't handle the linux model at all. But linux has other priorities than to cater to them, and has done better than windows in server and embedded use-cases as a result.
You'll also find that there are devices that had decent drivers for Windows XP when they were released, but never had Vista or Windows 7 or later drivers made. Those devices worked well on linux a couple years after they worked on windows with reverse-engineered drivers, and then (ironically) kept working for a decade or more, whereas the windows drivers did not. This includes a variety of printers, sound cards, non-standard usb devices, and more.
It's definitely true that many hardware companies which have modeled their driver development and support around the windows model can't handle the linux model at all. But linux has other priorities than to cater to them, and has done better than windows in server and embedded use-cases as a result.
Not spending money on licenses is a major appeal.
The ongoing efforts to drop anything GPL related on each new Android release shows where it is going.
You also gave a good example, OEMs want consumers to buy new devices, not to keep using existing ones.
The ongoing efforts to drop anything GPL related on each new Android release shows where it is going.
You also gave a good example, OEMs want consumers to buy new devices, not to keep using existing ones.
[deleted]
The Sheevaplug and Dreamplug boards were eventually mainlined, weren't they? I wonder what the bug was in USB Audio.
Yes, I was using mainline kernels with realtime patches. Unfortunately I was busy trying to bootstrap a company so I didn't have time to find out what changed in the USB subsystem. Now I'm a backend web engineer and have little time for hardware and kernel dev.
> Today, it's on Google to maintain dead kernels that it is
> still supporting. The 2016 Google Pixel shipped with
> Linux kernel 3.18, which was first released in 2014 and
> hit end-of-life in January 2017.
[deleted]
> The modus operandi should be to get upgrades to the current stable kernel frequently enough
How can you expect embedded manufactures to do this when Intel can't even keep it's CPU line stable on recent kernels. I have an Bay Trail tablet that I put Linux on, but was forced to move it back on to the ancient Android kernel that shipped with it because of this bug[1].
And if you think, these bugs only happen to Atom/Celron CPUs, think again. My Intel i3 laptop just started hard freeing with the latest 4.13 Kernel in Arch.[2]
As a hobbyist, i can deal, but there is no way you can expect small manufactures to deal with the constant influx of bugs introduced by kernel updates.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=109051
[2] https://bbs.archlinux.org/viewtopic.php?id=230676
How can you expect embedded manufactures to do this when Intel can't even keep it's CPU line stable on recent kernels. I have an Bay Trail tablet that I put Linux on, but was forced to move it back on to the ancient Android kernel that shipped with it because of this bug[1].
And if you think, these bugs only happen to Atom/Celron CPUs, think again. My Intel i3 laptop just started hard freeing with the latest 4.13 Kernel in Arch.[2]
As a hobbyist, i can deal, but there is no way you can expect small manufactures to deal with the constant influx of bugs introduced by kernel updates.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=109051
[2] https://bbs.archlinux.org/viewtopic.php?id=230676
> there is no way you can expect small manufactures to deal with the constant influx of bugs introduced by kernel updates
Well then maybe they should not be in the business they are in.
As people so like to point out here, their inability to support the devices they make becomes an externality that all the users end up paying for, when they have to deal with security vulnerabilities that cannot be resolved.
Well then maybe they should not be in the business they are in.
As people so like to point out here, their inability to support the devices they make becomes an externality that all the users end up paying for, when they have to deal with security vulnerabilities that cannot be resolved.
100% agree with this. I started my career backporting fixes to old Kernel's and it is error prone, time intensive, and certainly not catching every bug with security impact.
The focus of the industry should move to shipping up to date software in all devices, particularly in this infrastructure level software.
The focus of the industry should move to shipping up to date software in all devices, particularly in this infrastructure level software.
The constant churn in some of the driver stacks like graphics leaves us with long stretches of serious regressions. So while 4.14 can be perfectly stable in all regards and you might appreciate the new features in general code, it's not unusual that something in your graphics drivers gets broken and stays that way for a year or longer. For example Intel's DRM stack wasn't flawless but didn't have as many regressions before they introduced atomic modesetting in 4.2. From there on it's been hit and miss. 4.9 is fine, 4.12 is fine and 4.13 is pretty bad. I have one machine where I'm forced to stay at 4.1-lts. It's atomic modesetting, fences, etc. that caused many gpu regressions.
What I'm getting at is that there's no stable driver API or ABI and we're forced to suffer through regressions caused by development to support new graphics stack features or new GPUs, while one's "old" GPU was fully supported and stable in earlier kernels. With more and of the desktop and applications using the GPU for compositing, it's very easy to hang your Wayland or Xorg session for seconds until the driver recovers. This is on top of the many DMAR issues.
I don't like using an LTS kernel but I do need stable drivers because without those I cannot use the computer and neither can industrial embedded machines. I admit that it's highly likely that the high churn in the graphics drivers is the cause and it can be singled out, because I don't remember any regression in other drivers. I say it's time to rethink the development model of Linux kernel drm drivers.
What I'm getting at is that there's no stable driver API or ABI and we're forced to suffer through regressions caused by development to support new graphics stack features or new GPUs, while one's "old" GPU was fully supported and stable in earlier kernels. With more and of the desktop and applications using the GPU for compositing, it's very easy to hang your Wayland or Xorg session for seconds until the driver recovers. This is on top of the many DMAR issues.
I don't like using an LTS kernel but I do need stable drivers because without those I cannot use the computer and neither can industrial embedded machines. I admit that it's highly likely that the high churn in the graphics drivers is the cause and it can be singled out, because I don't remember any regression in other drivers. I say it's time to rethink the development model of Linux kernel drm drivers.
that is not going to happen in the industry, unfortunately. I worked there for years. the data in the article is probably correct, it takes about two years from the kernel->cpu_vendor->OEM on the development cycle for a stable product even in the fast-paced consumer electronic market, you just can not upgrade the kernel to chase the new releases which could cause instability chaos in the development team and put off the product delivery dates forever.
As long as Linus refuses to provide a stable driver API, this won’t happen.
OEMs will only pay to write custom drivers for a SoC once, and that means you’ll be stuck with one kernel (or any binary-compatible version). Every device requires entirely custom drivers for this, because ARM has no device enumeration.
Until Torvalds finally stops being so stubborn on this, Android and IoT devices will have such a short lifetime, and people will have to continue backporting fixes to ancient kernels.
OEMs will only pay to write custom drivers for a SoC once, and that means you’ll be stuck with one kernel (or any binary-compatible version). Every device requires entirely custom drivers for this, because ARM has no device enumeration.
Until Torvalds finally stops being so stubborn on this, Android and IoT devices will have such a short lifetime, and people will have to continue backporting fixes to ancient kernels.
I wrote this explanation for the intentional lack of a stable device driver API a decade ago, and it’s still relevant today: https://www.linuxfoundation.org/publications/the-linux-drive...
That’s an explanation, but doesn’t fix the very real issues.
We have a situation today where nvidia works better on Linux than AMD, even though AMD open sourced their entire base driver, and only wants to provide a few modules as proprietary additions (such as an implementation of 3D screenshots as Ansel competitor), because the kernel maintainers refuse to allow any stable ABI in the kernel.
And this is just stubborn, and doesn’t help at all. If this mindset continues, we continue to be stuck with drivers being proprietary DKMS modules. Already today I have to build dozens of proprietary DKMS modules into my kernel all the time, and recompilation times are horrible.
We have a situation today where nvidia works better on Linux than AMD, even though AMD open sourced their entire base driver, and only wants to provide a few modules as proprietary additions (such as an implementation of 3D screenshots as Ansel competitor), because the kernel maintainers refuse to allow any stable ABI in the kernel.
And this is just stubborn, and doesn’t help at all. If this mindset continues, we continue to be stuck with drivers being proprietary DKMS modules. Already today I have to build dozens of proprietary DKMS modules into my kernel all the time, and recompilation times are horrible.
I think you're confusing performance with ease of use.
Top of the line Nvidia hardware beats AMD hardware. As much as I hate to admit it, nvidia's cards perform better across all platforms leading me to believe that they have a real hardware advantage.
Nvidia's cards perform better on Linux than AMD, which I would argue is because Nvidia has more money to throw at the problem. If the issue was the non-stable kernel ABI, then Nvidia surely would be affected in exactly the same way.
AMD cards have more of the "Just Works" thing going for them that Dan mentioned in his article. In terms of ease of use I can't imagine it getting much easier than the driver you need being mainlined.
What I really liked about Dan's article was this bit:
In Linux, hardware support only gets better; it never gets worse.
Top of the line Nvidia hardware beats AMD hardware. As much as I hate to admit it, nvidia's cards perform better across all platforms leading me to believe that they have a real hardware advantage.
Nvidia's cards perform better on Linux than AMD, which I would argue is because Nvidia has more money to throw at the problem. If the issue was the non-stable kernel ABI, then Nvidia surely would be affected in exactly the same way.
AMD cards have more of the "Just Works" thing going for them that Dan mentioned in his article. In terms of ease of use I can't imagine it getting much easier than the driver you need being mainlined.
What I really liked about Dan's article was this bit:
In Linux, hardware support only gets better; it never gets worse.
But that's not the case.
AMDGPU with mesa on any distro I've tried leads to crashes in mesa, it leads to OpenGL not working, and nothing running. The mainline driver is useless, the average result is "the color of a television tuned to a dead channel".
AMDs AMDGPU-PRO proprietary solution at least works sometimes.
In contrast, NVIDIAs proprietary driver always simply works.
AMDGPU with mesa on any distro I've tried leads to crashes in mesa, it leads to OpenGL not working, and nothing running. The mainline driver is useless, the average result is "the color of a television tuned to a dead channel".
AMDs AMDGPU-PRO proprietary solution at least works sometimes.
In contrast, NVIDIAs proprietary driver always simply works.
> any distro I've tried leads to crashes in mesa, it leads to OpenGL not working, and nothing running
I don't know what edge-cases you are trying, but AMDGPU is working fine for most of us, and quickly improving over time.
Don't forget that AMDGPU is only two years old. It's steadily improving, and I have no doubt that within 5 years it will be at least on par with NVIDIA's driver.
> In contrast, NVIDIAs proprietary driver always simply works.
What about Wayland? KMS?
NVIDIA's driver works for the use cases they made it work for. You simply work inside those use cases, so you don't see the rough edges. Their driver team is quite good, which they have to be to swim upstream like they are. As long as they work against Linux instead of with it, open-source drivers like AMDGPU will always have an inherent advantage. In contrast, NVIDIAs proprietary driver always simply works.
I don't know what edge-cases you are trying, but AMDGPU is working fine for most of us, and quickly improving over time.
Don't forget that AMDGPU is only two years old. It's steadily improving, and I have no doubt that within 5 years it will be at least on par with NVIDIA's driver.
> In contrast, NVIDIAs proprietary driver always simply works.
What about Wayland? KMS?
NVIDIA's driver works for the use cases they made it work for. You simply work inside those use cases, so you don't see the rough edges. Their driver team is quite good, which they have to be to swim upstream like they are. As long as they work against Linux instead of with it, open-source drivers like AMDGPU will always have an inherent advantage. In contrast, NVIDIAs proprietary driver always simply works.
> What about Wayland? KMS?
Both of which cause AMDGPU on my system to crash, too. Or they cause the DE to crash.
In fact, I can’t even boot with KMS, because then I just get a black screen.
Both of which cause AMDGPU on my system to crash, too. Or they cause the DE to crash.
In fact, I can’t even boot with KMS, because then I just get a black screen.
Have you brought this is to the attention of the devs? I'd at least hop on freenode #dri-devel and ask around. The people working on this stuff are very accessible, and that is one of the advantages of having an open driver preferably in mainline. Instead of just complaining and accepting poor results, it's a very real possibility to get involved and collaborate with the authors in improving this for yourself and everyone else
After the devs’ fight on the mailing list with AMD, I’ve given up and switched to the proprietary driver. I’d rather use proprietary technology.
After all, the kernel maintainers suggested exactly that: They’d rather have everyone use only proprietary code, than any kind of modularity for drivers in Linux.
After all, the kernel maintainers suggested exactly that: They’d rather have everyone use only proprietary code, than any kind of modularity for drivers in Linux.
The fact that kernel devs are sticking to their guns does not mean that they are not working hard on AMDGPU, it just means they are not compromising to make it easier for AMD to provide the proprietary part (AMDGPU-pro).
AMDGPU-pro is only necessary for features that AMDGPU does not provide, and for the proprietary implementations of Vulkan, OpenCL, HDMI/DP audio (I'm not sure if that has been fixed yet), OpenGL, etc. AMDGPU-pro has nothing to do with KMS or Wayland. It's also worth noting that AMDGPU provides competitive OpenGL and Vulkan performance, so you are better off using it instead of forcing yourself to run an outdated kernel and Xorg that support AMDGPU-pro.
> I’d rather use proprietary technology.
You are free to your own opinion there, but know that there are many of us who care a great deal about open drivers. I, for one, bought 4 AMD cards, partly because of price, but mostly because of the promise of open drivers.
AMDGPU-pro is only necessary for features that AMDGPU does not provide, and for the proprietary implementations of Vulkan, OpenCL, HDMI/DP audio (I'm not sure if that has been fixed yet), OpenGL, etc. AMDGPU-pro has nothing to do with KMS or Wayland. It's also worth noting that AMDGPU provides competitive OpenGL and Vulkan performance, so you are better off using it instead of forcing yourself to run an outdated kernel and Xorg that support AMDGPU-pro.
> I’d rather use proprietary technology.
You are free to your own opinion there, but know that there are many of us who care a great deal about open drivers. I, for one, bought 4 AMD cards, partly because of price, but mostly because of the promise of open drivers.
> You are free to your own opinion there, but know that there are many of us who care a great deal about open drivers. I, for one, bought 4 AMD cards, partly because of price, but mostly because of the promise of open drivers.
I generally care more about open source, too, but when the Linux kernel maintainers tell me to "fuck off" and "just use proprietary drivers", then I’ll do exactly that.
> The fact that kernel devs are sticking to their guns does not mean that they are not working hard on AMDGPU, it just means they are not compromising to make it easier for AMD to provide the proprietary part (AMDGPU-pro).
Well, they are trying to make it harder to do that.
All that would be necessary would be a tiny abstraction layer to add driver extensions for functionality that can not be open source today (because it might be something where AMD is actively competing with NVIDIA).
Instead, I’m forced into running an outdated kernel, outdated Xorg, and proprietary versions of everything.
I generally care more about open source, too, but when the Linux kernel maintainers tell me to "fuck off" and "just use proprietary drivers", then I’ll do exactly that.
> The fact that kernel devs are sticking to their guns does not mean that they are not working hard on AMDGPU, it just means they are not compromising to make it easier for AMD to provide the proprietary part (AMDGPU-pro).
Well, they are trying to make it harder to do that.
All that would be necessary would be a tiny abstraction layer to add driver extensions for functionality that can not be open source today (because it might be something where AMD is actively competing with NVIDIA).
Instead, I’m forced into running an outdated kernel, outdated Xorg, and proprietary versions of everything.
Would you care to provide details relevant to your particular observation case?
I happen to be using Arch Linux (a rolling release distribution) on my main gaming workstation. Thus my R9 285 is supported by Linux 4.13.4, Mesa 17.2.2, and Xorg 1.19.3. My overall system stability appears to be either approximately as stable as, or possibly more so than, the same hardware on a Windows platform.
The only area of issues I run across these days are games that ship their own copies of libraries that /should/ be expected (and should be required) to be native libraries instead. A few games that should work have issues resulting from that general root cause and Steam doesn't always do the best job of utilizing the more up to date native libraries.
Things weren't as bright when I first bought the hardware, but they have improved vastly as support in the drivers caught up, and I am confident that it will not regress in the future, at least not until long past when it would make sense to buy newer hardware.
* What GPU hardware?
* Which release of what distribution?
* What period in time?
* If you happen to recall, what versions of: Linux (kernel), Mesa, and Xorg?
I happen to be using Arch Linux (a rolling release distribution) on my main gaming workstation. Thus my R9 285 is supported by Linux 4.13.4, Mesa 17.2.2, and Xorg 1.19.3. My overall system stability appears to be either approximately as stable as, or possibly more so than, the same hardware on a Windows platform.
The only area of issues I run across these days are games that ship their own copies of libraries that /should/ be expected (and should be required) to be native libraries instead. A few games that should work have issues resulting from that general root cause and Steam doesn't always do the best job of utilizing the more up to date native libraries.
Things weren't as bright when I first bought the hardware, but they have improved vastly as support in the drivers caught up, and I am confident that it will not regress in the future, at least not until long past when it would make sense to buy newer hardware.
Sure.
RX480, Reference Edition.
I’ve tried: Arch Linux, Ubuntu 16.04, 16.10, 17.04 (currently on 16.04), latest Fedora.
Time period: Bought GPU 11 days after official release, been switching distros about every one or two months since due to issues.
Only used distro-provided kernel, Mesa and Xorg.
With AMDGPU, no game works and OpenGL crashes, Wayland crashes, and nothing really works. In all cases.
With AMDGPU-PRO, everything works, except there’s a 50/50 chance on every boot that WebGL in Firefox will be broken.
This is exactly why I criticize the stubborn decision to refuse to allow such a solution. If the DAL is not implemented, we’ll never get feature parity for proprietary functionality between the Windows, Linux and Mac versions. AMD is known to release all their tech openly as soon as possible, but while they’re competing with NVIDIA in a space, they obviously can’t keep it 100% open.
And it’s also obvious that if AMD wants the same functionality on Windows, Linux, Mac and Android, they either need a DAL, or they need to let the Linux maintainers control their drivers for all other platforms.
RX480, Reference Edition.
I’ve tried: Arch Linux, Ubuntu 16.04, 16.10, 17.04 (currently on 16.04), latest Fedora.
Time period: Bought GPU 11 days after official release, been switching distros about every one or two months since due to issues.
Only used distro-provided kernel, Mesa and Xorg.
With AMDGPU, no game works and OpenGL crashes, Wayland crashes, and nothing really works. In all cases.
With AMDGPU-PRO, everything works, except there’s a 50/50 chance on every boot that WebGL in Firefox will be broken.
________________
This is exactly why I criticize the stubborn decision to refuse to allow such a solution. If the DAL is not implemented, we’ll never get feature parity for proprietary functionality between the Windows, Linux and Mac versions. AMD is known to release all their tech openly as soon as possible, but while they’re competing with NVIDIA in a space, they obviously can’t keep it 100% open.
And it’s also obvious that if AMD wants the same functionality on Windows, Linux, Mac and Android, they either need a DAL, or they need to let the Linux maintainers control their drivers for all other platforms.
> they obviously can’t keep it 100% open.
Why not?
Even if you honestly believe that it is a good idea to hide superior driver code (which it is not), AMD doesn't have any. NVIDIA has had superior proprietary drivers since AMD acquired ATI.
Why not?
Even if you honestly believe that it is a good idea to hide superior driver code (which it is not), AMD doesn't have any. NVIDIA has had superior proprietary drivers since AMD acquired ATI.
It’s not that simple.
AMD has to license code from other third parties, too (which is a common reason for proprietary code), and in some situations (as with the new tiled rasterizer of VEGA, which with its beta drivers gets 2x the performance of the open driver), it has significant advantages over what NVIDIA has.
AMD always has opened as much as possible, as soon as possible, but there’s situations where that’s not directly possible.
And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
AMD has to license code from other third parties, too (which is a common reason for proprietary code), and in some situations (as with the new tiled rasterizer of VEGA, which with its beta drivers gets 2x the performance of the open driver), it has significant advantages over what NVIDIA has.
AMD always has opened as much as possible, as soon as possible, but there’s situations where that’s not directly possible.
And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
> AMD always has opened as much as possible, as soon as possible, but there’s situations where that’s not directly possible.
This is the problem with proprietary software. There are politics involved. Note that when I refer to AMD, I am referring to a group of people, not a single individual. Those at AMD and those third parties that they work with that insist on proprietary software have made my life miserable. The hours I have spent trying to find a stable configuration to run fglrx are a direct result of their belief in the need for proprietary software. I'm sick of their excuses. I'm happy to finally have a free driver for my RX480. It's not perfect, but it's a leap in the right direction.
> And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
That is true. I see that as AMD's fault, not the Linux devs'.
This is the problem with proprietary software. There are politics involved. Note that when I refer to AMD, I am referring to a group of people, not a single individual. Those at AMD and those third parties that they work with that insist on proprietary software have made my life miserable. The hours I have spent trying to find a stable configuration to run fglrx are a direct result of their belief in the need for proprietary software. I'm sick of their excuses. I'm happy to finally have a free driver for my RX480. It's not perfect, but it's a leap in the right direction.
> And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
That is true. I see that as AMD's fault, not the Linux devs'.
> That is true. I see that as AMD's fault, not the Linux devs'.
And I disagree with that. AMD has said they'd publish it openly, but only in a version that relies on their abstraction layer.
Because implementing it the first time already is over budget and past deadline, implementing it twice would be impossible.
You can have a working, open source, version in a few weeks just by compiling AMDs kernel branch, and modules. But you'll never get it in mainline. And mainline will always be months or years behind.
And I disagree with that. AMD has said they'd publish it openly, but only in a version that relies on their abstraction layer.
Because implementing it the first time already is over budget and past deadline, implementing it twice would be impossible.
You can have a working, open source, version in a few weeks just by compiling AMDs kernel branch, and modules. But you'll never get it in mainline. And mainline will always be months or years behind.
I got an RX480 (no idea what edition) at the start of the year and it worked fine with with arch and ubunutu gnome 17.04. I've had some issues like the occasional system freeze and one game in particular always freezing but it's been stable for the most part. Other distros (including earlier ubuntu) went into some horribly unusable resolution on boot.
I was annoyed at the teething problems too, but the progress has been good enough that I stable API doesn't seem necessary. If they hadn't tried to work in their own abstractions then the progress might have been better.
I was annoyed at the teething problems too, but the progress has been good enough that I stable API doesn't seem necessary. If they hadn't tried to work in their own abstractions then the progress might have been better.
> If they hadn't tried to work in their own abstractions then the progress might have been better.
Not really. You're still so stubborn about having no DAL.
How do you propose should AMD develop an additional driver functionality for Linux, Mac, Windows and Android, and release them on the same day, without writing code twice, without such a DAL?
You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes.
But that's not true for GPU drivers anymore.
GPU drivers have to get feature updates every few weeks, and add new functionality and new APIs on all platforms at the same time with the same APIs. Often APIs that are completely new.
You can't write all this functionality 5 times for every platform while staying competitive with NVIDIA. The only choice is having a stable ABI to write driver extensions that implement the same new functionality for all platforms, or you'll never get the functionality.
And, guess what, that's exactly what happened.
Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux.
AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. They absolutely can not release new features every week for the mainlined driver in the official kernel and write them separately for every OS. The alternative is a DAL, or no functionality.
Thank you for driving more users to Windows.
Not really. You're still so stubborn about having no DAL.
How do you propose should AMD develop an additional driver functionality for Linux, Mac, Windows and Android, and release them on the same day, without writing code twice, without such a DAL?
You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes.
But that's not true for GPU drivers anymore.
GPU drivers have to get feature updates every few weeks, and add new functionality and new APIs on all platforms at the same time with the same APIs. Often APIs that are completely new.
You can't write all this functionality 5 times for every platform while staying competitive with NVIDIA. The only choice is having a stable ABI to write driver extensions that implement the same new functionality for all platforms, or you'll never get the functionality.
And, guess what, that's exactly what happened.
Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux.
AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. They absolutely can not release new features every week for the mainlined driver in the official kernel and write them separately for every OS. The alternative is a DAL, or no functionality.
Thank you for driving more users to Windows.
> and release them on the same day
That isn't necessary.
> without writing code twice
That isn't anywhere near as difficult as you make it out to be. Writing code is not difficult, or particularly time-consuming. Designing code is.
Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. to run incorrectly to optimize for a specific proprietary game engine. Those updates are to the OpenGL/etc. implementation itself, not the communication with the kernel, meaning those changes will be similar, if not exactly the same in each driver, without any extra abstraction. Also remember that most of these AAA title games do not have Linux support in the first place, and many of them only support DirectX, which will not be implemented in the Linux driver.
Here in Linux, we care about FPS in proprietary game engines much less than correct working drivers.
> You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes.
It's true that graphics APIs (especially Vulkan) are continually changing, and that those changes must be implemented in each driver. That still does not mean it is significantly easier to write one implementation for windows, and just copy it to the Linux driver. In fact, those who work on Linux itself believe the opposite. It's also worth noting that Vulkan is meant to be so low-level that its implementations will likely be quite different between Windows and Linux.
> AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality.
If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me.
> Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux.
You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. That means you are relying on AMD alone to implement them, so I am entirely unable to help you. That is the situation we started with for the entire driver, and AMDGPU marks a significant improvement.
You may believe that Linux devs compromising to allow AMD to create a complicated layer in their mainline driver would help them, but I don't believe that to be the case, and neither do they.
The true reason that AMD wants a DAL in their driver is that they aren't willing to entirely discard their old habits, and instead insist on a driver that is, at least partially, closed source. As long as they do that, they require themselves to do wildly unnecessary work, and create entirely worthless incompatibilities, purely out of stubbornness. Stubbornness that will continue to be reciprocated by the Linux dev team.
I will continue to do what I can to support AMD, as long as they make strides toward Free drivers, but I know there are always politics involved, and that AMD won't change overnight.
That isn't necessary.
> without writing code twice
That isn't anywhere near as difficult as you make it out to be. Writing code is not difficult, or particularly time-consuming. Designing code is.
Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. to run incorrectly to optimize for a specific proprietary game engine. Those updates are to the OpenGL/etc. implementation itself, not the communication with the kernel, meaning those changes will be similar, if not exactly the same in each driver, without any extra abstraction. Also remember that most of these AAA title games do not have Linux support in the first place, and many of them only support DirectX, which will not be implemented in the Linux driver.
Here in Linux, we care about FPS in proprietary game engines much less than correct working drivers.
> You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes.
It's true that graphics APIs (especially Vulkan) are continually changing, and that those changes must be implemented in each driver. That still does not mean it is significantly easier to write one implementation for windows, and just copy it to the Linux driver. In fact, those who work on Linux itself believe the opposite. It's also worth noting that Vulkan is meant to be so low-level that its implementations will likely be quite different between Windows and Linux.
> AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality.
If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me.
> Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux.
You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. That means you are relying on AMD alone to implement them, so I am entirely unable to help you. That is the situation we started with for the entire driver, and AMDGPU marks a significant improvement.
You may believe that Linux devs compromising to allow AMD to create a complicated layer in their mainline driver would help them, but I don't believe that to be the case, and neither do they.
The true reason that AMD wants a DAL in their driver is that they aren't willing to entirely discard their old habits, and instead insist on a driver that is, at least partially, closed source. As long as they do that, they require themselves to do wildly unnecessary work, and create entirely worthless incompatibilities, purely out of stubbornness. Stubbornness that will continue to be reciprocated by the Linux dev team.
I will continue to do what I can to support AMD, as long as they make strides toward Free drivers, but I know there are always politics involved, and that AMD won't change overnight.
> That isn't necessary.
Yes it is, if you care about your users.
> Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. t
Thanks to Vulkan that’s irrelevant anyway – I’m talking about stuff like shadowplay or similar functionality, and the APIs for that.
> It's true that graphics APIs (especially Vulkan) are continually changing
> You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for.
Stop being so stubborn, please. You still don’t get it. I’m not talking about the graphics APIs, which change on a scale of months to years.
I’m talking about exactly these additional functionalities, which are basically addons to the driver, hook into the driver, and for example dump the driver state at a moment (for 3D screenshots), or keep a memory buffer of the current videostream (for instant replay and share), or so on.
None of this functionality has to be closed source.
If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them.
> If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me.
You mean, developers that still don’t get the entire point of what I’ve been talking about, developers that suggest they’d rather have people use Windows than add a stable driver ABI into Linux, developers that want to force a release cycle of several years onto drivers?
Because that’s the reality of forcing drivers to be mainlined without a stable ABI.
The majority of users will be stuck on a several year old kernel.
How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?
Yes it is, if you care about your users.
> Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. t
Thanks to Vulkan that’s irrelevant anyway – I’m talking about stuff like shadowplay or similar functionality, and the APIs for that.
> It's true that graphics APIs (especially Vulkan) are continually changing
> You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for.
Stop being so stubborn, please. You still don’t get it. I’m not talking about the graphics APIs, which change on a scale of months to years.
I’m talking about exactly these additional functionalities, which are basically addons to the driver, hook into the driver, and for example dump the driver state at a moment (for 3D screenshots), or keep a memory buffer of the current videostream (for instant replay and share), or so on.
None of this functionality has to be closed source.
If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them.
> If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me.
You mean, developers that still don’t get the entire point of what I’ve been talking about, developers that suggest they’d rather have people use Windows than add a stable driver ABI into Linux, developers that want to force a release cycle of several years onto drivers?
Because that’s the reality of forcing drivers to be mainlined without a stable ABI.
The majority of users will be stuck on a several year old kernel.
How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?
And now it's 10 years later and it clearly hasn't worked. Time to revisit old assumptions and learn something new.
If it hasn't worked, why has no one forked the kernel and left Linus in the dust?
Manufacturers ought to support their products for their full lifecycle instead of behaving like e-waste factories. If they're not happy about unstable kernel ABIs, they can start making Windows devices.
Manufacturers ought to support their products for their full lifecycle instead of behaving like e-waste factories. If they're not happy about unstable kernel ABIs, they can start making Windows devices.
Allow me to play The Devil's Advocate: Those aggrieved by the lack of a Linux driver ABI have indeed forked the kernel, and some of them even maintain their forks. They just happen to be focussed solely on their own needs and thus their forks happen to be specific to their business requirements alone. Take Qualcomm's CodeAurora hosted repos for one: maintained for years, with backporting and new releases based on new upstream releases, all merged with Qualcomm's drivers for their own hardware.
The reason no one has left Linus['s repo] in the dust is because no one has taken the effort to put out and maintain a general purpose API-standardised fork instead of heavily-customised, specific-to-their-own-business codebases.
The reason no one has left Linus['s repo] in the dust is because no one has taken the effort to put out and maintain a general purpose API-standardised fork instead of heavily-customised, specific-to-their-own-business codebases.
This isn't up to manufacturers, but up to SoC vendors. And not even just to them.
They also just combine many chips into their systems, and also get precompiled driver blobs.
You're asking the entire tech industry to change how they're doing things.
They also just combine many chips into their systems, and also get precompiled driver blobs.
You're asking the entire tech industry to change how they're doing things.
[deleted]
Or they could put drivers in that are upstreamable.
That’s not easily possible – most ARM SoCs have no device enumeration, so you need to hardcode the memory addresses and physical ports of everything. These are different for every single chip.
EDIT: yes, some problems are now solved with Device Tree, but from my experience building Android ROMs, that doesn't solve half of the problems (as many SoCs have special custom hardware, too)
EDIT: yes, some problems are now solved with Device Tree, but from my experience building Android ROMs, that doesn't solve half of the problems (as many SoCs have special custom hardware, too)
This is what DeviceTree solves. Not using DeviceTree now for SoC drivers is just pure laziness.
https://elinux.org/Device_Tree_Reference
https://elinux.org/Device_Tree_Reference
Well, Device Tree solves some of the issues, but sadly not all of them.
A more stable ABI would certainly help a lot.
A more stable ABI would certainly help a lot.
Isn't that what devie-tree and those dts/dtb/dto files starting to appear under the arch/arm/ tree in the kernel source are meant to address?
Is it all that unreasonable? I don't see that Google's Zircon kernel has API guarantees either, but as the driver model doesn't require mainlining, it suggests the code can remain under wraps and ostensibly kernel specific.
If Zircon is a proper microkernel system, then it ought to have such guarantees. But it's too early to tell anything about Zircon and at what end of the microkernel spectrum it will land.
Does FreeBSD or NetBSD have a stable ABI?
The kernel ABI is stable between major version numbers. It is never intentionally broken between majors. More importantly, the kernel APIs are very stable, which seems to be intentionally broken on Linux regularly.
Userland ABI is much more stringent, pretty much any commercially used OS will maintain compatibility for old applications indefinitely, Linux and Free and Net BSD included.
Userland ABI is much more stringent, pretty much any commercially used OS will maintain compatibility for old applications indefinitely, Linux and Free and Net BSD included.
> which seems to be intentionally broken on Linux regularly
Please provide evidence to back the claim of intent. This comes across as if you're implying malice, when it's far more likely interfaces change in the natural course of development where there are no restraints like abi/api stability commitments.
Please provide evidence to back the claim of intent. This comes across as if you're implying malice, when it's far more likely interfaces change in the natural course of development where there are no restraints like abi/api stability commitments.
Yes, especially for the y part of X.y. [1] Although since version 7 multiple symbols are supported. [2] If you're interested in what the release engineering team has to say about it this page [3] contains more details.
[1] https://wiki.freebsd.org/Releng/ABI [2] https://wiki.freebsd.org/BinaryCompatibility [3] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd...
[1] https://wiki.freebsd.org/Releng/ABI [2] https://wiki.freebsd.org/BinaryCompatibility [3] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd...
Yes, the *BSDs, all proprietary UNIX variants, Windows, mainframes and pretty most everyone else with exception of Linux.
FreeBSD has a stable kernel ABI for each release and is allowed to break it in a new version. This allows nVidia to have an easier time providing binary drivers on FreeBSD.
I agree. But maybe this is what's needed to get the companies that depend on such long term support to actually contribute their on-going patches publicly rather than only internally?
Ostensibly any patches found in an LTS kernel, must first be proven in a mainline release. But it'll be interesting to see just exactly how old and crusty these kernels end up becoming.
Ostensibly any patches found in an LTS kernel, must first be proven in a mainline release. But it'll be interesting to see just exactly how old and crusty these kernels end up becoming.
You'd hope so. In reality, though, if they haven't been contributing by this point, they probably aren't going to bother doing it now either.
Tell that to Android chip makers and OEMs.
It almost never happens. A chip and device dies with the first and only kernel that were supported on them.
It almost never happens. A chip and device dies with the first and only kernel that were supported on them.
On the video of the keynote he mentions that even Treble is pretty much WIP, where Google expects cooperation from them, regarding the goals of moving everyone forward.
This seems to apply to 4.4; according to https://www.kernel.org/category/releases.html 4.9 has not been extended, so it only applies every few years that there will again be six year support.
4.4 is Google's base to develop Nougat
If, as per the table below [1], they've already moved on to 4.10, then 6 years is a long time to support 4.9
[1] https://android.stackexchange.com/questions/51651/which-andr...
If, as per the table below [1], they've already moved on to 4.10, then 6 years is a long time to support 4.9
[1] https://android.stackexchange.com/questions/51651/which-andr...
[deleted]
how time flys！
From https://www.kernel.org/category/releases.html:
These are just currently supported ones, there have been several other releases in the past with 5+ year support (like 2.6.32 and 3.4 from top of my mind). These were also (not coincidentally) selected kernels of older Android releases.
Edit: Digged here a bit more: https://en.wikipedia.org/wiki/Linux_kernel#Maintenance