10 ms·

Anyone want to explain this in simple terms for us folk not knee-deep in kernel graphics driver politics?

shmerl 10y ago
Very short - AMD made an abstraction layer, to share effort between Linux and other platforms (i.e. Windows and etc.). Kernel/DRM maintainers don't like that, since it causes several issues detailed in that thread (harder to understand logic of the driver, slowdown of DRM improvement itself, indirect workflow of AMD developers and so on). For the reference, DRM here is Direct Rendering Manager[1], nothing to do with crooked Digital Restrictions Management. 1. https://en.wikipedia.org/wiki/Direct_Rendering_Manager https://en.wikipedia.org/wiki/Direct_Rendering_Manager
- wolfgke 10y ago
  > nothing to do with crooked Digital Restrictions Management. Please prefer the term "Digital Restriction Management". :-)
theparanoid 10y ago
Nvidia uses largely the same driver code for both linux and windows in their proprietary driver (I believe they call it a unified driver). AMD tried the same in their open source driver and were rejected by the kernel maintainer. Unified drivers have code sharing advantages but don't follow the practices of the linux kernel.
- pcr0 10y ago
  But Nvidia's proprietary driver is a download right? Why is AMD trying to merge theirs into the kernel?
  - theparanoid 10y ago
    It's already part of the kernel, this was a re-architecture of the display portion of the driver.
  - ajdlinux 10y ago
    The amdgpu driver is open source, not proprietary.
    - gonmf 10y ago
      Open source != free software.
      - wolfgke 10y ago
        The difference between open source and free software is mostly in the political camp the word comes from. Read the OSI definition of open source if you don't believe: > https://opensource.org/osd-annotated https://opensource.org/osd-annotated The reasons why "free software" people don't like the word "open source" are indeed political: > https://www.gnu.org/philosophy/open-source-misses-the-point.html https://www.gnu.org/philosophy/open-source-misses-the-point.... For software for which the source code is available, but does not give the four freedoms: > https://www.gnu.org/philosophy/free-sw.html#content https://www.gnu.org/philosophy/free-sw.html#content it is common to use the word "shared source" (originally devised by Microsoft): > https://en.wikipedia.org/wiki/Shared_source https://en.wikipedia.org/wiki/Shared_source
      - SXX 10y ago
        Kernel driver of proprietary AMDGPU-PRO are licensed exactly same way as modules in mainline kernel. Most of them dual-licensed under MIT and GPL so BSD and other projects can use them.
      - majewsky 10y ago
        But it is free software. It resides in the kernel tree: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd/amdgpu?id=refs/tags/v4.8.13 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st...
  - wtallis 10y ago
    AMD's recent strategy has been to try to confine the proprietary stuff to userspace, and to implement an open-source kernel driver that can be used by either the proprietary userspace driver or open-source userspace stack.
  - Qwertious 10y ago
    Nvidia's proprietary driver breaks upon every new kernel release, which is why they have a shim. Furthermore, Nvidia can't ship their driver in the official Linux kernel due to copyright issues, and they're forced to handle all the maintenance burden of their driver (whereas AMD reaps the benefits of Intel's GPU driver bugfixing, and vice versa, thus lowering both Intel's and AMD's driver costs on Linux). Besides, Nvidia's been having trouble with their Tegra GPUs on Android, and as a result have been forced to pitch in a bit on Nouveau (the reverse-engineered open-source Nvidia driver). They're still having trouble with their driver situation on mobile, as a result of their unwillingness to play ball with the kernel. Actually, that last sentence above - I'm really not too confident on that, I've heard various hearsay but the only source I concretely remember is the "other drivers" section of http://richg42.blogspot.com.au/2014/05/the-truth-on-opengl-driver-quality.html http://richg42.blogspot.com.au/2014/05/the-truth-on-opengl-d...
    - Nullabillity 10y ago
      > Furthermore, Nvidia can't ship their driver in the official Linux kernel Nvidia has every ability to ship it, they just refuse to open it.
      - valdiorn 10y ago
        probably rightfully so, if this is the sort of welcome they'd get.
        Kubuxu 10y ago
        There is huge difference between opening code and merging it to the Linux kernel.
        pif 10y ago
        Opening their driver's code is different from merging it into the kernel source.
    - alkonaut 10y ago
      > Nvidia's proprietary driver breaks upon every new kernel release, which is why they have a shim. ELI5: why does each Linux kernel release break driver code? It can't be THAT hard to just have a stable interface and leave it for long periods of time, e.g. only bumping it on major version bumps in the Kernel?
  - topkekz 10y ago
    https://www.phoronix.com/scan.php?page=article&item=amd_catalyst_kernel&num=1 https://www.phoronix.com/scan.php?page=article&item=amd_cata... Note that both the amd and the nvidia kernel modules always have been FOSS because of the GPL license. It's just that nvidia provides it by its own ways, not through the official linux branch, and thus doesn't have to respect linux rules nor to document the driver.
    - SXX 10y ago
      Note that both the amd and the nvidia kernel modules always have been FOSS because of the GPL license. Only open source part of their modules was shim while 99% of driver is contained in blob. That's true for both Nvidia or ATI/AMD fglrx.
- tayo42 10y ago
  Maybe a stupid question but why is it a big deal? Who else does this effect other then nvidia and amd?
  - foota 10y ago
    I think the idea is that the kernel maintainers can't break the code that the AMD driver relies on and in order to properly do that they need to be able to easily grok all the driver implementations, and abstraction layers make that more difficult.
    - d1str0 10y ago
      Thank you. This comment clarifies things quite a bit for me.
    - kazarov 10y ago
      I don't know anything about linux display architecture, but this point sounds really weird to me from general software engineering perspective. Isn't one of the goals of having drivers in an OS to establish a formalized interface between drivers and kernel, and thus achieve separation of concerns between driver maintainers and kernel maintainers? Requiring that kernel maintainers understand how all drivers work does not sound very scalable.
      - bnastic 10y ago
        It's exactly opposite with Linux, where stable kernel API/ABI are avoided as a matter of principle
        tracker1 10y ago
        I wouldn't say avoided.. A lot of the interfaces are still compatible with prior versions as is the software that runs on it, or we'd be on Kernel v50+ by now. Not all software, but a bit. That said, the community isn't afraid of breaking changes to push future versions forward.
- vvanders 10y ago
  My naive assumption is that code reuse across platforms is a good thing, I'd love to understand why this isn't the case here or what the concrete arguments are against it.
  - tlow 10y ago
    I believe this link is the "concrete argument" against a unified abstraction layer in this particular instance.
  - justincormack 10y ago
    The open source developers don't care about invisible code reuse in a closed source driver. HALs across open source codebases do exist too (eg for ZFS) but Linux in particular does not like them.
    - cpeterso 10y ago
      AMD should move their HAL code into their Windows driver, making it a superset of the Linux driver. AMD would get to reduce driver code duplication and Linux kernel developers don't need to merge the AMD's ugly Linux/Windows HAL.
      - wolfgke 10y ago
        > AMD should move their HAL code into their Windows driver, making it a superset of the Linux driver. This might theoretically make sense if the Linux subsystem was very stable over many years. Practice shows that the Windows interfaces are what are a lot more stable over the years and changes in them are communicated for a long time beforehand so that hardware vendors can begin changing their drivers long beforehand.
        Kadin 10y ago
        Regardless of one's thoughts on AMD, I think this is broadly true. Microsoft may do a lot of things poorly, but one thing they are good at (arguably, the only thing they're good at, hell maybe the key to their success, really) is maintaining compatibility and not breaking stuff.
rasz_pl 10y ago
Short version: AMD as a company is dysfunctional. Perfectly happy to throw away $300Mil on failed acquisition, unwilling to hire sufficient number of competent driver developers. Result is no people to do the required work.
- chei0iaV 10y ago
  Where did you get this idea from? Just because a patch set got rejected, we can dismiss the fact that AMD had been providing excellent open source driver support for years, and just call them incompetent?
- EpicEng 10y ago
  AMD is prioritizing the business here, which makes perfect sense. Why would they spend more money than necessary to appease the Linux maintainers in order to serve the tiny population of Linux gamers who probably don't give a crap about how the kernel is maintained? Their business is on Windows.
  - mixedCase 10y ago
    Neither AMD nor Nvidia develop Linux drivers for Linux gamers. Not that they don't pay attention to us with fixes and optimizations here and there, but a good part of that is games simply being applications that make use of a lot of driver functionality that might not receive enough testing otherwise.
- serge2k 10y ago
  more like they don't want to spend twice as much trying to maintain a separate linux driver, because that's a bit ridiculous.

Very short - AMD made an abstraction layer, to share effort between Linux and other platforms (i.e. Windows and etc.). Kernel/DRM maintainers don't like that, since it causes several issues detailed in that thread (harder to understand logic of the driver, slowdown of DRM improvement itself, indirect workflow of AMD developers and so on). For the reference, DRM here is Direct Rendering Manager[1], nothing to do with crooked Digital Restrictions Management. 1. https://en.wikipedia.org/wiki/Direct_Rendering_Manager https://en.wikipedia.org/wiki/Direct_Rendering_Manager

wolfgke 10y ago
> nothing to do with crooked Digital Restrictions Management. Please prefer the term "Digital Restriction Management". :-)

theparanoid 10y ago

Nvidia uses largely the same driver code for both linux and windows in their proprietary driver (I believe they call it a unified driver). AMD tried the same in their open source driver and were rejected by the kernel maintainer. Unified drivers have code sharing advantages but don't follow the practices of the linux kernel.

pcr0 10y ago
But Nvidia's proprietary driver is a download right? Why is AMD trying to merge theirs into the kernel?
- theparanoid 10y ago
  It's already part of the kernel, this was a re-architecture of the display portion of the driver.
- ajdlinux 10y ago
  The amdgpu driver is open source, not proprietary.
  - gonmf 10y ago
    Open source != free software.
    - wolfgke 10y ago
      The difference between open source and free software is mostly in the political camp the word comes from. Read the OSI definition of open source if you don't believe: > https://opensource.org/osd-annotated https://opensource.org/osd-annotated The reasons why "free software" people don't like the word "open source" are indeed political: > https://www.gnu.org/philosophy/open-source-misses-the-point.html https://www.gnu.org/philosophy/open-source-misses-the-point.... For software for which the source code is available, but does not give the four freedoms: > https://www.gnu.org/philosophy/free-sw.html#content https://www.gnu.org/philosophy/free-sw.html#content it is common to use the word "shared source" (originally devised by Microsoft): > https://en.wikipedia.org/wiki/Shared_source https://en.wikipedia.org/wiki/Shared_source
    - SXX 10y ago
      Kernel driver of proprietary AMDGPU-PRO are licensed exactly same way as modules in mainline kernel. Most of them dual-licensed under MIT and GPL so BSD and other projects can use them.
    - majewsky 10y ago
      But it is free software. It resides in the kernel tree: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/amd/amdgpu?id=refs/tags/v4.8.13 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st...
- wtallis 10y ago
  AMD's recent strategy has been to try to confine the proprietary stuff to userspace, and to implement an open-source kernel driver that can be used by either the proprietary userspace driver or open-source userspace stack.
- Qwertious 10y ago
  Nvidia's proprietary driver breaks upon every new kernel release, which is why they have a shim. Furthermore, Nvidia can't ship their driver in the official Linux kernel due to copyright issues, and they're forced to handle all the maintenance burden of their driver (whereas AMD reaps the benefits of Intel's GPU driver bugfixing, and vice versa, thus lowering both Intel's and AMD's driver costs on Linux). Besides, Nvidia's been having trouble with their Tegra GPUs on Android, and as a result have been forced to pitch in a bit on Nouveau (the reverse-engineered open-source Nvidia driver). They're still having trouble with their driver situation on mobile, as a result of their unwillingness to play ball with the kernel. Actually, that last sentence above - I'm really not too confident on that, I've heard various hearsay but the only source I concretely remember is the "other drivers" section of http://richg42.blogspot.com.au/2014/05/the-truth-on-opengl-driver-quality.html http://richg42.blogspot.com.au/2014/05/the-truth-on-opengl-d...
  - Nullabillity 10y ago
    > Furthermore, Nvidia can't ship their driver in the official Linux kernel Nvidia has every ability to ship it, they just refuse to open it.
    - valdiorn 10y ago
      probably rightfully so, if this is the sort of welcome they'd get.
      - Kubuxu 10y ago
        There is huge difference between opening code and merging it to the Linux kernel.
      - pif 10y ago
        Opening their driver's code is different from merging it into the kernel source.
  - alkonaut 10y ago
    > Nvidia's proprietary driver breaks upon every new kernel release, which is why they have a shim. ELI5: why does each Linux kernel release break driver code? It can't be THAT hard to just have a stable interface and leave it for long periods of time, e.g. only bumping it on major version bumps in the Kernel?
- topkekz 10y ago
  https://www.phoronix.com/scan.php?page=article&item=amd_catalyst_kernel&num=1 https://www.phoronix.com/scan.php?page=article&item=amd_cata... Note that both the amd and the nvidia kernel modules always have been FOSS because of the GPL license. It's just that nvidia provides it by its own ways, not through the official linux branch, and thus doesn't have to respect linux rules nor to document the driver.
  - SXX 10y ago
    Note that both the amd and the nvidia kernel modules always have been FOSS because of the GPL license. Only open source part of their modules was shim while 99% of driver is contained in blob. That's true for both Nvidia or ATI/AMD fglrx.
tayo42 10y ago
Maybe a stupid question but why is it a big deal? Who else does this effect other then nvidia and amd?
- foota 10y ago
  I think the idea is that the kernel maintainers can't break the code that the AMD driver relies on and in order to properly do that they need to be able to easily grok all the driver implementations, and abstraction layers make that more difficult.
  - d1str0 10y ago
    Thank you. This comment clarifies things quite a bit for me.
  - kazarov 10y ago
    I don't know anything about linux display architecture, but this point sounds really weird to me from general software engineering perspective. Isn't one of the goals of having drivers in an OS to establish a formalized interface between drivers and kernel, and thus achieve separation of concerns between driver maintainers and kernel maintainers? Requiring that kernel maintainers understand how all drivers work does not sound very scalable.
    - bnastic 10y ago
      It's exactly opposite with Linux, where stable kernel API/ABI are avoided as a matter of principle
      - tracker1 10y ago
        I wouldn't say avoided.. A lot of the interfaces are still compatible with prior versions as is the software that runs on it, or we'd be on Kernel v50+ by now. Not all software, but a bit. That said, the community isn't afraid of breaking changes to push future versions forward.
vvanders 10y ago
My naive assumption is that code reuse across platforms is a good thing, I'd love to understand why this isn't the case here or what the concrete arguments are against it.
- tlow 10y ago
  I believe this link is the "concrete argument" against a unified abstraction layer in this particular instance.
- justincormack 10y ago
  The open source developers don't care about invisible code reuse in a closed source driver. HALs across open source codebases do exist too (eg for ZFS) but Linux in particular does not like them.
  - cpeterso 10y ago
    AMD should move their HAL code into their Windows driver, making it a superset of the Linux driver. AMD would get to reduce driver code duplication and Linux kernel developers don't need to merge the AMD's ugly Linux/Windows HAL.
    - wolfgke 10y ago
      > AMD should move their HAL code into their Windows driver, making it a superset of the Linux driver. This might theoretically make sense if the Linux subsystem was very stable over many years. Practice shows that the Windows interfaces are what are a lot more stable over the years and changes in them are communicated for a long time beforehand so that hardware vendors can begin changing their drivers long beforehand.
      - Kadin 10y ago
        Regardless of one's thoughts on AMD, I think this is broadly true. Microsoft may do a lot of things poorly, but one thing they are good at (arguably, the only thing they're good at, hell maybe the key to their success, really) is maintaining compatibility and not breaking stuff.

rasz_pl 10y ago

Short version: AMD as a company is dysfunctional. Perfectly happy to throw away $300Mil on failed acquisition, unwilling to hire sufficient number of competent driver developers. Result is no people to do the required work.

chei0iaV 10y ago
Where did you get this idea from? Just because a patch set got rejected, we can dismiss the fact that AMD had been providing excellent open source driver support for years, and just call them incompetent?
EpicEng 10y ago
AMD is prioritizing the business here, which makes perfect sense. Why would they spend more money than necessary to appease the Linux maintainers in order to serve the tiny population of Linux gamers who probably don't give a crap about how the kernel is maintained? Their business is on Windows.
- mixedCase 10y ago
  Neither AMD nor Nvidia develop Linux drivers for Linux gamers. Not that they don't pay attention to us with fixes and optimizations here and there, but a good part of that is games simply being applications that make use of a lot of driver functionality that might not receive enough testing otherwise.
serge2k 10y ago
more like they don't want to spend twice as much trying to maintain a separate linux driver, because that's a bit ridiculous.