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.
AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
181–190 of 284 posts
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#182Earlier 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…
This is exactly how I feel. I don't use Linux, I'm an outsider, and the whole thing just makes no sense to me.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#183I 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…
Or even better, give us an open source out-of-tree driver, and wait. Someone in the community will do the cleanup and get it upstream eventually. For free.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#184Earlier quoted context omitted.
> 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…
Without any conflict, uh? 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.
> 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.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#185Earlier 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
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...
[1] http://www.investopedia.com/terms/o/operating_expense.asp
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#186Earlier 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 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.
From the AMD point of view, the Linux upstream's approach to modifying the internal API and drivers is a problem itself: "I understand forward progress on APIs, but frankly from my perspective, atomic has been a disaster for stability of both atomic and pre-atomic code. Every kernel cycle manages to break several drivers. What happened to figuring out how to do in right in a couple of drivers and then moving that to the core. We seem to have lost that in favor of starting in the core first. I feel like we constantly refactor the core to deal with that or that quirk or requirement of someone's hardware and then deal with tons of fallout."
Certainly, from what I've seen the first few stable releases after every new kernel version are often full of fixes for modesetting-related regressions.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#187[deleted]
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#188Earlier quoted context omitted.
Breaking on every kernel upgrade is a configuration issue (and a result of Linux's driver model); the "quality" of the NVIDIA Linux driver being discussed is an issue of the actual performance, compliance, stability, and feature parity/freshness relative to others, once configured correctly. Reconfiguration/rebuild on every kernel update is definitely a hassle, and the NVIDIA scripts which try to automate the process…
That's why I switched to the open source nVidia driver long ago. I got tired of upgrades screwing up the driver. It's not a configuration issue, it's because the other nVida driver doesn't get rebuilt along with the kernel due to not being upstream.
To be clear, were you using DKMS? It's not clear at all to me if that's what the OP is talking about using (he mentions scripts in the nvidia installer), but DKMS has worked quite well for me for a long time when I needed to keep out-of-tree drivers up to date.
Of course, if your distro tracks the latest kernel upgrades in a frequent fashion (e.g. ArchLinux) then it's more problematic, since API changes in the kernel will actually cause compilation failures. But actually making a rebuild happen? Easy. Debian derivatives tend to have stable kernel versions for years and years, so DKMS works quite well here for modules that are out of tree (another example is ZFS on Linux).
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#189Earlier quoted context omitted.
Without any conflict, uh? 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.
> 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 imma…
Out of the three common GPU brands found in computers nowadays, Intel's integrated GPUs have mostly been a very pleasant experience for the end user when installing any GNU/Linux distribution. It just works without any additional work.
If AMD manages to reach that level of out-of-the-box working graphics driver, that will definitely reflect positively on their brand of graphics cards, and might give them an advantage over Nvidia.
I suspect that working with the kernel developers and maintainers will also be beneficial to the driver itself. It seems to me that for cooperating you gain valuable feedback on your code from people well-versed in kernel and driver code.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#190Earlier quoted context omitted.
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.
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.
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.