Live data from Hacker News

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

lists.freedesktop.org

121–130 of 284 posts

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

#121

Earlier quoted context omitted.

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.

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.

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

#122
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?

They have raised cash by taking on investment from the Abu Dhabi Investment Authority (the sovereign wealth fund) and also selling off some major assets, most notably their fabs (GlobalFoundries) and even their HQ building. It is also worth noting that large accounting losses do not always correspond to large negative cash flows. Stuff like depreciation (though less of an issue now without the fabs) and writing off "goodwill" from e.g. their ATI acquisition cause large paper losses without actually adversely affecting their cash position.

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

#123

Earlier quoted context omitted.

They don't have the resources to do it right. I loved that line from his post, in particular. "We have the resources to design a billion-transistor GPU, but not to write a Linux driver for it." Poor management on AMD's part does not constitute an emergency on the Linux kernel's part.

How is that poor management ? Linux gaming is a blip when you compare it to (a) the total gaming market, (b) the professional creative market and (c) the big data/deep learning market. All of which AMD is selling graphics cards into. And it's not like Linux is even some massive growth market that justifies some risky investment.

Graphics cards are used for professional work too, not only gaming.

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

#124

Earlier quoted context omitted.

They don't have the resources to do it right. I loved that line from his post, in particular. "We have the resources to design a billion-transistor GPU, but not to write a Linux driver for it." Poor management on AMD's part does not constitute an emergency on the Linux kernel's part.

How is that poor management ? Linux gaming is a blip when you compare it to (a) the total gaming market, (b) the professional creative market and (c) the big data/deep learning market. All of which AMD is selling graphics cards into. And it's not like Linux is even some massive growth market that justifies some risky investment.

> the professional creative market

This is not true for the animation/CGI/effects industry where Linux not only looms large but is growing.

I'm also sceptical of Linux having a small share of big data/machine learning since this is adjacent to servers where Linux dominates- would you mind sharing your sources? Nvidia's CUDA is cross-platform, this sets a baseline for whatever response AMD is planning.

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

#125
post #122

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?

They have raised cash by taking on investment from the Abu Dhabi Investment Authority (the sovereign wealth fund) and also selling off some major assets, most notably their fabs (GlobalFoundries) and even their HQ building. It is also worth noting that large accounting losses do not always correspond to large negative cash flows. Stuff like depreciation (though less of an issue now without the fabs) and writing off "…

Huh, not sure I understand all of it but good information nonetheless; thanks!

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

#126
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!

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

#127

Earlier quoted context omitted.

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.

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

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.

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

#129
post #25

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…

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 PRs from the community to get the code up to meet the kernel standards. When the time comes, it will be duly mainlined.

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

#130
post #27

Earlier quoted context omitted.

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 kernel demanded they drop the idea of a cross-platform driver to get merged into the kernel . They can still develop a standalone driver module, same as everybody else. Code doesn't need to be in kernel to run.

But then they don't get the free lunch of kernel people maintaining and fixing their stuff.

Which ends up in the same situation as older catalyst.

Post reply on HN