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.
AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
121–130 of 284 posts
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#122Earlier 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?
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#123Earlier 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.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#124Earlier 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.
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
#125Earlier 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 "…
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#126I'm glad that AMD is still not giving up on Linux!
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#127Earlier 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…
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
#128https://www.phoronix.com/forums/forum/phoronix/latest-phoron...
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#129The 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…
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
#130Earlier 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.
Which ends up in the same situation as older catalyst.