Announcement

Collapse
No announcement yet.

AMD's Kernel Graphics Code Is Approaching One Million Lines

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

  • AMD's Kernel Graphics Code Is Approaching One Million Lines

    Phoronix: AMD's Kernel Graphics Code Is Approaching One Million Lines

    With the DRM driver features settled for Linux 4.12, I was curious about the size of these Direct Rendering Manager drivers...

    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
    Back in my Slackware days when I used to configure and make my own kernels it was a game to get that thing down to as small as possible and see how it performed be it built-in or a mostly modularized kernel configuration. That was circa 2005 now when I look at a kernel sizes of coarse this means kernels distribution maintainers configure and make, "I laugh inside thinking geeeeeeeze". Stuff seemingly has become well.. hugely huge lol. I keep wanting to configure my own kernels but once I start learning to do that again,(PAUSE) I had it down to an exact science I knew how everything was related, right now I would scratch my head for weeks or even months on end if I were to attempt it especially on Ubuntu. I really miss my slack days. If you don't use it you lose it. I was fully dedicated back then to that, now I am dedicated to other endeavors.
    Last edited by creative; 13 April 2017, 11:55 AM.

    Comment


    • #3
      Considering it's code that is needed for the most complex hardware available in a computer, and it includes drivers from late 90s to yet unreleased hardware, it doesn't bad. As long as it is maintainable, everything is fine. People who like their kernel small can always compile their own, even though DRM stuff is usually on modules, so if you don't use it it won't be in your system.

      Also, it seems most of it it's headers. Hardware descriptions, registers, etc etc for every part of the GPU.
      Last edited by bibaheu; 13 April 2017, 12:01 PM. Reason: Last phrase

      Comment


      • #4
        Why are there 6 times as many lines in header files than source files?

        Why does the AMDGPU driver contain more lines than all the others combined? I mean Intel graphics and radeon are full-featured (shader, video en-/decoding, display) drivers as well, so why does AMDGPU need that many additional lines? Is this a code quality issue like with DC, just to a lesser extent?
        Last edited by CrystalGamma; 13 April 2017, 12:34 PM.

        Comment


        • #5
          Originally posted by CrystalGamma View Post
          Why are there 6 times as many lines in header files than source files?
          The header files are big because we are now providing header info for pretty much every register on the chip rather than only the registers the driver uses. Previously we had to loop through IP review every time the devs wanted to use a new register; now we try to do all that up front.

          We also generally have separate header file sets for each HW generation rather than trying to partially squoosh them together.

          Originally posted by CrystalGamma View Post
          Why does the AMDGPU driver contain more lines than all the others combined? I mean Intel graphics and radeon are full-featured (shader, video en-/decoding, display) drivers as well, so why does AMDGPU need that many additional lines? Is this a code quality issue like with DC, just to a lesser extent?
          Guessing there are three parts to the answer:

          1. see previous question - most of the lines are headers, not code (this is the main reason)

          2. support for more GPU generations in a single driver, making that driver bigger (vs Intel i810 + i915)

          3. more significant changes between GPU generations so more need for separate copies of code rather than just inserting runtime switches
          Last edited by bridgman; 13 April 2017, 09:13 PM.
          Test signature

          Comment


          • #6
            Originally posted by CrystalGamma View Post
            Why are there 6 times as many lines in header files than source files?

            Why does the AMDGPU driver contain more lines than all the others combined? I mean Intel graphics and radeon are full-featured (shader, video en-/decoding, display) drivers as well, so why does AMDGPU need that many additional lines? Is this a code quality issue like with DC, just to a lesser extent?
            in addition to bridgman's reply "To get it done right for the hardware at hand"

            You can agonise over making code size small, but that (IMHO) makes the code more unreadable. A little bit of verbosity helps when maintaining code!

            That had massively huge header files!

            Comment


            • #7
              Originally posted by CrystalGamma View Post
              Why does the AMDGPU driver contain more lines than all the others combined? I mean Intel graphics and radeon are full-featured (shader, video en-/decoding, display) drivers as well
              1. article is talking about all amd kernel graphics code, including radeon.
              2. intel does not have full-featured hardware
              Originally posted by CrystalGamma View Post
              Is this a code quality issue like with DC, just to a lesser extent?
              it is a forum commenter's quality issue as usual

              Comment


              • #8
                Originally posted by pal666 View Post
                1. article is talking about all amd kernel graphics code, including radeon.
                2. intel does not have full-featured hardware
                If you actually read the article, it talks about drivers/gpu/drm/amd, while the radeon driver is at drivers/gpu/drm/radeon.

                And as for Intel, I don't see how a GPU that supports OpenGL 4.5 and Vulkan, as well as OpenCL 2.0 and video en-/decoding, is not full-featured.

                it is a forum commenter's quality issue as usual
                Bridgman's explanation above does at least explain some reasons for the size (bigger differences between HW generations at AMD vs at Intel), yours is just dismissive. Well done.

                Comment


                • #9
                  Originally posted by bibaheu View Post
                  Considering it's code that is needed for the most complex hardware available in a computer, and it includes drivers from late 90s to yet unreleased hardware, it doesn't bad. As long as it is maintainable, everything is fine. People who like their kernel small can always compile their own, even though DRM stuff is usually on modules, so if you don't use it it won't be in your system.

                  Also, it seems most of it it's headers. Hardware descriptions, registers, etc etc for every part of the GPU.
                  Exhibit A why Linux desperately needs a working HAL. A stable driver ABI wouldn't hurt either.

                  Comment


                  • #10
                    Originally posted by gamerk2 View Post
                    Exhibit A why Linux desperately needs a working HAL.
                    Yeah, all problems can be solved by adding moar abstraction layers. This isn't even a problem, damnit. Headers are pretty much static stuff.

                    A stable driver ABI wouldn't hurt either.
                    And of course it's mandatory to beat dead horses.

                    Comment

                    Working...
                    X