23 ms·

AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

350 points by belltaco 10y ago

belltaco 10y ago
Discussion of the rejection here. https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426
imaginenore 10y ago
What I don't get is how one kernel maintainer can make such a massive decision that affects all of Linux. That's some near-totalitarian level of power. After reading the arguments, I'm kind of on AMD's side. I get what Dave wants, but it seems extremely idealistic.
- gigatexal 10y ago
  That's how the kernel development works. As far as I can tell, if you get maintainer status from Linus you can do as you please for the understanding is that you're acting as he would.
  - chx 10y ago
    As Dave said: > Given the choice between maintaining Linus' trust that I won't merge 100,000 lines of abstracted HAL code and merging 100,000 lines of abstracted HAL code I'll give you one guess where my loyalties lie. He is acting in a way he thinks would keep Linus' trust. Also, usually the maintainers have far superior technical knowledge of their areas to Linus. I mean, Linus is just one guy and each maintainer have their own specialty.
- wyldfire 10y ago
  Linus delegates authority to people he trusts. And in this case, Dave is likely representing well what Linus would do. > near-totalitarian level of power. I don't think you meant to use that word. Linus and the kernel contributors together own the copyrights on the kernel. It's not totalitarian for them to dictate its future. It's their creative work. It's downright egalitarian that they let you use the kernel however you like, provided that you give the source in turn to whoever you hand it to.
  - ocdtrekkie 10y ago
    I suppose the intended notion, would be given the number of Linux distributions and use cases out there, the number of companies involved, the number of products built on top of the Linux kernel... it's amazing that one guy with little financial interest in the results or effects can make that call for everyone. I'm not sure if that's a good thing or a bad thing, to be honest, it's just... particularly interesting about the way Linux works.
    - wmf 10y ago
      It's amazing that one guy with little financial interest in the results or effects can make that call for everyone. Impartial expert judges are usually considered a good thing. Note that Dave Airlie is not acting on a whim here; the Linux development community has discussed HALs for probably 20 years and has come to the conclusion that they are a net negative. For better or worse, the Linux development process does not care about democracy or market share or vendor relations. It's a somewhat unusual way to build software, but the result pretty much speaks for itself.
      - pjmlp 10y ago
        Yep, each vendor that doesn't want to deal with it, just forks it, never contributing anything back.
    - Analemma_ 10y ago
      If it was a big secret that this was how Linux worked and it took the companies by surprise, I could see how this could be a bad thing, but it never has been: Linus has always been very upfront that he is Benevolent Dictator for Life and always has the last word. Don't get onboard if you don't like that system.
      - wolfgke 10y ago
        Then all the Linux fans that complained to AMD that they don't deliver open source drivers should from now on better shitstorm the kernel maintainers, since AMD delivered.
- forgottenpass 10y ago
  That's some near-totalitarian level of power. AMD is perfectly within their rights and abilities to ship an out-of-tree driver. As I understand it, DKMS exists to make that use case easier for end users. The popular consumer-facing distros would probably make it easy as dirt to install too. The difference between that and upstreaming into the kernel is primarily shifting some of the the maintenance burden onto the kernel developers. That comes with the condition of adding stakeholders to the driver design, not just using them as a code dumping ground. "Totalitarian" seems a bit over the top.
- fapjacks 10y ago
  The Good King is how Linux has come to run the world's servers. I am perfectly fine missing out on some incidental functionality here or there in order to keep this power structure which had protected the Linux kernel thus far. It seems to work extremely well.
  - this-dang-guy 10y ago
    I'd prefer to see NVidia style drivers, personally. I don't give a rat's beans if optimized video card, nic, etc drivers are open. I just want a system that will work properly without them. Not 60FPS on Ultra settings in <game> work, I mean boot and function as a normal user's desktop.
    - fapjacks 10y ago
      Yeah, I don't care about nvidia drivers, either. AMD doesn't need this in the kernel anymore than nvidia does (and they don't). Kernel modules work just fine for drivers. I don't want some convoluted shit crammed into mainline because <company> chooses to ignore feedback about their code. I am perfectly fine with this one guy shooting down AMD's pretentious attitude here. If it weren't for those kernel devs, good luck getting a Linux system to "boot and function as a normal user's desktop" because of all the crap that would be in there. Like systemd, just piles of crap in a confused, kitchen-sink orgy.
      - digi_owl 10y ago
        I have come to fear that we will eventually need GPU drivers in the kernel directly, thanks to more and more of the graphics code out there assuming DRM/DRI etc.
  - pjmlp 10y ago
    Being a free beer clone of expensive UNIX workstation OSes helped. Of course companies had an agenda to improve it to the point they wouldn't need to keep paying Sun, SGI, HP, IBM, Compaq, Unisys,...
- matt4077 10y ago
  Why don't you try to get some code merged into the Windows kernel and tell us how that goes? > After reading the arguments, I'm kind of on AMD's side. And that's why stuff like this doesn't get put to a vote.
- k_sze 10y ago
  There's a reason Linus is called the BDFL of Linux.
deleted 10y ago
[deleted]
- deleted 10y ago
  [deleted]
lettergram 10y ago
I do feel Dave went a bit over the top in his response. If he keeps it technical it's easier to fix, people want to see their stuff merged. When he makes it personal (which he kind of did) it turns people off. That being said, I do think Dave probably made the right call, but I also think he may need to compromise on this one. That being said, AMD should strategicly try and get their GPUs supported. Couple that, with merging an OpenCL version of Tensorflow or something and AMD would probably be more valuable than Nvidia. I think both groups could benefit and should probably sit and try to work it out in person.
- 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.
aqtrans 10y ago
Did I miss the mud-slinging and corporate culture bashing from the original rejection? I can get the AMD dev being a bit sour by the whole situation if they personally spent time working on this rejected patch, but damn.
- jff 10y ago
  There were certainly implications that the AMD coders were making technically compromised decisions: > The reason the toplevel maintainer (me) doesn't work for Intel or AMD or any vendors, is that I can say NO when your maintainers can't or won't say it. And telling them to sit in a corner and really THINK about what you've done, young man: > I'd like some serious introspection on your team's part on how you got into this situation and how even if I was feeling like merging this (which I'm not) how you'd actually deal with being part of the Linux kernel and not hiding in nicely framed orgchart silo behind a HAL. I honestly don't think the code is Linux worthy code All pretty mild, really, but I'm not the one who got the email telling me my months of work was not Linux-quality and would not be merged. (I am giggling at the idea of "Linux quality" being held up as an ideal)
  - aqtrans 10y ago
    Ahh, thanks for pointing those out. I completely skipped over those portions...I was expecting some Linus-level chewing out that I'd missed given the tone of the response, haha. Certainly pretty mild considering the source, though I understand why the second quote would stir things up a bit, especially making it into an "Us vs Them" situation.
  - jlgaddis 10y ago
    > ... but I'm not the one who got the email telling me my months of work ... would not be merged. See, the thing is that they were told previously -- back in February? March? -- that this wasn't gonna happen. Instead of trying to work out a better way forward, AMD effectively ignored that, went back to work, and just now came back and said "here's 90k LOC, please merge". Dave replied -- rightfully, in my opinion -- "no".
- Analemma_ 10y ago
zznneezznnee 10y ago
The kernel maintainers don't necessarily want your code. Additional shit in mainline increases the maintenance burden. If the code isn't putting upstream maintainability above all else in its implementation, then it's generally not getting merged unless someone wasn't paying attention or some other forces compelled an exception. Alex's first reply reads like he's willfully ignoring that aspect of the NACK. It's not a coding style issue, it's a HAL issue. Upstream isn't interested in maintaining a HAL and living with the impedance mismatch from day zero. The driver can stay out of tree. This is just about code getting into mainline. I'm personally very happy to see the gpu subsystem maintainers paying attention and having the maturity to know a fool's errand when they see it.
- izacus 10y ago
  Then again, we're not talking about some wierd network card driver here. We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer. A driver which has caused a large amount of desktop users to return to Windows due to its historical issues. While I get the reasoning for rejection, the typical OSS rejection attitude is also problematic. I kinda don't see a dialog happening here on how to resolve problems both sides have, just a repeat of posturing which has historically brought us awesome things like binary blob drivers that only work with single version of kernels (yes, I'm looking at you every ARM GPU ever!).
  - x0x0 10y ago
    AMD was told in February that they would have to obey kernel code standards / no HAL. In late October they dropped a steaming pile of 100k lines of code with a HAL and are whining it isn't getting merged. The solution is AMD keeps code out of mainline or obeys kernel code standards.
    - ChoGGi 10y ago
      My favorite part is back in February they made mention of shrinking it to 1/3 of what it was (93KLOC). Now we're up to 100K+ https://lists.freedesktop.org/archives/dri-devel/2016-February/100715.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
Spivak 10y ago
I really don't understand why AMD cares so much about getting their driver upstreamed. If their code doesn't meet the kernel standards and they don't want to fix it then just package it up as kernel module and ship it like Nvidia does. Distributions will package it using DKMS and other than some occasional troubleshooting they wont even notice. It's really no difference than Windows in that respect. His arguments seem really weak. Apparently the AMD team believes that the kernel should accept this code despite it not meeting their standards because: * Otherwise they'll write angry blog posts about how mean the kernel maintainers are. * They're a primarily Windows shop. * They don't have the resources to do it right. * They don't have the time to do it right. * They're 'trying' to do the right thing. * They believe that AMD is a big enough company to get special treatment. * "But Andrrroid gets special treatment" * There are lots of people with unreleased hardware that desperately need driver support. * They're doing in wrong, but the current kernel maintainers are doing it wrong in a different way so it should be okay. * Graphics drivers are what's preventing the 'year of the Linux desktop'.
- izacus 10y ago
  That's a lot of strawmen you managed to build here :/
  - x0x0 10y ago
    That list really is sourced from Alex' email.
    - scrollaway 10y ago
      It's a really unfair reading of that email. Yes, some of them are true, but that post is no better than turning a random quote into a clickbait headline.
- vacri 10y ago
  You missed the bit where AMD chides kernel maintainer for attacking AMD's corporate culture rather than technical merits, and then goes on to chide maintainer culture in the same paragraph. And it's not even true what AMD says - that to commit to the kernel you need to be a funky part-time hacker or an immense behemoth. There are tons of small hardware shops out there with drivers in the kernel, written by paid developers. True, a graphics card is much more complex than any other appliance, but the characterisation is extremely wrong - the most active part of the kernel is the drivers, and they're not written by "redhat + movie-style hackers", but largely by the companies that make the hardware.
smnc 10y ago
> Is all we care about android? I constantly hear the argument, if we don't do all of this android will do their own thing and then that will be the end. Right now we are all suffering and android barely even using this yet. If Linux will carry on without AMD contributing maybe Linux will carry on ok without bending over backwards for android. Could someone here fill in the details for the uninitiated? Do the kernel devs feel a pressure for the kernel to stay relevant in the Android world?
- cypher543 10y ago
  I don't know the details either, but honestly, I'm amazed that Google hasn't just thrown Linux out and built a microkernel with a Linux-compatible syscall API. That way there's a single binary that only cares about standard ARM things like memory management and scheduling and doesn't require hardware vendors to tweak it for every new SoC. The SoC-specific drivers can be written and updated separately just like apps. Maybe then it would be easier for vendors to keep their shit updated so I don't have to throw out my perfectly good phone just because a company doesn't feel like porting their changes to a new kernel version.
  - indolering 10y ago
    Linus made the right engineering choice when he took the monolithic route in the 90's. However, the technical advantages of that architecture are now moot. Sooner-or-later, Google is going to get tired of Linux's shortcomings and build a replacement OS.
    - prodigal_erik 10y ago
      They seem to have started: https://fuchsia.googlesource.com/fuchsia/ https://fuchsia.googlesource.com/fuchsia/ https://en.wikipedia.org/wiki/Google_Fuchsia https://en.wikipedia.org/wiki/Google_Fuchsia
      - benjamin_mahler 10y ago
        They also have some folks working on Akaros. http://akaros.cs.berkeley.edu http://akaros.cs.berkeley.edu
izacus 10y ago
I think this is a great situation to quote Linus on Linux supporters inside companies (not 100% same, but I think related): (on litigation against companies that contribute) > Anyone in the company that pushed to use Linux is now seen as "wrong" and instantly is pissed off that external people just messed up their employment future. > - Anyone in the company that resisted the use of Linux (possibly in ways that caused the code not to be released over the objection of the previously mentioned people) are vindicated in their opinion of those "hippy"[2] programmers who develop Linux. ... > Now, even if, after many years of work on your part, you do get that code, what is the end result? You have made an enemy for life from the people who brought Linux into the company, you have pissed off the people who didn't like Linux in the first place as they were right and yet you "defeated" them. Both of those groups of people will now work together to never use Linux again as they don't want to go through that hell again, no matter what. (source and context: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html https://lists.linuxfoundation.org/pipermail/ksummit-discuss/... ) ... I think this is the worst part of this SNAFU - Dave has just proven every naysayer in AMD right that Linux is not worth supporting. He cut away feet from the team that has supported and fought for an equivalent opensource driver support on Linux which would be released in lockstep with Windows releases. He has also proven right everyone on nVidia which has talked against opensourcing their drivers and keeping them as a horrendous binary blob. He has also pissed off his greatest ally inside AMD. All with a single "no". Not "We can't accept this, let's talk about how to make us both happy". With that he gave new ammunition to every manager at every large hardware corporation that's fighting against opensourcing their drivers and made every Linux supporting team lead in such corporation less likely to push opensource world forward. It seems we're stuck in shitty Android kernel forks with shitty GPU binary blobs in near future, with only Windows as a proper contender for good 3D performance. EDIT: To be clear, I'm not blaming Dave for refusing the patch for tech cases. I AM blaming him for refusing it so flatly and not actively working more with AMD to get the situation fixed. This is not a minor thing - having stable AMD drivers in kernel would really push Linux desktop forward, make sure Linux is compatible with several Macs among other machines and put pressure on nVidia to opensource theirs. But you don't get there by belittling contributors and cultivating "us vs. them" mentality.
- plorkyeran 10y ago
akkartik 10y ago
On a tangent: what the fuck is up with the giant quotes at the top of these messages? They're technically fulfilling the letter of netiquette by not top-posting, but they serve absolutely no purpose. If you aren't going to take the trouble to pull out short quotes to respond to, please just delete the message altogether. All our clients have excellent support for threading these days, and we can find the message you're responding to without needing it repeated in full every. single. time. (This criticism also applies to the message this was responding to: https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426)
- motoboi 10y ago
  Some clients just fold the quote.
hubert123 10y ago
I am not familiar at all with this stuff but honestly people should be working on a way to isolate external code in the kernel at runtime somehow. I wouldnt want to be in either position, I dont want to maintain somebody else's shitty code or get any kind of bugs for my own code from it but I also wouldnt want to be in AMDs position and adhere or rewrite some code that I'm absolutely fine with as it is. There is a lack of a project vision if people reject code that would otherwise lead to great "commercial" aka user adoption success. The maintainers are understandably reluctant to accept new code, especially if it doesnt even try to adhere to the coding standards. He even acknowledged the political situation but it wasnt even his job to care about that. There needs to be somebody over him who's job it is to make him accept that code or figure out a better solution.
- prodigal_erik 10y ago
  The problem isn't runtime isolation. The problem is that if you merge a Windows driver into the Linux kernel, the Linux hackers won't be able to make effective and safe changes to it as the rest of the kernel evolves, because it's nearly unreadable to them. An unmaintainable mess with lots of users is not a victory unless users are paying you for shitty work.
  - hubert123 10y ago
    Runtime isolation would absolutely solve that problem, it would safely shift the blame to AMD if the thing becomes broken. Without it, the kernel devs now have to maintain more and more code that they probably dont know anything about. I dont see how that can possibly be a good solution. I dont see how anyone can even argue that. Why should a 3rd party graphics driver NOT be a plugin instead of core code? Stupidly obvious to make this an isolated plugin.
    - prodigal_erik 10y ago
      The whole point of putting drivers in the kernel tree is that they get properly maintained as part of kernel development. All the kernel hackers are responsible for keeping all the in-kernel drivers working. If it's at all acceptable for a kernel change to break a driver with no fix, that driver doesn't belong in the kernel tree.
gumby 10y ago
I didn't see where Dave slagged AMD's culture, and I think everyone was very polite and detailed about why this doesn't fit. I understand why AMD wants to have one code base, but the kernel needs to have one consistent code base and style and can't afford to do otherwise. There's nothing stopping AMD distributing the code, it just won't be upstreamed.
- sangnoir 10y ago
  Because rather than believing the AMD kernel devs are misguided about the kernel, he suspects the higher-ups at AMD are not listening to them. See https://news.ycombinator.com/item?id=13143371 https://news.ycombinator.com/item?id=13143371
  - nameless912 10y ago
    That's probably far more accurate and much more fair than assuming they're just shit programmers.
swehner 10y ago
Nice: so many we's in the last paragraph.
fbreduc 10y ago
oh this is good gets popcorn crunch crunch
jinmingjian 10y ago
I also stand on the kernel maintainer's side. Kernel is not your AMD's kitchen-sink:) They are always fighting for any holes. The maintainers become the maintainers because the community think they has the qualified capabilities. The best way is to argue in technical side: for example, why you should have such complexities, how to control the complexities or something like. No technical response makes non-sense and low down your reputation in the community.
vertex-four 10y ago
For the record... AMD are perfectly welcome to publish their patches and try to convince Ubuntu/Red Hat/etc to include them in their own forks of the kernel (no distro uses a completely vanilla kernel, they all have their own patchsets they apply on top of it for various reasons). The only great loss here is that AMD can't force kernel developers to maintain substandard code, and will have to do it themselves.
- AstralStorm 10y ago
  Which they generally fail at due to lack of manpower and pace of changes in the kernel.
ajarmst 10y ago
AMD's response is 25% talking about unrelated Exynos code, 35% sarcastic complaints about Linux culture and 20% explaining why its naive to care about code quality and style. It concludes with a barely veiled threat about how they won't change and that not merging their code is what is keeping Linux off the desktop. I think we're done here.
- geezerjay 10y ago
  > It concludes with a barely veiled threat about how they won't change and that not merging their code is what is keeping Linux off the desktop. It seems to me that they made no threat. They simply endorsed NVidia's product line for anyone interested in running Linux on the desktop.
  - XorNot 10y ago
    Gotta say this is my takeaway. If near latest kernels work with nvidia, I'll buy nvidia in the future (I'm all amd at the moment).
    - tankenmate 10y ago
      And yet AMD releases far more of it's specification for its chipsets than Nvidia does (which releases next to none). This is the reason that the AMD open source drivers are within 10~20% of performance of the closed source drivers on a number of chipsets (not all) whereas on Nvidia chipsets the open source driver is often just to boot a system and get X running enough to install the closed source driver.
      - geezerjay 10y ago
        > And yet AMD releases far more of it's specification for its chipsets than Nvidia does (which releases next to none). That is only relevant if any third-party has any interest in taking up the challenge of developing an alternative driver.
        10y ago
ajarmst 10y ago
Dave's response: https://lists.freedesktop.org/archives/dri-devel/2016-December/126701.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...
drewg123 10y ago
Coming from the FreeBSD perspective, I would freaking LOVE it if some drivers had a HAL (or, really, OSAL). Instead, for the vendors that cannot allocate the resources to properly support FreeBSD, we have a linux kernel compat shim that tries to translate from the linux kernel apis to FreeBSD ones. This is much harder to deal with than a HAL because it makes it even harder than a HAL to reason about the code. One recent example is that I was debugging a rogue DMA issue in a driver that uses the linux kpi shims. I wanted to use the Intel DMAR to try to catch the DMA, but because of the use of linux shims, the driver would not work at all with the DMAR. We had to improve the linux kpi shims to do busdma, rather than just use pmap_kextrect() to convert kernel virtual to physical addresses (and this was a hack, because there is a gigantic imedence mismatch between dma_map_single and busdma). And, as soon as we had the driver working with the DMAR, we caught the rogue DMA. Weeks of my time could have been saved if, instead of writing to Linux, the vendor driver had included a full hal that supported busdma. Instead, they wrote to the linux kpi. And I fully blame the Linux kernel maintainers for this. They're on top of the world and can dictate to hardware vendors to remove their portability shims. Meanwhile, other OS projects get the dregs.
- jaredklewis 10y ago
  I'm sympathetic to BSD, but that seems like a lot of misplaced blame to me. Companies don't write FreeBSD drivers because there's no ROI for the hardware companies. Making the drivers doesn't help them sell more hardware. Likewise, the LK devs made these decisions because their vision of the kernel doesn't involve HALs, not to spite FreeBSD.
  - notalaser 10y ago
    I don't know if HALs in the kernel would have been the smart thing to do here (I'm not familiar enough with the problem to comment; generally, abstracting hardware access behind a HAL is a smart thing, but "generally" is a really bad snare trap). On the other hand, I'd really love to see the Linux team getting the same treatment that Microsoft gets whenever they encourage lack of portability, even where portability would be irrelevant. A whole thread about this, and not once was the word "EEE" uttered. I'm sure business had nothing to do with the Linux team's decision here, I'm just a little pissed at our double standards ("our" as in the open source/free software community of users and developers). AMD's criticism is not without valid points. Getting drivers to work (let alone in upstream) while the hardware is still relevant is difficult and requires a lot of maintenance, hacking and testing due to things like API changes, undocumented/shifting ad-hoc conventions and so on. Driver development on Linux is very much unlike what you expect with a Windows background; the sheer fact that they managed to convince a largely Windows-only shop to let them do it, with an eye to the future, is amazing. I'd have expected to see questions like "why did these guys write the whole fsckin thing, all 100,000 lines of it, and only found out it's not upstreamable now". I've been hearing of AMD trying to get their Linux drivers in good shape for a long time now. "We don't do the thing that is most fundamental to your architecture" looks like the kind of problem that could have surfaced within, I don't know, two emails? Edit: I do think that the LK maintainer was right not to merge this. What bothers me is that everyone's focusing on everything except the examination of the technical issues and what would benefit Linux users.
diebir 10y ago
At this point in time, those who don't support Linux are only hurting themselves.
seesomesense 10y ago
"This is something you need to fix, or it'll stay completely painful forever. It's hard work and takes years, but here at Intel we pulled it off. We can upstream everything from a _very_ early stage (can't tell you how early). And we have full marketing approval for that. If you watch the i915 commit stream you can see how our code is chasing updates from the hw engineers debugging things. Daniel Vetter Software Engineer, Intel Corporation" Intel got their sh*t together, why can't AMD ?
- AstralStorm 10y ago
  Money (developer time) and some deluded idea that drivers, of all things, can be made portable across kernels.
- usernam 10y ago
  Well, whatever Intel has been doing, they're just successful as merging their codebase. It doesn't mean the driver is stable though. The KMS/dri driver itself certainly has _major_ unsolved issues since basically forever. The KMS driver for broadwell graphics was trashing the screen with massive horizontal flicker until kernel 4.8. That's not a long time ago. It's still not solved BTW, just got less frequent. Random pipeline stalls happen on an hourly basis. Tons of graphical glitches and random performance issues with the "glamour" accell path. I've stopped reporting issues at their tracker, as they just get ignored. The performance of the KMS driver is also inferior to their existing xorg driver in a number of very important scenarios (Xrender is particularly affected). Sure, I do have vulkan drivers as first class, but my screen flickers, I get graphical corruption and the driver hangs the entire system with certain shaders. I can see inkscape repainting beneath my eyes like it's '84. Wow. And I'm trying that with 4.9 rc8. I've been using laptops with integrated graphics for almost 10 years. The moment you can get the intel driver to work half-decently, they're already rewriting it. I wish I was kidding. Intel does have the money. They're actually doing worse in my mind.
ChuckMcM 10y ago
Would love to see FreeBSD take their code.
- floatboth 10y ago
  https://github.com/FreeBSDDesktop/freebsd-base-graphics https://github.com/FreeBSDDesktop/freebsd-base-graphics just takes whatever crap is in Linux. Very few people are there to maintain all that, so the focus is on reducing the diff with Linux and improving stability on Intel GPUs. Maintaining an additional patch written against Linux doesn't make sense.
mkj 10y ago
Do these drivers have any relevance to OpenCL etc? It seems that could be a bigger market for AMD on Linux than graphics/gaming.
- floatboth 10y ago
  The GPU driver that's required for both gaming and OpenCL is already in the kernel. The current issue is, if I understand correctly, is related to display management stuff.
Jerry2 10y ago
I don't know about AMD drivers but Nvidia's Linux drivers are so iffy. For one thing, I often notice some flickering of one of the windows that I have on the desktop (it's totally random and it usually involves some window in the background. But the biggest issue is that I can't suspend my PC because once it wakes up, GFX driver just goes nuts and everything starts to stutter and every window's corrupted and the only option is to hit the reset. Drives me nuts :( I'm glad that AMD is still not giving up on Linux!
gbil 10y ago
I think the issue is more or less clarified behind the scenes. Have a look here from AMD's bridgman https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/916781-it-looks-like-amdgpu-dc-dal-will-not-be-accepted-in-the-linux-kernel?p=917174#post917174 https://www.phoronix.com/forums/forum/phoronix/latest-phoron...
- y2kenny 10y ago
  And this is the thread that bridgman points to: https://lists.freedesktop.org/archives/dri-devel/2016-December/126698.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb... Much more constructive interactions, I think.
elcct 10y ago
We should be thankful to AMD for keeping thousands of poor people warm this winter.
jwr 10y ago
This is yet another situation where I (as a user) am being held hostage [1]. The net result of attitudes like these is that I can't have a working multi-monitor desktop Linux setup, because everything is hopelessly broken and requires many hours of tinkering just to kind-of sometimes work. I find it sad. [1] Apple has been excelling at this recently, too, with the forced move to USB-C and dropping of the headphone jack — to "make progress" at my expense, where I am held hostage in the dongle-world as companies "move to new standards".
- grzm 10y ago
  I understand and sympathize with your frustration. A month ago I threw out about 10 gallons of cables (it was a 10 gallon garbage bag) that I had collected over the years. I have a pile of drive enclosures with at least 4 different port connectors on the outside and at least 3 different interfaces connecting the drives to the ports. I have to use two different dongles to connect the 3 monitors I have to my two different machines, one of which I can't upgrade beyond OS X Leopard because it's PowerPC. I take issue with the held hostage hyperbole, though. Yeah, you're inconvenienced by the OS/hardware options you have available. Your freedom of movement is not at stake. Your life is not at risk. I know it's fashionable to take poetic license and raise the stakes for everyday inconveniences, but let's keep things in perspective. Nothing's preventing you from using your old phone, or switching to another platform, or buying a couple of inexpensive dongles (very inexpensive relative to the hardware you've chosen to buy into).
- pas 10y ago
  Hm, some folks have installed Ubuntu, plugged in monitors, and it works for them. KDE usually screws up when I plug a monitor into my notebook, but Xfce doesn't. It's not a kernel issue. KDE has a guy, he's singlehandedly awesome, yet of course a bit strange when it comes to interacting with mortals, who works on "these" things: https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/ https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-... And see, that it's NVIDIA that's currently holding back the year of the multi-monitor Linux desktop, because they're not supporting Wayland, like the others (Intel, AMD, Android).
  - 10y ago
nottorp 10y ago
Well, there's a reason I only ever buy NVidia video cards, even for AMD CPUs. I'm fine with AMD not being interested in Linux support, I'll just vote with my wallet.
- carlosrg 10y ago
  Yes, because NVIDIA has been great contributing kernel code. /irony
dschuetz 10y ago
I admire AMD for even trying to work with Linux on a driver solution for The Kernel. I am very worried about the development, because since Nvidia fucked me over with utterly crappy hardware in the past, now, that AMD started making decent hardware. I use three different kinds of operating systems at the same time, an Linux is on the least position of being stable and useable. There's always something broken in Linux, not working, patched/made worse - it's a mess. I'm not trying to defend Windows or something, it's been a rough for Windows too. MacOS leads the way. But, Linux is existing as long as those two did, and it's a huge pile of patchwork. Maybe it's supposed to be that way. But then I understand why it never had a year of Linux desktop.
deleted 10y ago
[deleted]
dorianm 10y ago
Original email: https://lists.freedesktop.org/archives/dri-devel/2016-December/126422.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb... Proposed driver code: https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7 https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/d... The file with the atomic functions: https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c?h=amd-staging-4.7 https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/d...
megous 10y ago
This actually feels kind of good to me as someone who's trying to get his code into the kernel. Big guys are not getting any special treatment. It feels fair.
carlosrg 10y ago
This (and the replies on this thread from Linux supporters) shows how far away Linux is to be an acceptable alternative to Windows on the desktop. Instead of welcoming such a big hardware manufacturer with open arms and try to reach a compromise (and understanding that a company is not going to devote infinite resources to something that's not really as profitable as Windows, because you know, companies are created to make money, not lose it - they aren't not-for-profit orgs) the kernel maintainers choose to focus on purity and style crap. Well, enjoy your pure code and your 2% desktop marketshare. The next time you recommend Linux to someone, when he finds out his graphics card doesn't work well you can put the blame on the hardware maker as always.
snvzz 10y ago
It's very simple, Linux won't bend the rules for anyone, and that includes AMD. The sooner they realize that, the faster they can actually work together with Linux kernel maintainers.
Waterluvian 10y ago
Didn't the AMD guy respond months ago that he expects they'll reduce it to like 30k loc? What happened to that? Not that this is the crux of the problem, just curious.
- digi_owl 10y ago
  It is not about compromise, it is about the long term maintainability of the code.
rasz_pl 10y ago
>We don't happen to have the resources to pay someone else to do that for us. Typical AMD bullshit. They do have resources for developing garbage like 'Gaming Evolved App' just to abandon it 6 months later tho.
- floatboth 10y ago
  Gaming Evolved was not developed by AMD, it's a branded version of raptr.com.
crb002 10y ago
Seems kind of silly that the Kernel should be nanny to all drivers. Drivers to me should host their own repo, and provide proper integration tests before they are blessed. Some sort of --externDrivers="foo2016" flag you pass to the build. No drama on how horrid their code is because the Kernel shouldn't care.
- nameless912 10y ago
  It's not that easy though. The kernel doesn't have a stable internal API, which means that it's nearly impossible to maintain an out-of-tree driver. The kernel operates on a classic google-style monorepo model (well, maybe google-style isn't a good term, after all, they certainly didn't invent it...) because when someone changes a kernel API they are obligated to ensure the change is propagated to all related code. You get maintenance basically for free in the kernel, but only if you build an in-tree driver. FWIW, a proprietary "binary blob" driver has already been available for a while that was built out-of-tree, but it constantly has to be updated for the latest kernel and doesn't release a version for every single kernel, so it's very difficult to use it unless you either 1) specifically use the exact version the driver requires (which is ridiculous-you should be able to dictate which kernel version you want) or 2) use a well-known and well-supported repo (which limits your choice as well). Ultimately, the best way to get driver support into the kernel is to go through the standard kernel channels. And also FWIW, the kernel does care about how drivers are written-even if the driver is out-of-tree, its possible shittiness reflects back (totally unfairly, I know) on the kernel. By having a gatekeeper for device drivers, they can ensure that the kernel is as stable as possible for as many users as possible, and that's a laudable end goal. It's also orthogonal to wide hardware support, as all that was required in this situation was for AMD to adhere to the guidelines properly, but they didn't do so, so they have no right to be upset that their code got rejected.
winteriscoming 10y ago
Alex, from AMD, has now posted a response saying he over-reacted https://lists.freedesktop.org/archives/dri-devel/2016-December/126757.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...
- caf 10y ago
  Everyone should take a deep breath and read this - it wasn't even a merge request originally, just an RFC.
Nano2rad 10y ago
AMD has been good to Linux and Linux community always supported AMD. Its principle from beginning of creating x86 clone has been something similar to what Linux is to other OSes. There will always be some up and down but has not gone too much away from Linux.
qplex 10y ago
I absolutely love that the maintainers can stick up to any company that tries to add shit code to the kernel. There is no excuse for AMD. The response reads like a total whine to me. It's not the kernel maintainers fault that your company does not give you proper resources or approach Linux in a correct way. If you had proper opensource drivers I'm sure the "in" crowd hackers you speak of would take it from there... I've personally had horrible experiences with AMD drivers on both Windows and Linux. I had a GPU that worked wellfor my purposes, even ran games well enough for me, but you dropped driver support for it, so I was left with no option but to buy another card...
anonbanker 10y ago
This was all a big ado over nothing. John Bridgman and two other AMD devs have backed away from Alex's initial flame-y post, and are trying to de-silo their codebase, break up the commit into smaller patches, and move forward (despite their marketing dept. getting in the way of fully-upstreaming beta cards the way Intel does).

350 points by belltaco 10y ago

Discussion of the rejection here. https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426

imaginenore 10y ago

What I don't get is how one kernel maintainer can make such a massive decision that affects all of Linux. That's some near-totalitarian level of power. After reading the arguments, I'm kind of on AMD's side. I get what Dave wants, but it seems extremely idealistic.

gigatexal 10y ago
That's how the kernel development works. As far as I can tell, if you get maintainer status from Linus you can do as you please for the understanding is that you're acting as he would.
- chx 10y ago
  As Dave said: > Given the choice between maintaining Linus' trust that I won't merge 100,000 lines of abstracted HAL code and merging 100,000 lines of abstracted HAL code I'll give you one guess where my loyalties lie. He is acting in a way he thinks would keep Linus' trust. Also, usually the maintainers have far superior technical knowledge of their areas to Linus. I mean, Linus is just one guy and each maintainer have their own specialty.
wyldfire 10y ago
Linus delegates authority to people he trusts. And in this case, Dave is likely representing well what Linus would do. > near-totalitarian level of power. I don't think you meant to use that word. Linus and the kernel contributors together own the copyrights on the kernel. It's not totalitarian for them to dictate its future. It's their creative work. It's downright egalitarian that they let you use the kernel however you like, provided that you give the source in turn to whoever you hand it to.
- ocdtrekkie 10y ago
  I suppose the intended notion, would be given the number of Linux distributions and use cases out there, the number of companies involved, the number of products built on top of the Linux kernel... it's amazing that one guy with little financial interest in the results or effects can make that call for everyone. I'm not sure if that's a good thing or a bad thing, to be honest, it's just... particularly interesting about the way Linux works.
  - wmf 10y ago
    It's amazing that one guy with little financial interest in the results or effects can make that call for everyone. Impartial expert judges are usually considered a good thing. Note that Dave Airlie is not acting on a whim here; the Linux development community has discussed HALs for probably 20 years and has come to the conclusion that they are a net negative. For better or worse, the Linux development process does not care about democracy or market share or vendor relations. It's a somewhat unusual way to build software, but the result pretty much speaks for itself.
    - pjmlp 10y ago
      Yep, each vendor that doesn't want to deal with it, just forks it, never contributing anything back.
  - Analemma_ 10y ago
    If it was a big secret that this was how Linux worked and it took the companies by surprise, I could see how this could be a bad thing, but it never has been: Linus has always been very upfront that he is Benevolent Dictator for Life and always has the last word. Don't get onboard if you don't like that system.
    - wolfgke 10y ago
      Then all the Linux fans that complained to AMD that they don't deliver open source drivers should from now on better shitstorm the kernel maintainers, since AMD delivered.
forgottenpass 10y ago
That's some near-totalitarian level of power. AMD is perfectly within their rights and abilities to ship an out-of-tree driver. As I understand it, DKMS exists to make that use case easier for end users. The popular consumer-facing distros would probably make it easy as dirt to install too. The difference between that and upstreaming into the kernel is primarily shifting some of the the maintenance burden onto the kernel developers. That comes with the condition of adding stakeholders to the driver design, not just using them as a code dumping ground. "Totalitarian" seems a bit over the top.
fapjacks 10y ago
The Good King is how Linux has come to run the world's servers. I am perfectly fine missing out on some incidental functionality here or there in order to keep this power structure which had protected the Linux kernel thus far. It seems to work extremely well.
- this-dang-guy 10y ago
  I'd prefer to see NVidia style drivers, personally. I don't give a rat's beans if optimized video card, nic, etc drivers are open. I just want a system that will work properly without them. Not 60FPS on Ultra settings in <game> work, I mean boot and function as a normal user's desktop.
  - fapjacks 10y ago
    Yeah, I don't care about nvidia drivers, either. AMD doesn't need this in the kernel anymore than nvidia does (and they don't). Kernel modules work just fine for drivers. I don't want some convoluted shit crammed into mainline because <company> chooses to ignore feedback about their code. I am perfectly fine with this one guy shooting down AMD's pretentious attitude here. If it weren't for those kernel devs, good luck getting a Linux system to "boot and function as a normal user's desktop" because of all the crap that would be in there. Like systemd, just piles of crap in a confused, kitchen-sink orgy.
    - digi_owl 10y ago
      I have come to fear that we will eventually need GPU drivers in the kernel directly, thanks to more and more of the graphics code out there assuming DRM/DRI etc.
- pjmlp 10y ago
  Being a free beer clone of expensive UNIX workstation OSes helped. Of course companies had an agenda to improve it to the point they wouldn't need to keep paying Sun, SGI, HP, IBM, Compaq, Unisys,...
matt4077 10y ago
Why don't you try to get some code merged into the Windows kernel and tell us how that goes? > After reading the arguments, I'm kind of on AMD's side. And that's why stuff like this doesn't get put to a vote.
k_sze 10y ago
There's a reason Linus is called the BDFL of Linux.

deleted 10y ago

[deleted]

deleted 10y ago
[deleted]

lettergram 10y ago

I do feel Dave went a bit over the top in his response. If he keeps it technical it's easier to fix, people want to see their stuff merged. When he makes it personal (which he kind of did) it turns people off. That being said, I do think Dave probably made the right call, but I also think he may need to compromise on this one. That being said, AMD should strategicly try and get their GPUs supported. Couple that, with merging an OpenCL version of Tensorflow or something and AMD would probably be more valuable than Nvidia. I think both groups could benefit and should probably sit and try to work it out in person.

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.

aqtrans 10y ago

Did I miss the mud-slinging and corporate culture bashing from the original rejection? I can get the AMD dev being a bit sour by the whole situation if they personally spent time working on this rejected patch, but damn.

jff 10y ago
There were certainly implications that the AMD coders were making technically compromised decisions: > The reason the toplevel maintainer (me) doesn't work for Intel or AMD or any vendors, is that I can say NO when your maintainers can't or won't say it. And telling them to sit in a corner and really THINK about what you've done, young man: > I'd like some serious introspection on your team's part on how you got into this situation and how even if I was feeling like merging this (which I'm not) how you'd actually deal with being part of the Linux kernel and not hiding in nicely framed orgchart silo behind a HAL. I honestly don't think the code is Linux worthy code All pretty mild, really, but I'm not the one who got the email telling me my months of work was not Linux-quality and would not be merged. (I am giggling at the idea of "Linux quality" being held up as an ideal)
- aqtrans 10y ago
  Ahh, thanks for pointing those out. I completely skipped over those portions...I was expecting some Linus-level chewing out that I'd missed given the tone of the response, haha. Certainly pretty mild considering the source, though I understand why the second quote would stir things up a bit, especially making it into an "Us vs Them" situation.
- jlgaddis 10y ago
  > ... but I'm not the one who got the email telling me my months of work ... would not be merged. See, the thing is that they were told previously -- back in February? March? -- that this wasn't gonna happen. Instead of trying to work out a better way forward, AMD effectively ignored that, went back to work, and just now came back and said "here's 90k LOC, please merge". Dave replied -- rightfully, in my opinion -- "no".
Analemma_ 10y ago

zznneezznnee 10y ago

The kernel maintainers don't necessarily want your code. Additional shit in mainline increases the maintenance burden. If the code isn't putting upstream maintainability above all else in its implementation, then it's generally not getting merged unless someone wasn't paying attention or some other forces compelled an exception. Alex's first reply reads like he's willfully ignoring that aspect of the NACK. It's not a coding style issue, it's a HAL issue. Upstream isn't interested in maintaining a HAL and living with the impedance mismatch from day zero. The driver can stay out of tree. This is just about code getting into mainline. I'm personally very happy to see the gpu subsystem maintainers paying attention and having the maturity to know a fool's errand when they see it.

izacus 10y ago
Then again, we're not talking about some wierd network card driver here. We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer. A driver which has caused a large amount of desktop users to return to Windows due to its historical issues. While I get the reasoning for rejection, the typical OSS rejection attitude is also problematic. I kinda don't see a dialog happening here on how to resolve problems both sides have, just a repeat of posturing which has historically brought us awesome things like binary blob drivers that only work with single version of kernels (yes, I'm looking at you every ARM GPU ever!).
- x0x0 10y ago
  AMD was told in February that they would have to obey kernel code standards / no HAL. In late October they dropped a steaming pile of 100k lines of code with a HAL and are whining it isn't getting merged. The solution is AMD keeps code out of mainline or obeys kernel code standards.
  - ChoGGi 10y ago
    My favorite part is back in February they made mention of shrinking it to 1/3 of what it was (93KLOC). Now we're up to 100K+ https://lists.freedesktop.org/archives/dri-devel/2016-February/100715.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

Spivak 10y ago

I really don't understand why AMD cares so much about getting their driver upstreamed. If their code doesn't meet the kernel standards and they don't want to fix it then just package it up as kernel module and ship it like Nvidia does. Distributions will package it using DKMS and other than some occasional troubleshooting they wont even notice. It's really no difference than Windows in that respect. His arguments seem really weak. Apparently the AMD team believes that the kernel should accept this code despite it not meeting their standards because: * Otherwise they'll write angry blog posts about how mean the kernel maintainers are. * They're a primarily Windows shop. * They don't have the resources to do it right. * They don't have the time to do it right. * They're 'trying' to do the right thing. * They believe that AMD is a big enough company to get special treatment. * "But Andrrroid gets special treatment" * There are lots of people with unreleased hardware that desperately need driver support. * They're doing in wrong, but the current kernel maintainers are doing it wrong in a different way so it should be okay. * Graphics drivers are what's preventing the 'year of the Linux desktop'.

izacus 10y ago
That's a lot of strawmen you managed to build here :/
- x0x0 10y ago
  That list really is sourced from Alex' email.
  - scrollaway 10y ago
    It's a really unfair reading of that email. Yes, some of them are true, but that post is no better than turning a random quote into a clickbait headline.
vacri 10y ago
You missed the bit where AMD chides kernel maintainer for attacking AMD's corporate culture rather than technical merits, and then goes on to chide maintainer culture in the same paragraph. And it's not even true what AMD says - that to commit to the kernel you need to be a funky part-time hacker or an immense behemoth. There are tons of small hardware shops out there with drivers in the kernel, written by paid developers. True, a graphics card is much more complex than any other appliance, but the characterisation is extremely wrong - the most active part of the kernel is the drivers, and they're not written by "redhat + movie-style hackers", but largely by the companies that make the hardware.

smnc 10y ago

> Is all we care about android? I constantly hear the argument, if we don't do all of this android will do their own thing and then that will be the end. Right now we are all suffering and android barely even using this yet. If Linux will carry on without AMD contributing maybe Linux will carry on ok without bending over backwards for android. Could someone here fill in the details for the uninitiated? Do the kernel devs feel a pressure for the kernel to stay relevant in the Android world?

cypher543 10y ago
I don't know the details either, but honestly, I'm amazed that Google hasn't just thrown Linux out and built a microkernel with a Linux-compatible syscall API. That way there's a single binary that only cares about standard ARM things like memory management and scheduling and doesn't require hardware vendors to tweak it for every new SoC. The SoC-specific drivers can be written and updated separately just like apps. Maybe then it would be easier for vendors to keep their shit updated so I don't have to throw out my perfectly good phone just because a company doesn't feel like porting their changes to a new kernel version.
- indolering 10y ago
  Linus made the right engineering choice when he took the monolithic route in the 90's. However, the technical advantages of that architecture are now moot. Sooner-or-later, Google is going to get tired of Linux's shortcomings and build a replacement OS.
  - prodigal_erik 10y ago
    They seem to have started: https://fuchsia.googlesource.com/fuchsia/ https://fuchsia.googlesource.com/fuchsia/ https://en.wikipedia.org/wiki/Google_Fuchsia https://en.wikipedia.org/wiki/Google_Fuchsia
    - benjamin_mahler 10y ago
      They also have some folks working on Akaros. http://akaros.cs.berkeley.edu http://akaros.cs.berkeley.edu

izacus 10y ago

I think this is a great situation to quote Linus on Linux supporters inside companies (not 100% same, but I think related): (on litigation against companies that contribute) > Anyone in the company that pushed to use Linux is now seen as "wrong" and instantly is pissed off that external people just messed up their employment future. > - Anyone in the company that resisted the use of Linux (possibly in ways that caused the code not to be released over the objection of the previously mentioned people) are vindicated in their opinion of those "hippy"[2] programmers who develop Linux. ... > Now, even if, after many years of work on your part, you do get that code, what is the end result? You have made an enemy for life from the people who brought Linux into the company, you have pissed off the people who didn't like Linux in the first place as they were right and yet you "defeated" them. Both of those groups of people will now work together to never use Linux again as they don't want to go through that hell again, no matter what. (source and context: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003580.html https://lists.linuxfoundation.org/pipermail/ksummit-discuss/... ) ... I think this is the worst part of this SNAFU - Dave has just proven every naysayer in AMD right that Linux is not worth supporting. He cut away feet from the team that has supported and fought for an equivalent opensource driver support on Linux which would be released in lockstep with Windows releases. He has also proven right everyone on nVidia which has talked against opensourcing their drivers and keeping them as a horrendous binary blob. He has also pissed off his greatest ally inside AMD. All with a single "no". Not "We can't accept this, let's talk about how to make us both happy". With that he gave new ammunition to every manager at every large hardware corporation that's fighting against opensourcing their drivers and made every Linux supporting team lead in such corporation less likely to push opensource world forward. It seems we're stuck in shitty Android kernel forks with shitty GPU binary blobs in near future, with only Windows as a proper contender for good 3D performance. EDIT: To be clear, I'm not blaming Dave for refusing the patch for tech cases. I AM blaming him for refusing it so flatly and not actively working more with AMD to get the situation fixed. This is not a minor thing - having stable AMD drivers in kernel would really push Linux desktop forward, make sure Linux is compatible with several Macs among other machines and put pressure on nVidia to opensource theirs. But you don't get there by belittling contributors and cultivating "us vs. them" mentality.

plorkyeran 10y ago

akkartik 10y ago

On a tangent: what the fuck is up with the giant quotes at the top of these messages? They're technically fulfilling the letter of netiquette by not top-posting, but they serve absolutely no purpose. If you aren't going to take the trouble to pull out short quotes to respond to, please just delete the message altogether. All our clients have excellent support for threading these days, and we can find the message you're responding to without needing it repeated in full every. single. time. (This criticism also applies to the message this was responding to: https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426)

motoboi 10y ago
Some clients just fold the quote.

hubert123 10y ago

I am not familiar at all with this stuff but honestly people should be working on a way to isolate external code in the kernel at runtime somehow. I wouldnt want to be in either position, I dont want to maintain somebody else's shitty code or get any kind of bugs for my own code from it but I also wouldnt want to be in AMDs position and adhere or rewrite some code that I'm absolutely fine with as it is. There is a lack of a project vision if people reject code that would otherwise lead to great "commercial" aka user adoption success. The maintainers are understandably reluctant to accept new code, especially if it doesnt even try to adhere to the coding standards. He even acknowledged the political situation but it wasnt even his job to care about that. There needs to be somebody over him who's job it is to make him accept that code or figure out a better solution.

prodigal_erik 10y ago
The problem isn't runtime isolation. The problem is that if you merge a Windows driver into the Linux kernel, the Linux hackers won't be able to make effective and safe changes to it as the rest of the kernel evolves, because it's nearly unreadable to them. An unmaintainable mess with lots of users is not a victory unless users are paying you for shitty work.
- hubert123 10y ago
  Runtime isolation would absolutely solve that problem, it would safely shift the blame to AMD if the thing becomes broken. Without it, the kernel devs now have to maintain more and more code that they probably dont know anything about. I dont see how that can possibly be a good solution. I dont see how anyone can even argue that. Why should a 3rd party graphics driver NOT be a plugin instead of core code? Stupidly obvious to make this an isolated plugin.
  - prodigal_erik 10y ago
    The whole point of putting drivers in the kernel tree is that they get properly maintained as part of kernel development. All the kernel hackers are responsible for keeping all the in-kernel drivers working. If it's at all acceptable for a kernel change to break a driver with no fix, that driver doesn't belong in the kernel tree.

gumby 10y ago

I didn't see where Dave slagged AMD's culture, and I think everyone was very polite and detailed about why this doesn't fit. I understand why AMD wants to have one code base, but the kernel needs to have one consistent code base and style and can't afford to do otherwise. There's nothing stopping AMD distributing the code, it just won't be upstreamed.

sangnoir 10y ago
Because rather than believing the AMD kernel devs are misguided about the kernel, he suspects the higher-ups at AMD are not listening to them. See https://news.ycombinator.com/item?id=13143371 https://news.ycombinator.com/item?id=13143371
- nameless912 10y ago
  That's probably far more accurate and much more fair than assuming they're just shit programmers.

swehner 10y ago

Nice: so many we's in the last paragraph.

fbreduc 10y ago

oh this is good gets popcorn crunch crunch

jinmingjian 10y ago

I also stand on the kernel maintainer's side. Kernel is not your AMD's kitchen-sink:) They are always fighting for any holes. The maintainers become the maintainers because the community think they has the qualified capabilities. The best way is to argue in technical side: for example, why you should have such complexities, how to control the complexities or something like. No technical response makes non-sense and low down your reputation in the community.

vertex-four 10y ago

For the record... AMD are perfectly welcome to publish their patches and try to convince Ubuntu/Red Hat/etc to include them in their own forks of the kernel (no distro uses a completely vanilla kernel, they all have their own patchsets they apply on top of it for various reasons). The only great loss here is that AMD can't force kernel developers to maintain substandard code, and will have to do it themselves.

AstralStorm 10y ago
Which they generally fail at due to lack of manpower and pace of changes in the kernel.

ajarmst 10y ago

AMD's response is 25% talking about unrelated Exynos code, 35% sarcastic complaints about Linux culture and 20% explaining why its naive to care about code quality and style. It concludes with a barely veiled threat about how they won't change and that not merging their code is what is keeping Linux off the desktop. I think we're done here.

geezerjay 10y ago
> It concludes with a barely veiled threat about how they won't change and that not merging their code is what is keeping Linux off the desktop. It seems to me that they made no threat. They simply endorsed NVidia's product line for anyone interested in running Linux on the desktop.
- XorNot 10y ago
  Gotta say this is my takeaway. If near latest kernels work with nvidia, I'll buy nvidia in the future (I'm all amd at the moment).
  - tankenmate 10y ago
    And yet AMD releases far more of it's specification for its chipsets than Nvidia does (which releases next to none). This is the reason that the AMD open source drivers are within 10~20% of performance of the closed source drivers on a number of chipsets (not all) whereas on Nvidia chipsets the open source driver is often just to boot a system and get X running enough to install the closed source driver.
    - geezerjay 10y ago
      > And yet AMD releases far more of it's specification for its chipsets than Nvidia does (which releases next to none). That is only relevant if any third-party has any interest in taking up the challenge of developing an alternative driver.
      - 10y ago

ajarmst 10y ago

Dave's response: https://lists.freedesktop.org/archives/dri-devel/2016-December/126701.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...

drewg123 10y ago

Coming from the FreeBSD perspective, I would freaking LOVE it if some drivers had a HAL (or, really, OSAL). Instead, for the vendors that cannot allocate the resources to properly support FreeBSD, we have a linux kernel compat shim that tries to translate from the linux kernel apis to FreeBSD ones. This is much harder to deal with than a HAL because it makes it even harder than a HAL to reason about the code. One recent example is that I was debugging a rogue DMA issue in a driver that uses the linux kpi shims. I wanted to use the Intel DMAR to try to catch the DMA, but because of the use of linux shims, the driver would not work at all with the DMAR. We had to improve the linux kpi shims to do busdma, rather than just use pmap_kextrect() to convert kernel virtual to physical addresses (and this was a hack, because there is a gigantic imedence mismatch between dma_map_single and busdma). And, as soon as we had the driver working with the DMAR, we caught the rogue DMA. Weeks of my time could have been saved if, instead of writing to Linux, the vendor driver had included a full hal that supported busdma. Instead, they wrote to the linux kpi. And I fully blame the Linux kernel maintainers for this. They're on top of the world and can dictate to hardware vendors to remove their portability shims. Meanwhile, other OS projects get the dregs.

jaredklewis 10y ago
I'm sympathetic to BSD, but that seems like a lot of misplaced blame to me. Companies don't write FreeBSD drivers because there's no ROI for the hardware companies. Making the drivers doesn't help them sell more hardware. Likewise, the LK devs made these decisions because their vision of the kernel doesn't involve HALs, not to spite FreeBSD.
- notalaser 10y ago
  I don't know if HALs in the kernel would have been the smart thing to do here (I'm not familiar enough with the problem to comment; generally, abstracting hardware access behind a HAL is a smart thing, but "generally" is a really bad snare trap). On the other hand, I'd really love to see the Linux team getting the same treatment that Microsoft gets whenever they encourage lack of portability, even where portability would be irrelevant. A whole thread about this, and not once was the word "EEE" uttered. I'm sure business had nothing to do with the Linux team's decision here, I'm just a little pissed at our double standards ("our" as in the open source/free software community of users and developers). AMD's criticism is not without valid points. Getting drivers to work (let alone in upstream) while the hardware is still relevant is difficult and requires a lot of maintenance, hacking and testing due to things like API changes, undocumented/shifting ad-hoc conventions and so on. Driver development on Linux is very much unlike what you expect with a Windows background; the sheer fact that they managed to convince a largely Windows-only shop to let them do it, with an eye to the future, is amazing. I'd have expected to see questions like "why did these guys write the whole fsckin thing, all 100,000 lines of it, and only found out it's not upstreamable now". I've been hearing of AMD trying to get their Linux drivers in good shape for a long time now. "We don't do the thing that is most fundamental to your architecture" looks like the kind of problem that could have surfaced within, I don't know, two emails? Edit: I do think that the LK maintainer was right not to merge this. What bothers me is that everyone's focusing on everything except the examination of the technical issues and what would benefit Linux users.

diebir 10y ago

At this point in time, those who don't support Linux are only hurting themselves.

seesomesense 10y ago

"This is something you need to fix, or it'll stay completely painful forever. It's hard work and takes years, but here at Intel we pulled it off. We can upstream everything from a _very_ early stage (can't tell you how early). And we have full marketing approval for that. If you watch the i915 commit stream you can see how our code is chasing updates from the hw engineers debugging things. Daniel Vetter Software Engineer, Intel Corporation" Intel got their sh*t together, why can't AMD ?

AstralStorm 10y ago
Money (developer time) and some deluded idea that drivers, of all things, can be made portable across kernels.
usernam 10y ago
Well, whatever Intel has been doing, they're just successful as merging their codebase. It doesn't mean the driver is stable though. The KMS/dri driver itself certainly has _major_ unsolved issues since basically forever. The KMS driver for broadwell graphics was trashing the screen with massive horizontal flicker until kernel 4.8. That's not a long time ago. It's still not solved BTW, just got less frequent. Random pipeline stalls happen on an hourly basis. Tons of graphical glitches and random performance issues with the "glamour" accell path. I've stopped reporting issues at their tracker, as they just get ignored. The performance of the KMS driver is also inferior to their existing xorg driver in a number of very important scenarios (Xrender is particularly affected). Sure, I do have vulkan drivers as first class, but my screen flickers, I get graphical corruption and the driver hangs the entire system with certain shaders. I can see inkscape repainting beneath my eyes like it's '84. Wow. And I'm trying that with 4.9 rc8. I've been using laptops with integrated graphics for almost 10 years. The moment you can get the intel driver to work half-decently, they're already rewriting it. I wish I was kidding. Intel does have the money. They're actually doing worse in my mind.

ChuckMcM 10y ago

Would love to see FreeBSD take their code.

floatboth 10y ago
https://github.com/FreeBSDDesktop/freebsd-base-graphics https://github.com/FreeBSDDesktop/freebsd-base-graphics just takes whatever crap is in Linux. Very few people are there to maintain all that, so the focus is on reducing the diff with Linux and improving stability on Intel GPUs. Maintaining an additional patch written against Linux doesn't make sense.

mkj 10y ago

Do these drivers have any relevance to OpenCL etc? It seems that could be a bigger market for AMD on Linux than graphics/gaming.

floatboth 10y ago
The GPU driver that's required for both gaming and OpenCL is already in the kernel. The current issue is, if I understand correctly, is related to display management stuff.

Jerry2 10y ago

I don't know about AMD drivers but Nvidia's Linux drivers are so iffy. For one thing, I often notice some flickering of one of the windows that I have on the desktop (it's totally random and it usually involves some window in the background. But the biggest issue is that I can't suspend my PC because once it wakes up, GFX driver just goes nuts and everything starts to stutter and every window's corrupted and the only option is to hit the reset. Drives me nuts :( I'm glad that AMD is still not giving up on Linux!

gbil 10y ago

I think the issue is more or less clarified behind the scenes. Have a look here from AMD's bridgman https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/916781-it-looks-like-amdgpu-dc-dal-will-not-be-accepted-in-the-linux-kernel?p=917174#post917174 https://www.phoronix.com/forums/forum/phoronix/latest-phoron...

y2kenny 10y ago
And this is the thread that bridgman points to: https://lists.freedesktop.org/archives/dri-devel/2016-December/126698.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb... Much more constructive interactions, I think.

elcct 10y ago

We should be thankful to AMD for keeping thousands of poor people warm this winter.

jwr 10y ago

This is yet another situation where I (as a user) am being held hostage [1]. The net result of attitudes like these is that I can't have a working multi-monitor desktop Linux setup, because everything is hopelessly broken and requires many hours of tinkering just to kind-of sometimes work. I find it sad. [1] Apple has been excelling at this recently, too, with the forced move to USB-C and dropping of the headphone jack — to "make progress" at my expense, where I am held hostage in the dongle-world as companies "move to new standards".

grzm 10y ago
I understand and sympathize with your frustration. A month ago I threw out about 10 gallons of cables (it was a 10 gallon garbage bag) that I had collected over the years. I have a pile of drive enclosures with at least 4 different port connectors on the outside and at least 3 different interfaces connecting the drives to the ports. I have to use two different dongles to connect the 3 monitors I have to my two different machines, one of which I can't upgrade beyond OS X Leopard because it's PowerPC. I take issue with the held hostage hyperbole, though. Yeah, you're inconvenienced by the OS/hardware options you have available. Your freedom of movement is not at stake. Your life is not at risk. I know it's fashionable to take poetic license and raise the stakes for everyday inconveniences, but let's keep things in perspective. Nothing's preventing you from using your old phone, or switching to another platform, or buying a couple of inexpensive dongles (very inexpensive relative to the hardware you've chosen to buy into).
pas 10y ago
Hm, some folks have installed Ubuntu, plugged in monitors, and it works for them. KDE usually screws up when I plug a monitor into my notebook, but Xfce doesn't. It's not a kernel issue. KDE has a guy, he's singlehandedly awesome, yet of course a bit strange when it comes to interacting with mortals, who works on "these" things: https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-not/ https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-... And see, that it's NVIDIA that's currently holding back the year of the multi-monitor Linux desktop, because they're not supporting Wayland, like the others (Intel, AMD, Android).
- 10y ago

nottorp 10y ago

Well, there's a reason I only ever buy NVidia video cards, even for AMD CPUs. I'm fine with AMD not being interested in Linux support, I'll just vote with my wallet.

carlosrg 10y ago
Yes, because NVIDIA has been great contributing kernel code. /irony

dschuetz 10y ago

I admire AMD for even trying to work with Linux on a driver solution for The Kernel. I am very worried about the development, because since Nvidia fucked me over with utterly crappy hardware in the past, now, that AMD started making decent hardware. I use three different kinds of operating systems at the same time, an Linux is on the least position of being stable and useable. There's always something broken in Linux, not working, patched/made worse - it's a mess. I'm not trying to defend Windows or something, it's been a rough for Windows too. MacOS leads the way. But, Linux is existing as long as those two did, and it's a huge pile of patchwork. Maybe it's supposed to be that way. But then I understand why it never had a year of Linux desktop.

deleted 10y ago

[deleted]

dorianm 10y ago

Original email: https://lists.freedesktop.org/archives/dri-devel/2016-December/126422.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb... Proposed driver code: https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7 https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/d... The file with the atomic functions: https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c?h=amd-staging-4.7 https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/d...

megous 10y ago

This actually feels kind of good to me as someone who's trying to get his code into the kernel. Big guys are not getting any special treatment. It feels fair.

carlosrg 10y ago

This (and the replies on this thread from Linux supporters) shows how far away Linux is to be an acceptable alternative to Windows on the desktop. Instead of welcoming such a big hardware manufacturer with open arms and try to reach a compromise (and understanding that a company is not going to devote infinite resources to something that's not really as profitable as Windows, because you know, companies are created to make money, not lose it - they aren't not-for-profit orgs) the kernel maintainers choose to focus on purity and style crap. Well, enjoy your pure code and your 2% desktop marketshare. The next time you recommend Linux to someone, when he finds out his graphics card doesn't work well you can put the blame on the hardware maker as always.

snvzz 10y ago

It's very simple, Linux won't bend the rules for anyone, and that includes AMD. The sooner they realize that, the faster they can actually work together with Linux kernel maintainers.

Waterluvian 10y ago

Didn't the AMD guy respond months ago that he expects they'll reduce it to like 30k loc? What happened to that? Not that this is the crux of the problem, just curious.

digi_owl 10y ago
It is not about compromise, it is about the long term maintainability of the code.

rasz_pl 10y ago

>We don't happen to have the resources to pay someone else to do that for us. Typical AMD bullshit. They do have resources for developing garbage like 'Gaming Evolved App' just to abandon it 6 months later tho.

floatboth 10y ago
Gaming Evolved was not developed by AMD, it's a branded version of raptr.com.

crb002 10y ago

Seems kind of silly that the Kernel should be nanny to all drivers. Drivers to me should host their own repo, and provide proper integration tests before they are blessed. Some sort of --externDrivers="foo2016" flag you pass to the build. No drama on how horrid their code is because the Kernel shouldn't care.

nameless912 10y ago
It's not that easy though. The kernel doesn't have a stable internal API, which means that it's nearly impossible to maintain an out-of-tree driver. The kernel operates on a classic google-style monorepo model (well, maybe google-style isn't a good term, after all, they certainly didn't invent it...) because when someone changes a kernel API they are obligated to ensure the change is propagated to all related code. You get maintenance basically for free in the kernel, but only if you build an in-tree driver. FWIW, a proprietary "binary blob" driver has already been available for a while that was built out-of-tree, but it constantly has to be updated for the latest kernel and doesn't release a version for every single kernel, so it's very difficult to use it unless you either 1) specifically use the exact version the driver requires (which is ridiculous-you should be able to dictate which kernel version you want) or 2) use a well-known and well-supported repo (which limits your choice as well). Ultimately, the best way to get driver support into the kernel is to go through the standard kernel channels. And also FWIW, the kernel does care about how drivers are written-even if the driver is out-of-tree, its possible shittiness reflects back (totally unfairly, I know) on the kernel. By having a gatekeeper for device drivers, they can ensure that the kernel is as stable as possible for as many users as possible, and that's a laudable end goal. It's also orthogonal to wide hardware support, as all that was required in this situation was for AMD to adhere to the guidelines properly, but they didn't do so, so they have no right to be upset that their code got rejected.

winteriscoming 10y ago

Alex, from AMD, has now posted a response saying he over-reacted https://lists.freedesktop.org/archives/dri-devel/2016-December/126757.html https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...

caf 10y ago
Everyone should take a deep breath and read this - it wasn't even a merge request originally, just an RFC.

Nano2rad 10y ago

AMD has been good to Linux and Linux community always supported AMD. Its principle from beginning of creating x86 clone has been something similar to what Linux is to other OSes. There will always be some up and down but has not gone too much away from Linux.

qplex 10y ago

I absolutely love that the maintainers can stick up to any company that tries to add shit code to the kernel. There is no excuse for AMD. The response reads like a total whine to me. It's not the kernel maintainers fault that your company does not give you proper resources or approach Linux in a correct way. If you had proper opensource drivers I'm sure the "in" crowd hackers you speak of would take it from there... I've personally had horrible experiences with AMD drivers on both Windows and Linux. I had a GPU that worked wellfor my purposes, even ran games well enough for me, but you dropped driver support for it, so I was left with no option but to buy another card...

anonbanker 10y ago

This was all a big ado over nothing. John Bridgman and two other AMD devs have backed away from Alex's initial flame-y post, and are trying to de-silo their codebase, break up the commit into smaller patches, and move forward (despite their marketing dept. getting in the way of fully-upstreaming beta cards the way Intel does).