AMD responds to Linux kernel maintainer's rejection of AMDGPU patch • Hacker News Board

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

#111

Post by bsder » Sat, Dec 10, 2016, 5:26 AM UTC

wfunction wrote: post #107

Lazare wrote: post #101

Earlier quoted context omitted.

AMD has had ups and downs, but over the past 15 years they've had a net loss of $7 billion. Yes, they've had some good years too. They made over a billion dollars in 2000 alone, and they've been knocking around since 1969. And they've been written off for dead many, many times. That being said, the current situation is bleak, and no, they never made a ridiculous amount of money. They've had to go to pretty extreme le…

Thanks! But I still don't understand how they're still alive? How can you lose billions of dollars and still be in business? Are they borrowing the money from someone? Where is the money they don't have coming from?

Intel infused them with money the last time they were about to go under.

AMD's existence prevents Intel from having to face prosecution for monopoly status.

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

#112

Post by wfunction » Sat, Dec 10, 2016, 5:35 AM UTC

bsder wrote: post #111

wfunction wrote: post #107

Earlier quoted context omitted.

Thanks! But I still don't understand how they're still alive? How can you lose billions of dollars and still be in business? Are they borrowing the money from someone? Where is the money they don't have coming from?

Intel infused them with money the last time they were about to go under. AMD's existence prevents Intel from having to face prosecution for monopoly status.

Thanks! But what does "infused them with money" money mean? They wrote them a check for a few billion dollars? Would you mind explaining like I'm completely clueless (which I kind of am)? I literally don't know (or if I did, remember) anything about this so the missing details are not helping. Thanks!

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

#113

Post by chris_wot » Sat, Dec 10, 2016, 5:37 AM UTC

lvs wrote: post #57

Spivak wrote: post #23

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 see…

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,…

The funny thing is, had they followed some of the subclassing practices already in the kernel, it sounds like they could have had cleaner, more easily testable code with what from what I can tell tends to giv them a pretty unified interface.

The belie, however, is an appalling response really:

I realize you care about code quality and style, but do you care about stable functionality? Would you really merge a bunch of huge cleanups that would potentially break tons of stuff in subtle ways because coding style is that important? I'm done with that myself. I've merged too many half-baked cleanups and new features in the past and ended up spending way more time fixing them than I would have otherwise for relatively little gain. The hw is just too complicated these days. At some point people what support for the hw they have and they want it to work. If code trumps all, then why do we have staging?

Wut? If you want stable functionality, then you follow the kernel conventions, practices and coding styles.

This whole screed equates to: "We've got some code we've put together in our silo, you amateurs who want perfection are wrong and our unified layers and push to get our processors to market mean you can't comment on our code."

The bit about cleanups makes little sense to me, they seem to have some fundamental issues baked into their code that will necessitate these very cleanups...

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

#114

Post by dman » Sat, Dec 10, 2016, 5:37 AM UTC

bsder wrote: post #111

wfunction wrote: post #107

Earlier quoted context omitted.

Thanks! But I still don't understand how they're still alive? How can you lose billions of dollars and still be in business? Are they borrowing the money from someone? Where is the money they don't have coming from?

Intel infused them with money the last time they were about to go under. AMD's existence prevents Intel from having to face prosecution for monopoly status.

Infused them with money? If you are talking about the legal settlement then this is a very charitable description on what happened from Intels side. https://en.wikipedia.org/wiki/Advanced_Micro_Devices,_Inc._v....

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

#115

Post by 0xcde4c3db » Sat, Dec 10, 2016, 5:42 AM UTC

bsder wrote: post #111

wfunction wrote: post #107

Earlier quoted context omitted.

Thanks! But I still don't understand how they're still alive? How can you lose billions of dollars and still be in business? Are they borrowing the money from someone? Where is the money they don't have coming from?

Intel infused them with money the last time they were about to go under. AMD's existence prevents Intel from having to face prosecution for monopoly status.

I don't remember where I read this, but as I understand it, Intel is required by various contracts (military, aerospace, various other mission-critical stuff) to not become a monopoly on certain classes of products. In other words, if AMD went under, Intel would have to give the x86 license to someone else.

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

#116

Post by appleiigs » Sat, Dec 10, 2016, 5:47 AM UTC

wfunction wrote: post #107

Lazare wrote: post #101

Earlier quoted context omitted.

AMD has had ups and downs, but over the past 15 years they've had a net loss of $7 billion. Yes, they've had some good years too. They made over a billion dollars in 2000 alone, and they've been knocking around since 1969. And they've been written off for dead many, many times. That being said, the current situation is bleak, and no, they never made a ridiculous amount of money. They've had to go to pretty extreme le…

Thanks! But I still don't understand how they're still alive? How can you lose billions of dollars and still be in business? Are they borrowing the money from someone? Where is the money they don't have coming from?

You can see this by looking at their balance sheet or cash flow statement. Easiest to see these on Yahoo Finance or Google Finance.

Looking at the quarterly data, as of Sept 2016, you can see in the Balance Sheet, there is a "Capital Surplus" line showing they have raised $8.2B of equity over the life of the Corp. Now look at the "Retained Earnings", they have lost $7.7B of it. They also have $1.6B in debt.

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

#117

Post by prodigal_erik » Sat, Dec 10, 2016, 6:01 AM UTC

izacus wrote: post #27

pja wrote: post #13

Earlier quoted context omitted.

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.

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 post…

The goal of Linux governance is that all the video developers can understand and maintain all the in-kernel video drivers in order to evolve the internal API as needed. The goal of AMD is to reuse whatever the hell they had to write for Windows. Since Linus and friends are not in charge of Microsoft's driver API, these can't be reconciled.

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

#118

Post by quetzthecoatl » Sat, Dec 10, 2016, 6:09 AM UTC

tw04 wrote: post #102

Dylan16807 wrote: post #96

Earlier quoted context omitted.

Writing the software that makes your hardware work is much more of a revenue-based issue than a profit-based issue. Even if you're losing money you need to balance your development budget, and not cut any segment too far.

Yes, AMD should definitely dedicate an entire team to focusing on writing drivers for desktop Linux. An OS that currently captures less than 1% of the overall desktop gaming market[1]. In other news, McDonald's should really start tailoring their marketing and in-store experience to people making over $10 million/year. [1] https://en.wikipedia.org/wiki/Linux_gaming#Market_share_vs._...

Isn't it because the high end hardware becoming useless because of the very lack of drivers? Nobody wants to spend lot of money on hardware and don't get to use it optimally.

Driver support on platform -> Games released on platform -> Gamers using the platform.

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

#119

Post by hubert123 » Sat, Dec 10, 2016, 6:11 AM UTC

prodigal_erik wrote: post #71

hubert123 wrote: post #38

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 la…

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.

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.

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

#120

Post by prodigal_erik » Sat, Dec 10, 2016, 6:16 AM UTC

hubert123 wrote: post #119

prodigal_erik wrote: post #71

Earlier quoted context omitted.

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.

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 ob…

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.