5 ms·

79% of OpenBSD kernel source is AMD DRM

86 points by cnst 1y ago

cnst 1y ago
> 79% of OpenBSD kernel source is AMD DRM The sys.tar.gz from https://ftp.eu.openbsd.org/pub/OpenBSD/7.7/ https://ftp.eu.openbsd.org/pub/OpenBSD/7.7/ (normally unpacked into /usr/src/sys on an OpenBSD machine) represents the entire kernel source code of OpenBSD 7.7. (The userland and compiler are in src.tar.gz, Xorg is in xenocara.tar.gz, and ports are in ports.tar.gz.) It has grown to 634MB unpacked for the entire kernel source tree. But the vast majority of this growth is attributable to the sys/dev/pci/drm/amd directory, which is AMD Direct Rendering Manager, standing at 499MB, with the include files at sys/dev/pci/drm/amd/include being 458MB, the biggest of which is the asic_reg directory. 499/634 is 79%. It follows that 79% of OpenBSD kernel by source code is dedicated to AMD's DRM implementation. Note that we're talking about the source code, NOT compiled code. It's a huge part of Linux, too, over at drivers/gpu/drm/amd/include/asic_reg: https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/amd/include/asic_reg/ https://github.com/torvalds/linux/tree/master/drivers/gpu/dr... In OpenBSD, the last release before the explosive growth, was OpenBSD 6.5 (Apr 2019) with sys.tar.gz at 20MB. With OpenBSD 6.6 (Oct 2019), it went to 30MB, now with 7.7 (Apr 2025) it's 64MB compressed.
- Y_Y 1y ago
  https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h https://github.com/torvalds/linux/blob/master/drivers/gpu/dr... 11k lines of #defines Is this truly necessary?
  - cnst 1y ago
    11k defines in gc is nothing, the files in the nbio dir are so big, github even refuses to parse many them: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/refs/heads/master/drivers/gpu/drm/amd/include/asic_reg/nbio/ https://kernel.googlesource.com/pub/scm/linux/kernel/git/tor... https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_sh_mask.h https://github.com/torvalds/linux/blob/master/drivers/gpu/dr... The last file in nbio is a header file with 38900 lines — a single file of 3.92 MB. There's actually another one in nbio that's 16MB: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_7_0_sh_mask.h https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...
    - burnt-resistor 1y ago
      Brotli was able to crush it down to 229 KiB after about 30 seconds, but still, this is an absurd amount of unnecessary, low value bullshit.
      - layla5alive 1y ago
        Clearly this is generated code. I have mixed feelings about this. On the one hand, I'm glad its a single file, as its faster to parse than if it'd been split up among a whole bunch of smaller files. And that it isn't generated during the build is a complexity advantage, even if it is huge. OTOH, no human is going to read this whole file, so I wonder if there was not a better way.
        burnt-resistor 1y ago
        All other things being equal, I'd rather have a codegen step added to the build process for mechanical, non-human-maintained code rather than foist mega files on everyone if those were the only two choices.
        beeflet 1y ago
        I suppose it depends on the portability of the mega-files. It could be an output from a complex non-portable program.
        burnt-resistor 1y ago
        Don't make or allow complex, non-portable programs. There's no reason for this. Simplicity and Turing completeness means it can always be written in something understandable and maintainable.
        lunar-whitey 1y ago
        Simple portable programs that perform nontrivial tasks are expensive. Open source overcomes this where possible by socializing the cost.
  - zamalek 1y ago
    Yes, it's hardware registers. Could be a better idea to generate that from some more compact format, though.
    - phendrenad2 1y ago
      But really, who needs THAT many hardware registers? I'm guessing that what's happening here is the internal "registers" are actually structs in memory, and someone wanted to address one memory location and thought, "I know, I'll auto-generate #defines for all of the words/longs/bytes!" And now, we're stuck with a billion "hardware registers" that are no such thing. Because somewhere in the code they might be used as such.
      - lunar-whitey 1y ago
        The size of the MMIO addressable register space on many modern VLSI devices is shocking the first time you see it. However, OS device drivers often do not need to access more than a small subset of the registers. In addition, the register layout for functional units within a larger device is often identical after accounting for unremarkable changes to unit base addresses or iterative, generational addition of new registers. The problem is the language and toolchain for OS device drivers cannot consume the manifests RTL designers use to enumerate registers, and and RTL designers rarely share the manifests and toolchains they use to generate source files for the OS developers. Instead, it is common to generate and share sources for the entire MMIO space of every supported chip revision. To eliminate the source bloat this produces, OS driver developers would need to work with RTL design teams to release IP sanitized register manifests and tooling that can generate saner outputs for their own consumption. This is fairly specialized work and there is not a strong business incentive for most large firms to support it.
        Y_Y 1y ago
        What about just committing the symbols that are actually referenced in the code? I be most almost all of those registers are never mentioned elsewhere and and could be culled with an appropriate dead-code elimination step (per release).
- deleted 1y ago
  [deleted]
- wodenokoto 1y ago
  So it’s not Digital Rights Management?
  - worthless-trash 1y ago
    Direct Rendering Manager
    - spauldo 1y ago
      I've always thought that was an unfortunate name collision.
rasz 1y ago
related "Linux kernel maintainer says no to AMDGPU patch" https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426
- cnst 1y ago
  So how did we end up with a situation where 80% of the kernel is AMD DRM?
  - beng-nl 1y ago
    Openbsd != Linux
    - cnst 1y ago
      Not relevant because AMD DRM is still the same, and it is distributed via Linux.
bombcar 1y ago
This lends some credence to the idea that modern computers are actually GPUs and the CPU and OS are just boot support software.
somat 1y ago
On the one hand I sort of understand it, by not having a stable ISA you don't get tied down in past mistakes and can have really clever hardware innovations. But on the other hand it leads to bullshit like this. where every hardware device is a special snowflake and effectively needs it's own unique driver. Final thoughts, It's not perfect but I really appreciate AMD's more open stance that gives us this source. And to the absolute heroes who are able to take this big steaming linux centric turd and make it work on openbsd, huge salutes. well done. However I do wish AMD would clean up their driver. Or at least settle on an ISA.
- almostgotcaught 1y ago
  > However I do wish AMD would clean up their driver. Or at least settle on an ISA. These two things have absolutely nothing to do with each other - drivers don't talk to the cores, which "run" the ISA, they talk to the command processors (which are RISCV or MIPS or some other uC) using the command packet protocol.
- deleted 1y ago
  [deleted]
snvzz 1y ago
Belongs in userspace. Absolutely not the kernel. But we can't seem to move past archaic UNIX architecture.
- mey 1y ago
  While there are issues with Window's WDM (badly writen drivers abound), it really should be looked as a model. _but_ that would require a stable ABI. Which is specifically called out as not desired here https://www.kernel.org/doc/html/next/process/stable-api-nonsense.html https://www.kernel.org/doc/html/next/process/stable-api-nons... There are valid concerns, but the analysis doesn't lay out the issues with the current design either making it a one sided review.
  - JackSlateur 1y ago
    Could you tell more about the WDM advantages ?
- account42 1y ago
  Most of the graphic drivers is already in user space. What's in the kernel is there the to manage memory and handle coordinate command submission and scheduling as well as display output configuration. There is no reason why this shouldn't be in the kernel.
  - cnst 1y ago
    But why do we need 499MB for such simple tasks, where all the rest of the kernel combined still fits in 135MB, with all the drivers for all the other devices, including Intel graphics? I mean, it's 3.7x larger than all the rest of the kernel (135x3.7=499), how is that in any way reasonable for such a small set of functions across so few devices to take up so much space?
__turbobrew__ 1y ago
AMD is bloat
methou 1y ago
For Mac and Windows users: Not to be confused with Digital Rights Management: https://en.wikipedia.org/wiki/Direct_Rendering_Manager https://en.wikipedia.org/wiki/Direct_Rendering_Manager
- deleted 1y ago
  [deleted]
evanjrowley 1y ago
FreeBSD has lots of AMD graphics code because Sony Playstation 4 and 5 are both based on FreeBSD. I'm not sure how much, but some of OpenBSD's AMD graphics code comes from FreeBSD[0]. Considering the prolific success of the PS4/PS5, it would make sense that FreeBSD's AMD graphics code is a considerable size. If OpenBSD is using parts of it, then we should expect those parts to be large. [0] https://www.phoronix.com/news/MTQzNjI https://www.phoronix.com/news/MTQzNjI

86 points by cnst 1y ago

cnst 1y ago

> 79% of OpenBSD kernel source is AMD DRM The sys.tar.gz from https://ftp.eu.openbsd.org/pub/OpenBSD/7.7/ https://ftp.eu.openbsd.org/pub/OpenBSD/7.7/ (normally unpacked into /usr/src/sys on an OpenBSD machine) represents the entire kernel source code of OpenBSD 7.7. (The userland and compiler are in src.tar.gz, Xorg is in xenocara.tar.gz, and ports are in ports.tar.gz.) It has grown to 634MB unpacked for the entire kernel source tree. But the vast majority of this growth is attributable to the sys/dev/pci/drm/amd directory, which is AMD Direct Rendering Manager, standing at 499MB, with the include files at sys/dev/pci/drm/amd/include being 458MB, the biggest of which is the asic_reg directory. 499/634 is 79%. It follows that 79% of OpenBSD kernel by source code is dedicated to AMD's DRM implementation. Note that we're talking about the source code, NOT compiled code. It's a huge part of Linux, too, over at drivers/gpu/drm/amd/include/asic_reg: https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/amd/include/asic_reg/ https://github.com/torvalds/linux/tree/master/drivers/gpu/dr... In OpenBSD, the last release before the explosive growth, was OpenBSD 6.5 (Apr 2019) with sys.tar.gz at 20MB. With OpenBSD 6.6 (Oct 2019), it went to 30MB, now with 7.7 (Apr 2025) it's 64MB compressed.

Y_Y 1y ago
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h https://github.com/torvalds/linux/blob/master/drivers/gpu/dr... 11k lines of #defines Is this truly necessary?
- cnst 1y ago
  11k defines in gc is nothing, the files in the nbio dir are so big, github even refuses to parse many them: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/refs/heads/master/drivers/gpu/drm/amd/include/asic_reg/nbio/ https://kernel.googlesource.com/pub/scm/linux/kernel/git/tor... https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_sh_mask.h https://github.com/torvalds/linux/blob/master/drivers/gpu/dr... The last file in nbio is a header file with 38900 lines — a single file of 3.92 MB. There's actually another one in nbio that's 16MB: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_7_0_sh_mask.h https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...
  - burnt-resistor 1y ago
    Brotli was able to crush it down to 229 KiB after about 30 seconds, but still, this is an absurd amount of unnecessary, low value bullshit.
    - layla5alive 1y ago
      Clearly this is generated code. I have mixed feelings about this. On the one hand, I'm glad its a single file, as its faster to parse than if it'd been split up among a whole bunch of smaller files. And that it isn't generated during the build is a complexity advantage, even if it is huge. OTOH, no human is going to read this whole file, so I wonder if there was not a better way.
      - burnt-resistor 1y ago
        All other things being equal, I'd rather have a codegen step added to the build process for mechanical, non-human-maintained code rather than foist mega files on everyone if those were the only two choices.
        beeflet 1y ago
        I suppose it depends on the portability of the mega-files. It could be an output from a complex non-portable program.
        burnt-resistor 1y ago
        Don't make or allow complex, non-portable programs. There's no reason for this. Simplicity and Turing completeness means it can always be written in something understandable and maintainable.
        lunar-whitey 1y ago
        Simple portable programs that perform nontrivial tasks are expensive. Open source overcomes this where possible by socializing the cost.
- zamalek 1y ago
  Yes, it's hardware registers. Could be a better idea to generate that from some more compact format, though.
  - phendrenad2 1y ago
    But really, who needs THAT many hardware registers? I'm guessing that what's happening here is the internal "registers" are actually structs in memory, and someone wanted to address one memory location and thought, "I know, I'll auto-generate #defines for all of the words/longs/bytes!" And now, we're stuck with a billion "hardware registers" that are no such thing. Because somewhere in the code they might be used as such.
    - lunar-whitey 1y ago
      The size of the MMIO addressable register space on many modern VLSI devices is shocking the first time you see it. However, OS device drivers often do not need to access more than a small subset of the registers. In addition, the register layout for functional units within a larger device is often identical after accounting for unremarkable changes to unit base addresses or iterative, generational addition of new registers. The problem is the language and toolchain for OS device drivers cannot consume the manifests RTL designers use to enumerate registers, and and RTL designers rarely share the manifests and toolchains they use to generate source files for the OS developers. Instead, it is common to generate and share sources for the entire MMIO space of every supported chip revision. To eliminate the source bloat this produces, OS driver developers would need to work with RTL design teams to release IP sanitized register manifests and tooling that can generate saner outputs for their own consumption. This is fairly specialized work and there is not a strong business incentive for most large firms to support it.
      - Y_Y 1y ago
        What about just committing the symbols that are actually referenced in the code? I be most almost all of those registers are never mentioned elsewhere and and could be culled with an appropriate dead-code elimination step (per release).
deleted 1y ago
[deleted]
wodenokoto 1y ago
So it’s not Digital Rights Management?
- worthless-trash 1y ago
  Direct Rendering Manager
  - spauldo 1y ago
    I've always thought that was an unfortunate name collision.

rasz 1y ago

related "Linux kernel maintainer says no to AMDGPU patch" https://news.ycombinator.com/item?id=13136426 https://news.ycombinator.com/item?id=13136426

cnst 1y ago
So how did we end up with a situation where 80% of the kernel is AMD DRM?
- beng-nl 1y ago
  Openbsd != Linux
  - cnst 1y ago
    Not relevant because AMD DRM is still the same, and it is distributed via Linux.

bombcar 1y ago

This lends some credence to the idea that modern computers are actually GPUs and the CPU and OS are just boot support software.

somat 1y ago

On the one hand I sort of understand it, by not having a stable ISA you don't get tied down in past mistakes and can have really clever hardware innovations. But on the other hand it leads to bullshit like this. where every hardware device is a special snowflake and effectively needs it's own unique driver. Final thoughts, It's not perfect but I really appreciate AMD's more open stance that gives us this source. And to the absolute heroes who are able to take this big steaming linux centric turd and make it work on openbsd, huge salutes. well done. However I do wish AMD would clean up their driver. Or at least settle on an ISA.

almostgotcaught 1y ago
> However I do wish AMD would clean up their driver. Or at least settle on an ISA. These two things have absolutely nothing to do with each other - drivers don't talk to the cores, which "run" the ISA, they talk to the command processors (which are RISCV or MIPS or some other uC) using the command packet protocol.
deleted 1y ago
[deleted]

snvzz 1y ago

Belongs in userspace. Absolutely not the kernel. But we can't seem to move past archaic UNIX architecture.

mey 1y ago
While there are issues with Window's WDM (badly writen drivers abound), it really should be looked as a model. _but_ that would require a stable ABI. Which is specifically called out as not desired here https://www.kernel.org/doc/html/next/process/stable-api-nonsense.html https://www.kernel.org/doc/html/next/process/stable-api-nons... There are valid concerns, but the analysis doesn't lay out the issues with the current design either making it a one sided review.
- JackSlateur 1y ago
  Could you tell more about the WDM advantages ?
account42 1y ago
Most of the graphic drivers is already in user space. What's in the kernel is there the to manage memory and handle coordinate command submission and scheduling as well as display output configuration. There is no reason why this shouldn't be in the kernel.
- cnst 1y ago
  But why do we need 499MB for such simple tasks, where all the rest of the kernel combined still fits in 135MB, with all the drivers for all the other devices, including Intel graphics? I mean, it's 3.7x larger than all the rest of the kernel (135x3.7=499), how is that in any way reasonable for such a small set of functions across so few devices to take up so much space?

__turbobrew__ 1y ago

AMD is bloat

methou 1y ago

For Mac and Windows users: Not to be confused with Digital Rights Management: https://en.wikipedia.org/wiki/Direct_Rendering_Manager https://en.wikipedia.org/wiki/Direct_Rendering_Manager

deleted 1y ago
[deleted]

evanjrowley 1y ago

FreeBSD has lots of AMD graphics code because Sony Playstation 4 and 5 are both based on FreeBSD. I'm not sure how much, but some of OpenBSD's AMD graphics code comes from FreeBSD[0]. Considering the prolific success of the PS4/PS5, it would make sense that FreeBSD's AMD graphics code is a considerable size. If OpenBSD is using parts of it, then we should expect those parts to be large. [0] https://www.phoronix.com/news/MTQzNjI https://www.phoronix.com/news/MTQzNjI