231–240 of 284 posts
I think the issue is more or less clarified behind the scenes. Have a look here from AMD's bridgman https://www.phoronix.com/forums/forum/phoronix/latest-phoron...
Much more constructive interactions, I think.
I think this is a great situation to quote Linus on Linux supporters inside companies (not 100% same, but I think related): (on litigation against companies that contribute) > Anyone in the company that pushed to use Linux is now seen as "wrong" and instantly is pissed off that external people just messed up their employment future. > - Anyone in the company that resisted the use of Linux (possibly in ways that cause…
That argument is too broad, because it could be used against /any/ effort to get code into the kernel by a large corp. Linux is no longer in the weak position it once was. It has won the war for server market share (at least to a degree where using it has nothing to do with being a "hippy" programmer), and it has lost the desktop war so thoroughly that at this point it really doesn't matter anymore. In this position,…
Now if Linux only wants to be a server OS then that is fine but if it wants to try and grow then it does need either AMD or Nvidia. I think that for now Nvidia will continue to do what they have always done(binary blob) but if AMD gains market share by being more open then Nvidia will respond in turn.
Earlier quoted context omitted.
> 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.
Gotta say this is my takeaway. If near latest kernels work with nvidia, I'll buy nvidia in the future (I'm all amd at the moment).
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 essentially demanded they drop the idea of cross-platform driver 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.
Earlier quoted context omitted.
> A driver which has caused a large amount of desktop users to return to Windows due to its historical issues. Kernel developers do not care. They care about good software.
Define "good" and "software."
Define "good." Is quality a thing just defined by code style and properness, or is it defined as fitness for a purpose, connection to human use and usefulness, usability or function, or lack of defects to the end user?
Define "software." Is software just code, or does it also include the experience the code generates for the user? Is software only considered in terms of what developers of software are interested in, or does it include what users need and want?
Of course Linux kernel developers are only interested in narrow definitions of those things, and that's surely part of the problem. It's good to think about what "good software" really means, in my opinion.
Earlier quoted context omitted.
Hell, even Rockchip, Allwinner and Sony can do it, Qualcomm, Mediatek, Google and Samsung are just not doing it because they are able to skate by without doing it. 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 pu…
Upstream Allwinner support is a community effort, and it takes so long to convince the kernel developers to merge code that parts are generally years obsolete by the time they're fully supported. I think the upstream support may almost be at the point that C.H.I.P could use it - but they're using a single-core SoC from early 2012. I've seen patches for basic functionality like clock controllers (without which nothing…
I would not expect much from Allwinner directly, but at this point there is a sizable ecosystem and mainline support for most of their chips, which can't be said for most other ARM vendors. Another aspect of this is Allwinner sells most of their chips thru multiple business units, with the silicon being exactly the same, just what is silkscreened on the top of the package being different[3].
1 - http://www.cnx-software.com/2015/11/10/allwinner-a64-datashe... and https://forum.armbian.com/index.php/topic/1917-armbian-runni... 2 - http://www.cnx-software.com/2016/08/17/allwinner-h5-is-a-qua...
3 - https://forum.armbian.com/index.php/topic/2099-crypto-engine...
Earlier quoted context omitted.
AMD could likely allocate the resources, but what will they cut to do so? At this point they are a token competitor to Intel and are losing money and have been losing money for years, so how much of their financial runway are they willing to burn up on a platform that doesn't use them for servers and minimally uses them for gaming (where the platform has no marketshare). I as a full time debian user for the past few…
OMG I didn't know they were making customers pay in advance. That's really bad. I do understand their position on the issue, but I also get the kernel guys point. I have some faith that a compromise will be found because it's in the best interest of AMD and Linux.
Earlier quoted context omitted.
You're asking a question with a very complex answer. 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 driver…
Although you don't say it directly but by saying that "The open drivers (nouveau) were slow and far behind in features." and then that the situation improved because of Nvidia involvement you are not being honest. Nvidia hasn't improved performance or contributed features to nouveau. Their changes are limited to code that is mobile chip-specific and from time to time they contribute some reliability fix that affects…
> Nvidia hasn't improved performance or contributed features to nouveau.
Fair point, I didn't realise it could be read that way. Thank you.
Nvidia has contributed enough fixes to make their hardware sort of respond out of the fox. Yes, primarily for devices on mobile space, and occasionally on non-mobile when the same fixes happen to apply. I believe this is directly a result of same hardware designs being used across the board.
I didn't mean NVIDIA were being particularly nice, although I didn't know about the active hostility against nouveau. (IIRC their driver employees are contractually prevented from contributing to nouveau, but I can't find reference. At least there I can understand the reason.)
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…
Windows presents an API to drivers that's very painful for them to change. This is a problem that Linux can avoid by not treating drivers as black boxes.