AMD Contributes 8.5x More Code To The Linux Kernel Than NVIDIA, But Intel Still Leads

[illwieckz]

You can add all the code in the world but it won't mean anything if it's bad code.

To be upstreamed in Linux you have to face the same reviewers whatever you come from Nvidia or AMD, and see how many years people have waited for DAL/DC and you'll see the review job is done and AMD code is never blindly merged. You'll see the same about the needed bits for ROCm that aren't upstream yet despite working yet. Linux is not a software distro shipping various packages from various upstreams, it's one source tree, one package, one upstream, one review team, one set of rules for everyone. Everything else on your comment looks very absurd once those facts are stated.

By the way, why stating that AMD and Intel contribute more than Nvidia whatever the metrics is so problematic to some people that they need to arguments with fallacies? And what's the problem in stating that Nvidia does not contribute as much as others ? If Nvidia does not contribute a lot compared to others it's not AMD's fault, neither Intel's fault, neither Linux's fault, it's just Nvidia's strategy. If you're worried by the fact Nvidia's strategy does not suffer the comparison with other makers, tell Nvidia.

[clavko]

There's absolutely no fallacy in saying that LoC is almost not a metric. The fact that AMD has to add headers every now and then means they have a lot of hardware design changes, and a lot of different SKU's - how is that nVidia's fault, or AMD's benefit in sense of contribution to kernel, it's hard to derive. Adding header specs can hardly be called anything more than a boilerplate effort, but it's more than welcome.

Now, in 200k of C code you can say really a lot. And 200k is hard-ish to maintain as well. I've never seen a production code that couldn't benefit from refactoring. And I've worked on code for repositories ranging from 10k, 100k to several millions lines.

And yes, it's modern to s*** on nVidia, but while you're at it, don't use LoC. Use number of features added, percentage of SKU gamma covered by os driver, test coverage, performance results, review issues count... Almost anything but LoC, I'd say.

[vladpetric]

Lines of code is hardly a metric you should be proud of. If anything, with mature codebase, you should be removing lines, rather than adding them. In my last company we wrote a 5k LoC project that replaced 45k LoC legacy solution, heavy templated and consolidated. And still we removed a couple of hundreds of lines after a while through refactoring.

I'm totally with you, but, Linux is still written in pure C ... there's definitely C in legaCy.

[clavko]

Oh yeah, that makes perfect sense. You are gonna make new hardware work with the old kernel by removing code from it, and of course, without breaking any existing support.

It's more than possible. I've made a POS terminal support another ECR protocol by consolidating other supported protocols with a total negative LoC outcome. No support was broken, we have unit tests for that

[brrrrttttt]

I'm surprised at the number of obtuse comments in here focusing on LoC as a metric. It's fairly clear that AMD, and especially Intel, have each made at least an order of magnitude larger contribution to Linux and free software than NVidia. Doesn't matter how you measure it. In-fact, NVidia's contribution could be argued negative.

[clavko]

Can you explain why AMD driver code contribution would be 80% header but Nvidia driver code would not be 80% header? Aren't people from both companies writing GPU driver code ? ...

Can you? AMD has changed a lot of architecture styles in a last couple of years VLIW, GCN, you name it. It might be that nVidia wouldn't require so much code to properly support their GPU's. Or not. I won't go further into "what if" scenarios.

But you (and many others) are missing my point completely. It's intuitively clear that AMD is contributing to the kernel in larger sense than nVidia. But if we (Michael) choose to show that by using bogoLoCs, we make it look funny and easily falsifiable. There is more than enough proper metrics that could show that, I'm not trying to crush your (and mine) open source dream here.

[ddriver]

LOC is an unreliable metric for 2 reasons:

1 - code quality varies a lot in general
2 - code density varies a lot in general

They key here is "in general". Big and serious projects have very strict guidelines for code style and therefore density, and meticulous code quality control. This puts the LOC metric in such projects into much tighter margins, making it a lot more indicative in this particular context than it is in general.

Blast LOC all you need in order to pretend to be smarter than you are, but in practice LOC is the "best" metric, simply because a better one is not available in this case. It might be possible to formulate a better one, if someone bothers to count the feature implementations and bug fixes those LOC went into, but it will still not change the narrative, because nvidia cannot simply poop out neutron star density code that will somehow skew the weight of actual open source contribution between it and amd in its favor.

This stuff goes on and on, and it is just lame. Globals are evil, raw pointers are evil, C style casts are evil, blah blah, and many pick those up and parrot them as a substitute to actual competence just because someone competent made such statements. News flash - those are not always optimal or even applicable, but they are useful, because if they weren't, they wouldn't be in use in the first place. Try thinking for a moment, don't be broken records.

[clavko]

ddriver First you go on admitting how LoC is an unreliable metric. Then you go into salvation project for this particular cause, just to fit your theory of people with opposing opinion "pretending to be smart", which is a typical form of ad hominem.

Then you conclude that code style restrictions imply density restrictions, while these couldn't be in a more loose relation, barely related. Yes, code style disables you to submit stupid code. No, code style won't enforce architecture change, reviewer might, but they often got other things to do, and review is hardly the time and place to be changing arch design. At best, by having a code style guidelines you'll set a relatively high upper bound on code density, and almost nonexistent lower boundary, which is far, far from enforcing great architecture, or having almost any restriction on actual code density.

Then you conclude that there is no better metric available, when there clearly are lots of available, some of which I already mentioned. This salto mortale from "unreliable metric" to"best metric" is rarely seen in any sane discussion.

The rest of your comment consists of putting things into other people mouths, and inferring conclusions about their intellect based on this fabrication. Clearly, given that you're intellectually superior in this area, I'll gladly remove myself from this vanity fair.

And yes, globals are definitely evil, even if you don't understand exactly why

[ddriver]

...

Boy, aren't your comprehensions skills low... You can't even understand when you are being schooled. Yeah, globals are evil, so evil that the standard allows them, the standard that is defined by a committee of experts in the industry. You seem to even know even better than they know. You should submit your genius proposal to remove support for global from the language, seeing how evil they are... And just in case you are unable to tell, I am being sarcastic...

You came to this thread just to show your "amazing software engineering knowledge", and even tho you criticized the choice of metric, and claimed that there are better alternatives, you provided none. That doesn't display even a shred of competence. News flash, everyone knows how reliable the LOC metric is. You are basically insinuating competence by stating that water is wet. Kudos to you Captain Obvious, certified genius LOL

So far you have only proven competence in the capacity of "clueless wannabe".

[wizard69]

What a bitchy discussion this has turned into!!

First off "LOC" is a metric. It is impossible to deny that. Like all metrics its applicability is variable. It is sort of like a programmer describing himself as a "pro", ifvsaid programmer resorts to that he likely has something to hide with respect to ability.

As for AMD it is as much about what they commit than how much they commit. Back at the beginning of the year i biught a ryzen mobile based laptop becausevive seen AMD materially improving their drivers on a monthly basis. It was the right choice even if Meltdown / Spectra derail the schedule a bit. In the end i have a platform that gets better with every kernel update from Fedora which is what you would expect for new architecture support.

The other way to look at this is that the LOC AMD has been submitting of late have a high density of improvements. That is AMDs commits have lead to far better hardware support. More importantky AMDs open support means i know what is coming in future kernels to better support the hardware i have. To put it another way those LOC AMD contributes have a high likely hood of doing something constructive for somebody.

So LOC might not be an ideal metric (there probably isnt an ideal metric) but in this case it is representative of a lot of useful or important updates.