The AMD Radeon Graphics Driver Makes Up Roughly 10.5% of the Linux Kernel

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-AMDGPU-Stats

by akvadrako • 6 years ago

707 462 6 years ago

henriquez• 6 years ago

The real shame is that Nvidia is still doing binary blob drivers 15 years after I started caring about Linux. Are they really that afraid of someone taking their Lucky Charms?

banachtarski• 6 years ago

Well, in their defense, I generally haven't run into any issues with their driver and it's also pretty easy to package/install as an enduser.

sushisource• 6 years ago

I agree, if it weren't for the fact that they give zero shits about Wayland support. I'd be totally fine with them staying closed source as long as they kept up with the standards.

tomc1985• 6 years ago

Is it? This is the same driver that makes me shut down X and fucks up xorg.conf every time I need to update?

mcguire2• 6 years ago

I have. Like keeping a copy of the last page you viewed in Chrome and overlaying it on the screen after exiting the browser.

That one is fun.

Nullabillity• 6 years ago

I still haven't been able to get my laptop's 1660Ti to display anything else than glitch art, proprietary or nouveau.

PurpleFoxy2• 6 years ago

I have. I needed a prerelease kernel for a new driver but nvidia had not released a binary for the new kernel yet so I was unable to use anything but the open source nvidia driver.

asddubs• 6 years ago

wayland doesn't work at all so if you have a 4k monitor and a non-4k monitor and an nvidia card, you're basically just fucked, because you can't selectively scale things

etaioinshrdlu• 6 years ago

My new theory is the Nvidia driver can't be GPL and in the Linux kernel, because then they couldn't ban datacenter usage of their GeForce cards by not licensing the driver for datacenter use. The upcharge on the Tesla series of cards is huge compared to GeForce for mostly the same chips. (For those not aware, see if you can find and GTX 2080 or 3080 from a cloud provider. It's not a thing. This is actually a huge deal for the machine learning industry, massively increasing costs. I doubt Google would have made the TPU if not for this.)

Also, their driver is very complex, and they are constantly improving their hardware. They don't want to be dependent on getting new features and performance improvements upstreamed.

amelius14• 6 years ago

not licensing the driver for datacenter use.

Why are these kind of licenses even allowed. If I buy a product, surely I can do with it as I please?

Also, why doesn't TSMC slap a license on every IC that leaves their fab, taking (say) a 30% profit from every application in which their ICs are being used?

aaomidi• 6 years ago

Meanwhile people say capitalism drives innovation.

How much is nvidia single handedly holding back innovation and new discoveries?

kanox• 6 years ago

This sounds dubious, isn't it easier/more reliable to just block parts of the hardware using fuses?

userbinator2• 6 years ago

Don't forget the fact that most of their silicon is basically the same and you can easily change it with some hardware/software mods[1] --- I think they have tried to lock that down a bit more, but ultimately it's a cat-and-mouse game and the only ones who win are those willing to ignore the insanity of Imaginary Property laws and take matters into their own hands.

[1] https://www.eevblog.com/forum/general-computing/hacking-nvid...

chrisseaton2• 6 years ago

Maybe they can't open-source it because they don't own all the IP? That's very likely the case for Windows as well, for example, Microsoft just didn't licence all the code they used for releasing the source, and now you can't go back to 1000 different IP owners and negotiate anything reasonable.

bonzini• 6 years ago

Didn't they have to manually prepare a binary patch for a security issue in the Word Equation Editor, because they either lost or could not compile the source code anymore?

MayeulC• 6 years ago

Well, at the very least, they could allow loading unsigned firmware, or allow their firmware to be redistributed, then.

This is the number one usability issue with nouveau: no firmware means no re-clocking, which means bad perf.

vbezhenar3• 6 years ago

I think that Microsoft can open-source most of Windows sources. Nobody would care too much about few binary blobs and I don't believe that they don't own license for a significant portion of OS.

TheAceOfHearts• 6 years ago

Here's a kernel engineer from Microsoft answering the question: What do you think about open sourcing windows and getting rid of the licensing code? [0]

[0] https://www.quora.com/What-do-you-think-about-open-sourcing-...

znpy3• 6 years ago

that's what kept Solaris from being open sourced for years.

There's a talk by Bryan Cantrill about that.

They basically could not provide a fully functional OS because some marginal yet used-everywhere parts where licensed and proprietary (Bryan cites the internationalization library as an example).

paulmd• 6 years ago

second-hand information but apparently the reason they can't is that the driver contains code licensed from other companies and they can't open-source that.

https://www.reddit.com/r/hardware/comments/j217oo/gamers_nex...

while obviously not an official source, that isn't particularly surprising either.

as an additional relatively-well-known-but-possibly-incorrect bit of internet lore, right now their Linux driver is basically a wrapper around their Windows driver, so that explanation makes a lot of sense. They would have to go through and disentangle what parts they own and what needs to be stripped out / replaced for the linux version at an absolute minimum.

CamperBob2• 6 years ago

Are they really that afraid of someone taking their Lucky Charms?

They're afraid of patent trolls.

severino3• 6 years ago

Why is it a shame? They had been providing quality Linux drivers for years, when nobody else cared about high-end graphics for Linux. Remember fglrx?

Now AMD is opensource? Great! However, it's still very far from perfect. You only have to take a look at the list of AMDGPU issues at freedesktop[1]... because being opensource is easy, but working fine in a stable manner is another.

[1]https://gitlab.freedesktop.org/drm/amd/-/issues

Aeolun• 6 years ago

Providing support for a marginal platform is also much harder when you’re <0.1 times the size.

shmerl10• 6 years ago

It's shame, because they hinder the progress of Linux desktop and prevent Nouveau from reclocking properly.

And what about AMD bug tracker? It's open, so you can see the bugs. That's a plus, not a minus. Nvidia blob has all the bugs hidden somewhere, so you don't see them. It doesn't mean the blob doesn't have them.

javchz• 6 years ago

That's my dream... or in a short time frame at least wayland support.

amelius14• 6 years ago

In source code, or in compiled bytes?

tomcam• 6 years ago

According to the first line of the second paragraph, it is source code

capableweb• 6 years ago

Or just the huge output from cloc that is showing the count of lines of code.

amelius14• 6 years ago

It turns out that it's generated source code. So the actual source code may be substantially smaller.

atq21194• 6 years ago

Most of it is dumb automatic header generation as the article points out, but looking at the source[0], there seems to be a lot of code duplication, e.g. 5 different vcn_*.c files that seem of significant size and largely identical at a glance.

That frankly seems like horrible software design.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

pantalaimon3• 6 years ago

That frankly seems like horrible software design.

Why? If it's auto-generated and the generated code is never touched by humans, that's not too bad.

This information is sourced by some CAD/synthesis tool and just describes the hardware register layout.

Manually maintaining that would be much worse and error prone.

tylerhou6• 6 years ago

Compile times increase superlinearly with program size. How many cycles and developer hours are wasted if this duplication is not necessary?

atq21194• 6 years ago

That part of the comment was specifically talking about the parts that are not auto-generated, but copy&pasted from one hardware generation to the next -- and then bugs need to be fixed and interface changes need to be applied in N different places forever.

deaddodo5• 6 years ago

How do you figure? VCN 1.0[0] and VCN 2.0[1] differ within the first few lines and only do so further, the more you compare them. The files seem to correlate to each version of AMD's Video Core Next hardware[2]; and not anything to do with autogeneration.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[2] https://en.wikipedia.org/wiki/Video_Core_Next

atq21194• 6 years ago

Actually, there's a lot of commonality between those two files. Just look at all the "is_idle", "get_wptr", "set_wptr" type functions. They're either literally identical or the v2_0 version is a superset of functionality of the v1_0 version.

This is a case where code is identical not by random chance but due to an underlying logical pattern (in this case: ring buffers for communication between CPU and GPU seem to continue working the same way). Hiding that via code duplication is going to make the code overall less maintainable, because the code lacks implicit knowledge of these patterns.

P.S.: It's interesting how many people missed that my complaint was specifically not about the auto-generated part, but about the part that humans copy&paste.

fizixer4• 6 years ago

Yes. Despite being an avid code minimalism and refactoring advocate, I have zero problems with auto generated code size, as long as the size of "the source that generated the code" is reasonable.

Here's how I count the size of the code:

So if a codebase is 1 million lines, but 900k was autogenerated using, let's say, a 10k line 'metaprogram' (which is otherwise not included in the source), the real size of the code is 100k + 10k = 110k.

Now, with the stupid vcn_* .c duplication, that I have serious problems with. But what you could do is take a diff of the two vcn_* .c files, keep those diffs as part of the source code, plus only one version of vcn_* .c file, but now add a small script that generates the remaining vcn_* .c files during the build process by using the diffs, e.g., using the patch command. Now the size of the diffs and the size of the patch script, plus the size of one vcn_* .c files, is a better measure of the size of the code.

Of course this is a short-term workaround. There's still a need to refactor the code properly.

IncRnd3• 6 years ago

That can be a useful way to calculate lines of code, however it is only nominally correct.

In many cases it is more useful to calculate the lines of code according to what was checked into the build system, since those files can drift from the primary source. This is true, even if a million lines of checked-in source originated from 1k lines of meta-source.

est31• 6 years ago

IDK it seems pretty common in the embedded world to add support for a new piece of hardware by copying the entire driver and then changing the parts that the new hardware supports instead of trying to come up with a driver that supports all generations of the hardware. Pretty sad if you ask me and very unmaintainable, but, at least if you ask the companies, people should just buy newer generations of their hardware if they want those bugfixes :).

rictic• 6 years ago

Wild speculation from someone who doesn't do hardware, but I'd guess that it's not so much writing the software as testing it that motivates that. It'd be hard to keep the testing matrix of apps X hardware X driver version from exploding out of control.

Your customers will be hella pissed at you if their favorite game suddenly doesn't work on their system after a driver update. So you need to test a representative sample of previously-working software across all hardware that the updated driver applies to.

That sounds like a nightmare, and a capital-intensive one because you need to keep machines up with all of these cards, both in continuous integration and for interactive debugging.

I can understand the impulse to keep the list of hardware that new driver versions support small.

oblio3• 6 years ago

The thing is, DRY has some downsides. If you've pretty much nailed down the functionality of the old thing, especially if it involves some kind of manual testing/open beta test with users, the last thing you want to do is touch the old code.

I'm not defending them, but sometimes something is good enough and you have to move on.

barumi7• 6 years ago

IDK it seems pretty common in the embedded world to add support for a new piece of hardware by copying the entire driver and then changing the parts that the new hardware supports instead of trying to come up with a driver that supports all generations of the hardware.

The rule of three is not exclusive to the embedded world. It´s far better to have duplicate code around then to have to deal with poor generalizations that affect multiple independent modules, which in this case mean hardware support.

To put it in perspective, how many pieces of hardware would you require to re-test and validate if you decided to refactor bits of drivers that might share a common code path?

qppo• 6 years ago

I don't know, to me this is a bit like taking two c programs that print "hello world" and "goodbye world", looking at the assembly that is compiled then remarking "pretty sad and very unmaintainable."

Point being, maintain the code generator and not the generated code.

notanotherycomb• 6 years ago

That's how we do things at work. If we need to change a class function we outright copy/paste it then change what we need. This is so everything is backwards compatible. A bug in one version might be expected or documented in a previous. We can't fix the bug in an older version unless we get the OK from our clients because they might be depending/expecting it for their code to run correctly

It's a good system. You shouldn't complain. And deleting code is easy since not everything depends on everything

chrisseaton2• 6 years ago

83k lines of YAML. Wow.

tinco• 6 years ago

What percentage of the Linux kernel is actually still there after you run it through the preprocessor on a modern system?

jws• 6 years ago

A rough rule of thumb is 20 bytes of object for 1 line of C.[1] So if you have a 5MB kernel you might have 250k source lines of code.

That said, the Linux kernel is not typical code. Great swaths of it are architectures and devices you will not need, so they are rightly ignored.

[1] https://www.leshatton.org/Documents/LOC2005.pdf

dodobirdlord• 6 years ago

I think that’s the core of the question. How much of the kernel is left if you strip out all of the sections that would be stripped by the preprocessor when building for a current-generation 64-bit x86 target.

AWS had a blog post about this topic a few years back. They created a cut-down Linux variant for running Lambda functions that only supported exactly their server architecture, only contained exactly the drivers they actually use, and notably only had 1 keyboard driver for a keyboard with only 1 key, which was mapped to Halt.

znpy3• 6 years ago

IMHO a fairer comparison would be the amd drivers vs the nvidia drivers, but we don't have the nvidia sources (of course).

nemetroid• 6 years ago

Though as reported previously, much of the AMDGPU driver code base is so large because of auto-generated header files for GPU registers, etc. In fact, 1.79 million lines as of Linux 5.9 for AMDGPU is simply header files that are predominantly auto-generated. It's 366k lines of the 2.71 million lines of code that is actual C code.

spullara• 6 years ago

Why not generate it during the build? Is there a good reason not to do that?

stefan_• 6 years ago

The Linux kernel doesn't play the Firefox game of requiring Ruby, Python3, Python2, NodeJS and Rust to even be able to build the thing.

barumi7• 6 years ago

Why not generate it during the build?

If those headers aren't expected to change then, with regards to accountability, it's far better to have the code checked into the version control and processed as is.

More importantly, if the code is already generated then there's no need to make the build system more brittle by adding a non-standard build target that depends on custom/third-party tools.

ploxiln2• 6 years ago

It was generated by the hardware division. These are the registers that are authorized for disclosure in the open-source driver by the AMD employed open-source driver developers.

So, it includes many times more register definitions than are ever used (consider there are 8x more register definition lines than actual code lines that could use them) and it includes many sets of 16 or 64 definitions that a software developer would have made one parameterized definition (all the same except for _00, _01, _02, _03, etc). But this is exactly what the hardware guys generated for public release, and it is to be used as-is.

IMHO it's kinda annoying and sad. The rest of the kernel is held to a higher standard, that's why all the other non-trivial multi-arch multi-family multi-generation code in the linux kernel is much more concise / less sloppy. It takes a lot of effort to make it that way, and commercial companies pretty much never bother, except when required by the Linux maintainers.

But, modern graphics drivers are way too complex and way too much work, and most people do want some proper modern GPU support in the kernel, so compromises have to be made. It's not too bad, just a bunch of inert header lines, git and the compiler handle them just fine I guess.

Taniwha3• 6 years ago

Why not generate it during the build? Is there a good reason not to do that?

In many hardware shops the C definitions for the visible registers are generated automatically from the hardware's source code

saxonww• 6 years ago

If it never changes, generating the headers during the build is just wasted time for whoever/whatever is running that build.

_x5tx• 6 years ago

Honest question: why these gpu drivers need some many lines of code? Anybody with more background can explain?

bleepblorp2• 6 years ago

GPU drivers are essentially operating systems for the GPU.

extropy• 6 years ago

And also ~real time compilers for any user code (shaders, etc) that will be running on the GPU.

detaro3• 6 years ago

GPUs are complex computers in themselves, and the driver needs to provide compilers etc that target them (e.g. when it comes to shaders, applications hand the driver source code that is then compiled for the specific GPU architecture). Combine that with many different product generations and configurations being supported, code apparently being autogenerated and thus probably not optimized for size and you get to this.

EDIT: monocasa points out below that the compiler is not a correct example - true, that does live in e.g. mesa userspace code.

radium3d• 6 years ago

And it still has a bug with residual cursor after wake from sleep on my desktop running Ubuntu 20.04...

https://gitlab.gnome.org/GNOME/mutter/-/issues/1108

Hopefully not for long though with this

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-stag...

blunte2• 6 years ago

So does my latest macos with intel video and second monitor.

ysleepy• 6 years ago

Yeah, the intel driver in Mojave on my 2015 13" pro has a bunch of issues.

I see random buffer garble when waking the external screen, sometimes the machine freezes with hw video decoding and the resolution switches to low-def on monitor sleep only to switch back on monitor wake. It's a shitshow.

pantalaimon3• 6 years ago

What I find worse is the lack of analog output support with DC. One of my monitors only has a VGA input and I have no intentions of replacing it.

However, the new Display Core does not support analog output and it will stay dark.

Fortunately amdgpu.dc=0 is still an option, but I dread the day when this code path is removed (or bit rots away).

p1necone• 6 years ago

Is it a really good VGA monitor or something?

You can buy relatively inexpensive active DVI/HDMI to VGA converters if that helps.

TheCapeGreek• 6 years ago

Oh, let's not also forget (to pile on) the GPU hangs on the 5000 series cards across many games, and for some many ordinary applications.

https://gitlab.freedesktop.org/drm/amd/-/issues/914

blunte2• 6 years ago

It is another highly complex computer after all.

mey2• 6 years ago

Can someone with more understanding of the Linux Kernel arch/design describe why these drivers are in the kernel tree? Are these not part of a HAL or are they more "integrated" then that?

detaro3• 6 years ago

Linux does not use a stable API to talk to drivers, so drivers are intended to be part of the kernel tree so they can change with the rest of the kernel evolving.

deaddodo5• 6 years ago

Eh, that's not exactly true. Most of the API is pretty standard and stable. They don't have a fixed ABI, which is how closed source OSes handle driver compatibility.

l3s2d• 6 years ago

Here's some more HN discussion around this: https://news.ycombinator.com/item?id=14533398

And the relevant doc in the kernel source: https://github.com/torvalds/linux/blob/master/Documentation/...

cardiffspaceman2• 6 years ago

What percentage of loaded and running binary is it?

edoceo2• 6 years ago

0% on mine (cause I'm on Intel and Nvidia HW) and have a custom kernel config.

yjftsjthsd-h4• 6 years ago

While the down votes are understandable, this is actually a somewhat legitimate take; the kernel's pretty good about not loading stuff that it's not actually going to use on your actual hardware, so the impact of this is limited to people who are actually using that hardware, which by extension means they kinda do need the driver in some form.

notaplumber• 6 years ago

AMDGPU It was significantly larger than the entire OpenBSD kernel sources. The dev/pci/drm directory ballooned to around ~130M. As of 6.8/-current, it's now 191M. It was under ~20M before May of 2019, prior to it first being committed.

This driver is I believe part of the common codebase that AMD upstreamed to the Linux kernel, it's shared with its proprietary driver on other platforms.

miki123211• 6 years ago

According to the stats in the article, the kernel contains 225085 lines of assembly.

Just for comparison, the whole DOS 2.0 operating system, which was written in assembly entirely, has just 37955.

barumi7• 6 years ago

Just for comparison, the whole DOS 2.0 operating system, which was written in assembly entirely, has just 37955.

Apples to oranges.

I mean, how many drivers were shipped with DOS 2.0?

nybble414• 6 years ago

Right, and how many distinct instruction set architectures did DOS 2.0 support? The fact that there are only 225k lines of assembly in the Linux kernel, across the 30 or so major architecture families Linux supports plus any number of variations within each family, is rather impressive. If you ported DOS 2.0 to one variant of each of those 30 architectures, assuming roughly equal code density, that would be over a million lines of assembly code altogether, for a far, far less capable system. That's considering only the OS core, not device drivers, which is reasonable since DOS 2.0 didn't really have any drivers worth speaking of by modern standards. Most of the real low-level I/O was handled by the BIOS.

zamadatix3• 6 years ago

I think you're reading the comment backwards from intent. To me this comment is just pointing that while the vast majority of the Linux kernel C it supports so much stuff it still has an order of magnitude more assembly than old operating systems that were 100% written in assembly.

Yes, apples to oranges... but interestingly so not as a knock that DOS was coded better or something.

anaganisk• 6 years ago

But cant it run Crysis on Ultra at 120FPS?

armatav4• 6 years ago

And they still don't work.

armatav4• 6 years ago

Downvote all you want - AMD OS drivers still do not work. Even the proprietary drivers do not work.

The driver has had issues for ages with AMDs new cards. Guaranteed if you’re downvoting this you have no used a recent AMD card on Linux.

Jweb_Guru• 6 years ago

As someone developing a cross-platform game engine, the AMD Linux drivers perform quite well, notably better than many proprietary Windows drivers do, both from a performance and stability perspective.

ranger207• 6 years ago

What doesn't work? I have a 5700XT and it seems to be fine to me. What am I missing?

oblio3• 6 years ago

I find it funny that developers (especially less experienced ones?) are so fascinated with the "big size" of the Linux kernel. I've seen this in various discussions, both online and offline.

By commercial standards, the Linux kernel is really small. The average enterprise application which has been in development for that long (almost 30 years) usually has at least several million lines of code, if not tens of millions or more.

User facing functionality is HUGE in size compared to tech functionality, usually.

nybble414• 6 years ago

The size is impressive relative to other kernels. A line of kernel code is much more expensive to develop than a line of application code. Of course, size is not be best metric by which to judge a project; it's always better to have more capability with less code if you can manage it. For its size Linux supports quite a wide variety of architectures and add-on hardware. Also, a great deal of effort goes into keeping the kernel codebase maintainable, which is more likely to manifest as lines of code removed rather than added.

marcan_424• 6 years ago

Linux is the only kernel in the world with wide-ranging hardware support (due to its development policy). Everything else is either orders of magnitude more niche and only supports a tiny subset of hardware, or has a stable ABI and relies on out of tree drivers almost exclusively (Windows). Nevermind architecture support.

No given person is ever actually running most kernel code. If you took only lines compiled into the core on an average system plus the line count of currently loaded modules, you'd come up with a much smaller number.

Polylactic_acid5• 6 years ago

A Google dev once told me that every day they write as much code as the whole kernel contains.

burntoutfire• 6 years ago

A quick math tells us that every employee (that includes non-technical people) of Google would have to write around 200 lines of code per day, which seems completely implausible in a company with a heavy software development process.

nexuist6• 6 years ago

109 lines of a "Windows Module Definition"? What's that about?

k4rli• 6 years ago

I found [this](https://old.reddit.com/r/linux/comments/2e255r/this_is_how_b...)

False positives because def and config are pretty common suffixes:

ISL• 6 years ago

What is the one sed file?

Impossible• 6 years ago

People complain about Nvidia's proprietary driver, but imagine if they opensourced all of their software stack and had it in the kernel. If AMD is 10.5%, Nvidia might be like 35% :)

mugivarra69• 6 years ago

lol, not really. 10.5% is ~ 190M. if nvidia x2 that, its 380M of code, which would mean lesser, as the deominator expands significantly, so their share falls too lool.

tkuraku3• 6 years ago

I really like that the AMD drivers are open source and up streamed into the kernel. However, that doesn't solve all the use cases. If I want to use newer hardware on an older distribution (RHEL, DEBIAN, Ubuntu LTS, etc) the upstreamed drivers will be too old. Distributing the driver like Nvidia or Radeon Software for Linux will still be necessary.

foxrider• 6 years ago

You can always install a newer kernel - thankfully Linux is notorious for never breaking the userspace as a general rule.

tkuraku3• 6 years ago

It is a reasonable thing to want to keep the kernel stable for custom kernel drivers. So stable kernel space is also important to me.

zamadatix3• 6 years ago

Either way what you're looking for is a backport, open or proprietary doesn't change that. I think it's important to note amdgpu-pro already requires amdgpu as well so "will still be necessary" has already passed.

unsignedchar• 6 years ago

The title is misleading, there is a nontrivial distinction between the Kernel and its source code.

broodbucket4• 6 years ago

My two cents as a kernel developer, the driver is pretty abominable compared to the code quality of most of the rest of the kernel.

However, having a GPU driver not just be open source but in the upstream Linux kernel is a gigantic deal. Kernel development takes a long time, we have millions of lines in the amdgpu driver, and if every one of those dealt with the lengthy review process it would have never made it in the tree.

So it's a necessary evil. I do wish they would clean it up though, I sent a fix to amdgpu once that was the same thing for 3 different files that were largely duplicated. That kind of thing wouldn't fly anywhere else in the kernel

randyrand• 6 years ago

duplication 3 times with small differences between is a good case to keep separate imo.

abstraction is one of the main sources of code complexity.

you start with one function used in 3 places, then add boolean args to it to get slightly different functionality at each place, eventually it becomes a mess of complexity

trey-jones• 6 years ago

Or you duplicate code in 3 places, and apply the same fixes or updates in 3 places for all of eternity. There are pros and cons to both methods and each have their places, no need to start this constant debate here.

broodbucket4• 6 years ago

I think that's very subjective and situational.

The amdgpu driver has duplicated files for different versions of things, so it'll have thing_v6.c and thing_v7.c and thing_v8.c with a lot of duplicated functions.

The more common way of doing something like this would be to have structs of function pointers that get populated based on what version of GPU you have. You have one file with all the common functions that they can share, in the definitions for each GPU version you set the majority of the function pointers to the common version they all share and for ones that have to be different, you set them to their unique version. That way you can define all the common functions once, and point to them in the structs for each version.

Having a quick flick through the code now, they do use structs of function pointers in each version for common operations but they still don't abstract out the ones that are either identical or have very few differences that you could special case.

Refactoring such a giant driver for no performance gain is going to be extremely low on AMD's todo list, so it'll probably stay like that. It just doesn't look like anything else in the kernel

Cthulhu_• 6 years ago

Proverb: "A little copying is better than a little dependency." (Rob Pike)

That is, it's better to have duplications than the wrong abstraction. This may also be in reference to C compilation, in that loading header files and dependencies costs more than inlined code. That's one of the goals that the Go language sought to resolve, anyway.

StavrosK4• 6 years ago

I understand how big a deal this is and want to buy an AMD card for my next PC, just to support them, but is the driver actually good? Ie, is support for AMD cards on par with Windows?

The Nvidia driver is crappy, doesn't support Optimus, etc, but at least I haven't had any problems with it for as long as I've used it.

broodbucket4• 6 years ago

At least on par. That said, the AMD driver on Windows is notoriously crap compared to Nvidia.

I'm hoping AMD's next gen turns out to be competitive with the RTX3000 series for my next GPU for the same reason.

armatav4• 6 years ago

It is not on par at all - my 5600 got annihilated by driver issues.

AMD has incredible CPUs, but just buy an Nvidia GPU - especially if you are using linux.

shmerl10• 6 years ago

It is good enough. I'd say overall Nvidia's driver is worse.

taurath2• 6 years ago

I have returned 2 Radeons that I bought for specs but returned because the drivers were bad enough that I couldn’t get the same-clock performance as Nvidia or worse dealt with driver crashes and system reboots - note that this was between 10 and 20 years ago. I am highly considering trying again at eom when they announce the new cards but that it’s a Radeon is still a downside to me.

Most of the Linux community has a historical hatred of Nvidia because of the driver issue so there’s a lot of relative love out in forums, but just “stable” would be a step up for me for Radeons on windows.

datalus• 6 years ago

AMD has caught up to Intel but still lags behind nVidia (on Windows at least). I'm just not sure they can fight a two front war. Something has to give.

hatsunearu2• 6 years ago

Not sure if this is a driver problem but there's a LOT of general usability issues on AMDGPU + Linux. The default thermal control being absolute catastrophe for one.

Teknoman117• 6 years ago

The Nvidia driver started supporting proper optimus at the begining of 2020 (can runs apps on integrated and dedicated cards simultaneously). I use it regularly on my XPS 15 (to play Kerbal Space Program). It's called "DRI PRIME". You have to set an environment variable for starting and application saying what GPU you want it to run on.

I am, however, very much looking forward to the new AMD GPUs. Hopefully the RX 6000 series will be near a 3080 in more than the 3 hand picked games in their teaser. Would love to use Wayland on my desktop.

zeta0134• 6 years ago

I bought an AMD GPU specifically for use with my Linux workstation and haven't regretted it. Perhaps I simply had bad luck with specific nVidia cards, but the AMD driver is stable in a way the nVidia driver simply never was, especially w/ respect to GPU accelerated desktop environments and screen capture utilities. The only change I made was to switch Arch over to the LTS kernel, as the upstream kernel in Arch isn't quite as battle hardened, and did occasionally require a rollback. That's not something that's likely to affect any other distro though, it's a side effect of Arch's bleeding edge nature.

Anecdotal data and all that. I'm on a Radeon VII, pretty darn solid, will probably continue to choose AMD cards in the future. Wish the Windows driver were a bit more stable, and it's... frankly weird to be saying that in comparison to the Linux driver for the same card.

djsumdog• 6 years ago

I remember back when AMD had both closed and open drivers and, having trouble with the proprietary drivers, I switched to the OSS version. It was NIGHT AND DAY. Games that would crash and had weird oddities now ran smooth with higher frame rates. A lot of weird video issues, especially those that come from running more than one X server or Xnest, all went away.

I would only use AMD cards in my Linux boxes. The nvidia drivers/cards pale in comparison.

aero-glide• 6 years ago

Have you tried Nvidia on-demand option for Optimus?

jl6• 6 years ago

Search for “amdgpu ring gfx timeout”. There seem to be a whole class of bugs that have been open for years which not only haven’t been fixed, but there isn’t even any clear indication of what the root cause(s) is/are.

sph• 6 years ago

It is not. My 5500 XT is unusable when using 2 monitors. https://gitlab.freedesktop.org/drm/amd/-/issues/929

Apparently AMD doesn't have the resources to debug these millions lines of code, since this has been open for a year now.

Yet people still say NVIDIA on Linux has issue. They don't support Wayland and tend to lag behind with Linux only tech in general, but the driver itself is top notch. I haven't had an nv driver crash on Linux in 10 years. It's only the same echo chamber borne by the famous moment of Linus flipping NVIDIA the bird.

KozmoNau72• 6 years ago

I upgraded from a Geforce 460GTX to a Radeon RX560, and I ran into two issues. Nothing major, and I've had worse issues with the Nvidia drivers, but they are still something to be aware of.

The first was that my distro (KDE Neon based on Ubuntu 18.04) shipped an older version of Mesa at the time, which was too old for the AMDGPU driver, so I had to add a PPA with an updated version. Since Neon updated to a 20.04 base, it works straight from a clean install. It also worked with no issues when I switched to openSUSE Leap 15.2.

The second was that DVI output was limited to single-link instead of dual-link. My monitor at the time only supported full 1440p through dual-link DVI or displayport, and the old GPU didn't have displayport. Buying a displayport cable was a quick fix, and I believe the DVI issue is fixed in the driver now.

Aside from those two minor hurdles, it has been smooth sailing, very good OpenGL performance in the games I play.

tracker13• 6 years ago

Wait a few months after a new GPU comes out, maybe until the next major version cycle (like if you want a new card that comes out in November, wait until the 21.04 Ubuntu/PopOS release).

I bought my RX 5700XT shortly after release, and was using alpha/beta kernel releases and downloading extra files manually for several months after to run, then an upgrade/update may turn into a blank screen on boot for me. It also broke out of the box support for running full VMs, which was pretty painful for me as well, and I wasn't going down that rabbit hole to try and build it myself.

YMMV of course.. but that's just my take on it.. I bought specifically for Linux support, but took a few months to shake out.

bdowling13• 6 years ago

the driver is pretty abominable compared to the code quality of most of the rest of the kernel.

Could you say more about what specifically makes the driver abominable? Is it just those files with largely duplicated code?

m463• 6 years ago

I would also mention that gpus are a GIANT abstraction, and since they are rev'd faster than arguably any hardware in a sytem, there are abstractions layered on top of that for the families and models of gpus too.

Another way of looking at it is -- I started playing with openwrt for a relatively small router, with 5 ports plus wifi.

I was amazed at not only the amount of openwrt code required to support the different router families and the different router models, but at the sheer amount of stuff turned on by default in the kernel just in case I might need to load a module for some obscure feature or package. I assume the same goes for a gpu driver both at the source level and in the kernel.

andromeduck4• 6 years ago

Yeah AMD/NV typically do 2-3 chips per year. That complexity adds up pretty quickly when backwards/forwards compatibility is fairly strict and the inputs/abstractions not particularly well defined or behaved.

de_watcher2• 6 years ago

Are there still workarounds for specific games/programs inside the driver?

djmips• 6 years ago

Shouldn't a GPU driver have a significant representation in the Linux Kernel? It represents a lot of the computation.

new_realist• 6 years ago

And it still doesn’t support 8K MST monitors.

kartayyar• 6 years ago

Hacker News: Nvidia is evil because they don't have an open source driver !

Also Hacker News: AMD is evil because they increase the size of the kernel by 10%.

Honestly, I think Nvidia made the right call by just focused on ordinary users who just want the card to work and can just focus on their work.

mcv• 6 years ago

Is the AMD Radeon Graphics Driver part of the Linux Kernel? Does that make sense? Aren't graphics drivers updated independently from the kernel? I'm aware that Linus isn't a fan of microkernels, but this seems a bit overly monolithic to me.

Traubenfuchs2• 6 years ago

Does something "being part of the kernel" mean it's part of every Linux distribution? Even on server distros?

lxpz• 6 years ago

"Being part of the kernel" is defined as being in the kernel's source code tree. Not all of the kernel's source code is included in a kernel binary, most pieces are compiled as modules that can be loaded at run-time. However many distribution do indeed ship the binaries for most kernel modules so some server distros like Ubuntu server probably do have GPU drivers installed, although they are never loaded.

Traubenfuchs2• 6 years ago

If the Linux kernel can be sliced and diced, what's the point in putting non-essential code, that won't be used by the majority of running systems, in the kernel?

Why not offer the driver as additional package / download?

tsegratis• 6 years ago

Isn't the implication that, to some extent they are chasing their own tail; adding features on a wobbly foundation gives wobbly features

Never looked at a single line of their code, but still presumptious enough to suggest pruning and repotting before watering the beautiful rain of more features :)

-- An idea to be fertilized with several grains of salt

known• 6 years ago

While compiling kernel

    yes '' | make localmodconfig

will create a config based on current config and loaded modules (lsmod). Disables any module option that is not needed for the loaded modules.

JoeAltmaier• 6 years ago

A kernel is supposed to be a small set of necessary code to boot and manage some hardware. It's host to drivers, applications and UIs. Thus the name, 'kernel'.

To compare a driver with the kernel proper, seems very strange. There are other large codes in the world too.

The AMD Radeon Graphics Driver Makes Up Roughly 10.5% of the Linux Kernel

Related Stories