8 ms·
AMD Open-Source GPU Kernel Driver Above 5M Lines, Entire Linux Kernel at 34.8M
- 1-6 3y ago"Of course, much of that is auto-generated header files... A large portion of it with AMD continuing to introduce new auto-generated header files with each new generation/version of a given block. These verbose header files has been AMD's alternative to creating exhaustive public documentation on their GPUs that they were once known for." So what's the point of saying that it's large?
- dijit 3y agoI read it as a bit of a negative situation. So the reason for mentioning it is to shame AMD into doing a more correct or sane thing instead of spewing out enormous amounts of what is basically repetitive noise. Pointing out that enormity is important because source files need to be stored; interpreted, versioned and parsed by humans/IDE's. It has an externalised cost (but, then again, isn't capitalism all about externalising costs?)
- throwaway193439 3y agoBecause it's large and large is difficult to maintain. AMD maintains it but do we know how they are generated? Probably not. It's like a gift that stinks but you can't complain about because it's a gift.
- FirmwareBurner 3y ago>but do we know how they are generated? Probably not Having worked in the semi industry, I can fathom a guess: It's a spaghetti mess of cascading Perl scripts that parse the Verilog/VHDL design files, with their development going back 20+ years, full of comments like "don't touch this line because it breaks another line, nobody knows why", and maintained by a team where a gray-beard "Gandalf" engineer wearing an ATI t-shirt, has most of the deep-down low-level knowledge on how to un-fuck them whenever they get fucked, pardon my french.
- baq 3y agoHaving too worked in the semi industry, this is spot on
- sshine 3y agoI haven’t worked in the semi industry, but I’ve worked with EE’s and Perl programmers, and they do love that undocumented lore. And the universe does reward you with a grey beard after enough Perl.
- trws 3y agoI have not seen these scripts, but can confirm that AMD has a long history of such Perl scripts. Look at hipcc for a current, moderately frustrating, example of this. Also the last time I met one of the open source driver team in person he was, in fact, wearing a classic ATI red ATI t-shirt straight in from Markham. Much of that team is European now though from what I hear, and they’re generally a good bunch.
- FirmwareBurner 3y ago>ATI t-shirt straight in from Markham. Curious how much of AMD Radeon GPU development now is being done in Markham-Canada, as AFAIK, the modern Radeon architecture stems from ATI's acquisition of ArtX[1], a US-based spin-ff of SGI, which was responsible for the GPUs in the Nintendo GameCube, Wii and many other innovations like programable shaders, later found in ATI/AMD GPUs. >Much of that team is European now though from what I hear, and they’re generally a good bunch. I didn't know AMD has a GPU design team in Europe. Where? I know they had a fab in Germany and they have an office for the Ryzen and Infinity Fabric R&D in Romania, but I had no idea they do GPU stuff as well in Europe. Where is that office? [1] https://en.wikipedia.org/wiki/ArtX https://en.wikipedia.org/wiki/ArtX
- ahartmetz 3y ago>I didn't know AMD has a GPU design team in Europe AFAIK they don't, but the Linux driver guys seem to be mostly German and Polish and such. And yeah, they are doing good work. I half-expect AMD to reboot their Windows driver from the Linux driver code base at some point.
- SXX 3y ago> AMD maintains it but do we know how they are generated? Probably not. Basically those files are generated from AMD GPU register data files where majorify of registers are documented, but there of course bunch of magic numbers as well probably because they belong to HDCP or other cases where documentation only available under NDA. There been a number of leaks of AMD internal documentation so anyone who is into GPU drivers can really find a lot of information on their GPU internal workings. I've archieved some of it many years ago and it's was never DMCA*ed: https://github.com/ArseniyShestakov/rai-bonaire https://github.com/ArseniyShestakov/rai-bonaire Source was a talk on CCC.
- somat 3y agoThe openbsd situation is even worse. over there the driver is bigger than the rest of the kernel. Don't get me wrong I use the driver every day and AMD is definitely one of the good guys for making an open source driver and them who ported it are absolute heros. However.... Sometimes I wish AMD had tied down the isa to their cards a little better. Narrowed the interface if you would. because as it is the driver is so big because there is this combinatorial explosion of generated header files. https://flak.tedunangst.com/post/watc https://flak.tedunangst.com/post/watc
- Laaas 3y agoThe issue is that the generated code is checked in. Surely there's a better solution.
- tux3 3y agoThey _could_ in theory post the (no doubt) Perl scripts that generate those headers from the HDL along with the relevant source files, but I imagine that would be a _very_ hard sell. And probably not much more helpful to the kernel, as no one reads those headers anyways, and the compile time will not improve by shuffling where the generation step happens. It may be more practical to rework the scripts to try to find ways to reduce the verbosity and redundancy. The actual .c driver code probably doesn't need every copy of every lines in all those .h files.
- alfalfasprout 3y agoAs long as it's deterministic there should be no issue checking in the generators right?
- tux3 3y agoThe generators themselves probably not, but the definition of all those registers is from hardware. These kind of code generators convert input source files that describe the hardware into C header files for the software. But I expect AMD would be skittish about open-sourcing anything that could even remotely be construed as HDL, even if it's just dry lists of registers. Open sourcing the drivers is one thing, but the hardware itself is another.
- pixelesque 3y agoIt's not completely clear from the article, but: are the files generated 'on-the-fly' during the build process (and therefore not in git), or generated once (by AMD), and then committed?
- Kab1r 3y agoI would much rather have a large amount of in-tree driver source over a small driver with a "large" firmware binary.
- Thaxll 3y agoLinux kernel is not made of 34M loc, most of it is drivers which I hardly consider kernel code.
- agloe_dreams 3y agoI'm not sure I get why the comparison to the Kernel is needed. GPUs are wildly complex. Rendering is wildly complex. Managing memory and data is complex. Managing connected hardware is complex. I am not sure why anyone would expect a GPU Driver to be small while also doing a billion things and playing games as well as mature gaming platforms.
- harry8 3y agoIf you're not intimately familiar with GPU drivers and what goes on this gives you a very quick, back-of-the-envelope of the size and complexity of the work involved. 1/7th the size and complexity of the kernel for this one driver. I raised an eyebrow but I have only the vaguest notion of how the hardware works and what a driver might have to manage.
- dralley 3y agoAs the article pointed out, the vast majority of the lines of code in the driver are autogenerated header files for things like defining hardware registers. There's not much complexity or logic in that type of code. Probably if AMD wanted to spend the time, they could compress it down to a fraction of it's current size.
- jmole 3y agoRight, if you have 7 different architectures, each with it's own register map, and then model-specific tweaks, you're going to have a ton of code like that.
- undersuit 3y agoWe could just compile it into a proprietary blob like Nvidia! /s
- benlwalker 3y agoIs it really that much code? I don't know GPU hardware, but the NVMe spec header file in SPDK is around 4k lines[0]. If there's 7 of them and they're twice as complicated each, we're still well under 100k from register map headers. I didn't actually look through Linux to see how big they are, so maybe it is that much more complex. 0: https://github.com/spdk/spdk/blob/master/include/spdk/nvme_spec.h https://github.com/spdk/spdk/blob/master/include/spdk/nvme_s...
- trevithick 3y agoDoes a graphical representation of the files in the Linux kernel exist anywhere? Like a graphical file explorer but for the different kernel components.
- fooker 3y agoYeah the files are organized into a directory hierarchy, pretty cool tech! :-) And there are great tools for exploring directories of files, my current favorite is dolphin with two or three panes.
- Sjonny 3y agoyou can run windirstat (or similar tool) on a checkout to get an idea
- trevithick 3y agoYeah, I guess this is the answer. When I posted the question I had this[1] in mind, and was thinking of something like that with simplified labels maybe. But I guess the file structure is so organized it would explain itself to anyone interested in this kind of thing. [1] https://upload.wikimedia.org/wikipedia/commons/d/d5/GNOME_Disk_Usage_Analyzer_Tree_View.png https://upload.wikimedia.org/wikipedia/commons/d/d5/GNOME_Di...
- pavon 3y agoWikipedia has a graph showing high-level breakdown of the kernel tree, and the size of the components[1] [1] https://en.wikipedia.org/wiki/Linux_kernel#/media/File:Sankey_Diagram_of_Linux_Kernel_Source_Lines_of_Code.jpg https://en.wikipedia.org/wiki/Linux_kernel#/media/File:Sanke...
- mrweasel 3y agoSo while the AMD driver is open source, the community is basically excluded from contributing? Should someone decided that they'd start working through the code, removing duplicate code and clean up headers, functions and abstraction, they work would either be rejected, or undone with the next AMD code dump?
- kube-system 3y agoA lot of open source projects work that way. Open source means you get access to the source and get to make changes for your own use. It doesn't mean you get to force anyone else to merge your code.
- mrweasel 3y ago> It doesn't mean you get to force anyone else to merge your code. Sure, you can fork the code if you really feel that strongly about it. My main "issue" is that it basically removes one of the big benefits of open source, that we can collaborate and do better as a collective. If it's just a big code dump that other kernel developers can't really touch it's more "source code is available" than actual open source.
- acrispino 3y agoIt's not open source unless you can have it your way? That's too picky, for me
- kube-system 3y agoOpen source is a licensing model, not a community organization model. Collaboration is not a benefit of open source, it's a benefit of collaboration software and a group of people who welcome collaboration. Almost all of the people who like collaborating on software use open source licensing. But there are plenty of people who use open source licensing who are not interested in collaborating. For example, it is very normal for projects maintained by someone with a narrow focus, or projects with limited or formally organized resources to not accept PRs. When you send someone a PR, you are demanding that they do work for you to review and merge. Open source licensing does not mandate that they do this. Heck, most open source licenses even disclaim warranty to avoid obligating the authors of even doing work that the law would otherwise require them to do. Now yes, some people will help you with problems. This is because they're nice, not because it's open source.
- shmerl 3y agoThis could be expressed in binary format using way less space, but expressing it in code / text I suppose make it more suitable to call it a source.
- tiffanyh 3y agoAs a comparison: FreeBSD: ~9M loc NetBSD: ~7M loc OpenBSD: ~3M loc And this includes the base userland (not just kernel) https://www.csoonline.com/article/564373/is-the-bsd-os-dying-some-security-researchers-think-so.html/amp/ https://www.csoonline.com/article/564373/is-the-bsd-os-dying...
- rjsw 3y agoNetBSD currently contains an older version of this driver, from Linux 5.6. Checking just now it comes to 2.2M loc. Running the same test on the Linux 6.4 source tree, does give me the reported 5M loc. Maybe the figures you quote exclude things imported from elsewhere like gcc and llvm, I get a figure of 75M loc for base + kernel of NetBSD-10.
- tgsovlerkhgsel 3y ago... and it doesn't work right. When you start googling for your syslog entries you find countless reports spanning many kernel versions of identical looking crashes, likely with different root causes since all the message basically says is "the GPU hung".
- guardiangod 3y agoI am working on the kernel right now, the code is very pleasant (as far as C code goes) to work with. Whereas I worked on Chrome's V8 C++ code for a year and I still could not say I understand more than half of it. Its complexity is a factor more than the Linux kernel.
- amelius 3y agoHow much of it is generated code?
- 1letterunixname 3y agoCorporations don't incentivize good engineering, they incentivize functionality at any cost. This leads to giant codebases, over-engineering, bad engineering, fragility, unmaintainable, useless code, and duplication. The FOSS/FLOSS community must push back against the hot mess turds corporations want to dump into their source.
- Osiris 3y agoWhy are GPU drivers baked into the kernel? Wouldn’t it be better to load them in such a way that a crash in the GPU driver can be recovered from as opposed to crashing the whole system? Other operating systems load the GPUs drivers separately.
- bendhoefs 3y agoWhy should having the GPU drivers checked into the same repository mean that they can't be loaded and unloaded dynamically?
- zaggynl 3y ago>as opposed to crashing the whole system Depending on your definition of 'the whole system' this is not entirely true. The AMD driver for example will reset the GPU and force a xorg restart: https://paste.debian.net/plain/1290344 https://paste.debian.net/plain/1290344 Now this does mean all desktop applications don't close properly, so I restart the PC to a 100% sure stability is at 100%, it didn't cause a kernel panic like the GPU crash would do previously. I've had this crash happen only twice in ~90 hours of play time. GPU: 5700XT Driver: Mesa 23.1.5
- deleted 3y ago[deleted]
- userbinator 3y agoAutogenerated code aside, I find that the vast majority of programmers are simply incapable of writing concise and straightforward code. They instead appear to love complexity, creating tons more abstractions and indirections than necessary. Not too long ago I wanted to figure out how to use the basic 2D acceleration (blitter) feature on Nvidia's GPUs, and looked into the Nouveau driver. Despite the fact that I already had a general idea of the command submission process and queues etc., following the codepath from the top-level "copy this rectangle from here to there" function down to the hardware registers felt ridiculously long-winded, although the ultimate actions were very very simple: write the command and its parameters to a circular queue, and tell the GPU to execute it by updating the queue registers.
- nextaccountic 3y agoOften straightforward code is full of repetition. Abstraction is usually brought up to reduce repetition, but it comes with its own problems
- torginus 3y agoWouldn't it be possible to move most of this code out of the kernel? I'm not sure what's in it, but my guess what you actually need to have in the kernel is buffer allocation, memory protection and command submission code, and some modesetting/graphics display specific bits so you can display some basic graphics without the userland.