Announcement

Collapse
No announcement yet.

The Cost Of ATI Kernel Mode-Setting On Fedora 12

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

  • #16
    one more for phoronix - blindfrog is correct to note that this is being worked on even now. You may want to try with this Koji build of the ATI driver:

    http://koji.fedoraproject.org/koji/b...buildID=142974

    this build of Mesa:

    http://koji.fedoraproject.org/koji/b...buildID=142633

    this libdrm:

    http://koji.fedoraproject.org/koji/b...buildID=142111

    and this kernel:

    http://koji.fedoraproject.org/koji/b...buildID=142993

    and see how that combination performs.

    Comment


    • #17
      mplayer -vo gl2

      mplayer -vo gl2 is only for video resolutions higher than the max texture size of your openGL stack. mplayer -vo gl is better when it works. I use

      vo=gl:yuv=2:swapinterval=1:lscale=1:cscale=0 in my ~/.mplayer/config

      (gl looks better than xv when up-scaling. Less chroma blockiness, I've found.)

      Comment


      • #18
        Originally posted by AdamW View Post
        one more for phoronix - blindfrog is correct to note that this is being worked on even now. You may want to try with this Koji build of the ATI driver:

        http://koji.fedoraproject.org/koji/b...buildID=142974

        this build of Mesa:

        http://koji.fedoraproject.org/koji/b...buildID=142633

        this libdrm:

        http://koji.fedoraproject.org/koji/b...buildID=142111

        and this kernel:

        http://koji.fedoraproject.org/koji/b...buildID=142993

        and see how that combination performs.
        Well done! Excellent job! +200 FPS on glxgears. So for now, we are at 900 FPS without composition, and 700 FPS under kwin composition.

        So 200 down, at least 1000 to go (I hope one day this driver will accelerate glxgears up to 3000 FPS on my graphics card, as fglrx used to do).

        Comment


        • #19
          I own a X1600pro AGP. Since Kernel-Modesetting introduction, XV playback took an enormous hit. As of today, I simple cannot playback x264/720p content (at least, nothing with a length of 5+ minutes) without hogging my CPU time. It gives an impression that is leaking somehow memory, consuming my CPU as time goes by.

          I must say that these x264 files are part of a collection and used to play without major problems before KMS/GEM/DRI2 introduction.

          Also (this is new) on Fedora 12 ( tested on release day) and Ubuntu Lucid (My actual OS) using KMS (ON) + AGPMODE (8x) compiz, while is on, turns the system unbearably slow. I mean, even a click on the gnome menu takes seconds to actually happen.

          These issues are known to the devs?

          PS: I'm using radeon, mesa, etc from xorg-edgers PPA and AFAIK those packages are up-to-date.
          Last edited by hobbes; 11-25-2009, 07:29 PM.

          Comment


          • #20
            dodoent: glxgears is not a benchmark, it's not even anywhere close. It would be a much better idea to test with something more resembling real world use than three extremely simple non-lit, non-textured, rotating shapes. Phoronix's own benchmarks are probably the best thing for 3D testing on Linux, actually. Try those.

            hobbes: on a quick search I can't find a report of that problem in Fedora or freedesktop.org Bugzilla, or Launchpad. You might want to file a report at fd.o or Launchpad, I guess. Have you verified that it works OK if you disable KMS (nomodeset)?

            Comment


            • #21
              Originally posted by bugmenot View Post
              What is the actual *reason* that it is slower?

              Will color tiling be enabled with an update?

              Thanks devs, you are doing an awesome job by the way.

              A similar thing happened with the Intel drivers transition away from multiple independent drivers to a unified memory management model.

              It came in stages, one after a while, and performance and stability suffered. KMS, GEM, UXA, etc etc. One feature after another.

              Then you ended up with the low-point of reliability and performance when you had the Xorg driver that supported all the different combination of legacy and next-gen features. You could choose to go with the older stuff and get better performance in the benchmarks, or go with the newer stuff and get better usability with composited desktops.

              Now, finally, with Fedora 12 the Intel drivers dropped the support for the legacy stuff and now rely entirely on KMS, UXA, and GEM all being functional. Now you have Phoronix articles praising the performance of F12 isntead of trying to account for the loss of performance in different Ubuntu versions.

              Hopefully with the Radeon stuff they will take a more aggressive approach and thus shorten the time that users must suffer through the transition period, but I don't know how practical that will be considering the restricted resources in terms of time and manpower that goes on with typical X development stuff. The faster they can move to the unified memory management and get away from relying on the DDX for everything the faster they can concentrate on improving performance and application/game compatibility and introducing Gallium features.

              And, yes, cheers to the developers. Everybody needs this stuff to work and I know it is hard work. Thank you.

              Comment


              • #22
                "Now, finally, with Fedora 12 the Intel drivers dropped the support for the legacy stuff and now rely entirely on KMS, UXA, and GEM all being functional."

                This isn't actually true. You can still use UMS (kernel parameter 'nomodeset') and EXA or XAA (AccelMethod in xorg.conf) on F12, if you really want to. You won't get a lot of interest from the developers if they turn out to be broken, but the codepaths are still there and mostly working.

                Comment


                • #23
                  Originally posted by AdamW View Post
                  one more for phoronix - blindfrog is correct to note that this is being worked on even now. You may want to try with this Koji build of the ATI driver:

                  http://koji.fedoraproject.org/koji/b...buildID=142974

                  this build of Mesa:

                  http://koji.fedoraproject.org/koji/b...buildID=142633

                  this libdrm:

                  http://koji.fedoraproject.org/koji/b...buildID=142111

                  and this kernel:

                  http://koji.fedoraproject.org/koji/b...buildID=142993

                  and see how that combination performs.
                  There are a lot of things that are right with Fedora, but handling updates is not one of them. Sometimes an update gets stuck in testing limbo for ages (and nobody tests them either), despite the corresponding "stable" packages being pretty much broken.

                  Comment


                  • #24
                    Originally posted by ufaogros View Post
                    This isn't news. I have filled bugs against this issue (https://bugzilla.redhat.com/show_bug.cgi?id=533244
                    You may want to take a look here: http://bugs.freedesktop.org/show_bug.cgi?id=22743
                    This was a darkplaces bug, not a driver bug.

                    Comment


                    • #25
                      Originally posted by remm View Post
                      There are a lot of things that are right with Fedora, but handling updates is not one of them. Sometimes an update gets stuck in testing limbo for ages (and nobody tests them either), despite the corresponding "stable" packages being pretty much broken.
                      None of those packages are 'updates', yet. The developers are still working on them and haven't decided to submit them as official updates.

                      Comment


                      • #26
                        Originally posted by hobbes View Post
                        These issues are known to the devs?
                        The XV high Cpu issue is known to the devs, so will hopefully get better with time.

                        Comment


                        • #27
                          There's a blog post by Dave Airlie about this stuff here:

                          http://airlied.livejournal.com/69074.html

                          it notes that some of the performance 'regression' is due to the new driver doing vsync, which we wouldn't want to disable (as you get tearing without it).

                          Comment


                          • #28
                            Originally posted by AdamW View Post
                            None of those packages are 'updates', yet. The developers are still working on them and haven't decided to submit them as official updates.
                            What actually happens is that, even in cases where current packages are demonstrably broken (as in, the user's installation no longer boots), propagating an update often takes days and days.

                            Comment


                            • #29
                              Indeed. This is because it's not as simple as slapping together a fix and stuffing it out, as that's what causes regressions.

                              It's funny, most people complain about Fedora updating too much, not too little.

                              Comment


                              • #30
                                I guess the specific complaint here is "updating too much in the initial release and *then* updating too little"

                                The tricky part is that post-release changes may be a big help for one group of users but a big problem for others, and figuring out which potential improvements should be released as updates can require as much or more testing than the original release.

                                In that case I guess there's a good argument for making most of the potential updates available only for cherry-picking by the user rather than something more-or-less automatic.
                                Last edited by bridgman; 11-27-2009, 12:14 PM.

                                Comment

                                Working...
                                X