17 ms·

Linux kernel maintainer says no to AMDGPU patch

446 points by pero 10y ago

bentona 10y ago
What's the practical effect of this? We'll have to wait until someone writes a reasonable alternative for these GPUs to be supported in Linux? Edit: Here's the start of the thread https://lists.freedesktop.org/archives/dri-devel/2016-December/126422.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...
- orionblastar 10y ago
  SteamOS and SteamMachines will be delayed as well. Nvidia support for Linux is hard to get as well. Now AMD support is also hard to get. Hardware OEM companies make Windows drivers, and don't seem to care about Linux. This is the same thing that happened to IBM and OS/2 not good third party driver support. There are open source drivers that work, but are not as fast as the proprietary drivers. Linux needs better display drivers and for that OpenCL or Vulkan support as well. Windows uses dotnet and DirectX for games.
  - kstrauser 10y ago
    > SteamOS and SteamMachines will be delayed as well. Not necessarily. It not being merged into mainline Linux doesn't mean that other parties can't include it with their own distros.
  - microcolonel 10y ago
    Windows games are generally not made in dotnet, and games which are made in dotnet (mostly Unity) are actually run on Mono. AMD's Mesa RadeonSI(free) driver frequently outpaces their fglrx(proprietary) driver on recent hardware. NVIDIA and AMD distribute good quality proprietary drivers for Linux, but given the pace the Linux kernel takes, and the benefits of integrating with the native interfaces of the kernel, AMD has decided to write good quality open source drivers as well as their proprietary ones. NVIDIA blocks community open source efforts by delaying the release of firmware images vital to enabling basic features of their GPUs. SteamOS is shipping fglrx for now, and fglrx doesn't currently rely on the DC kernel code. Most SteamMachines seem to be NVIDIA-based for now, and while it's inconvenient to ship their proprietary driver, it is in no danger of failing to work. Read an article or something.
    - untoreh 10y ago
      you can do a quick browse on winehq and see that quite a lot of games use dotnet
      - SXX 10y ago
        Yeah a lot of games use it for configuration / mod management and auto-update tools. But list of games that only use dotnet is relatively short.
  - majewsky 10y ago
    What are you talking about? The amdgpu driver has been in the kernel for over a year and has been working just fine ever since. Source: My desktop PC has an R9 Nano, and I've used the amdgpu driver since Linux 4.5 (when it good power management support for my card and thus could enable usual GPU clock speeds).
  - prodigal_erik 10y ago
    Microsoft management happened to OS/2. There was plenty of hardware that worked, OEMs just couldn't get away with selling a complete system.
- deleted 10y ago
  [deleted]
- zanny 10y ago
  This whole project from AMD was to try to unify their driver infrastructure between Linux and Windows, because their old FGLRX driver was trash and was a hacked together mess of Windows bits tied to the Linux system with its own binary kernel driver. So they wanted to get rid of the ugly kernel part that was a PITA to install and update and are now pushing a lot of their hardware abstraction code from Windows into kernel patches so the AMDGPU driver can just talk to the Windows blob pretty much verbatim (which is now AMDGPU Pro). The practical effect is a continuation of the status quo. AMDGPU Pro, without a lot of this functionality, is either broken or underperforming across all distros. It is still better than what the last FGLRX was, but nowadays the Gallium free driver they also develop is beating the blob in almost everything except the latest driver-level optimized games. Most distros have completely dropped all proprietary AMD support. Going forward, it will be up to them to ship a proprietary driver and maintain installation faculties pretty much everywhere. AMDGPU with Mesa is going to continue working fine, new GPUs are getting supported still, and a lot of what this HAL does (display / window management) has had usable support that has worked for years in various parts of Gallium / Mesa / DRM. The optimistic future is that AMD drops AMDGPU Pro, refocuses developer effort on AMDGPU / Gallium, and works with the rest of the Linux graphics community to implement Freesync / Trueaudio / whatever other tech AMD has buzzwords on into shared kernel code rather than trying to stick it in a HAL from their Windows driver. The pessimistic view has AMD just fire or reassign a lot of its Linux staff, leaving its hardware on the platform to wilt. It would never stop entirely, AMD provides programming manuals for their hardware and most of their ASM in new platforms to enable almost anyone to program their GPUs (unlike Nvidia, who publishes nothing, requiring devs to reverse engineer their hardware and ASM) so the support would still be better than Nouveau.
  - pjmlp 10y ago
    Nothing is preventing AMD to only provide manuals under NDAs, just like NVidia, if they stop seeing value in their contributions.
  - witty_username 10y ago
    Why can't AMD work on the open-source driver? It works good in my experience unlike fglrx.
- saalweachter 10y ago
  Someone at AMD is not making their Q4 OKRs.
theparanoid 10y ago
Sucks to be an AMD graphics driver developer, right now.
- steve-howard 10y ago
  I'm sure there's at least a few who saw this coming, argued against writing a HAL that the kernel developers didn't want, and feel at least a little vindicated right now.
- Kubuxu 10y ago
  That is why in OSS communication is the key. Imagine how much money would be saved if they have asked maintainers first.
  - bsg75 10y ago
    I think they had forewarning for months: https://lists.freedesktop.org/archives/dri-devel/2016-February/100566.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
codys 10y ago
Summary: HALs in the linux kernel are a not acceptable, even large companies are held to some standards. Well, at least for the DRM (Direct Rendering Manager) subsystem.
ageofwant 10y ago
This is why the Linux kernel runs and will continue to run the world. The No men is all that stands between us and the Yes men. Praise and salutations to the No men, God bless you.
- tw04 10y ago
  That's an interesting take... this is why Linux gaming sucks. I get the pragmatism but we also need to be realistic that they aren't going to maintain a completely separate driver for Linux when the Linux gaming market share is barely a rounding error.
  - williadc 10y ago
    > I get the pragmatism but we also need to be realistic I think what you mean is "I get the idealism but you also need to be realistic." It's not pragmatic to stand your guns and ask a multi-million dollar company to change the code they submit to your open-source project.
    - ssutch3 10y ago
      Haha yeah, because the Linux Kernel is just another open source project.
    - omegaworks 10y ago
      Thing is, Linux was never intended to run the latest greatest desktop gaming hardware. It was intended to be an open architecture where people contribute from all around the world to make something larger then themselves. All of these people pretty much contribute their free time to it. If they can't make basic architectural decisions that improve the worst kinds of work (driver authorship and maintenance is awful drudgery) how can you expect them to feel any kind of ownership over their fate? You're asking unpaid people to do the work people get paid for. Even worse, when this work just gets dumped on those unpaid people by people who are paid quite well.
      - egil 10y ago
indolering 10y ago
Dave Airlie's followup is pretty great, > Here's the thing, we want AMD to join the graphics community not hang out inside the company in silos. We need to enable FreeSync on Linux, go ask the community how would be best to do it, don't shove it inside the driver hidden in a special ioctl. Got some new HDMI features that are secret, talk to other ppl in the same position and work out a plan for moving forward. At the moment there is no engaging with the Linux stack because you aren't really using it, as long as you hide behind the abstraction there won't be much engagement, and neither side benefits, so why should we merge the code if nobody benefits? > The platform problem/Windows mindset is scary and makes a lot of decisions for you, open source doesn't have those restrictions, and I don't accept drivers that try and push those development model problems into our codebase.
- X86BSD 10y ago
  That's an interesting take from someone who develops a kernel that the rest of the world has to rip out all sorts of "linux'isms" from code daily and deal with the pain of porting non portable Linux code to their platform. Jesus the hypocrisy is deep.
  - eVeechu7 10y ago
    If someone writes application software that depends on the linux kernel, and someone else wants to port that code to another platform, how is the fact that code changes are required the fault of the kernel developers? I don't see any hypocrisy.
    - dom0 10y ago
      I feel X86BSD here, because Linux has a history of being different for the sake of being different. A relatively recent example could be getentropy (BSD) vs getrandom (Linux). OTOH Linux has some extremely useful syscalls that others just don't have, sometimes causing major performance regressions. Case in point: sync_file_range. But then Linux also has a history of screwing up and having a bunch of different syscalls on different platforms because somebody introducing a syscall didn't quite think it through. Case in point: sync_file_range. This "only" causes extra work for developers directly working with syscalls - so usually libc devs.
joeguilmette 10y ago
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.
partycoder 10y ago
I wonder why this feedback came just now and not earlier. It will be time consuming to change now.
- tw04 10y ago
  Exactly what I'm wondering since they've been working on this for quite some time and asked for feedback a long time ago. How do you sit on this until they are this far along?
  - dflock 10y ago
    They've been getting this feedback - and apparently ignoring it - since February: > Cleaning up that is not enough, abstracting kernel API like kmalloc or i2c, or similar, is a no go. If the current drm infrastructure does not suit your need then you need to work on improving it to suit your need. You can not redevelop a whole drm layer inside your code and expect to upstream it. > Linux device driver are about sharing infrastructure and trying to expose it through common API to userspace. > So i strongly suggest that you start thinking on how to change the drm API to suit your need and to start discussions about those changes. If you need them then they will likely be usefull to others down the road. https://lists.freedesktop.org/archives/dri-devel/2016-February/100729.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
- pero 10y ago
  It seems like they might have somehow ignored direction from as early as February... https://lists.freedesktop.org/archives/dri-devel/2016-February/100566.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
  - aidenn0 10y ago
    Even more clear: > Cleaning up that is not enough, abstracting kernel API like kmalloc or i2c, or similar, is a no go. If the current drm infrastructure does not suit your need then you need to work on improving it to suit your need. You can not develop a whole drm layer inside your code and expect to upstream it. https://lists.freedesktop.org/archives/dri-devel/2016-February/100729.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
deleted 10y ago
[deleted]
nice_byte 10y ago
honestly, i'd rather have a functional but proprietary driver than have nothing at all. this is wrong.
- abrodersen 10y ago
  That's easy to say when you don't have to maintain the code!
- farresito 10y ago
  They were advised months ago that this could happen and they kept going with that. It might suck as a user, but you have to respect whichever standards the Linux kernel asks for.
  - m-p-3 10y ago
    Binary blob it is I suppose..
    - tracker1 10y ago
      a 100kloc hal shim for a single vendor is unacceptable. I don't blame them... If they'd presented this as a joint approach with nvidia and intel, maybe, but that is not the case... Why not make a HAL for Windows/osx and use a linux mode as the base? In the end, it kind of sucks, but was the right thing to do.
      - izacus 10y ago
        I wonder how that proposal would go inside a corporation - "we need to rewrite our driver at huge development costs instead of further competing with nVidia because we need to make OS developers of marginal market importance happy".
        dragandj 10y ago
        One of the problems for AMD is that everybody uses nVidia for computing, and nobody uses AMD. One of the reasons is thaf they have been ignoring non-mainstream GPU market. Well, those non-mainstream markets become mainstream and if you fall behind it is almost impossible to catch up. I personally prefer AMD's GPUs for computing and prefer OpenCL to CUDA. But, they are minor, since nvidia has much better software offering. AMD absolutely need to offer superb Linux story if they want to get people to use their hardware for computing instead of nvidia. They need Linux more than Linux needs them.
mVChr 10y ago
For any other layer-7-only arm-chair mechanics who also weren't sure what a HAL[1] was, I'm here to help. [1] https://en.wikipedia.org/wiki/HAL_(software) https://en.wikipedia.org/wiki/HAL_(software)
- Noughmad 10y ago
  While HAL does stand for Hardware Abstraction Layer in general, the page you linked is for a specific piece of software that was used by previous versions of KDE and Gnome for this purpose.
  - mVChr 10y ago
    True, good clarification. I had visited the more general page also[1] but thought the other was more relevant to the email thread. And definitely much better than my only other inkling for what that meant in relation to computer systems.[2] [1] https://en.wikipedia.org/wiki/Hardware_abstraction https://en.wikipedia.org/wiki/Hardware_abstraction [2] https://en.wikipedia.org/wiki/HAL_9000 https://en.wikipedia.org/wiki/HAL_9000
microcolonel 10y ago
As far as I'm concerned, it would be great to have more sophisticated modesetting available on my new AMD hardware; but if it means a compromise in the DRI I won't stand for it. There's no sense in having a review process if a vendor can largely ignore a review and go silent for three quarters, then ask for whatever they have to be merged because they'd like it that way.
laurentoget 10y ago
I suspect some bearded guy at AMD is having his 'i told you so' hour of glory sometime this week.
- frozenport 10y ago
  Quite the opposite, somebody at AMD wanted to play along with the openness of the Linux kernel. Then to help unify their codes bases they push this - and get rejected. Somebody at NVIDIA is laughing their ass off, saying it would have much easier if AMD just did what NVIDIA does!
  - joecool1029 10y ago
    Don't see why you're getting downvoted. This is likely the closest to the truth.
    - sangnoir 10y ago
      > This is likely the closest to the truth. This depends on whether there is at least 1 person at AMD who has experience with kernel development. If all of the team members all kernel outsiders, then this might confuse/surprise them. Otherwise someone likely raised this as a potential issue.
      - chei0iaV 10y ago
        AMD had hired kernel developers to work on graphics drivers soon after taking over ATI.
        dvfjsdhgfv 10y ago
        well, the conclusion is obvious then
    - aseipp 10y ago
      Because they were told months ago this could have happened. They didn't listen.
fowl2 10y ago
Quite professional, well written and clearly the words of someone who cares about the product. Lack of profanities already exceeded the LKML reputation. I think the point about rules being applied consistently is very true. If Alice does the work to comply then Bob shouldn't be able to get away without doing it just because he's bigger.
- bonzini 10y ago
  Reputation or perception are sometimes very different from reality.
  - shadowban_me 10y ago
    Reality has a pro-liberal bias. Any other pointless context-less generalizations we can cram in here?
- mackal 10y ago
  Maybe they swore at AMD back in February when they told them this wasn't gonna work AMD wouldn't have wasted almost a year.
leni536 10y ago
Many people in this thread implicitly suggest that this will have a negative impact on end users. I'm not so sure, amdgpu still can be distributed separately to the vanilla kernel. So this rejection is about maintainership that negatively affects distribution of the amdgpu module as a side effect. It's nothing that can't be solved by linux distributions though.
MrQuincle 10y ago
It seems people think only about games for now, but taking a maintenance perspective is also wise from the perspective of using GPUs for other purposes. One of these is cloud computing on large clusters of headless machines using the parallelization that GPUs are known for. If you want to do this right you definitely need input from a lot of sources, not just hacks in AMD delivered code.
mijoharas 10y ago
Can anyone explain what the acronym DC stands for in these emails? (managed to get most of the others, but googling DC kernel doesn't turn up much :) )
- tremon 10y ago
  Display core. From a message upthread: We propose to use the Display Core (DC) driver for display support on AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to avoid a flag day the plan is to only support uGPU initially and transition to older ASICs gradually. The DC component has received extensive testing within AMD for DCE8, 10, and 11 GPUs and is being prepared for uGPU. Support should be better than amdgpu's current display support.
- deleted 10y ago
  [deleted]
ldev 10y ago
Linux should be pure and open source, not user friendly and convenient.
- frumiousirc 10y ago
  Internet arguments should rely only on false dichotomy, not nuanced and reasoned statements.
- majewsky 10y ago
  How does this relate in any way to this discussion? Do you think the kernel will be more user-friendly when the maintainers cannot understand their code anymore?
fithisux 10y ago
The bright side is that they are OSS friendly, not like NVIDIA, and they can take their code to github for cleanup and further inclusion.
UhUhUhUh 10y ago
I side with the little guy (i.e. < 2.5% market share) who makes my personal life easier everyday.
deleted 10y ago
[deleted]
danvet 10y ago
I commented a summary on the phoronix forums already, copypasting here. I'm the good cop in the good cop/bad coop game Dave&I have been playing in this. Maybe this helps clear up some of the confusion and anger here. This is me talking with my community hat on (not my Intel maintainer hat), and with that hat on my overall goal is always to build a strong community so that in the future open source gfx wins everywhere, and everyone can have good drivers with source-code. Anyway: - "Why not merge through staging?" Staging is a ghetto, separate from the main dri-devel discussions. We've merged a few drivers through staging, it's a pain, and if your goal is to build a strong cross-vendor community and foster good collaboration between different teams to share code and bugfixes and ideas then staging is fail. We've merged about 20 atomic modeset drivers in the past 2 years, non of them went through staging. - "Typing code twice doesn't make sense, why do you reject this?" Agreed, but there's fundamentally two ways to share code in drivers. One is you add a masive HAL to abstract away the differences between all the places you want your driver to run in. The other is that you build a helper library that programs different parts of your hw, and then you have a (fairly minimal) OS-specific piece of glue that binds it together in a way that's best for each OS. Simplifying things of course here, but the big lesson in Linux device drivers (not just drm) is that HAL is pain, and the little bit of additional unshared code that the helper library code requires gives you massive benefits. Upstream doesn't ask AMD to not share code, it's only the specific code sharing design that DAL/DC implements which isn't good. - "Why do you expect perfect code before merging?" We don't, I think compard to most other parts in the kernel DRM is rather lenient in accepting good enough code - we know that somewhat bad code today is much more useful than perfect code 2 years down the road, simply because in 2 years no one gives a shit about your outdated gpu any more. But the goal is always to make the community stronger, and like Dave explains in his follow up, merging code that hurts effective collaboration is likely an overall (for the community, not individual vendors) loss and not worth it. - "Why not fix up post-merge?" Perfectly reasonable plan, and often what we do. See above for why we tend to except not-yet-perfect code rather often. But doing that only makes sense when thing will move forward soon&fast, and for better or worse the DAL team is hidden behind that massive abstraction layer. And I've seen a lot of these, and if there's not massive pressure to fix up th problem it tends to get postponed forever since demidlayering a driver or subsystem is very hard work. We have some midlayer/abstraction layer issues dating back from the first drm drivers 15 years ago in the drm core, and it took over 5 years to clean up that mess. For a grand total of about 10k lines of code. Merging DAL as-is pretty much guarantees it'll never get fixed until the driver is forked once more. - "Why don't you just talk and reach some sort of agreement?" There's lots of talking going on, it's just that most of it happens in private because things are complicated, and it's never easy to do such big course correction with big projects like AMD's DAL/DC efforts. - "Why do you open source hippies hate AMD so much?" We don't, everyone wants to get AMD on board with upstream and be able to treat open-source gfx drivers as a first class citizen within AMD (stuff like using it to validate and power-on hardware is what will make the difference between "Linux kinda runs" and "Linux runs as good or better than any other OS"). But doing things the open source way is completely different from how companies tend to do things traditinoally (note: just different, not better or worse!), and if you drag lots of engineers and teams and managers into upstream the learning experience tends to be painful for everyone and take years. We'll all get there eventually, but it's not going to happen in a few days. It's just unfortunate that things are a bit ugly while that's going on, but looking at any other company that tries to do large-scale open-source efforts, especially hw teams, it's the same story, e.g. see what IBM is trying to pull off with open power. Hope that sheds some more light onto all this and calms everyone down ;-)
hobarrera 10y ago
What are the chances that some lone developers will pick this source up and patch it up enough to be acceptable inside the kernel? I mean, it is all GPL, so it's perfectly okay. Is it too much for some dev in seek of fame to do this?

446 points by pero 10y ago

What's the practical effect of this? We'll have to wait until someone writes a reasonable alternative for these GPUs to be supported in Linux? Edit: Here's the start of the thread https://lists.freedesktop.org/archives/dri-devel/2016-December/126422.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...

orionblastar 10y ago
SteamOS and SteamMachines will be delayed as well. Nvidia support for Linux is hard to get as well. Now AMD support is also hard to get. Hardware OEM companies make Windows drivers, and don't seem to care about Linux. This is the same thing that happened to IBM and OS/2 not good third party driver support. There are open source drivers that work, but are not as fast as the proprietary drivers. Linux needs better display drivers and for that OpenCL or Vulkan support as well. Windows uses dotnet and DirectX for games.
- kstrauser 10y ago
  > SteamOS and SteamMachines will be delayed as well. Not necessarily. It not being merged into mainline Linux doesn't mean that other parties can't include it with their own distros.
- microcolonel 10y ago
  Windows games are generally not made in dotnet, and games which are made in dotnet (mostly Unity) are actually run on Mono. AMD's Mesa RadeonSI(free) driver frequently outpaces their fglrx(proprietary) driver on recent hardware. NVIDIA and AMD distribute good quality proprietary drivers for Linux, but given the pace the Linux kernel takes, and the benefits of integrating with the native interfaces of the kernel, AMD has decided to write good quality open source drivers as well as their proprietary ones. NVIDIA blocks community open source efforts by delaying the release of firmware images vital to enabling basic features of their GPUs. SteamOS is shipping fglrx for now, and fglrx doesn't currently rely on the DC kernel code. Most SteamMachines seem to be NVIDIA-based for now, and while it's inconvenient to ship their proprietary driver, it is in no danger of failing to work. Read an article or something.
  - untoreh 10y ago
    you can do a quick browse on winehq and see that quite a lot of games use dotnet
    - SXX 10y ago
      Yeah a lot of games use it for configuration / mod management and auto-update tools. But list of games that only use dotnet is relatively short.
- majewsky 10y ago
  What are you talking about? The amdgpu driver has been in the kernel for over a year and has been working just fine ever since. Source: My desktop PC has an R9 Nano, and I've used the amdgpu driver since Linux 4.5 (when it good power management support for my card and thus could enable usual GPU clock speeds).
- prodigal_erik 10y ago
  Microsoft management happened to OS/2. There was plenty of hardware that worked, OEMs just couldn't get away with selling a complete system.
deleted 10y ago
[deleted]
zanny 10y ago
This whole project from AMD was to try to unify their driver infrastructure between Linux and Windows, because their old FGLRX driver was trash and was a hacked together mess of Windows bits tied to the Linux system with its own binary kernel driver. So they wanted to get rid of the ugly kernel part that was a PITA to install and update and are now pushing a lot of their hardware abstraction code from Windows into kernel patches so the AMDGPU driver can just talk to the Windows blob pretty much verbatim (which is now AMDGPU Pro). The practical effect is a continuation of the status quo. AMDGPU Pro, without a lot of this functionality, is either broken or underperforming across all distros. It is still better than what the last FGLRX was, but nowadays the Gallium free driver they also develop is beating the blob in almost everything except the latest driver-level optimized games. Most distros have completely dropped all proprietary AMD support. Going forward, it will be up to them to ship a proprietary driver and maintain installation faculties pretty much everywhere. AMDGPU with Mesa is going to continue working fine, new GPUs are getting supported still, and a lot of what this HAL does (display / window management) has had usable support that has worked for years in various parts of Gallium / Mesa / DRM. The optimistic future is that AMD drops AMDGPU Pro, refocuses developer effort on AMDGPU / Gallium, and works with the rest of the Linux graphics community to implement Freesync / Trueaudio / whatever other tech AMD has buzzwords on into shared kernel code rather than trying to stick it in a HAL from their Windows driver. The pessimistic view has AMD just fire or reassign a lot of its Linux staff, leaving its hardware on the platform to wilt. It would never stop entirely, AMD provides programming manuals for their hardware and most of their ASM in new platforms to enable almost anyone to program their GPUs (unlike Nvidia, who publishes nothing, requiring devs to reverse engineer their hardware and ASM) so the support would still be better than Nouveau.
- pjmlp 10y ago
  Nothing is preventing AMD to only provide manuals under NDAs, just like NVidia, if they stop seeing value in their contributions.
- witty_username 10y ago
  Why can't AMD work on the open-source driver? It works good in my experience unlike fglrx.
saalweachter 10y ago
Someone at AMD is not making their Q4 OKRs.

theparanoid 10y ago

Sucks to be an AMD graphics driver developer, right now.

steve-howard 10y ago
I'm sure there's at least a few who saw this coming, argued against writing a HAL that the kernel developers didn't want, and feel at least a little vindicated right now.
Kubuxu 10y ago
That is why in OSS communication is the key. Imagine how much money would be saved if they have asked maintainers first.
- bsg75 10y ago
  I think they had forewarning for months: https://lists.freedesktop.org/archives/dri-devel/2016-February/100566.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

codys 10y ago

Summary: HALs in the linux kernel are a not acceptable, even large companies are held to some standards. Well, at least for the DRM (Direct Rendering Manager) subsystem.

ageofwant 10y ago

This is why the Linux kernel runs and will continue to run the world. The No men is all that stands between us and the Yes men. Praise and salutations to the No men, God bless you.

tw04 10y ago
That's an interesting take... this is why Linux gaming sucks. I get the pragmatism but we also need to be realistic that they aren't going to maintain a completely separate driver for Linux when the Linux gaming market share is barely a rounding error.
- williadc 10y ago
  > I get the pragmatism but we also need to be realistic I think what you mean is "I get the idealism but you also need to be realistic." It's not pragmatic to stand your guns and ask a multi-million dollar company to change the code they submit to your open-source project.
  - ssutch3 10y ago
    Haha yeah, because the Linux Kernel is just another open source project.
  - omegaworks 10y ago
    Thing is, Linux was never intended to run the latest greatest desktop gaming hardware. It was intended to be an open architecture where people contribute from all around the world to make something larger then themselves. All of these people pretty much contribute their free time to it. If they can't make basic architectural decisions that improve the worst kinds of work (driver authorship and maintenance is awful drudgery) how can you expect them to feel any kind of ownership over their fate? You're asking unpaid people to do the work people get paid for. Even worse, when this work just gets dumped on those unpaid people by people who are paid quite well.
    - egil 10y ago

indolering 10y ago

Dave Airlie's followup is pretty great, > Here's the thing, we want AMD to join the graphics community not hang out inside the company in silos. We need to enable FreeSync on Linux, go ask the community how would be best to do it, don't shove it inside the driver hidden in a special ioctl. Got some new HDMI features that are secret, talk to other ppl in the same position and work out a plan for moving forward. At the moment there is no engaging with the Linux stack because you aren't really using it, as long as you hide behind the abstraction there won't be much engagement, and neither side benefits, so why should we merge the code if nobody benefits? > The platform problem/Windows mindset is scary and makes a lot of decisions for you, open source doesn't have those restrictions, and I don't accept drivers that try and push those development model problems into our codebase.

X86BSD 10y ago
That's an interesting take from someone who develops a kernel that the rest of the world has to rip out all sorts of "linux'isms" from code daily and deal with the pain of porting non portable Linux code to their platform. Jesus the hypocrisy is deep.
- eVeechu7 10y ago
  If someone writes application software that depends on the linux kernel, and someone else wants to port that code to another platform, how is the fact that code changes are required the fault of the kernel developers? I don't see any hypocrisy.
  - dom0 10y ago
    I feel X86BSD here, because Linux has a history of being different for the sake of being different. A relatively recent example could be getentropy (BSD) vs getrandom (Linux). OTOH Linux has some extremely useful syscalls that others just don't have, sometimes causing major performance regressions. Case in point: sync_file_range. But then Linux also has a history of screwing up and having a bunch of different syscalls on different platforms because somebody introducing a syscall didn't quite think it through. Case in point: sync_file_range. This "only" causes extra work for developers directly working with syscalls - so usually libc devs.

joeguilmette 10y ago

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.

partycoder 10y ago

I wonder why this feedback came just now and not earlier. It will be time consuming to change now.

tw04 10y ago
Exactly what I'm wondering since they've been working on this for quite some time and asked for feedback a long time ago. How do you sit on this until they are this far along?
- dflock 10y ago
  They've been getting this feedback - and apparently ignoring it - since February: > Cleaning up that is not enough, abstracting kernel API like kmalloc or i2c, or similar, is a no go. If the current drm infrastructure does not suit your need then you need to work on improving it to suit your need. You can not redevelop a whole drm layer inside your code and expect to upstream it. > Linux device driver are about sharing infrastructure and trying to expose it through common API to userspace. > So i strongly suggest that you start thinking on how to change the drm API to suit your need and to start discussions about those changes. If you need them then they will likely be usefull to others down the road. https://lists.freedesktop.org/archives/dri-devel/2016-February/100729.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
pero 10y ago
It seems like they might have somehow ignored direction from as early as February... https://lists.freedesktop.org/archives/dri-devel/2016-February/100566.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
- aidenn0 10y ago
  Even more clear: > Cleaning up that is not enough, abstracting kernel API like kmalloc or i2c, or similar, is a no go. If the current drm infrastructure does not suit your need then you need to work on improving it to suit your need. You can not develop a whole drm layer inside your code and expect to upstream it. https://lists.freedesktop.org/archives/dri-devel/2016-February/100729.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

deleted 10y ago

[deleted]

nice_byte 10y ago

honestly, i'd rather have a functional but proprietary driver than have nothing at all. this is wrong.

abrodersen 10y ago
That's easy to say when you don't have to maintain the code!
farresito 10y ago
They were advised months ago that this could happen and they kept going with that. It might suck as a user, but you have to respect whichever standards the Linux kernel asks for.
- m-p-3 10y ago
  Binary blob it is I suppose..
  - tracker1 10y ago
    a 100kloc hal shim for a single vendor is unacceptable. I don't blame them... If they'd presented this as a joint approach with nvidia and intel, maybe, but that is not the case... Why not make a HAL for Windows/osx and use a linux mode as the base? In the end, it kind of sucks, but was the right thing to do.
    - izacus 10y ago
      I wonder how that proposal would go inside a corporation - "we need to rewrite our driver at huge development costs instead of further competing with nVidia because we need to make OS developers of marginal market importance happy".
      - dragandj 10y ago
        One of the problems for AMD is that everybody uses nVidia for computing, and nobody uses AMD. One of the reasons is thaf they have been ignoring non-mainstream GPU market. Well, those non-mainstream markets become mainstream and if you fall behind it is almost impossible to catch up. I personally prefer AMD's GPUs for computing and prefer OpenCL to CUDA. But, they are minor, since nvidia has much better software offering. AMD absolutely need to offer superb Linux story if they want to get people to use their hardware for computing instead of nvidia. They need Linux more than Linux needs them.

mVChr 10y ago

For any other layer-7-only arm-chair mechanics who also weren't sure what a HAL[1] was, I'm here to help. [1] https://en.wikipedia.org/wiki/HAL_(software) https://en.wikipedia.org/wiki/HAL_(software)

Noughmad 10y ago
While HAL does stand for Hardware Abstraction Layer in general, the page you linked is for a specific piece of software that was used by previous versions of KDE and Gnome for this purpose.
- mVChr 10y ago
  True, good clarification. I had visited the more general page also[1] but thought the other was more relevant to the email thread. And definitely much better than my only other inkling for what that meant in relation to computer systems.[2] [1] https://en.wikipedia.org/wiki/Hardware_abstraction https://en.wikipedia.org/wiki/Hardware_abstraction [2] https://en.wikipedia.org/wiki/HAL_9000 https://en.wikipedia.org/wiki/HAL_9000

microcolonel 10y ago

As far as I'm concerned, it would be great to have more sophisticated modesetting available on my new AMD hardware; but if it means a compromise in the DRI I won't stand for it. There's no sense in having a review process if a vendor can largely ignore a review and go silent for three quarters, then ask for whatever they have to be merged because they'd like it that way.

laurentoget 10y ago

I suspect some bearded guy at AMD is having his 'i told you so' hour of glory sometime this week.

frozenport 10y ago
Quite the opposite, somebody at AMD wanted to play along with the openness of the Linux kernel. Then to help unify their codes bases they push this - and get rejected. Somebody at NVIDIA is laughing their ass off, saying it would have much easier if AMD just did what NVIDIA does!
- joecool1029 10y ago
  Don't see why you're getting downvoted. This is likely the closest to the truth.
  - sangnoir 10y ago
    > This is likely the closest to the truth. This depends on whether there is at least 1 person at AMD who has experience with kernel development. If all of the team members all kernel outsiders, then this might confuse/surprise them. Otherwise someone likely raised this as a potential issue.
    - chei0iaV 10y ago
      AMD had hired kernel developers to work on graphics drivers soon after taking over ATI.
      - dvfjsdhgfv 10y ago
        well, the conclusion is obvious then
  - aseipp 10y ago
    Because they were told months ago this could have happened. They didn't listen.

fowl2 10y ago

Quite professional, well written and clearly the words of someone who cares about the product. Lack of profanities already exceeded the LKML reputation. I think the point about rules being applied consistently is very true. If Alice does the work to comply then Bob shouldn't be able to get away without doing it just because he's bigger.

bonzini 10y ago
Reputation or perception are sometimes very different from reality.
- shadowban_me 10y ago
  Reality has a pro-liberal bias. Any other pointless context-less generalizations we can cram in here?
mackal 10y ago
Maybe they swore at AMD back in February when they told them this wasn't gonna work AMD wouldn't have wasted almost a year.

leni536 10y ago

Many people in this thread implicitly suggest that this will have a negative impact on end users. I'm not so sure, amdgpu still can be distributed separately to the vanilla kernel. So this rejection is about maintainership that negatively affects distribution of the amdgpu module as a side effect. It's nothing that can't be solved by linux distributions though.

MrQuincle 10y ago

It seems people think only about games for now, but taking a maintenance perspective is also wise from the perspective of using GPUs for other purposes. One of these is cloud computing on large clusters of headless machines using the parallelization that GPUs are known for. If you want to do this right you definitely need input from a lot of sources, not just hacks in AMD delivered code.

mijoharas 10y ago

Can anyone explain what the acronym DC stands for in these emails? (managed to get most of the others, but googling DC kernel doesn't turn up much :) )

tremon 10y ago
Display core. From a message upthread: We propose to use the Display Core (DC) driver for display support on AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to avoid a flag day the plan is to only support uGPU initially and transition to older ASICs gradually. The DC component has received extensive testing within AMD for DCE8, 10, and 11 GPUs and is being prepared for uGPU. Support should be better than amdgpu's current display support.
deleted 10y ago
[deleted]

ldev 10y ago

Linux should be pure and open source, not user friendly and convenient.

frumiousirc 10y ago
Internet arguments should rely only on false dichotomy, not nuanced and reasoned statements.
majewsky 10y ago
How does this relate in any way to this discussion? Do you think the kernel will be more user-friendly when the maintainers cannot understand their code anymore?

fithisux 10y ago

The bright side is that they are OSS friendly, not like NVIDIA, and they can take their code to github for cleanup and further inclusion.

UhUhUhUh 10y ago

I side with the little guy (i.e. < 2.5% market share) who makes my personal life easier everyday.

deleted 10y ago

[deleted]

danvet 10y ago

I commented a summary on the phoronix forums already, copypasting here. I'm the good cop in the good cop/bad coop game Dave&I have been playing in this. Maybe this helps clear up some of the confusion and anger here. This is me talking with my community hat on (not my Intel maintainer hat), and with that hat on my overall goal is always to build a strong community so that in the future open source gfx wins everywhere, and everyone can have good drivers with source-code. Anyway: - "Why not merge through staging?" Staging is a ghetto, separate from the main dri-devel discussions. We've merged a few drivers through staging, it's a pain, and if your goal is to build a strong cross-vendor community and foster good collaboration between different teams to share code and bugfixes and ideas then staging is fail. We've merged about 20 atomic modeset drivers in the past 2 years, non of them went through staging. - "Typing code twice doesn't make sense, why do you reject this?" Agreed, but there's fundamentally two ways to share code in drivers. One is you add a masive HAL to abstract away the differences between all the places you want your driver to run in. The other is that you build a helper library that programs different parts of your hw, and then you have a (fairly minimal) OS-specific piece of glue that binds it together in a way that's best for each OS. Simplifying things of course here, but the big lesson in Linux device drivers (not just drm) is that HAL is pain, and the little bit of additional unshared code that the helper library code requires gives you massive benefits. Upstream doesn't ask AMD to not share code, it's only the specific code sharing design that DAL/DC implements which isn't good. - "Why do you expect perfect code before merging?" We don't, I think compard to most other parts in the kernel DRM is rather lenient in accepting good enough code - we know that somewhat bad code today is much more useful than perfect code 2 years down the road, simply because in 2 years no one gives a shit about your outdated gpu any more. But the goal is always to make the community stronger, and like Dave explains in his follow up, merging code that hurts effective collaboration is likely an overall (for the community, not individual vendors) loss and not worth it. - "Why not fix up post-merge?" Perfectly reasonable plan, and often what we do. See above for why we tend to except not-yet-perfect code rather often. But doing that only makes sense when thing will move forward soon&fast, and for better or worse the DAL team is hidden behind that massive abstraction layer. And I've seen a lot of these, and if there's not massive pressure to fix up th problem it tends to get postponed forever since demidlayering a driver or subsystem is very hard work. We have some midlayer/abstraction layer issues dating back from the first drm drivers 15 years ago in the drm core, and it took over 5 years to clean up that mess. For a grand total of about 10k lines of code. Merging DAL as-is pretty much guarantees it'll never get fixed until the driver is forked once more. - "Why don't you just talk and reach some sort of agreement?" There's lots of talking going on, it's just that most of it happens in private because things are complicated, and it's never easy to do such big course correction with big projects like AMD's DAL/DC efforts. - "Why do you open source hippies hate AMD so much?" We don't, everyone wants to get AMD on board with upstream and be able to treat open-source gfx drivers as a first class citizen within AMD (stuff like using it to validate and power-on hardware is what will make the difference between "Linux kinda runs" and "Linux runs as good or better than any other OS"). But doing things the open source way is completely different from how companies tend to do things traditinoally (note: just different, not better or worse!), and if you drag lots of engineers and teams and managers into upstream the learning experience tends to be painful for everyone and take years. We'll all get there eventually, but it's not going to happen in a few days. It's just unfortunate that things are a bit ugly while that's going on, but looking at any other company that tries to do large-scale open-source efforts, especially hw teams, it's the same story, e.g. see what IBM is trying to pull off with open power. Hope that sheds some more light onto all this and calms everyone down ;-)

hobarrera 10y ago

What are the chances that some lone developers will pick this source up and patch it up enough to be acceptable inside the kernel? I mean, it is all GPL, so it's perfectly okay. Is it too much for some dev in seek of fame to do this?