6 ms·

From his point of view the AMD guys were told that this code wouldn’t be merged as is six months ago and now they come back with a massive code drop and very ef

by pja 10y ago

From his point of view the AMD guys were told that this code wouldn’t be merged as is six months ago and now they come back with a massive code drop and very effectively put him in the position of having to be the bad guy. I think we’d all have some sharp words we’d like to use in that situation even if the better part of our natures might counsel us to keep them to ourselves.

izacus 10y ago
The kernel essentially demanded they drop the idea of cross-platform driver (which is what makes nVidia drivers work so well on Linux and is keeping them in lockstep with Windows releases) and maintain a full separate copy with a small team. It was unrealistic six months ago as it is now. And yet, I still don't see a constructive debate from Linux (or AMD) side on how to sync the goals. All I see is Linux people posturing about how they don't want to be the second platform and AMD refusing to rebuild the driver just for them. These kind of attitudes bring us awful situations like Android Linux devices each having a broken fork of Linux kernel to accomodate closed proprietary blobs because neither side is ready to step together.
- serge2k 10y ago
  why does AMD need to be in the kernel? Why can't they release the way nVidia does? or open source it, develop along with upstream but don't make it part of upstream.
  - j1vms 10y ago
    > why does AMD need to be in the kernel? Why can't they release the way nVidia does? Perhaps it was strategically important to them to be upstream (marketing point, driver ubiquity)? It may not be the year of Linux on the Desktop, but GNOME and the like are well-placed to grow in usage over the next 5 or so odd years. As others here have said, that other than for average desktop users, I don't see this as being as important to more technical Linux users (including corporate).
    - sangnoir 10y ago
      If it is strategically important, then they should allocate enough resources to do it right.
  - bostik 10y ago
    You're asking a question with a very complex answer. I'll start with a short answer - AMD wants to have at minimum a reasonably good baseline functionality on linux, out of the box. If that answer doesn't make much sense, please read on for the complex bits. To provide some historical context, Linus gave a VERY public, VERY brutal rant on NVIDIA and their drivers four years ago.[0] At the time, NVIDIA's closed drivers were an opaque blob which basically reimplemented the entirety of OpenGL. These collided with everything else. The open drivers (nouveau) were slow and far behind in features. The situation was bad enough that you couldn't necessarily even install a linux distro on a system with NVIDIA chip because the open drivers wouldn't work well enough for X and/or desktop environment to initialise properly, let alone remain up and functional. In effect, if you wanted to run linux, you were best off without NVIDIA. Fast forward year and a half. NVIDIA had come out and committed to improving the linux driver situation. They still couldn't open source their current-generation drivers, but they had realised the horrible reputation of their hardware on linux was going to be a persistent PR nightmare, and thus an existential threat to their growing mobile division. A space where they were up against Imagination Technologies. (Don't get me started on ImgTec, please...) NVIDIA needed to get their hardware and software processes aligned in a way that they would work reliably out of the box on linux, everywhere. Even if the user only needed to keep the freshly installed or upgraded system up long enough for them to download and install the closed drivers, the system really should not break. Incidentally this meant that even the open drivers should be "good enough". Over the past 3+ years, the situation has improved. NVIDIA has managed to shed their reputation of being completely broken on linux, they have worked closely with kernel folks to get their more recent hardware supported sensibly out of the box and in the process (I believe) they have managed to reduce the code delta between their windows drivers and linux drivers. It helps that during the same 4 years we have had OpenGL on mobile drive the separation of duties between EGL and GLES (v2+). These changes, with all the refactorings, have also provided a cleaner split on desktop - to the point that it is no longer absolutely necessary to provide full OpenGL implementation. You can, for most parts, expect that EGL just works; that DRM and KMS both just work; and that your highly optimised GLES implementation can happily live on top of these layers. As a result, your closed driver offering has less to override. Of course it's going to be less unstable! Disclosure: in my previous job, I helped integrate couple of EGL+GLES driver stacks with Wayland on mobile systems. I learned to hate mobile GPU drivers with a passion. P.S.: I haven't read enough about Vulkan to know if it improves things or not. 0: https://www.youtube.com/watch?v=IVpOyKCNZYw https://www.youtube.com/watch?v=IVpOyKCNZYw
  - geezerjay 10y ago
    > why does AMD need to be in the kernel? Speaking as an ATI user, having the drives in the kernel means that the GPU card just works right out of the box. No need to mess up with drivers. Just install a distro and you're good to go.
- mattnewton 10y ago
  Nvidia also doesn't merge into the kernel. "Nvidia does it" is not a good argument IMO.
- deleted 10y ago
  [deleted]
- pmelendez 10y ago
  > which is what makes nVidia drivers work so well on Linux Maybe for you, every kernel upgrade I have done in the past would break my desktop for a day or two until a patch is released. Not too mention oddities and artifacts, I get from time to time. Things that I find unacceptable and embarrassing if it happens on Windows or Mac and I have to learn to live with it on Linux. I am probably out of luck but I think I would start to see you if FreeBSD would be a good replacement for Linux
  - jrk 10y ago
    Breaking on every kernel upgrade is a configuration issue (and a result of Linux's driver model); the "quality" of the NVIDIA Linux driver being discussed is an issue of the actual performance, compliance, stability, and feature parity/freshness relative to others, once configured correctly. Reconfiguration/rebuild on every kernel update is definitely a hassle, and the NVIDIA scripts which try to automate the process still occasionally fail (IME, generally due to conflicts with the system package manager constantly deciding it knows best and trying to displace them with its own versions). But that's essentially an unavoidable consequence of combining out-of-tree drivers Linux's extreme no-stable-driver-ABI-ever design which requires all drivers to be rebuilt directly against the exact current kernel source: you always have to rebuild the bindings on kernel upgrade. The bindings can still be maintained by the distro vendor and its package manager, so they're centrally rebuilt (and fixed if needed), and updated in lock step with the kernel. This works well in Ubuntu, at least, these days. But absent that, the Linux model fundamentally requires local rebuild automation (or full manual rebuilds), which is prone to breakage, like any other "just download and rebuild from scratch against a new version" you've ever done, kernel/driver or otherwise.
    - phkahler 10y ago
      That's why I switched to the open source nVidia driver long ago. I got tired of upgrades screwing up the driver. It's not a configuration issue, it's because the other nVida driver doesn't get rebuilt along with the kernel due to not being upstream.
      - 10y ago
- freeone3000 10y ago
  The kernel demanded they drop the idea of a cross-platform driver to get merged into the kernel. They can still develop a standalone driver module, same as everybody else. Code doesn't need to be in kernel to run.
  - AstralStorm 10y ago
    But then they don't get the free lunch of kernel people maintaining and fixing their stuff. Which ends up in the same situation as older catalyst.
    - ldng 10y ago
      Looks like the free lunch isn't that free after all then. Tough luck.
    - rbanffy 10y ago
      They can still get the free lunch, but they have to deserve it.
- prodigal_erik 10y ago
  The goal of Linux governance is that all the video developers can understand and maintain all the in-kernel video drivers in order to evolve the internal API as needed. The goal of AMD is to reuse whatever the hell they had to write for Windows. Since Linus and friends are not in charge of Microsoft's driver API, these can't be reconciled.
  - makomk 10y ago
    From the AMD point of view, the Linux upstream's approach to modifying the internal API and drivers is a problem itself: "I understand forward progress on APIs, but frankly from my perspective, atomic has been a disaster for stability of both atomic and pre-atomic code. Every kernel cycle manages to break several drivers. What happened to figuring out how to do in right in a couple of drivers and then moving that to the core. We seem to have lost that in favor of starting in the core first. I feel like we constantly refactor the core to deal with that or that quirk or requirement of someone's hardware and then deal with tons of fallout." Certainly, from what I've seen the first few stable releases after every new kernel version are often full of fixes for modesetting-related regressions.
- geezerjay 10y ago
  > The kernel essentially demanded they drop the idea of cross-platform driver Don't you agree that it is very silly to try to force cross-platform code into the very source of a very specific platform? After all, the people working for that platform need to actually maintain that code.
  - izacus 10y ago
    No, it works very well for nVidia.
    - geezerjay 10y ago
      NVidia does nothing of the sort. NVidia's driver is a kernel module they distribute themselves, and that NVidia users need to download and install themselves.
- sqldba 10y ago
  This is exactly how I feel. I don't use Linux, I'm an outsider, and the whole thing just makes no sense to me.

by pja 10y ago

izacus 10y ago

The kernel essentially demanded they drop the idea of cross-platform driver (which is what makes nVidia drivers work so well on Linux and is keeping them in lockstep with Windows releases) and maintain a full separate copy with a small team. It was unrealistic six months ago as it is now. And yet, I still don't see a constructive debate from Linux (or AMD) side on how to sync the goals. All I see is Linux people posturing about how they don't want to be the second platform and AMD refusing to rebuild the driver just for them. These kind of attitudes bring us awful situations like Android Linux devices each having a broken fork of Linux kernel to accomodate closed proprietary blobs because neither side is ready to step together.

serge2k 10y ago
why does AMD need to be in the kernel? Why can't they release the way nVidia does? or open source it, develop along with upstream but don't make it part of upstream.
- j1vms 10y ago
  > why does AMD need to be in the kernel? Why can't they release the way nVidia does? Perhaps it was strategically important to them to be upstream (marketing point, driver ubiquity)? It may not be the year of Linux on the Desktop, but GNOME and the like are well-placed to grow in usage over the next 5 or so odd years. As others here have said, that other than for average desktop users, I don't see this as being as important to more technical Linux users (including corporate).
  - sangnoir 10y ago
    If it is strategically important, then they should allocate enough resources to do it right.
- bostik 10y ago
  You're asking a question with a very complex answer. I'll start with a short answer - AMD wants to have at minimum a reasonably good baseline functionality on linux, out of the box. If that answer doesn't make much sense, please read on for the complex bits. To provide some historical context, Linus gave a VERY public, VERY brutal rant on NVIDIA and their drivers four years ago.[0] At the time, NVIDIA's closed drivers were an opaque blob which basically reimplemented the entirety of OpenGL. These collided with everything else. The open drivers (nouveau) were slow and far behind in features. The situation was bad enough that you couldn't necessarily even install a linux distro on a system with NVIDIA chip because the open drivers wouldn't work well enough for X and/or desktop environment to initialise properly, let alone remain up and functional. In effect, if you wanted to run linux, you were best off without NVIDIA. Fast forward year and a half. NVIDIA had come out and committed to improving the linux driver situation. They still couldn't open source their current-generation drivers, but they had realised the horrible reputation of their hardware on linux was going to be a persistent PR nightmare, and thus an existential threat to their growing mobile division. A space where they were up against Imagination Technologies. (Don't get me started on ImgTec, please...) NVIDIA needed to get their hardware and software processes aligned in a way that they would work reliably out of the box on linux, everywhere. Even if the user only needed to keep the freshly installed or upgraded system up long enough for them to download and install the closed drivers, the system really should not break. Incidentally this meant that even the open drivers should be "good enough". Over the past 3+ years, the situation has improved. NVIDIA has managed to shed their reputation of being completely broken on linux, they have worked closely with kernel folks to get their more recent hardware supported sensibly out of the box and in the process (I believe) they have managed to reduce the code delta between their windows drivers and linux drivers. It helps that during the same 4 years we have had OpenGL on mobile drive the separation of duties between EGL and GLES (v2+). These changes, with all the refactorings, have also provided a cleaner split on desktop - to the point that it is no longer absolutely necessary to provide full OpenGL implementation. You can, for most parts, expect that EGL just works; that DRM and KMS both just work; and that your highly optimised GLES implementation can happily live on top of these layers. As a result, your closed driver offering has less to override. Of course it's going to be less unstable! Disclosure: in my previous job, I helped integrate couple of EGL+GLES driver stacks with Wayland on mobile systems. I learned to hate mobile GPU drivers with a passion. P.S.: I haven't read enough about Vulkan to know if it improves things or not. 0: https://www.youtube.com/watch?v=IVpOyKCNZYw https://www.youtube.com/watch?v=IVpOyKCNZYw
- geezerjay 10y ago
  > why does AMD need to be in the kernel? Speaking as an ATI user, having the drives in the kernel means that the GPU card just works right out of the box. No need to mess up with drivers. Just install a distro and you're good to go.
mattnewton 10y ago
Nvidia also doesn't merge into the kernel. "Nvidia does it" is not a good argument IMO.
deleted 10y ago
[deleted]
pmelendez 10y ago
> which is what makes nVidia drivers work so well on Linux Maybe for you, every kernel upgrade I have done in the past would break my desktop for a day or two until a patch is released. Not too mention oddities and artifacts, I get from time to time. Things that I find unacceptable and embarrassing if it happens on Windows or Mac and I have to learn to live with it on Linux. I am probably out of luck but I think I would start to see you if FreeBSD would be a good replacement for Linux
- jrk 10y ago
  Breaking on every kernel upgrade is a configuration issue (and a result of Linux's driver model); the "quality" of the NVIDIA Linux driver being discussed is an issue of the actual performance, compliance, stability, and feature parity/freshness relative to others, once configured correctly. Reconfiguration/rebuild on every kernel update is definitely a hassle, and the NVIDIA scripts which try to automate the process still occasionally fail (IME, generally due to conflicts with the system package manager constantly deciding it knows best and trying to displace them with its own versions). But that's essentially an unavoidable consequence of combining out-of-tree drivers Linux's extreme no-stable-driver-ABI-ever design which requires all drivers to be rebuilt directly against the exact current kernel source: you always have to rebuild the bindings on kernel upgrade. The bindings can still be maintained by the distro vendor and its package manager, so they're centrally rebuilt (and fixed if needed), and updated in lock step with the kernel. This works well in Ubuntu, at least, these days. But absent that, the Linux model fundamentally requires local rebuild automation (or full manual rebuilds), which is prone to breakage, like any other "just download and rebuild from scratch against a new version" you've ever done, kernel/driver or otherwise.
  - phkahler 10y ago
    That's why I switched to the open source nVidia driver long ago. I got tired of upgrades screwing up the driver. It's not a configuration issue, it's because the other nVida driver doesn't get rebuilt along with the kernel due to not being upstream.
    - 10y ago
freeone3000 10y ago
The kernel demanded they drop the idea of a cross-platform driver to get merged into the kernel. They can still develop a standalone driver module, same as everybody else. Code doesn't need to be in kernel to run.
- AstralStorm 10y ago
  But then they don't get the free lunch of kernel people maintaining and fixing their stuff. Which ends up in the same situation as older catalyst.
  - ldng 10y ago
    Looks like the free lunch isn't that free after all then. Tough luck.
  - rbanffy 10y ago
    They can still get the free lunch, but they have to deserve it.
prodigal_erik 10y ago
The goal of Linux governance is that all the video developers can understand and maintain all the in-kernel video drivers in order to evolve the internal API as needed. The goal of AMD is to reuse whatever the hell they had to write for Windows. Since Linus and friends are not in charge of Microsoft's driver API, these can't be reconciled.
- makomk 10y ago
  From the AMD point of view, the Linux upstream's approach to modifying the internal API and drivers is a problem itself: "I understand forward progress on APIs, but frankly from my perspective, atomic has been a disaster for stability of both atomic and pre-atomic code. Every kernel cycle manages to break several drivers. What happened to figuring out how to do in right in a couple of drivers and then moving that to the core. We seem to have lost that in favor of starting in the core first. I feel like we constantly refactor the core to deal with that or that quirk or requirement of someone's hardware and then deal with tons of fallout." Certainly, from what I've seen the first few stable releases after every new kernel version are often full of fixes for modesetting-related regressions.
geezerjay 10y ago
> The kernel essentially demanded they drop the idea of cross-platform driver Don't you agree that it is very silly to try to force cross-platform code into the very source of a very specific platform? After all, the people working for that platform need to actually maintain that code.
- izacus 10y ago
  No, it works very well for nVidia.
  - geezerjay 10y ago
    NVidia does nothing of the sort. NVidia's driver is a kernel module they distribute themselves, and that NVidia users need to download and install themselves.
sqldba 10y ago
This is exactly how I feel. I don't use Linux, I'm an outsider, and the whole thing just makes no sense to me.