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

Post by StRoy » Sat, Dec 10, 2016, 10:21 AM UTC

sangnoir wrote: post #129

izacus wrote: post #25

Earlier quoted context omitted.

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

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

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

mcpherrinm wrote: post #164

chris_wot wrote: post #113

Earlier quoted context omitted.

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

I think the argument here is that stability is gained from having code shared as closely as possible with the Windows codebase, which is where most of the QA work happens, and what the real experts debugging their ASICs use. From a hardware and driver development standpoint, I think that makes a decent amount of sense. Hardware is often weird and quirky, so making sure you handle all the edge cases in two different c…

Post by XorNot » Sat, Dec 10, 2016, 10:40 AM UTC

geezerjay wrote: post #153

ajarmst wrote: post #70

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.

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

Post by tankenmate » Sat, Dec 10, 2016, 10:48 AM UTC

lvs wrote: post #168

dzhang50 wrote: post #76

Earlier quoted context omitted.

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.

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

Post by TD-Linux » Sat, Dec 10, 2016, 11:10 AM UTC

cromwellian wrote: post #145

cypher543 wrote: post #67

Earlier quoted context omitted.

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

They have, it's called Fuchsia. I think most the arguments for monokernels have weakened with age. You have L4 microkernels in every iPhone A7 processor now. The demands of security, crash resistance, and portability I think outweigh any small advantages in performance. We've got performance to waste these days, what we're lacking is more secure, crash resilient software.