33 ms·

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

707 points by akvadrako 6y ago

henriquez 6y 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 6y 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 6y 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.
    - izacus 6y ago
      What are you talking about? Wayland is supported on DEs that wanted to support nVidia chips. Meanwhile projects like Sway have a direct "Go to hell if you use nVidia, we won't let you run this code." It's bizarre that you blame nVidia for this.
      - PurpleFoxy 6y ago
        It’s “””supported”””. It’s apparently very buggy and very difficult to debug. Sway lets you run it after you set a flag making it very clear that if something is broken you may not report a bug since the developers are unable to reasonably fix it. Most Linux distro will also prevent you submitting a bug report for a kernel issue if you have a tainted kernel.
      - nybble41 6y ago
        It's possible to create a Wayland compositor that works with the proprietary nVidia drivers, but it requires using nVidia-specific interfaces because nVidia refuses to support the same interfaces for non-GLX, non-X11 hardware acceleration provided by every other Linux graphics driver. It's hardly surprising that a lot of Wayland compositor developers would rather not put in a ton of extra effort to add a special case for one particular set of proprietary drivers, which they would then need to maintain and support separately from the common code path.
        1_player 6y ago
        To tell the whole story, the NVIDIA argument is that they want cross platform standard interfaces (EGLStream), which would use the same code the Windows driver uses, but the Linux world is pushing for Linux-only interfaces (EGL)
        1_player 6y ago
        Typo, by Linux-only interface I meant GBM.
        nybble41 6y ago
        That may be, but the fact remains that nVidia is pushing an interface that no other Linux drivers currently support, for reasons that really only benefit them. The Linux kernel team has never been particularly supportive of middleware layers designed to promote common drivers between Linux and other operating systems, and for good reason—it impedes the development of optimized, native Linux drivers. The only way I see nVidia succeeding here is if they clearly demonstrate that EGLStreams is a technically superior alternative to GBM, not just for their own hardware but in general, and also contribute the changes needed to support EGLStreams for all the other graphics drivers currently using GBM so that applications don't need to deal with both systems. As long as the EGLStreams code path can only be exercised in combination with the proprietary nVidia drivers it will remain a second-class citizen and projects would be well-advised to avoid it. (Drew DeVault goes into more detail[1] in his objection to the inclusion of EGLStreams support in KWin, which I agree with 100%.) Or they could just acknowledge that this is a Linux driver, not a Windows driver, and implement the standard Linux GBM interfaces like everyone else even if that means less shared code. [1] https://lists.sr.ht/~sircmpwn/public-inbox/%3C20190220154143.GA31283%40homura.localdomain%3E https://lists.sr.ht/~sircmpwn/public-inbox/%3C20190220154143...
  - tomc1985 6y 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?
    - mistaken 6y ago
      Not to mention that nvidia uses proprietary configuration options even in Xorg.conf. A multi-monitor configuration which works fine in nouveau (or really any other driver) refuses to work with nvidia, because if you use the binary driver you have to set bizarre metamode options to make it work.
  - mcguire 6y 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.
    - colechristensen 6y ago
      I encountered a real fun bug where a game on linux crashed and a ghost of the game remained on the monitor even after it was connected to a different computer and power cycled, it remained for days. Some really interesting cascading bugs there.
      - cesarb 6y ago
        That reminds me of the spookiest bug I've ever encountered: once, when resuming a Dell laptop from suspend at work, it showed a Windows desktop. Said laptop had been running Linux exclusively for several months (but it had previously been used with Windows). Interacting with the laptop made the expected xscreensaver unlock screen appear, and everything worked normally afterwards. The only explanation I could come up with was that, somehow, a snapshot of the Windows screen had survived intact in a corner of the framebuffer which the Linux driver didn't touch, even after months of power off/on and suspend/resume cycles, and a bizarre driver glitch made it visible in that particular resume cycle.
        ateng 6y ago
        The said windows desktop ghost screen didn’t have date time on start menu, did it?
        cesarb 6y ago
        If I recall correctly, the Windows XP default was to show only the time, so the date probably wasn't visible.
      - marcan_42 6y ago
        That's not a software bug, that's an image retention issue with your monitor. If it was that severe then it probably got into a state where it was sending severely invalid timings to the TFT LCD array, DC biasing it, which causes long-term retention and may even cause permanent damage if done for too long. Software isn't supposed to be able to cause that. That's on your monitor.
  - Nullabillity 6y ago
    I still haven't been able to get my laptop's 1660Ti to display anything else than glitch art, proprietary or nouveau.
  - PurpleFoxy 6y 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.
    - wang_li 6y ago
      You could just as easily blame the author of the driver that only works on a prerelease kernel.
  - asddubs 6y 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
- deleted 6y ago
  [deleted]
- etaioinshrdlu 6y 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.
  - amelius 6y 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?
    - sandworm101 6y ago
      lol. When was the last time anyone actually bought a copy of software? You own nothing. You are a party to a contract written by nvidia and signed by you when you installed their driver. You can do only what they allow and they can yank thier permission whenever they see fit. Not happy? That is what makes FOSS so appealing.
      - vbezhenar 6y ago
        > When was the last time anyone actually bought a copy of software? Satya Nadella bought Skyrim recently. All of it.
        jackvalentine 6y ago
        Skyrim includes licensed code such as Bink Video.
- chrisseaton 6y 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 6y 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?
    - skissane 6y ago
      The original Equation Editor was licensed from a third party (Design Science), and it is possible that Microsoft never had the source code. Maybe the third party vendor lost the source code, but I think it is more likely that getting the third party vendor to fix the bug would have required negotiation with that vendor, and maybe Microsoft and that vendor were having trouble agreeing. (This is speculation on my part, I have no inside info.)
      - jamiek88 6y ago
        Or equally likely, that vendor no longer exists.
        easton 6y ago
        Likely, perhaps, but not true, since they still exist: https://www.dessci.com/en/ https://www.dessci.com/en/ Microsoft probably started wondering internally why they don't just write their own equation editor, but didn't have time, so decided to do a crazy patch to this one and then start on a rewrite.
  - MayeulC 6y 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.
- paulmd 6y 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_nexus_the_real_problem_with_rtx_3080/g734l93/ 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 6y ago
  Are they really that afraid of someone taking their Lucky Charms? They're afraid of patent trolls.
- severino 6y 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 https://gitlab.freedesktop.org/drm/amd/-/issues
  - Aeolun 6y ago
    Providing support for a marginal platform is also much harder when you’re <0.1 times the size.
  - shmerl 6y 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.
    - severino 6y ago
      > It's shame, because they hinder the progress of Linux desktop and prevent Nouveau from reclocking properly. I think it's the opposite. Some years ago, Nvidia was your only chance to have accelerated graphics on Linux. ATI/AMD didn't care about it at all, and Intel cards were not for gaming. So Nvidia made it possible to do things in Linux when nobody else allowed you to... how's that hindering the progress of anything? Specially when nobody forces you to get an Nvidia card. > 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. Yes, I didn't say Nvidia was bug free. I just said AMD drivers for Linux are, at the moment, far from perfect, despite being opensource. I'd say, for newer cards, they're worse than Nvidia's. I value opensource, but if I have to choose between having an opensource desktop crashing twice a day, vs. the Nvidia blob, of course I'd go for the latter, as much as I'd love to have a fully opensource OS.
- javchz 6y ago
  That's my dream... or in a short time frame at least wayland support.
amelius 6y ago
In source code, or in compiled bytes?
- tomcam 6y ago
  According to the first line of the second paragraph, it is source code
  - capableweb 6y ago
    Or just the huge output from cloc that is showing the count of lines of code.
  - amelius 6y ago
    It turns out that it's generated source code. So the actual source code may be substantially smaller.
    - _chris_ 6y ago
      Are they also open-sourcing the tool that generates the committed code? If not, then there's little difference between "generated" and "actual" source code.
atq2119 6y 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/linux.git/tree/drivers/gpu/drm/amd/amdgpu?h=v5.9-rc8 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- pantalaimon 6y 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.
  - tylerhou 6y ago
    Compile times increase superlinearly with program size. How many cycles and developer hours are wasted if this duplication is not necessary?
    - mcguire 6y ago
      "Compile times increase superlinearly with program size." I've seen this said a couple of times lately. What is the source?
      - saagarjha 6y ago
        Internal compiler datastructures and the need to keep more things in memory?
        jchw 6y ago
        This particular thought thread is about more translation units, not larger translation units. I can't see why those would not mostly scale linearly.
chrisseaton 6y ago
83k lines of YAML. Wow.
tinco 6y ago
What percentage of the Linux kernel is actually still there after you run it through the preprocessor on a modern system?
- jws 6y 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 https://www.leshatton.org/Documents/LOC2005.pdf
  - dodobirdlord 6y 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.
    - mgharrisdc 6y ago
      https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/ https://aws.amazon.com/blogs/opensource/firecracker-open-sou...
znpy 6y 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 6y 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 6y ago
  Why not generate it during the build? Is there a good reason not to do that?
  - stefan_ 6y 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.
    - nathell 6y ago
      Not for the build itself, but there are Perl and Python scripts in the kernel source, which are referenced by the kernel's main Makefile.
    - Ar-Curunir 6y ago
      If you don’t want to use languages that enable code reuse, then you can’t complain about repeated code
  - barumi 6y 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.
  - ploxiln 6y 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.
loop0 6y ago
Honest question: why these gpu drivers need some many lines of code? Anybody with more background can explain?
- bleepblorp 6y ago
  GPU drivers are essentially operating systems for the GPU.
  - deleted 6y ago
    [deleted]
  - extropy 6y ago
    And also ~real time compilers for any user code (shaders, etc) that will be running on the GPU.
    - monocasa 6y ago
      The compiler isn't in the kernel though. That's in the user space half.
- detaro 6y 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.
- deleted 6y ago
  [deleted]
radium3d 6y 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 https://gitlab.gnome.org/GNOME/mutter/-/issues/1108 Hopefully not for long though with this https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=95f29c0b5105e80b9cfdd1bd706e1ed4f9af9743 https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-stag...
- blunte 6y ago
  So does my latest macos with intel video and second monitor.
  - ysleepy 6y 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.
- pantalaimon 6y 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 6y ago
    Is it a really good VGA monitor or something? You can buy relatively inexpensive active DVI/HDMI to VGA converters if that helps.
    - pantalaimon 6y ago
      > Is it a really good VGA monitor or something? Not at all. It's an old 19" with a resolution of 1280x1024, you can get those pretty much for free these days. But hey, n + 1 screens > n screens :D I usually just have my browser on it in full screen. And because of the resolution I don't have to worry about overly long lines on websites that aren't restricted in with (like hacker news). At work I picked up an old 19" TFT from the trash that connects neatly to the unused VGA port of the docking station. It has abysmal ghosting issues, so it's no use for the browser, but still good enough for a terminal. With modern graphics cards supporting many outputs and monitors that you can literally get for free, you can have the luxury of dedicating a display to a single task or application, so that's pretty cool.
blunte 6y ago
It is another highly complex computer after all.
mey 6y 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?
- detaro 6y 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.
  - deaddodo 6y 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.
    - mey 6y ago
      There is a significant difference between having a supported defined interface boundary, and a semi-stable interface that doesn't necessarily guarantee backwards comparability to prior interfaces.
      - deaddodo 6y ago
        > There is a significant difference between having a supported defined interface boundary Which is literally the delineating mark between an API and and ABI. A stable ABI means your binary interface will remain the same and your compiled drivers should work, despite any changes on the kernel level. A stable API means you'll probably have to recompile your drivers when the kernel changes, but that they'll require little (if any) modifications.
        dTal 6y ago
        A stable API means you will definitely not have to make any modifications, and Linux provides no such guarantees. "Pretty" standard and stable is not the same at all.
cardiffspaceman 6y ago
What percentage of loaded and running binary is it?
- edoceo 6y ago
  0% on mine (cause I'm on Intel and Nvidia HW) and have a custom kernel config.
  - yjftsjthsd-h 6y 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.
    - cardiffspaceman 6y ago
      This is what I was interested in. As I understand it, there are extra drivers in most installs and this is reconciled as the kernel boots.
      - edoceo 6y ago
        Correct. A bare kernel to get to an initrd. That loads the rest of the modules is the common distro pattern. I build a kernel w/o initrd, only my necessary hardware and then only modules I need. It's pretty easy, boots fast, stable, etc. But, I'm already a type-A for my work-box (Gentoo)
      - yjftsjthsd-h 6y ago
        I mean, you can just run lsmod to see what modules are loaded; I don't think that lists anything that's statically compiled in, but most distros don't really do that AFAIK.
notaplumber 6y 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 6y 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.
- barumi 6y 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?
  - nybble41 6y 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.
    - barumi 6y ago
      > 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. Except that's not the intent that's conveyed by blindly throwing LoC numbers into the air. The intent is to suggest the exact opposite: bloat. Hence the blind comparisons that mean nothing at all.
  - zamadatix 6y 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.
armatav 6y ago
And they still don't work.
- armatav 6y 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.
  - ranger207 6y ago
    What doesn't work? I have a 5700XT and it seems to be fine to me. What am I missing?
  - Jweb_Guru 6y 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.
oblio 6y 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.
- nybble41 6y 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_42 6y 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_acid 6y ago
  A Google dev once told me that every day they write as much code as the whole kernel contains.
  - burntoutfire 6y 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.
nexuist 6y ago
109 lines of a "Windows Module Definition"? What's that about?
- k4rli 6y ago
  I found [this](https://old.reddit.com/r/linux/comments/2e255r/this_is_how_big_is_the_linux_kernel/cjvf359/ https://old.reddit.com/r/linux/comments/2e255r/this_is_how_b...) > False positives because def and config are pretty common suffixes:
ISL 6y ago
What is the one sed file?
Impossible 6y 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 6y 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.
tkuraku 6y 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 6y ago
  You can always install a newer kernel - thankfully Linux is notorious for never breaking the userspace as a general rule.
  - tkuraku 6y 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.
    - josephcsible 6y ago
      The "custom kernel drivers" are the problem. Whatever they are, they should be upstreamed too. Trying to keep a stable ABI just causes problems.
      - tkuraku 6y ago
        That might be an ok solution for consumer devices, but the kernel drivers I'm talking about are for custom setups that will only be used internally by me. There would never be any reason to upstream them. Constantly upgrading the kernel just creates a lot of work.
- zamadatix 6y 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 6y ago
The title is misleading, there is a nontrivial distinction between the Kernel and its source code.
broodbucket 6y 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 6y 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 6y 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.
    - shadowgovt 6y ago
      That's why this approach can tend to be a positive for driver versions matched to hardware iterations: a given fix may or may not apply to a given hardware config, and likely has to be tested against each config separately. It's one of the unusual circumstances where, unfortunately, abstraction can decrease flexibility and increase development time.
  - broodbucket 6y 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
deleted 6y ago
[deleted]
djmips 6y ago
Shouldn't a GPU driver have a significant representation in the Linux Kernel? It represents a lot of the computation.
new_realist 6y ago
And it still doesn’t support 8K MST monitors.
kartayyar 6y 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 6y 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.
Traubenfuchs 6y ago
Does something "being part of the kernel" mean it's part of every Linux distribution? Even on server distros?
- lxpz 6y 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.
  - Traubenfuchs 6y 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?
JoeAltmaier 6y 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.
tsegratis 6y 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 6y 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.

707 points by akvadrako 6y 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 6y 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 6y 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.
  - izacus 6y ago
    What are you talking about? Wayland is supported on DEs that wanted to support nVidia chips. Meanwhile projects like Sway have a direct "Go to hell if you use nVidia, we won't let you run this code." It's bizarre that you blame nVidia for this.
    - PurpleFoxy 6y ago
      It’s “””supported”””. It’s apparently very buggy and very difficult to debug. Sway lets you run it after you set a flag making it very clear that if something is broken you may not report a bug since the developers are unable to reasonably fix it. Most Linux distro will also prevent you submitting a bug report for a kernel issue if you have a tainted kernel.
    - nybble41 6y ago
      It's possible to create a Wayland compositor that works with the proprietary nVidia drivers, but it requires using nVidia-specific interfaces because nVidia refuses to support the same interfaces for non-GLX, non-X11 hardware acceleration provided by every other Linux graphics driver. It's hardly surprising that a lot of Wayland compositor developers would rather not put in a ton of extra effort to add a special case for one particular set of proprietary drivers, which they would then need to maintain and support separately from the common code path.
      - 1_player 6y ago
        To tell the whole story, the NVIDIA argument is that they want cross platform standard interfaces (EGLStream), which would use the same code the Windows driver uses, but the Linux world is pushing for Linux-only interfaces (EGL)
        1_player 6y ago
        Typo, by Linux-only interface I meant GBM.
        nybble41 6y ago
        That may be, but the fact remains that nVidia is pushing an interface that no other Linux drivers currently support, for reasons that really only benefit them. The Linux kernel team has never been particularly supportive of middleware layers designed to promote common drivers between Linux and other operating systems, and for good reason—it impedes the development of optimized, native Linux drivers. The only way I see nVidia succeeding here is if they clearly demonstrate that EGLStreams is a technically superior alternative to GBM, not just for their own hardware but in general, and also contribute the changes needed to support EGLStreams for all the other graphics drivers currently using GBM so that applications don't need to deal with both systems. As long as the EGLStreams code path can only be exercised in combination with the proprietary nVidia drivers it will remain a second-class citizen and projects would be well-advised to avoid it. (Drew DeVault goes into more detail[1] in his objection to the inclusion of EGLStreams support in KWin, which I agree with 100%.) Or they could just acknowledge that this is a Linux driver, not a Windows driver, and implement the standard Linux GBM interfaces like everyone else even if that means less shared code. [1] https://lists.sr.ht/~sircmpwn/public-inbox/%3C20190220154143.GA31283%40homura.localdomain%3E https://lists.sr.ht/~sircmpwn/public-inbox/%3C20190220154143...
- tomc1985 6y 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?
  - mistaken 6y ago
    Not to mention that nvidia uses proprietary configuration options even in Xorg.conf. A multi-monitor configuration which works fine in nouveau (or really any other driver) refuses to work with nvidia, because if you use the binary driver you have to set bizarre metamode options to make it work.
- mcguire 6y 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.
  - colechristensen 6y ago
    I encountered a real fun bug where a game on linux crashed and a ghost of the game remained on the monitor even after it was connected to a different computer and power cycled, it remained for days. Some really interesting cascading bugs there.
    - cesarb 6y ago
      That reminds me of the spookiest bug I've ever encountered: once, when resuming a Dell laptop from suspend at work, it showed a Windows desktop. Said laptop had been running Linux exclusively for several months (but it had previously been used with Windows). Interacting with the laptop made the expected xscreensaver unlock screen appear, and everything worked normally afterwards. The only explanation I could come up with was that, somehow, a snapshot of the Windows screen had survived intact in a corner of the framebuffer which the Linux driver didn't touch, even after months of power off/on and suspend/resume cycles, and a bizarre driver glitch made it visible in that particular resume cycle.
      - ateng 6y ago
        The said windows desktop ghost screen didn’t have date time on start menu, did it?
        cesarb 6y ago
        If I recall correctly, the Windows XP default was to show only the time, so the date probably wasn't visible.
    - marcan_42 6y ago
      That's not a software bug, that's an image retention issue with your monitor. If it was that severe then it probably got into a state where it was sending severely invalid timings to the TFT LCD array, DC biasing it, which causes long-term retention and may even cause permanent damage if done for too long. Software isn't supposed to be able to cause that. That's on your monitor.
- Nullabillity 6y ago
  I still haven't been able to get my laptop's 1660Ti to display anything else than glitch art, proprietary or nouveau.
- PurpleFoxy 6y 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.
  - wang_li 6y ago
    You could just as easily blame the author of the driver that only works on a prerelease kernel.
- asddubs 6y 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
deleted 6y ago
[deleted]
etaioinshrdlu 6y 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.
- amelius 6y 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?
  - sandworm101 6y ago
    lol. When was the last time anyone actually bought a copy of software? You own nothing. You are a party to a contract written by nvidia and signed by you when you installed their driver. You can do only what they allow and they can yank thier permission whenever they see fit. Not happy? That is what makes FOSS so appealing.
    - vbezhenar 6y ago
      > When was the last time anyone actually bought a copy of software? Satya Nadella bought Skyrim recently. All of it.
      - jackvalentine 6y ago
        Skyrim includes licensed code such as Bink Video.
chrisseaton 6y 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 6y 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?
  - skissane 6y ago
    The original Equation Editor was licensed from a third party (Design Science), and it is possible that Microsoft never had the source code. Maybe the third party vendor lost the source code, but I think it is more likely that getting the third party vendor to fix the bug would have required negotiation with that vendor, and maybe Microsoft and that vendor were having trouble agreeing. (This is speculation on my part, I have no inside info.)
    - jamiek88 6y ago
      Or equally likely, that vendor no longer exists.
      - easton 6y ago
        Likely, perhaps, but not true, since they still exist: https://www.dessci.com/en/ https://www.dessci.com/en/ Microsoft probably started wondering internally why they don't just write their own equation editor, but didn't have time, so decided to do a crazy patch to this one and then start on a rewrite.
- MayeulC 6y 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.
paulmd 6y 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_nexus_the_real_problem_with_rtx_3080/g734l93/ 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 6y ago
Are they really that afraid of someone taking their Lucky Charms? They're afraid of patent trolls.
severino 6y 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 https://gitlab.freedesktop.org/drm/amd/-/issues
- Aeolun 6y ago
  Providing support for a marginal platform is also much harder when you’re <0.1 times the size.
- shmerl 6y 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.
  - severino 6y ago
    > It's shame, because they hinder the progress of Linux desktop and prevent Nouveau from reclocking properly. I think it's the opposite. Some years ago, Nvidia was your only chance to have accelerated graphics on Linux. ATI/AMD didn't care about it at all, and Intel cards were not for gaming. So Nvidia made it possible to do things in Linux when nobody else allowed you to... how's that hindering the progress of anything? Specially when nobody forces you to get an Nvidia card. > 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. Yes, I didn't say Nvidia was bug free. I just said AMD drivers for Linux are, at the moment, far from perfect, despite being opensource. I'd say, for newer cards, they're worse than Nvidia's. I value opensource, but if I have to choose between having an opensource desktop crashing twice a day, vs. the Nvidia blob, of course I'd go for the latter, as much as I'd love to have a fully opensource OS.
javchz 6y ago
That's my dream... or in a short time frame at least wayland support.

amelius 6y ago

In source code, or in compiled bytes?

tomcam 6y ago
According to the first line of the second paragraph, it is source code
- capableweb 6y ago
  Or just the huge output from cloc that is showing the count of lines of code.
- amelius 6y ago
  It turns out that it's generated source code. So the actual source code may be substantially smaller.
  - _chris_ 6y ago
    Are they also open-sourcing the tool that generates the committed code? If not, then there's little difference between "generated" and "actual" source code.

atq2119 6y 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/linux.git/tree/drivers/gpu/drm/amd/amdgpu?h=v5.9-rc8 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

pantalaimon 6y 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.
- tylerhou 6y ago
  Compile times increase superlinearly with program size. How many cycles and developer hours are wasted if this duplication is not necessary?
  - mcguire 6y ago
    "Compile times increase superlinearly with program size." I've seen this said a couple of times lately. What is the source?
    - saagarjha 6y ago
      Internal compiler datastructures and the need to keep more things in memory?
      - jchw 6y ago
        This particular thought thread is about more translation units, not larger translation units. I can't see why those would not mostly scale linearly.

chrisseaton 6y ago

83k lines of YAML. Wow.

tinco 6y ago

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

jws 6y 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 https://www.leshatton.org/Documents/LOC2005.pdf
- dodobirdlord 6y 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.
  - mgharrisdc 6y ago
    https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/ https://aws.amazon.com/blogs/opensource/firecracker-open-sou...

znpy 6y 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 6y 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 6y ago
Why not generate it during the build? Is there a good reason not to do that?
- stefan_ 6y 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.
  - nathell 6y ago
    Not for the build itself, but there are Perl and Python scripts in the kernel source, which are referenced by the kernel's main Makefile.
  - Ar-Curunir 6y ago
    If you don’t want to use languages that enable code reuse, then you can’t complain about repeated code
- barumi 6y 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.
- ploxiln 6y 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.

loop0 6y ago

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

bleepblorp 6y ago
GPU drivers are essentially operating systems for the GPU.
- deleted 6y ago
  [deleted]
- extropy 6y ago
  And also ~real time compilers for any user code (shaders, etc) that will be running on the GPU.
  - monocasa 6y ago
    The compiler isn't in the kernel though. That's in the user space half.
detaro 6y 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.
deleted 6y ago
[deleted]

radium3d 6y 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 https://gitlab.gnome.org/GNOME/mutter/-/issues/1108 Hopefully not for long though with this https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=95f29c0b5105e80b9cfdd1bd706e1ed4f9af9743 https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-stag...

blunte 6y ago
So does my latest macos with intel video and second monitor.
- ysleepy 6y 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.
pantalaimon 6y 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 6y ago
  Is it a really good VGA monitor or something? You can buy relatively inexpensive active DVI/HDMI to VGA converters if that helps.
  - pantalaimon 6y ago
    > Is it a really good VGA monitor or something? Not at all. It's an old 19" with a resolution of 1280x1024, you can get those pretty much for free these days. But hey, n + 1 screens > n screens :D I usually just have my browser on it in full screen. And because of the resolution I don't have to worry about overly long lines on websites that aren't restricted in with (like hacker news). At work I picked up an old 19" TFT from the trash that connects neatly to the unused VGA port of the docking station. It has abysmal ghosting issues, so it's no use for the browser, but still good enough for a terminal. With modern graphics cards supporting many outputs and monitors that you can literally get for free, you can have the luxury of dedicating a display to a single task or application, so that's pretty cool.

blunte 6y ago

It is another highly complex computer after all.

mey 6y 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?

detaro 6y 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.
- deaddodo 6y 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.
  - mey 6y ago
    There is a significant difference between having a supported defined interface boundary, and a semi-stable interface that doesn't necessarily guarantee backwards comparability to prior interfaces.
    - deaddodo 6y ago
      > There is a significant difference between having a supported defined interface boundary Which is literally the delineating mark between an API and and ABI. A stable ABI means your binary interface will remain the same and your compiled drivers should work, despite any changes on the kernel level. A stable API means you'll probably have to recompile your drivers when the kernel changes, but that they'll require little (if any) modifications.
      - dTal 6y ago
        A stable API means you will definitely not have to make any modifications, and Linux provides no such guarantees. "Pretty" standard and stable is not the same at all.

cardiffspaceman 6y ago

What percentage of loaded and running binary is it?

edoceo 6y ago
0% on mine (cause I'm on Intel and Nvidia HW) and have a custom kernel config.
- yjftsjthsd-h 6y 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.
  - cardiffspaceman 6y ago
    This is what I was interested in. As I understand it, there are extra drivers in most installs and this is reconciled as the kernel boots.
    - edoceo 6y ago
      Correct. A bare kernel to get to an initrd. That loads the rest of the modules is the common distro pattern. I build a kernel w/o initrd, only my necessary hardware and then only modules I need. It's pretty easy, boots fast, stable, etc. But, I'm already a type-A for my work-box (Gentoo)
    - yjftsjthsd-h 6y ago
      I mean, you can just run lsmod to see what modules are loaded; I don't think that lists anything that's statically compiled in, but most distros don't really do that AFAIK.

notaplumber 6y 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 6y 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.

barumi 6y 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?
- nybble41 6y 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.
  - barumi 6y ago
    > 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. Except that's not the intent that's conveyed by blindly throwing LoC numbers into the air. The intent is to suggest the exact opposite: bloat. Hence the blind comparisons that mean nothing at all.
- zamadatix 6y 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.

armatav 6y ago

And they still don't work.

armatav 6y 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.
- ranger207 6y ago
  What doesn't work? I have a 5700XT and it seems to be fine to me. What am I missing?
- Jweb_Guru 6y 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.

oblio 6y 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.

nybble41 6y 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_42 6y 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_acid 6y ago
A Google dev once told me that every day they write as much code as the whole kernel contains.
- burntoutfire 6y 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.

nexuist 6y ago

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

k4rli 6y ago
I found [this](https://old.reddit.com/r/linux/comments/2e255r/this_is_how_big_is_the_linux_kernel/cjvf359/ https://old.reddit.com/r/linux/comments/2e255r/this_is_how_b...) > False positives because def and config are pretty common suffixes:

ISL 6y ago

What is the one sed file?

Impossible 6y 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 6y 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.

tkuraku 6y 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 6y ago
You can always install a newer kernel - thankfully Linux is notorious for never breaking the userspace as a general rule.
- tkuraku 6y 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.
  - josephcsible 6y ago
    The "custom kernel drivers" are the problem. Whatever they are, they should be upstreamed too. Trying to keep a stable ABI just causes problems.
    - tkuraku 6y ago
      That might be an ok solution for consumer devices, but the kernel drivers I'm talking about are for custom setups that will only be used internally by me. There would never be any reason to upstream them. Constantly upgrading the kernel just creates a lot of work.
zamadatix 6y 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 6y ago

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

broodbucket 6y 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 6y 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 6y 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.
  - shadowgovt 6y ago
    That's why this approach can tend to be a positive for driver versions matched to hardware iterations: a given fix may or may not apply to a given hardware config, and likely has to be tested against each config separately. It's one of the unusual circumstances where, unfortunately, abstraction can decrease flexibility and increase development time.
- broodbucket 6y 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

deleted 6y ago

[deleted]

djmips 6y ago

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

new_realist 6y ago

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

kartayyar 6y 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 6y 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.

Traubenfuchs 6y ago

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

lxpz 6y 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.
- Traubenfuchs 6y 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?

JoeAltmaier 6y 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.

tsegratis 6y 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 6y 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.