Announcement

Collapse
No announcement yet.

DRM Changes Coming Up For Linux 3.1 Kernel

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

  • DRM Changes Coming Up For Linux 3.1 Kernel

    Phoronix: DRM Changes Coming Up For Linux 3.1 Kernel

    There's still a few more weeks left until the Linux 3.0 kernel will be officially released, but there are already some changes worth looking forward to with the Linux 3.1 kernel as it pertains to the 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
    Typo: kermnel

    Comment


    • #3
      I'd rather see KMS lose its GPL-only state. As an nVidia user I don't even use the kernel's own DRM system, but I sure hate having to use uvesafb when I have a card that's capable of so much more.

      Sadly, display drivers in Linux go one of two ways:

      Either they fully support OpenGL or they fully support KMS. Never both. If you have a driver that fully supports KMS, chances are you're missing anywhere to 25 to 66 percent of support of OpenGL's features, and virtually all of OpenGL's nicer features will be missing support from the driver.

      You can get 100% support for OpenGL in software, but software rendering pretty effectively defeats the entire purpose of OpenGL to begin with. If you're an OpenGL/OpenCL programmer on Linux, you're not going to be using Nouveau, I promise that.

      Gallium is a fantastic effort, but without a fully open specification from any given hardware manufacturer (ATI still has some aspects of Radeon and Radeon HD under lock and key. I know that the editors at Phoronix are a bit biased toward ATI, so I take pains to point this out.) it isn't going to be making any huge breakthroughs.

      As it stands for right now, nVidia is the best video option for Linux. ATI is improving but there are entire product lines that have either no supprt, or abysmal support from both Catalyst and the open source drivers. I agree ATI may be the wave of the future for Linux video support. Right now, though, ATI is the last brand of GPU I'd want to use Linux on. This is largely due to the fact that before AMD bought ATI, ATI barely took Linux seriously. AMD reported not long after taking over that they were utterly shocked at how lacking ATI's support for Linux actualy was.

      Maybe in another five years ATI will be the best option for Linux, but for now I'd still recommend nVidia to anyone who asks.

      So while improved DRM might be a good thing, I think unlocking KMS so nVidia and Catalyst can actually use it is more important. Nouveau's a nice driver, but I'd rather have full OpenGL support than KMS, and I think this is why Wayland will never replace Xorg. Outright requiring KMS basically guarantees no one will see full OpenGL working on Wayland.

      Comment


      • #4
        The DRM code is X11 licensed, not GPL.

        Comment


        • #5
          There also doesn't appear to be any pending fixes yet for some of the Radeon HD 6000 series bugs that others and I have been hitting.
          I also run into one bug with my new HD6870. It makes the system freeze when loading the radeon module. But i know that there are only a few people working on this driver.

          Comment


          • #6
            Originally posted by Yaro View Post
            I'd rather see KMS lose its GPL-only state.
            The entire DRI subsystem, including KMS, is MIT licensed, so it can be ported to the BSDs. Actually, it is already ported to FreeBSD, OpenBSD and (Open)Solaris, though those ports are way out-of-date, and does not include KMS.

            The problem isn't the license of the KMS subsubsystem, the problem is that NVidia would have to move and rework a lot of the stuff from their userland blob into their kernelspace blob, and thus do a major rework of their currently quite minimal GPL licensed compatibility layer, which they don't seem to think is worth it.

            Honestly, I expect it would be less work for them to improve the current KSM drivers and update their userland blob to use the MIT licensed libdrm to talk to the open source kernel module instead, dropping their kernelspace blob entirely.

            Not that that would be easy, just less difficult than reworking their existing stuff to support KMS.

            Comment


            • #7
              Fermi Benchmarks

              If you make another article on those Fermi benchmarks and nouveau tends to be 10 to 20 times slower than the blob (if you happen to find a GPU limited benchmark):
              Please please please mention that we're running the GPU at ~50 MHz and the blob is running it at ~600 MHz.
              Yes, the boot performance level is that low.

              Comment


              • #8
                Originally posted by Jonno View Post
                The entire DRI subsystem, including KMS, is MIT licensed, so it can be ported to the BSDs. Actually, it is already ported to FreeBSD, OpenBSD and (Open)Solaris, though those ports are way out-of-date, and does not include KMS.

                The problem isn't the license of the KMS subsubsystem, the problem is that NVidia would have to move and rework a lot of the stuff from their userland blob into their kernelspace blob, and thus do a major rework of their currently quite minimal GPL licensed compatibility layer, which they don't seem to think is worth it.

                Honestly, I expect it would be less work for them to improve the current KSM drivers and update their userland blob to use the MIT licensed libdrm to talk to the open source kernel module instead, dropping their kernelspace blob entirely.

                Not that that would be easy, just less difficult than reworking their existing stuff to support KMS.
                I didn't say that KMS or DRM was GPL. Reread what I said, I said they were GPL-only, as in they explicitly won't allow the use of binary blobs, which is not a good thing. nVidia's driver provides it's own DRM subsystem and makes no use of the kernel's DRM, but there is no KMS in the nVidia driver because, from the very words of one of the developers of the binary nVidia driver, the KMS system won't allow non-GPL compatible modules to use it. It's *not* nVidia's choice of whether KMS support is in the driver as of now, and is entirely on the shortsighted KMS developers.

                Comment


                • #9
                  Which other parts of the kernel do you think should not be GPL-ed so huge multinationals can have a bit less work?

                  Comment


                  • #10
                    Originally posted by Yaro View Post
                    Either they fully support OpenGL or they fully support KMS. Never both. If you have a driver that fully supports KMS, chances are you're missing anywhere to 25 to 66 percent of support of OpenGL's features, and virtually all of OpenGL's nicer features will be missing support from the driver.
                    This, and pretty much your entire post, is false.

                    Comment

                    Working...
                    X