6 ms·

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/g

• 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.
              • emchammer 1y ago
                I use open-source OpenBSD is because the entire source tree is small enough for me to understand and manipulate. I guess I expect that it is all human-generated. This unwieldy, proprietary chunk makes me want to ditch graphics support in order to keep my source tree significantly smaller.
                • lunar-whitey 1y ago
                  After cleaning up the sources, the whole chip would still be an unwieldy proprietary chunk - you would just be able to ignore it more easily.
        • 1y ago
  • hulitu 1y ago
    > The last file in nbio is a header file with 38900 lines — a single file of 3.92 MB. Good programming practices gone extreme. We really need some low memory machines for developers.
• 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).