8 ms·

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/pub

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-driver-model-a-better-way-to-support-devices/ https://www.linuxfoundation.org/publications/the-linux-drive...

kuschku 9y ago
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.
- colemannugent 9y ago
  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.
  - kuschku 9y ago
    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.
    - thomastjeffery 9y ago
      > 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.
      - kuschku 9y ago
        > 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.
        tosstossy 9y ago
        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
        kuschku 9y ago
        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.
revelation 9y ago
And now it's 10 years later and it clearly hasn't worked. Time to revisit old assumptions and learn something new.
- uabstraction 9y ago
  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.
  - kuschku 9y ago
    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.
  - pritambaral 9y ago
    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.
  - deleted 9y ago
    [deleted]

kuschku 9y ago

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.

colemannugent 9y ago
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.
- kuschku 9y ago
  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.
  - thomastjeffery 9y ago
    > 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.
    - kuschku 9y ago
      > 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.
      - tosstossy 9y ago
        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
        kuschku 9y ago
        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.

revelation 9y ago

And now it's 10 years later and it clearly hasn't worked. Time to revisit old assumptions and learn something new.

uabstraction 9y ago
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.
- kuschku 9y ago
  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.
- pritambaral 9y ago
  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.
- deleted 9y ago
  [deleted]