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

[iskra32]

Integrated GPU's (within a CPU) tend to be a lot simpler/smaller in scope compared to actual discrete GPU's.

In any case as I have stated elsewhere, this is going to be the new reality so get used to it. If Linux devs are adamant about wanting EVERY driver to be in the tree and not providing a lower level stable ABI (so that drivers can be independent of the Kernel) then yeah, this is the result.

Its not unfathomable that at some time the majority of the code in the Kernel is just going to be graphics drivers, I guess be careful of what you wish for.

who actually cares about *lines of code* if we're talking about autogenerated headers. This stuff isn't a maintenance burden on the non-AMD maintainers, and the only real issue is that git operations on the kernel tree would take longer. Given your asinine takes on a stable kernel ABI, you certainly don't do that one very often. About that one, if you want a real world example, the Kernel's USB subsystem has been improved many times over the years(and nearly rewritten from scratch once too I think). Something that would have been thoroughly impossible if the kernel wanted to maintain a stable ABI for drivers of USB devices.

[mdedetrich]

who actually cares about *lines of code* if we're talking about autogenerated headers. This stuff isn't a maintenance burden on the non-AMD maintainers, and the only real issue is that git operations on the kernel tree would take longer.

I am actually not even really talking about the auto generated headers

Given your asinine takes on a stable kernel ABI, you certainly don't do that one very often. About that one, if you want a real world example, the Kernel's USB subsystem has been improved many times over the years(and nearly rewritten from scratch once too I think). Something that would have been thoroughly impossible if the kernel wanted to maintain a stable ABI for drivers of USB devices.

Actually no, nothing is stopping the creation of a new backwards breaking API if significant improvements come as a result of it. Windows has changed their APIs many times, what it does do is that during the lifecycle of that API things are stable (and historically lifecycle is around 10 years), a real world example is when Windows released a new graphics API in Vista era (called WDDM), which did require rewrites for graphics drivers.

The amount frankly ridiculous/baseless assumptions flying around here is baffable. Its like no one in the Linux bubble has actually looked up real usecases of API's and their history/lifecycle and instead people are just spreading baseless FUD everywhere.

Also there is a difference between USB drivers and graphics drivers, there is nothing wrong with making an pragmatic exception/experiment with a type of hardware which is clearly in terms of design, scope and features way more extensive than a god damn USB/keyboard driver.

[tomas]

mdedetrich

The amount frankly ridiculous/baseless assumptions flying around here is baffable

Well, at least we can agree on that.
Although I suspect we have different views regarding who's responsible for the "flying around" part. 😊

[mdedetrich]

mdedetrich



Well, at least we can agree on that.
Although I suspect we have different views regarding who's responsible for the "flying around" part. 😊

Well its not hard to argue that Linux devs view of how API's work has no real resemblance to reality. Either they seem to think there is a new breaking API release every year or an API doesn't change in 40 years, both of which don't accurately represent whats actually happening.

[marek]

The existence of this article implies otherwise, its a concern at least.

I'll take that as a joke.

[bridgman]

That's a lot of unwanted baggage if you don't have/want or use an AMD GPU.

Have to disagree here:

- roughly 85% of the "code" is header files, and those are only used as reference when compiling - they do not add to kernel or driver binary size
- in terms of code that gets compiled into a binary amdgpu is just over 2x the size of i915 but supports a wider range of architectures
- the headers compress very efficiently so don't have even have much impact on git operations

The primary reasons for headers being large are:

- we have separate headers for each IP block version, which makes the actual code smaller and easier to maintain
- we supply full headers (all registers/fields) for each IP block, not just the registers/fields the driver touches today
- we support a lot of HW generations in the same driver, with some very significant register layout changes between generations

Valid complaints could include:

- using up a tiny bit more of your disk space if you download source
- possibly making driver compiles a bit slower, although AFAIK each IP block references a very small number of header files so probably not

These discussions always remind me of the start of the Great LaRouche Toad-Frog Massacre from Bloom County:

On June 21, 1988, the following item appeared on page 3 of the daily Bloom Beacon, sandwiched between an article on the plummeting price of cow tongue and "Dear Abby":

COMMUNISTS AT U.S. DOORSTEP
by Milo Bloom, Investigative Reporter

Today it was discovered that after years of aggressive expansion, the Soviet Union has stretched its borders to within a mere 12 miles of American soil. The State Department has no immediate comment.

...which wasn't particularly surprising since the State Department had been aware for some time that the easternmost tip of Siberia comes within a polar bear's whisker of Alaska, but who cares since it's too damned cold to worry about. But the vast bulk of the Beacon's readership had no such knowledge and a subdued rumble of patriotic consternation coursed through the local population like some frightening new flu virus. The consensus was that something ought to be done.

"SOMETHING," bellowed Steve Dallas at a hastily called town meeting, "SHOULD BE DONE!"

http://www.highwaygirl.com/archive/000007.html

[mdedetrich]

mdedetrich



How so? Please explain. The article does not say anything about it being an issue.

Wow some people here can really be a bit thick/dense and not read between the lines. Phoronix articles are either made because the author/s think

1. There is a new interesting feature (not this case)
2. There is a some bug/critical issue/security problem (not this case)
3. Some benchmarking of hardware (not this case)
4. Deprecation of something (not this case)
5. Some concerning treand/issue (which is this case). Other examples including Steam Linux usage charts, distro/desktop usage charts/, increasing/decreasing hardware requirements for software etc etc

I mean the article headlines is literally "there is a huge bunch of AMD graphics code in the kernel". You can argue till the cows come home whether this is just an "observation" but

1. Its not the first article on this point
2. No one is going to make an article about an observation unless its pointing some positive (or negative trend) or that its entertaining (not sure about you, but the line count of the kernel isn't exactly entertaining in itself).

So yes the existence of this article implies there is an important observation being made, and unless anyone here is arguing that having such massive lines of code is a good thing (given if you have an alternative of it not being there all else things being equal). I am pretty damn sure the article wasn't written out of boredom. Also I am getting the impression no one really read the contents of the article (which is even if you ignore the header's, as a percentage of the Linux kernel the GPU driver code is outpacing everything else).

And yes, YOU may not think its an issue but that is subjective and also besides the point. This is one of the reasons why journalism exists, someone notices or finds something which they think can be concerning/an issue and they report about it.

[illwieckz]

Are you seriously saying that an API is going to be as bloated as the entire AMD graphics driver?

No one said those 3.3 Million lines are bloat. This is 3.3 Million line of precious documentation and featureful code.

You seem to suffer from a kind of specific bias, very close to the “confirmation bias” mechanism, the “public” bias, if you don't see what is not public you're free to imagine any imaginary comparison and nothing can defeat such dream.

if this code was living in a out-of-tree non-public repository and delivered as precompiled modules, you would not feel any bloat, same would apply if all those generated headers were kind of highly packed binary blob the rest of the open source driver would read.

Though, all that data is not produced to be tight-packed, it's produced to be human readable as far as I know, hence the extensiveness.

For example we may see people signing abusive contracts because they made them feel super important, since they “signed with them”, though they would kept their freedom and would have done more awesomeness without signing such contract, but you can see the bias: being subject to some very hard constrain, waive rights in order to be part of something, this can make a man feel he is part of a select club, that can make someone feel so important, while at some point it may be close to being a slave.

This is the same bias here: it's public, there is no select club, you can see how big such work is, AMD takes the risk you discover some part of modern industry is huge for one mind, well, it's good they don't lie: that's the world we live in, it's just truth and they don't hide it, and they would not hide the truth and close their driver to make you feel better.

Nobody said it was an issue.

The existence of this article implies otherwise, its a concern at least.

You seem to suffer from some bias, really. This article is just about numbers and doing statistics, then you want to see such numbers as a concern. If today another article states that AMD market share has reached this or that number, would you see it as a concern as well?

Such kind of big numbers can be a very good sign, by itself they don't imply bloat, if those numbers are about bloat, that's bad, but if they are not about bloat, then this kind of number is awesome. Do you imagine if those 3.3 Million line are not bloat? That would mean we have 3.3 Million line of non-bloat code for AMD support in kernel, imagine how awesome that meaning would be? Do you know any other GPU brand that can compete with such awesomeness and support for Linux. If those 3.3 Million line are not bloat, do you know any other GPU brand that can claim having 3.3 Million line of non-bloat Linux code?

[tomas]

mdedetrich

Wow Some people here can really be a bit thick/dense....

Wow, now you are getting nasty. How sad.

... Wall of text with a lot of ramblings...

Who knows exactly why Michael decides to publish an article or not? It is well known that one of his most important revenue streams are ads which is driven by page hits. So in this case he was quite successful. For every comment we make now he gets more ad revenue. 😊.

Now, regarding the actual article. You assume that it was actually about something being an issue, but you can not really point to anything specific in the article to prove that point. Yes, I've read the article several times. Exactly where does it state that the number of lines of code for the AMD driver being an issue? And no, "reading between the lines" does not count. In fact, the article explicitly states

"Thankfully unused portions of these header files... are eliminated by the compiler at build time"

Now it's your turn. Let's generate some more ad revenue for Michael. 😉

[mdedetrich]

No one said those 3.3 Million lines are bloat. This is 3.3 Million line of precious documentation and featureful code.

You seem to suffer from a kind of specific bias, very close to the “confirmation bias” mechanism, the “public” bias, if you don't see what is not public you're free to imagine any imaginary comparison and nothing can defeat such dream.

if this code was living in a out-of-tree non-public repository and delivered as precompiled modules, you would not feel any bloat, same would apply if all those generated headers were kind of highly packed binary blob the rest of the open source driver would read.

Funnily enough I half agree with you, but only on the technical aspects and not the whole confirmation bias part. Having the code outside of the kernel (out of the tree) as you rightly pointed out means you don't notice the code/don't care, but that is the whole point because whats being discussed is modularity. The issue with the driver being in the tree is that the Linux kernel being monolithic (which is the opposite of modular) means that the driver code is completely hamstrung by Linux lifecycle and processes, i.e. you only get driver updates when you update the kernel (which is in stark contrast to how some other kernels work).

So yes, not noticing the code is what you rightly pointed about but it has nothing to do with confirmation bias but everything to do with abstraction/modularity.

There is also the other point of maintenance burden which if the code proportion (minus the headers) steadily grows over time (which it is, as pointed out in the article text).

You seem to suffer from some bias, really. This article is just about numbers and doing statistics, then you want to see such numbers as a concern.

Well no its not just about numbers. There are limitless amounts of numbers/statistics that you can derive, but no one is going to make an article about it unless there is an interesting take on it. Phoronix could just release an article saying, "a new patched bluetooth driver was released that has an extra 200 lines of code" and almost everyone would be like "so what". But when you have a single driver (again minus the headers) taking up 10% of the entire Kernel (and this amount is increasing over time) then yeah that is a possible room for concern which is why the article was made in the first place.

If today another article states that AMD market share has reached this or that number, would you see it as a concern as well?

Well if its decreasing then yes it is a concern, maybe not for me personally but for AMD and maybe the larger ecosystem. Just like the frequent %of Linux gamers being stuck at a trivially low number (0.9%) and even decreasing slightly iirc, that is also a concern, hence why an article was about it.

Such kind of big numbers can be a very good sign, by itself they don't imply bloat, if those numbers are about bloat, that's bad, but if they are not about bloat, then this kind of number is awesome. Do you imagine if those 3.3 Million line are not bloat? That would mean we have 3.3 Million line of non-bloat code for AMD support in kernel, imagine how awesome that meaning would be? Do you know any other GPU brand that can compete with such awesomeness and support for Linux. If those 3.3 Million line are not bloat, do you know any other GPU brand that can claim having 3.3 Million line of non-bloat Linux code?

To be frank as a software engineer I would disagree here, having giant monolithic systems with so many lines of code invariably ends up causing problems. Even Linus himself agrees that he is concerned about the code bloat in the Linux kernel, and that was in 2009