Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by bridgman View Post
    Given that 5/6 of the lines are register headers that do not produce code, I would argue "no".

    The driver code itself is less that 2% of the kernel.
    But without those register headers, the code is still 75% larger than the Intel drm driver, which presumably also includes a considerable number of register defines in its 209 klines. Certainly one could argue the amdgpu driver does more than the i915 driver and should be larger.

    If I look at my currently running system, the amdgpu kernel module is 5,861,376 bytes. The next largest modules are kvm at 823,296, drm at 626,688, and sunrpc at 565,248 (when did rpc get so huge???). Total size of all modules is 12,898,304. So the admgpu driver is largest single module by over a factor of seven and accounts for 45% of the total size of all loaded modules! And yes I know this doesn't account for compiled in drivers. But basically anything that can be a module is a module in Fedora distro kernel.

    Certainly seems possible that amdgpu is bloated.

    Originally posted by Bobby Bob
    Isn't there some way of separating these things into modules or something rather than having it all crammed in there?
    Part of the reason the module is huge is that it is one module for all architectures. It could be designed for better modularity, so that one could only load the VI support module and not was is a probably nearly identically sized module for SI support, and another for CIK, and so on.

    We designed a system for the dvb drivers that allowed for greater modularity. The hardware usually had a main capture chip, from just a couple choices, with e.g. a PCI interface like bt849 or cx88, and then one or more RF demodulators attached to it, from dozens of choices. A different card would use a different combo of capture + demod. We came up with a demod interface that all the demod drivers could use. This way the same demod driver could work for bt849 or cx88. And instead of putting every possible demod driver into the cx88 driver, we came up with a dynamic attachment system so that only the demod driver(s) actually used needed to be loaded into the kernel.

    But this just address the runtime bloat of loading into RAM drivers for every AMD video card made in the last decade.



    Last edited by tpiepho; 12 October 2020, 03:46 PM.

    Comment


    • #42
      Originally posted by mdedetrich View Post
      I understand you need the kernel headers to compile its own driver to work against the Linux kernel, but the documentation is also clearly saying you need the kernel sources (this is the part that is confusing).

      To me the definition of kernel sources is the actual source code of the kernel, so why/what is this needed for?
      It's not entirely clear to me if nvidia is saying you need the kernel source or the kernel headers. Both come from the same place: the kernel source. But many distros make a package with just the headers. So maybe they are just covering the possibilities of what package a distro might but the headers in. The headers are just the ones in the top level include directory tree. The global kernel headers. You need these to compile an out of tree module, like what dkms does with the nvidia module. The kernel source also contains more headers intermixed with the individual drivers' code. These are private headers that aren't meant to be used outside of a driver or subsystem they are in. Maybe nvidia uses some of theses too and then would require the full kernel source to build.

      Comment


      • #43
        Originally posted by mdedetrich View Post

        I understand you need the kernel headers to compile its own driver to work against the Linux kernel, but the documentation is also clearly saying you need the kernel sources (this is the part that is confusing).

        To me the definition of kernel sources is the actual source code of the kernel, so why/what is this needed for?
        They're just wording it that way because of different distributions packaging the kernel sources differently (and just packages in general). Sometimes the headers are included, sometimes (usually) they're not; some distributions have "developer" packages, some include that part with the regular package. It varies so Nvidia has instructions that cover all the bases even though all they need is the kernel headers potion of the kernel sources.

        install the correct kernel-source, kernel-headers, or kernel-devel package
        "correct" is the keyword making things confusing.

        Comment


        • #44
          Originally posted by mdedetrich View Post

          Quoting directly from http://download.nvidia.com/XFree86/L...alldriver.html (emphasis mine)



          So either NVidia's documentation for how their own installation works is unclear/outdated or something else is going on.
          I see that others already have replied about this but looking at your quote the important word there is "OR":
          correct kernel-source, kernel-headers, or kernel-devel package;
          Anyway, you can always download the nVidia driver and execute it with -x so it just extracts the package instead of running the full install-script, then in the "kernel" folder you have the code for the nVidia shim and if you examine all the files there you will clearly see that they just include a bunch of headers from the kernel.

          Them patching the kernel would require not only the kernel sources but also the complete kernel build environment, and would break e.g signed kernels.

          Comment


          • #45
            Originally posted by F.Ultra View Post
            Them patching the kernel would require not only the kernel sources but also the complete kernel build environment, and would break e.g signed kernels.
            I've seen out of tree modules that patch the kernel source to make some macros and structure definitions visible to their code. I.e., move them out of a C file and into a header. In this case you don't need to rebuild the kernel after the patching, if the patch didn't actually change what the kernel should compile to.

            So in that case you could patch the kernel source, build your out-of-tree module, and load it into the running (unpatched) kernel just fine.

            But often kernel patches for drivers do need change the kernel. Maybe they un-GPL an exported symbol (bad!). Or add some hook into existing kernel code. So one would need to rebuild the kernel, maybe sign it, install the new kernel, and boot into it, before the driver could be loaded.

            Comment


            • #46
              Originally posted by tpiepho View Post
              I've seen out of tree modules that patch the kernel source to make some macros and structure definitions visible to their code. I.e., move them out of a C file and into a header. In this case you don't need to rebuild the kernel after the patching, if the patch didn't actually change what the kernel should compile to.

              So in that case you could patch the kernel source, build your out-of-tree module, and load it into the running (unpatched) kernel just fine.

              But often kernel patches for drivers do need change the kernel. Maybe they un-GPL an exported symbol (bad!). Or add some hook into existing kernel code. So one would need to rebuild the kernel, maybe sign it, install the new kernel, and boot into it, before the driver could be loaded.
              But that is not patching, not exactly sure that the correct nomenclature would be but patching it ain't. And yes a driver could patch the kernel in the way you described last and that would indeed be patching, but nVidia doesn't do this so that is nothing that we can accuse them of despite all their other shortcomings.

              Comment


              • #47
                They need only the linux-_headers_, which are often in an extra package, but sometimes only in the sources-package.
                Btw, the first NT was NT 3.1. Which had much of the GUI in the userspace - NT 4 moved much of the GUI into kernelspace. Too much - Vista moved much of it out into userspace again.

                Comment


                • #48
                  10%?! Wow, damn, that is a lot!!

                  Comment

                  Working...
                  X