Announcement

Collapse
No announcement yet.

Intel's Patches Proposed For Adding Legacy UMS

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

  • Intel's Patches Proposed For Adding Legacy UMS

    Phoronix: Intel's Patches Proposed For Adding Legacy UMS

    Back in July we reported on driver work done by Intel's Chris Wilson to add back user-space mode-setting support to the Intel X.Org DDX driver (xf86-video-intel) to allow those with older Intel (i8xx) chipsets where kernel mode-setting can be buggy to at least have a decent experience with UMS. Intel was quick to strip out user mode-setting support from their X.Org driver once their KMS support was stabilized, but it turns out that old Intel hardware with UXA (the GEM-ified EXA) and kernel mode-setting was buggy and could lead to artifacts and stability issues. These problems had led Ubuntu and other distribution vendors to use old Intel drivers so that they wouldn't be shafting a small percent of their users with vintage Intel hardware...

    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
    Why, again, is it better to do this than fix the bugs in the KMS code?

    I don't know a whole lot about the details of the systems in question, but it seems to me that if you really want to do modesetting in userspace, you should have a userspace modesetting daemon that gets called by the kernel's KMS code. That way, you can get some of the benefits of KMS without actually using the KMS code that fiddles with the GPU registers.

    Comment


    • #3
      Originally posted by waucka View Post
      Why, again, is it better to do this than fix the bugs in the KMS code?

      I don't know a whole lot about the details of the systems in question, but it seems to me that if you really want to do modesetting in userspace, you should have a userspace modesetting daemon that gets called by the kernel's KMS code. That way, you can get some of the benefits of KMS without actually using the KMS code that fiddles with the GPU registers.
      The UMS code should be in a library instead of directly into the driver, or provided as a totally separate driver as a fallback till KMS is fully stabilized and bug free.

      So why dump all that old code back directly into the driver at the risk of destabilizing it?

      Just my 2 cents

      Comment


      • #4
        Imo a respectable thing to admit having made an incorrect judgement in dropping UMS so early.

        Comment


        • #5
          It seems as though Intel wants to drop all 8xx users and isn't willing to spend the money on developers to fix the drivers for that hardware. But distros are unwilling to stop supporting it, so to keep them happy Intel is just sticking the old UMS code back in rather than actually fixing the drivers like they should.

          Yuck.

          Comment


          • #6
            Originally posted by smitty3268 View Post
            It seems as though Intel wants to drop all 8xx users and isn't willing to spend the money on developers to fix the drivers for that hardware. But distros are unwilling to stop supporting it, so to keep them happy Intel is just sticking the old UMS code back in rather than actually fixing the drivers like they should.

            Yuck.
            Agree, disgusting behavior. Just fix KMS to work with 18xx, so that they get cool booting graphics, etc. It shouldn't be hard.

            Comment


            • #7
              Originally posted by stan View Post
              Agree, disgusting behavior. Just fix KMS to work with 18xx, so that they get cool booting graphics, etc. It shouldn't be hard.
              Are you a graphics driver developer or how come you consider yourself capable of making that judgement?

              Comment


              • #8
                Originally posted by nanonyme View Post
                Are you a graphics driver developer or how come you consider yourself capable of making that judgement?
                No need for ad-hominem attacks.

                It shouldn't be hard because all the hardware workarounds are present in the userspace driver, and they just need to be copied into the kernel's DRM files. It's infinitely easier than writing code from scratch, where you need documentation or reverse engineering.

                What Intel is doing is to create a whole new driver, duplicating execution paths, which will individually be less thoroughly tested and therefore gather even more bugs. Very stupid.

                Comment


                • #9
                  Urgh, this is bad, but Intel developers have made a couple really silly decisions in the past 2 years. Remember the chaos when GEM and UXA was introduced? (early '09)

                  Let's hope it stops.

                  Comment


                  • #10
                    Originally posted by waucka View Post
                    Why, again, is it better to do this than fix the bugs in the KMS code?
                    It's not. They (The Intel Developers) would much prefer to find and fix the coherency bugs plaguing the i8xx hardware when using KMS/GEM. Unfortunately, they can't.

                    It looks to me that Chris Wilson (working for Intel) and David Vetter (volunteer) are the only ones actually trying to solve it though.

                    Comment

                    Working...
                    X