Announcement

Collapse
No announcement yet.

The Extraordinary DRM Pull Request For Linux 3.11

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

  • The Extraordinary DRM Pull Request For Linux 3.11

    Phoronix: The Extraordinary DRM Pull Request For Linux 3.11

    David Airlie has submitted the DRM subsystem pull request for the Linux 3.11 kernel that is of monster size. The Radeon DRM kernel driver is now perhaps the single biggest Linux kernel driver by code size after the merging of its huge dynamic power management code addition...

    http://www.phoronix.com/vr.php?view=MTQwNjA

  • #2
    Very big to boot ?

    By the sounds of it .. how do you fit such as big driver with the kernel updates, boot disks and distributions. I would love to see them have a basic core driver that is simple and small to get the computer started and then allows the system to load or swap drivers to enable playing games and advanced features. If it's done right we have the convenience of a small driver that is included everywhere and the user can then load the fancy stuff after the initial boot. Otherwise we are left with big packages and updates even before you can boot.

    Comment


    • #3
      Originally posted by tygrus View Post
      By the sounds of it .. how do you fit such as big driver with the kernel updates, boot disks and distributions. I would love to see them have a basic core driver that is simple and small to get the computer started and then allows the system to load or swap drivers to enable playing games and advanced features. If it's done right we have the convenience of a small driver that is included everywhere and the user can then load the fancy stuff after the initial boot. Otherwise we are left with big packages and updates even before you can boot.
      That is not a real issue, and even if it was what you're proposing is not a good solution because videocards in particular need proper power and fan management that a generic VESA driver can't handle.

      Comment


      • #4
        It's going to be fun to see Linus' response to this =)

        Another interesting thing is to see if any extensive code review is done (many eyes on your code, right?) since that is one of the points of FOSS. I'm mainly thinking of the following words of wisdom:

        Ask a programmer to review 10 lines of code, he'll find 10 issues. Ask him to do 500 lines and he'll say it looks good.

        Comment


        • #5
          Originally posted by Azpegath View Post
          It's going to be fun to see Linus' response to this =)

          Another interesting thing is to see if any extensive code review is done (many eyes on your code, right?) since that is one of the points of FOSS. I'm mainly thinking of the following words of wisdom:
          Well I doubt Linus will really care, its the merge window, he merges stuff that has been tested, and this code has seen a lot of testing already,

          The code has been reviewed by a number of people, granted the number of people who can make sense of gpu power management code is limited :-P

          Dave.

          Comment


          • #6
            Originally posted by airlied View Post
            Well I doubt Linus will really care, its the merge window, he merges stuff that has been tested, and this code has seen a lot of testing already,
            The code has been reviewed by a number of people, granted the number of people who can make sense of gpu power management code is limited :-P
            Dave.
            I was just recollecting his previous responses to large merges, like the "What is this crap?!" that he's said before. But perhaps that's just from a testing viewpoint, and not code review. I guess he doesn't really have time to do code reviews of the things he merges.

            Comment


            • #7
              Originally posted by Azpegath View Post
              I was just recollecting his previous responses to large merges, like the "What is this crap?!" that he's said before. But perhaps that's just from a testing viewpoint, and not code review. I guess he doesn't really have time to do code reviews of the things he merges.
              again the bullshit argument about seeing more eyes the code or foss is useless or something like that.

              I cant hear it any more... first of all there are more reasons for foss, when you argue in the way that oss means the same than free software, for some people thats shurly true but not for all, but ok...

              But even that point, yes you get not of every line of code 100 code reviews from people understand exactly what here happens. BUT some people read over it, and if there are some tcp-ip daemon port opening code like if login==NSA and password==NSA or something like that in the changelog, or if user has-interesting data open ssh port or something similar yes somebody would see that.

              And even if you really that good to hide some good bugs that are not obvious and you could use against somebody, still you would most probably not use the radeon module to make such a backdoor because most users dont have radeon gpus. and even most use intel gpu you would most probably use a network-subsystem or something like that to target every linux-user.

              And I think the network-stack is watched over more eyes than the radeon drivers.


              And there is another point there are programms that make automatic code analyses they also need the source and cant check microsoft code as example.

              so yes security most likely is much much higher for opensource stuff in any case even if no men would look over the code except the paid developer from the company...

              Comment


              • #8
                The AMD Radeon HD 8000 "Sea Islands" support for the open-source driver. AMD hasn't yet released their GCN 2.0 hardware, but there's early support within the Linux 3.11 kernel. Patches have also been submitted for libdrm and the RadeonSI Gallium3D driver living in Mesa.
                The age of AMD has officially begun.

                Comment


                • #9
                  Originally posted by Azpegath View Post
                  It's going to be fun to see Linus' response to this =)

                  Another interesting thing is to see if any extensive code review is done (many eyes on your code, right?) since that is one of the points of FOSS. I'm mainly thinking of the following words of wisdom:

                  I wanted to respond to this comment in my last comment.

                  Comment


                  • #10
                    Originally posted by tygrus View Post
                    By the sounds of it .. how do you fit such as big driver with the kernel updates, boot disks and distributions. I would love to see them have a basic core driver that is simple and small to get the computer started and then allows the system to load or swap drivers to enable playing games and advanced features. If it's done right we have the convenience of a small driver that is included everywhere and the user can then load the fancy stuff after the initial boot. Otherwise we are left with big packages and updates even before you can boot.
                    All 3d stuff is in Mesa so in a way this is already the case. In any cases i can almost assure you that what you are loading with Linux is smaller then what you would load with catalyst (not that that automatically equals faster)

                    Comment


                    • #11
                      Originally posted by tomato View Post
                      The age of AMD has officially begun.
                      No? The HD 8000s are only rebrands right now, with the exception of some low end GPU. The next actual graphic cards will be HD 9000s.

                      Comment


                      • #12
                        Originally posted by Calinou View Post
                        No? The HD 8000s are only rebrands right now, with the exception of some low end GPU. The next actual graphic cards will be HD 9000s.
                        Kabini/Temash are new products, not rebrands. Similar for Hainan, which is not low-end. Richland uses VLIW4 for 3D, so is not all-new. The rest of 8000 are Southern Islands chips I think.

                        Comment


                        • #13
                          Originally posted by Azpegath View Post
                          I was just recollecting his previous responses to large merges, like the "What is this crap?!" that he's said before. But perhaps that's just from a testing viewpoint, and not code review. I guess he doesn't really have time to do code reviews of the things he merges.
                          I think his rants about big merges were only directed at requests made late in the merge window.
                          Also given the size of the DPM code seems justified, not much you can do about it.

                          Comment


                          • #14
                            Originally posted by PsynoKhi0 View Post
                            I think his rants about big merges were only directed at requests made late in the merge window.
                            Also given the size of the DPM code seems justified, not much you can do about it.
                            Actually, his rants were about people adding features in the RC state of the kernel, which is for bugfixing, not adding features (this is what the merge window is for).

                            Comment


                            • #15
                              Does anyone know where the interface to vebox exists?
                              I've looked through the enablement and testing commits, but I couldn't find any place where userspace could make use of it.
                              I'm asking b/c the description of vebox makes it sound like hw enabled postprocessing which could be useful as we don't have many of those with the open drivers that I've seen.

                              Comment

                              Working...
                              X