Hacker News Reader

Comment by DCKing | Hacker News Reader

It's a daunting task to get a new GPU architecture in the Linux kernel that's likely as complicated as AMD's. The AMD driver takes up a sizeable chunk of the Linux kernel [1], although that figure includes lots of autogenerated files and a lot of different product generations. Certainly a top notch high performance driver is a very daunting task without documentation, although I expect a driver that is more in the ballpark of the nouveau driver is in the realm of possibility in the long term.

I can't help but smile at the prospect that Torvalds' pessimism here - while warranted - creates an incentive to prove something to both Torvalds and Apple...

[1]: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

View on HN

Last time I pointed out the AMD driver size, somebody on HN mentioned that it was common to copy the entire driver and make the modifications necessary for specific models/generations of hardware. Not all of it is necessary, it’s just by virtue of copying the code each generation

A decent chunk of it also comprises definitions of names/addresses/values that are (presumably) automatically translated from some authoritative description. This seems to be optimized for portability and consistent mapping to the input, not optimized for size, so there's a lot of stuff like [1]:

    typedef enum CRC_SRC_SEL {
    CRC_SRC_0                                = 0x00000000,
    CRC_SRC_1                                = 0x00000001,
    CRC_SRC_2                                = 0x00000002,
    CRC_SRC_3                                = 0x00000003,
    } CRC_SRC_SEL;

This might seem silly and redundant, and there are arguably better ways to express it, but the explicit approach makes a lot more sense if you skim the other definitions and see that some are 1-indexed, some have discontinuities, some have non-obvious reserved or otherwise special values, some have a totally distinct meaning for each value, etc.. Some of the definitions do look questionable, but on the whole I don't think any amount of macro magic could actually make these definitions small; the feature set of a modern GPU really is massively complex.

[1] https://github.com/torvalds/linux/blob/c84e1efae022071a4fcf9...

That makes me wonder: is there some tool for C that does dead-code elimination of source code rather than of the target binary? Something that'd strip out all these un-referenced constants?

It certainly wouldn't be useful for most projects, because most code that's un-referenced is only temporarily so. But in this codebase, it's a more permanent thing, with the driver for any given model being guaranteed to never need e.g. hardware register addresses for hardware doesn't have.

Not a kernel expert, but I am curious, couldn't we load that AMD driver conditionally?

Sizeable chunk in the source tree. The binary driver built from that is only loaded when the hardware is present...

"Or all in, Linux 5.9 comes in at roughly 27.81 million lines distributed among some fifty-nine thousand source files.

...

For a while now the AMDGPU kernel graphics driver has been around 2+ million lines of code making it the largest in-tree kernel driver. With Linux 5.9, it comes in at 2.16 million lines of code plus another 247k lines of code comments and another 109k blank lines... Or up to 2.51 million lines of code is the AMD DRM driver code including AMDKFD, PowerPlay, DC, and all the kernel code ultimately making up the AMD Radeon support on that driver (but not the older Radeon DRM driver -- that older Radeon driver is at around 157k lines of code). "

You can also build the kernel yourself. It's fun.

If you build your own kernel and you can choose between hundreds of options including building many components as optionally loaded modules. Its all configured through an ncurses interface.

Want a kernel that doesn’t support USB? Sure.

Reply on news.ycombinator.com