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

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

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

    Given the impending release of Linux 5.9, I was having some fun with cloc today looking at the current lines of code count for this near-final Linux 5.9 kernel state...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    phoronix It's hard to read the text-based tables in Chrome on Android because the page won't scroll horizontally.

    Comment


    • #3
      the tables extend past the right side of the screen

      Comment


      • #4
        Good job AMD!

        Comment


        • #5
          And how much of that is kms or display related?

          Comment


          • #6
            Originally posted by SilverFox
            Could this be considered bloat?
            I don't think so. A big part is auto-generated code, like the header files that are too big but probably no one will change them manually.

            Comment


            • #7
              I'm not an expert in amdgpu, but I did look at the code recently. I had a fix the BIOS in a XFX RX 560, which has broken UEFI support, so that it would work on a new MB that only supports video in UEFI mode. It's possible to get the vbios and patch in a new GOP driver. But the debugfs function in amdgpu to get the vbios doesn't return the entire contents of the vbios flash.

              I traced the code to a function to get the bios that tries about ten different code paths. Asking ACPI for the bios. Using a gpu specific function. A bunch of stuff. Do the really need all that? Probably not. I figured the code that talked to the hardware was probably the best bet and looked for it. And found a function for volcanic islands cards that does it. Lots of unsafe pointer casts. There's another entire copy of the function for southern islands. Exactly the same code. soc15 copy. Identical. And so on.

              It looks like for each new family, they copy the entire driver from previous family and make a few changes.

              I didn't do an extensive survey. Maybe I just saw the identical bits. But it looks like the driver is really about five nearly identical drivers that all get loaded and then one gets used. Because that's easier than refactoring your design to share common code. If you don't care about bloat or the cost of supporting five copies of your code. That cost isn't much if you don't care about anything but the latest version.

              Comment


              • #8
                The obvious result of importing cooperate, windows derived source bases? Display Engine, Atom BIOS, etc. pp?

                Comment


                • #9
                  Originally posted by SilverFox
                  Could this be considered bloat?
                  . yes .

                  Comment


                  • #10
                    By uploading the entire auto generated header they basically documented the whole register space.
                    These days even a cell phone camera comes with tens of thousands of registers but the driver simply hard code everything into a big sequence, turning it into essentially a firmware blob.

                    Comment

                    Working...
                    X