4 ms·

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 ups

by 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
- aseipp 10y ago
  > In effect, if you wanted to run linux, you were best off without NVIDIA. Depends on your choices. I guess if you throw Intel in there as an option, then maybe. But as of 4 years ago, if you were running a desktop -- Nvidia was pretty much the only acceptable choice if you wanted discrete graphics on Linux of any form, IMO, and driver quality was a massive part of why this is true. Optimus, though -- that's what was really the debbie-downer for Linux/Nvidia, and Optimus is what inspired the question which lead to Linus's "Fuck you" rant, because Optimus support was so bad, and is still bad. But the mainstream cards have worked fine for a long time, and, at least for me and everyone I know -- were the only acceptable ones for Linux, until relatively recently, and most certainly as of ~5yrs ago. As opposed to AMD, where I don't think I ever heard of a single instance of fglrx ever being anything but a nightmare.
- mslusarz 10y ago
  Although you don't say it directly but by saying that "The open drivers (nouveau) were slow and far behind in features." and then that the situation improved because of Nvidia involvement you are not being honest. Nvidia hasn't improved performance or contributed features to nouveau. Their changes are limited to code that is mobile chip-specific and from time to time they contribute some reliability fix that affects non-mobile chips, but only if benefits mobile. Since Maxwell 2 (9xx+) their chips are designed to be hostile to nouveau, by requiring firmware loaded by the driver to be signed by Nvidia (hardware refuses to load firmware that wasn't signed by them). It means that without Nvidia blessing nouveau for example can't change the fan speed (but still can change clocks! how ridiculous it is?). Nvidia contibuted signed firmware loading for non-mobile chips (so called SecureBoot), but only because it's also required by mobile. And they still have not released enough firmwares for desktop cards to be usable...
  - bostik 10y ago
    > Although you don't say it directly but by saying that "The open drivers (nouveau) were slow and far behind in features." and then that the situation improved because of Nvidia involvement you are not being honest. > Nvidia hasn't improved performance or contributed features to nouveau. Fair point, I didn't realise it could be read that way. Thank you. Nvidia has contributed enough fixes to make their hardware sort of respond out of the fox. Yes, primarily for devices on mobile space, and occasionally on non-mobile when the same fixes happen to apply. I believe this is directly a result of same hardware designs being used across the board. I didn't mean NVIDIA were being particularly nice, although I didn't know about the active hostility against nouveau. (IIRC their driver employees are contractually prevented from contributing to nouveau, but I can't find reference. At least there I can understand the reason.)
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.

by 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

aseipp 10y ago
> In effect, if you wanted to run linux, you were best off without NVIDIA. Depends on your choices. I guess if you throw Intel in there as an option, then maybe. But as of 4 years ago, if you were running a desktop -- Nvidia was pretty much the only acceptable choice if you wanted discrete graphics on Linux of any form, IMO, and driver quality was a massive part of why this is true. Optimus, though -- that's what was really the debbie-downer for Linux/Nvidia, and Optimus is what inspired the question which lead to Linus's "Fuck you" rant, because Optimus support was so bad, and is still bad. But the mainstream cards have worked fine for a long time, and, at least for me and everyone I know -- were the only acceptable ones for Linux, until relatively recently, and most certainly as of ~5yrs ago. As opposed to AMD, where I don't think I ever heard of a single instance of fglrx ever being anything but a nightmare.
mslusarz 10y ago
Although you don't say it directly but by saying that "The open drivers (nouveau) were slow and far behind in features." and then that the situation improved because of Nvidia involvement you are not being honest. Nvidia hasn't improved performance or contributed features to nouveau. Their changes are limited to code that is mobile chip-specific and from time to time they contribute some reliability fix that affects non-mobile chips, but only if benefits mobile. Since Maxwell 2 (9xx+) their chips are designed to be hostile to nouveau, by requiring firmware loaded by the driver to be signed by Nvidia (hardware refuses to load firmware that wasn't signed by them). It means that without Nvidia blessing nouveau for example can't change the fan speed (but still can change clocks! how ridiculous it is?). Nvidia contibuted signed firmware loading for non-mobile chips (so called SecureBoot), but only because it's also required by mobile. And they still have not released enough firmwares for desktop cards to be usable...
- bostik 10y ago
  > Although you don't say it directly but by saying that "The open drivers (nouveau) were slow and far behind in features." and then that the situation improved because of Nvidia involvement you are not being honest. > Nvidia hasn't improved performance or contributed features to nouveau. Fair point, I didn't realise it could be read that way. Thank you. Nvidia has contributed enough fixes to make their hardware sort of respond out of the fox. Yes, primarily for devices on mobile space, and occasionally on non-mobile when the same fixes happen to apply. I believe this is directly a result of same hardware designs being used across the board. I didn't mean NVIDIA were being particularly nice, although I didn't know about the active hostility against nouveau. (IIRC their driver employees are contractually prevented from contributing to nouveau, but I can't find reference. At least there I can understand the reason.)

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.