
AMD responds to Linux kernel maintainer's rejection of AMDGPU patch - belltaco
https://lists.freedesktop.org/archives/dri-devel/2016-December/126684.html
======
Spivak
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'.

~~~
lvs
The claim that AMD, a company with gross profit in the $1 - 2 billion range,
does not have the resources to support a dedicated development team that can
do a good job on upstream-able code is just farcical. That's a question of
corporate priorities, not resources, and gets precisely to the critique of
corporate culture that was in question.

> There's only so much time in the day; we'd like to make our code perfect,
> but we also want to get it out to customers while the hw is still relevant.

And this has always been the damn problem with AMD's drivers, even in their
wheelhouse, Windows. They just have a slipshod attitude toward the software
end of their core business.

~~~
dzhang50
AMD doesn't have "gross profit in the $1 - 2 billion range". They have about
$1B in revenue per quarter and have had negative profits (i.e. they lose
money) for quite some time now. They were on the verge of bankrupcy about a
year ago. Maybe Zen can turn their fortunes around, but they're correct in
that they don't have the resources for a dedicated development team right now.

~~~
lvs
It does, in fact, report around the gross profit I specified. Why don't you
look at the financials [1]. I think many people in this thread, including you,
don't know what the term "gross profit" means.

[1] [http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-
fundIncomeA](http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-fundIncomeA)

~~~
peller
I had to look it up. And you're right, I didn't know what the accountants
think gross profit means. The thing is, gross profit doesn't include operating
expenses[0]: "rent, equipment, inventory costs, marketing, payroll, insurance
and funds allocated toward research and development."[1] As you can see on the
page you linked, for a company like AMD, their operating expenses are _huge_.
And that's not even including expenses from taxes and debts. So the number we
_really_ want, and what I imagine most people are thinking you meant, is net
income. Which, you'll notice is sadly rather negative.

[0] [http://www.investopedia.com/ask/answers/031015/what-
differen...](http://www.investopedia.com/ask/answers/031015/what-difference-
between-gross-profit-operating-profit-and-net-income.asp)

[1]
[http://www.investopedia.com/terms/o/operating_expense.asp](http://www.investopedia.com/terms/o/operating_expense.asp)

------
drewg123
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
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
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.

~~~
shakna
> 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"

AMD was told 6 months ago that it wouldn't be merged if they didn't follow
certain guidelines. Then they didn't follow the guidelines.

What bothers me here, is the way AMD's management has handled the whole thing.

It seems like management demanded it be a certain way, and the coders were
forced to build something they knew would be unmergable. And then management
chucked a hissy fit.

There's been really good work here, and management has got upset, rather than
follow guidelines, or nVidia's example.

It reflects really badly on the company, which is sad considering the space
for AMD left by nVidia's Optimus kafuffle.

There is a market for GPUs here, but it does need to show some
professionalism, which they (management) haven't.

~~~
notalaser
I agree that there is room for disagreement between the two approaches.
However, I don't think that AMD did things this way just because of short-
sighted management. A HAL-like layer is a solution that I've seen or heard of
in a lot of places, from a lot of hardware manufacturers that want to support
Linux.

It may seem -- and may well _be_ \-- a sub-optimal solution, but it's not
worse than what we have now, and AMD looks willing to commit to the long-term
support of the HAL and the drivers. This is likely something that they want to
do not just because they're lazy and would rather spend the money on something
else -- it's likely that their management genuinely sees the development and
maintenance of an entirely unabstracted set of drivers for Linux as
inefficient, _especially_ when you look at how much money they make out of it.
And they aren't entirely wrong.

Deucher's remark about the Red Hat silo may look malicious and abrasive, but
it has a glimpse of truth. I could make a really cool photo album by taking
snapshots of developers and managers who are only familiar with Windows and
hear about the challenges involved in writing (and upstreaming) a non-trivial
Linux driver.

I'm not saying that the driver should have been merged as it is just because
there's no alternative. I do think, however, that it's a little presumptuous
to think its architecture is the way it is just because managers are stupid.
Maybe a third option, that's not HAL but also addresses the concerns and
requirements of AMD exists.

------
zznneezznnee
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
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!).

~~~
sangnoir
> We're talking about having a constant up-to-date driver on par with Windows
> for a major GPU card manufacturer

Nvidia manages to do this without any conflict with the kernel maintainers by
simply not mainlining the code. If functionality trumps code quality, AMD can
release kernel modules.

Perhaps the best current solution for all parties is for AMD publish sources
on github and release kernel modules while getting PRs from the community to
get the code up to meet the kernel standards. When the time comes, it will be
duly mainlined.

~~~
StRoy
Without any conflict, uh?

[https://www.youtube.com/watch?v=iYWzMvlj2RQ](https://www.youtube.com/watch?v=iYWzMvlj2RQ)

> Nvidia has been the single worst company we've ever dealt with.

> \- Linus

Kernel devs are antagonizing the only two GPU makers that matters. Besides the
kernel, there has been some flame going between NVIDIA and Wayland devs too.
Open source devs are immature men who do not understand the word compromise.

~~~
sangnoir
> Without any conflict, uh?

> Nvidia has been the single worst company we've ever dealt with.

> \- Linus

This had nothing to do with the kernel and everything to do with the lack of
optimus support (years later, its still shit).

> Kernel devs are antagonizing the only two GPU makers that matters

Maybe the 2 should ask Intel for some pointers on how to contribute to the
kernel the right way.

> Open source devs are immature men who do not understand the word compromise.

I suspect that's part of the reason the kernel is stable, and for that I'm
thankful. Not compromising on code quality is something I wish more projects
would do, if they had the well-earned political/social capital the Linux
kernel has.

~~~
_yosefk
Sarah Sharp worked for Intel and apparently didn't manage to contribute to the
kernel in a way that would make communication with Torvalds particularly
pleasant.

I extend my sympathy to anyone paid to contribute code to Linux.

~~~
bonzini
She never had any unpleasant communication herself, for what it's worth.

Most people who are paid to contribute to Linux, including myself, are very
happy to do so, and no, it's not a case of Stockholm syndrome.

------
lettergram
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
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
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
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.

~~~
bostik
You're asking a question with a very complex answer.

I'll start with a short answer - AMD wants to have at minimum a _reasonably
good_ baseline functionality on linux, out of the box. If that answer doesn't
make much sense, please read on for the complex bits.

To provide some historical context, Linus gave a VERY public, VERY brutal rant
on NVIDIA and their drivers four years ago.[0] At the time, NVIDIA's closed
drivers were an opaque blob which basically reimplemented the entirety of
OpenGL. These collided with everything else.

The open drivers (nouveau) were slow and far behind in features. The situation
was bad enough that you couldn't necessarily even _install_ a linux distro on
a system with NVIDIA chip because the open drivers wouldn't work well enough
for X and/or desktop environment to initialise properly, let alone remain up
and functional.

In effect, if you wanted to run linux, you were best off _without_ NVIDIA.

Fast forward year and a half. NVIDIA had come out and committed to improving
the linux driver situation. They still couldn't open source their current-
generation drivers, but they had realised the horrible reputation of their
hardware on linux was going to be a persistent PR nightmare, and thus an
existential threat to their growing mobile division. A space where they were
up against Imagination Technologies. (Don't get me started on ImgTec,
please...)

NVIDIA needed to get their hardware and software processes aligned in a way
that _they would work reliably out of the box on linux_ , everywhere. Even if
the user only needed to keep the freshly installed or upgraded system up long
enough for them to download and install the closed drivers, the system really
should not break. Incidentally this meant that even the open drivers should be
"good enough".

Over the past 3+ years, the situation has improved. NVIDIA has managed to shed
their reputation of being completely broken on linux, they have worked closely
with kernel folks to get their more recent hardware supported sensibly out of
the box and in the process (I believe) they have managed to reduce the code
delta between their windows drivers and linux drivers.

It helps that during the same 4 years we have had OpenGL on mobile drive the
separation of duties between EGL and GLES (v2+). These changes, with all the
refactorings, have also provided a cleaner split on desktop - to the point
that it is no longer absolutely necessary to provide full OpenGL
implementation. You can, for most parts, expect that EGL just works; that DRM
and KMS both just work; and that your highly optimised GLES implementation can
happily live on top of these layers.

As a result, your closed driver offering has less to override. Of course it's
going to be less unstable!

Disclosure: in my previous job, I helped integrate couple of EGL+GLES driver
stacks with Wayland on mobile systems. I learned to hate mobile GPU drivers
with a passion.

P.S.: I haven't read enough about Vulkan to know if it improves things or not.

0:
[https://www.youtube.com/watch?v=IVpOyKCNZYw](https://www.youtube.com/watch?v=IVpOyKCNZYw)

~~~
mslusarz
Although you don't say it directly but by saying that "The open drivers
(nouveau) were slow and far behind in features." and then that the situation
improved because of Nvidia involvement you are not being honest.

Nvidia hasn't improved performance or contributed features to nouveau.

Their changes are limited to code that is mobile chip-specific and from time
to time they contribute some reliability fix that affects non-mobile chips,
but only if benefits mobile.

Since Maxwell 2 (9xx+) their chips are designed to be hostile to nouveau, by
requiring firmware loaded by the driver to be signed by Nvidia (hardware
refuses to load firmware that wasn't signed by them). It means that without
Nvidia blessing nouveau for example can't change the fan speed (but still can
change clocks! how ridiculous it is?).

Nvidia contibuted signed firmware loading for non-mobile chips (so called
SecureBoot), but only because it's also required by mobile. And they still
have not released enough firmwares for desktop cards to be usable...

~~~
bostik
> _Although you don 't say it directly but by saying that "The open drivers
> (nouveau) were slow and far behind in features." and then that the situation
> improved because of Nvidia involvement you are not being honest._

> _Nvidia hasn 't improved performance or contributed features to nouveau._

Fair point, I didn't realise it could be read that way. Thank you.

Nvidia has contributed enough fixes to make their hardware sort of respond out
of the fox. Yes, primarily for devices on mobile space, and occasionally on
non-mobile when the same fixes happen to apply. I believe this is directly a
result of same hardware designs being used across the board.

I didn't mean NVIDIA were being particularly nice, although I didn't know
about the active hostility against nouveau. (IIRC their driver employees are
contractually prevented from contributing to nouveau, but I can't find
reference. At least there I can understand the reason.)

------
ajarmst
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
> 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
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
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
> 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.

~~~
tankenmate
And the open source drivers that do exist (and are far better than the Nvidia
open source drivers) are proof that said third parties exist. So the net take
away is that if you are a pragmatic open sourcer then you should buy AMD
hardware. And even better support the open source coders who do write these
drivers; cash, bug reports, testing, documentation, etc.

------
akkartik
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
Some clients just fold the quote.

------
jinmingjian
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.

------
gumby
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
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
That's probably far more accurate and much more fair than assuming they're
just shit programmers.

------
jwr
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".

~~~
pas
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-...](https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-or-
not/)

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).

~~~
digi_owl
Best i can tell, Xfce gets it right because by virtue of being short staffed
they trust X to not screw up. KDE and Gnome would rather see X get out of the
way and let them do their "magic".

Sadly the latter people are now in control of "X" development, or perhaps i
should say post-X development, thanks to Wayland.

------
seesomesense
"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 ?

~~~
usernam
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.

------
aqtrans
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
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)

~~~
jlgaddis
> _... 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".

------
gbil
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-
phoron...](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)

~~~
y2kenny
And this is the thread that bridgman points to:
[https://lists.freedesktop.org/archives/dri-
devel/2016-Decemb...](https://lists.freedesktop.org/archives/dri-
devel/2016-December/126698.html)

Much more constructive interactions, I think.

------
smnc
> 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
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
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
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
They also have some folks working on Akaros.
[http://akaros.cs.berkeley.edu](http://akaros.cs.berkeley.edu)

------
dorianm
Original email: [https://lists.freedesktop.org/archives/dri-
devel/2016-Decemb...](https://lists.freedesktop.org/archives/dri-
devel/2016-December/126422.html)

Proposed driver code:
[https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/d...](https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-
staging-4.7)

The file with the atomic functions:
[https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/d...](https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c?h=amd-
staging-4.7)

------
belltaco
Discussion of the rejection here.

[https://news.ycombinator.com/item?id=13136426](https://news.ycombinator.com/item?id=13136426)

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

------
dschuetz
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.

------
vertex-four
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
Which they generally fail at due to lack of manpower and pace of changes in
the kernel.

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

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

------
Jerry2
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!

------
izacus
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/...](https://lists.linuxfoundation.org/pipermail/ksummit-
discuss/2016-August/003580.html) )

...

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
> Not "We can't accept this, let's talk about how to make us both happy".

He gave them that answer 6 months ago, and they ignored it. This was not an
abrupt rejection out of nowhere.

~~~
izacus
The "answer" 6 months ago was "Yeah, you'll have to write a full Linux driver
yourself and maintain it." type deal.

It was unreasonable then as it is now.

If I tell you "You need to rewrite your product in Brainfuck or I'll kick you
out in 6 months.", the fact that I told you that doesn't make it any less
insane.

~~~
prodigal_erik
AMD is trying to merge a Windows driver with enough shims to make it sort of
interact with Linux. That might as well be written in Brainfuck from the point
of view of a Linux kernel hacker trying to figure out WTF it does.

To merge a driver into the kernel is to accept responsibility for maintaining
it, which they recognize they are not prepared or even interested in doing.

~~~
makomk
They've made it clear that this code doesn't come from the Windows driver, it
was specifically written with the intention of being usable on any platform.
Also, they seem quite willing to maintain it. The problem is that the Linux
developers aren't willing to merge code that's usable on anything other than
Linux.

~~~
prodigal_erik
Thanks for the correction. They aren't relying upon a Windows API that Linux
kernel hackers have no experience with, but instead a new API that _nobody_
has experience with. That's still a huge problem for the maintenance that in-
kernel drivers need; they can't have a driver which only one company
understands.

------
megous
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.

------
snvzz
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.

------
mkj
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
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.

------
crb002
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
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.

------
ChuckMcM
Would love to see FreeBSD take their code.

~~~
floatboth
[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.

------
carlosrg
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.

------
qplex
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
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).

------
Nano2rad
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.

------
hubert123
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
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
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
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.

~~~
hubert123
The whole point of plugins is that they dont need to be maintained as part of
the core product. Seeing AMD's response, it's obvious that they dont expect
Linux kernel devs to maintain this thing. They should offer a proper and easy
plugin interface for the kernel where devs can make drivers for it without
having to merge code into the kernel itself. This really seems too obvious, at
some point the kernel will have too much code, will have to support too many
different pieces of new hardware to be understood or maintained by anybody.
I'm sure Windows doesnt merge 3rd party graphics driver code into their
subversion repo, that would be insane. But just because Linux is open source,
it has to do that.. no of course not.

~~~
chris_wot
They do already have clear interfaces that do this. Some modules have less
clear interfaces, but if you followed what they were saying they actually said
that it would have been easier if they had subclassed some of the code and
followed the way that most folks were writing atomic code.

And there was a function with the bane "validate" that didn't, well,
_validate_. In a bit of code that rung alarm bells.

~~~
hubert123
> And there was a function with the bane "validate" that didn't, well,
> validate

so what? you still dont seem to grasp the concept of plugins. Plugin = the 3rd
party developer can do whatever he wants and it doesnt hurt the core product.

~~~
chris_wot
You say "so what", but that _is_ the so what. A core Linux developer saw a
massive commit come though from AMD and couldn't understand it easily.

The point that has been made over and over in these threads is that if you
want to develop Linux code then you can't just stick a development team to
work in complete isolation from everyone else in the Linux development
community and expect to be able submit grand unifying architectures you
designed to make it easier for your company but that make it harder for
everyone else.

If you want to do this, then you really need to work within this particular
community to effect change. For instance, there apparently are some standard
idioms that have emerged from within the atomic code. The way AMD have done
things is different enough to confuse the core maintainer, and he has
reasonably said that he doesn't want to accept a commit like this. Hence his
comments about the HAL and a massive middleware layer.

The bottom line is: AMD want to merge this into the kernel's main tree. But if
they want to do this, they have to get through the maintainers, and the
maintainers have to consider the whole picture and _not_ just your team, no
matter how hard they have worked on their code.

The AMD team seem to have worked in a silo, not released to the CI servers and
from what I'm reading broke stuff that others then fixed. So when the AMD guys
did a big release all at once like this, then they got told - politely! - that
their code wasn't up to scratch.

~~~
hubert123
I'm not arguing with you over what they did, I have not read about it enough.
I didn't even read the the exchange in full. This is purely political and a
sign of a lack of leadership. The Linux guys should be so grateful for these
drivers that they do everything they can to keep AMD happy.

> The point that has been made over and over in these threads is that if you
> want to develop Linux code then you can't just stick a development team to
> work in complete isolation from everyone else

that's a problem for Linux

> The bottom line is: AMD want to merge this into the kernel's main tree

No, AMD wants to have working AMD drivers on Linux. It's more than likely that
they were told to do it this way and this way sucks. A lot.

But hell, maybe Linux devs think that Linux is so important now that they can
pressure AMD devs into doing whatever they want from them. Maybe it works,
maybe it wont.

~~~
aseipp
> I'm not arguing with you over what they did, I have not read about it
> enough. I didn't even read the the exchange in full. This is purely
> political and a sign of a lack of leadership.

"I literally don't even know what I'm talking about at all, I'll admit it --
but definitely, trust me and my immediate assessment of the situation, it's
accurate"

LOL.

>> The bottom line is: AMD want to merge this into the kernel's main tree

> No, AMD wants to have working AMD drivers on Linux.

Are you even _reading the words you type_? AMD _already has working drivers_.
They're right there. You can go look at the code right now, 'git pull' it and
install it on your machine. What's stopping you? Your inability to read,
apparently?

No, it is literally -- by the definition of the above email -- the case that
they want to merge already existing code upstream, into the kernel, and have
upstream share the maintenance burden. That's part of the deal -- if AMD code
goes upstream, everyone helps maintain it, and in turn, they help maintain
everyone elses.

But it turns out, upstream doesn't want their code in its current state. Of
course, they don't have to merge it upstream -- they just want to. They don't
even have to merge it upstream now or "soon", but they would have liked that.
They could easily ship the AMDGPU driver as an external module using DKMS or
something, just as things like ZFS-on-Linux do, and start ironing out problems
for upstreamability while actually shipping drivers to people.

They have drivers. The drivers work already, in fact. Having them upstream is
totally different. Try _reading_ the article and doing some digging through
this thread to understand the context.

> But hell, maybe Linux devs think that Linux is so important now that they
> can pressure AMD devs into doing whatever they want from them. Maybe it
> works, maybe it wont.

You realize that given AMD's history -- it's entirely possible AMD needs Linux
more than Linux needs AMD, right? Linux doesn't need to win the desktop or win
over AMD, it thrives in its own market and has been surviving perfectly well
without them.

------
rasz_pl
>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
Gaming Evolved was not developed by AMD, it's a branded version of raptr.com.

------
Waterluvian
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
It is not about compromise, it is about the long term maintainability of the
code.

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

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

------
fbreduc
oh this is good _gets popcorn crunch crunch_

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

------
nottorp
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
Yes, because NVIDIA has been great contributing kernel code. /irony

------
imaginenore
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.

~~~
fapjacks
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
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
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
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.

