Earlier quoted context omitted.
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!
AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
151–160 of 284 posts
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#152Earlier 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…
Don't you agree that it is very silly to try to force cross-platform code into the very source of a very specific platform?
After all, the people working for that platform need to actually maintain that code.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#153AMD'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 seems to me that they made no threat. They simply endorsed NVidia's product line for anyone interested in running Linux on the desktop.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#154Earlier quoted context omitted.
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.
so what? you still dont seem to grasp the concept of plugins. Plugin = the 3rd party developer can do whatever he wants and it doesnt hurt the core product.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#155Earlier quoted context omitted.
> Not "We can't accept this, let's talk about how to make us both happy". He gave them that answer 6 months ago, and they ignored it. This was not an abrupt rejection out of nowhere.
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.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#156Earlier quoted context omitted.
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.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#157Earlier 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…
why does AMD need to be in the kernel? Why can't they release the way nVidia does? or open source it, develop along with upstream but don't make it part of upstream.
I'll start with a short answer - AMD wants to have at minimum a reasonably good baseline functionality on linux, out of the box. If that answer doesn't make much sense, please read on for the complex bits.
To provide some historical context, Linus gave a VERY public, VERY brutal rant on NVIDIA and their drivers four years ago.[0] At the time, NVIDIA's closed drivers were an opaque blob which basically reimplemented the entirety of OpenGL. These collided with everything else.
The open drivers (nouveau) were slow and far behind in features. The situation was bad enough that you couldn't necessarily even install a linux distro on a system with NVIDIA chip because the open drivers wouldn't work well enough for X and/or desktop environment to initialise properly, let alone remain up and functional.
In effect, if you wanted to run linux, you were best off without NVIDIA.
Fast forward year and a half. NVIDIA had come out and committed to improving the linux driver situation. They still couldn't open source their current-generation drivers, but they had realised the horrible reputation of their hardware on linux was going to be a persistent PR nightmare, and thus an existential threat to their growing mobile division. A space where they were up against Imagination Technologies. (Don't get me started on ImgTec, please...)
NVIDIA needed to get their hardware and software processes aligned in a way that they would work reliably out of the box on linux, everywhere. Even if the user only needed to keep the freshly installed or upgraded system up long enough for them to download and install the closed drivers, the system really should not break. Incidentally this meant that even the open drivers should be "good enough".
Over the past 3+ years, the situation has improved. NVIDIA has managed to shed their reputation of being completely broken on linux, they have worked closely with kernel folks to get their more recent hardware supported sensibly out of the box and in the process (I believe) they have managed to reduce the code delta between their windows drivers and linux drivers.
It helps that during the same 4 years we have had OpenGL on mobile drive the separation of duties between EGL and GLES (v2+). These changes, with all the refactorings, have also provided a cleaner split on desktop - to the point that it is no longer absolutely necessary to provide full OpenGL implementation. You can, for most parts, expect that EGL just works; that DRM and KMS both just work; and that your highly optimised GLES implementation can happily live on top of these layers.
As a result, your closed driver offering has less to override. Of course it's going to be less unstable!
Disclosure: in my previous job, I helped integrate couple of EGL+GLES driver stacks with Wayland on mobile systems. I learned to hate mobile GPU drivers with a passion.
P.S.: I haven't read enough about Vulkan to know if it improves things or not.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#158Earlier quoted context omitted.
Except the largest deployment of Linux in the world: Android devices. Which are running a severely modified kernel because the process of going through mainline to get it mobile ready would be far too painful.
Not really severely. It has a few questionable tweaks here and there. The questionable part is CPU companies not pushing for upstream integration, so you get e.g. Qualcomm Linux. In fact, the process is not pushing, it is pulling. (some people have started working on it, still long way off) It can be done, as shown by efforts by TI, ARM and many more...
The funny part is on Windows Phone, Microsoft learned from the kernel development process and made Samsung, LG, HTC, et all upstream their drivers, whereas Google in the same position with the same vendors has not done this and thus Sony is the only OEM pushing drivers upstream.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#159The net result of attitudes like these is that I can't have a working multi-monitor desktop Linux setup, because everything is hopelessly broken and requires many hours of tinkering just to kind-of sometimes work.
I find it sad.
[1] Apple has been excelling at this recently, too, with the forced move to USB-C and dropping of the headphone jack — to "make progress" at my expense, where I am held hostage in the dongle-world as companies "move to new standards".
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#160Earlier quoted context omitted.
If it was a big secret that this was how Linux worked and it took the companies by surprise, I could see how this could be a bad thing, but it never has been: Linus has always been very upfront that he is Benevolent Dictator for Life and always has the last word. Don't get onboard if you don't like that system.
Then all the Linux fans that complained to AMD that they don't deliver open source drivers should from now on better shitstorm the kernel maintainers, since AMD delivered.
A year ago AMD said they would just use what is currently in the kernel with a few minor modifications to get their driver working in userspace, apparently they did not follow through on that though