AMD's Modern Graphics Driver In Linux 5.14 Exceeds 3.3 Million Lines Of Code

[mdedetrich]

Ok, so you finally admit that there is nothing in the article itself that supports your claim? Good.

Try again

[tomas]

mdedetrich

Try again.

I don't have to try anything.
It is you that has so far failed to back up any of your claims. First you refer to the article itself even though it does not back your claim. And then you say it does not matter anyway, since apparently Linus Torvalds agrees with you, which is also a false claim as I showed in my response to you.

I don't understand your need to back your claims with external sources.
If you think that a stable driver ABI is superior to the current in-tree driver model that Linux uses, then fine, argue that point on its own merits, with your own arguments. But don't try to artificially prove your point with references that don't support your claim.

Regarding having the AMD GPU driver being part of the Linux kernel instead of being distributed separately, exactly how does that affect the "maintenance burden" for the Linux kernel developers apart from the ones from AMD that are the one maintaining and developing the driver? If internal APIs and data structures associated with the graphics drivers sub-system changes, then it is AMD that will adapt its GPU drivers in the kernel, so no extra burden for other parts of the kernel. On the other hand, having to maintain a stable driver ABI does put extra burden on the kernel developers, unlike today. Which vendor, except Nvidia with its proprietary driver, would benefit from a stable driver ABI? Not the drivers that are already shipped as part af the kernel anyway.

[skeevy420]

Nobody said it was an issue.

I meant issue more like a talking point than an actual problem. I'm not necessarily very articulate the first hour in the day which is when I do most of my posts...drink my coffee, read Linux news, make some comments.

[illwieckz]

Yeah I know this, and to be clear I wasn't saying "moving to code out of the Linux tree and have it loaded as a DKMS module" implied it was modular, thats something @illwieckz said, not me.

Wow, now you fake quotes and put them in mouth of other people? I never talked about something close to or far from DKMS in that thread. And if I'm right and did not missed anything, you're the one bringing that DKMS topic on this thread with this comment and this fake quote with fake attribution.

I said:

If such big repository may require specific care (for example, the cost of cloning is not low, that can be a problem), if one day some Linux big head decide to turn big parts of it (like such GPU code) as submodule, that would be a worst concern. At this point there is no better solution than submodule for repository repository, and I have hard time to write “no better” in such sentence because it may sound good while submodules are a deep pain to deal with.

Some aspect of Linux repository may not be perfect, but it looks like other solutions are just worst…

Cost of submodules is higher than “the big monolitic repo”.

Cost of stable ABI is higher than “the big monolitic repo”.

At no point I talked about DKMS. I did not talked about DKMS because the cost of DKMS is negligible compared to submodule cost or stable ABI cost, also DKMS is mainly a problem for the user, not the developers.

But maybe you don't know what is a git submodule? Maybe you don't really know the various costs of the various quoted solutions? And especially the costs for the developer?

Ok, so you finally admit that there is nothing in the article itself that supports your claim? Good.

In factmdedetrich is not really doing claims except wrongly assuming other's intention or even now putting lies in other's mouth.

Though, mdedetrich has some pet topic, he likes to defend the idea the Linux project must do kind of 180° turn in their decade-proven methodology to fit Nvidia development process instead of Nvidia having to fit Linux development process so he can use the Nvidia blob on its own computer (probably x86_64).

For example instead of talking about “NVidia drivers having issues with older GPU's due to NVidia not following the guidelines for kernel development”, he would talk about “NVidia drivers having issues with older GPU's due to them to tied to outdated kernels”, which is a very special point of view.

The concern of making sure the driver works on more than a platform (an ABI is very arch-dependent, and Linux focus more on API compatibility across system than specific stable x86_64 ABI), making sure the driver is reviewed, making sure the driver is updated to best practices, making sure the driver shares common code and receive fixes as other drivers get fixes, all of this sounds useless compared to him running the proprietary out-of-tree closed Nvidia driver on what is probably an IBM PC compatible. His concern is about having an operating system to run Nvidia, he would even says Windows is better than Linux for the need of running Nvidia, which may be true but out of topic. Quote from mdedetrich in another thread:

You don't have this problem on Windows

He is just looking for an OS to run Nvidia. That's all. Any argument about Linux having development guidelines that works, about drivers getting reviewed, about sharing code, about saving time on making things better instead of caring about brands that don't care about open source, about taking care of open sourceceness would be out of topic, at best the answers are just entertaining him.

He does not want to run Linux first, he wants to run on Nvidia first. He wants to run Nvidia/Linux, Nvidia being the platform and Linux being a kind of microkernel for the Nvidia platform. Though, unfortunately for him, Linux development does not go that way.

Proving anything right or wrong is useless, he is just looking for a microkernel to run the Nvidia platform and Linux does not fulfill that need. The only answers he is looking for are answers meaning Linux development would start shifting development methods in order to fit his specific need. Any argument about Linux itself, development methods or cost, open source, etc. are just distracting him, entertaining him at best.