Announcement

Collapse
No announcement yet.

ATI Radeon KMS vs. UMS With Ubuntu 10.04

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

  • #11
    Originally posted by Chewi View Post
    Can anyone explain why KMS is slower? From what I know about it, I'm not sure why it would be.
    I guess that its "kernel" nature might be the cause : switching to kernel space has a high cost.

    Comment


    • #12
      Originally posted by RealNC View Post
      Since KMS/DRI2 is supposed to be the future and be faster than UMS/DRI1, I'd say it is horrible :P
      It's supposed to be the future, and smoother. The associated memory manager (GEM/TTM) is supposed to make things like support for GL 2 and higher possible, which makes it possible to run a lot more apps and run some of them faster than before.

      I don't think anyone expected KMS/DRI2 to be faster in other ways or claimed that it would be (other than things like terminal switching and improvements related to higher levels of GL support)... the challenge is to add the capability for *new* functionality without making *existing* functionality too much slower.
      Test signature

      Comment


      • #13
        Nice though the window control buttons are still on the left side!

        Comment


        • #14
          Originally posted by zoomblab View Post
          Nice though the window control buttons are still on the left side!
          *sigh*

          I take that this is a joke.

          Comment


          • #15
            I doubt that any optimisations are done yet on KMS code and DRI2.

            Comment


            • #16
              Having just jumped through a few hoops to get kms working on an ati x700 mobile card, my impression is that the new mesa/gallium/whatever is slower at doing the easy stuff: lighting, textures, moving triangles etc. But, and this is the big "but", it supports newer effects, for example in nexuiz normal performance with dynamic lighting takes a (qualitatively) significant performance hit, but the game now runs with blur and bloom effects enabled. Before upgrading, enabling these effects made the game switch from frames per second to seconds per frame.

              I personally have high hopes for this new graphic stack (having being declared obsolete by the ATI fglrx stack), and I'm pretty confident that with some cleaning up and optimization it will overtake the old one. It's just a little green around the ears.

              Comment


              • #17
                Originally posted by xir_ View Post
                thanks for these results. It seems to be shame that the KMS isnt working as well.
                Not yet, but afaik they're working on features first and then they'll be working on optimizations. However, only one game wasn't using Quake engine here and KMS was faster there. I'd like to see some other games like Flight Gear which is unplayable with UMS on my hardware/drivers, Vdrift was also unplayable on some tracks, but I didn't tried with KMS.

                Additionally it would be really cool to see if BFS has any affect at all. Especially if you were to run it concurrently with a background compilation of a kernel.
                If you have some time why don't you do this yourself? :> I'm also interested. I will probably do this, but when 2.6.33 will get into Arch Linux core repository and the newest open source radeon driver.

                Comment


                • #18
                  Originally posted by B4ud3 View Post
                  I guess that its "kernel" nature might be the cause : switching to kernel space has a high cost.
                  That makes it faster, not slower
                  I'm guessing this is probably because it is new code that isn't perfectly stable yet, it depends on new code (GEM/TTM), and it isn't fully optimized.

                  Comment


                  • #19
                    Part of the problem is due to vline waiting for buffer swaps in the dri2 paths. This avoids tearing at the expense of performance (you can't really see more frames than the monitor can display, but...). This should be alleviated with page-flipping support. Try this ddx patch:

                    Code:
                    diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
                    index 103972f..7ddcda0 100644
                    --- a/src/radeon_dri2.c
                    +++ b/src/radeon_dri2.c
                    @@ -313,7 +313,7 @@ radeon_dri2_copy_region(DrawablePtr drawable,
                         }
                     
                         vsync = info->accel_state->vsync;
                    -    info->accel_state->vsync = TRUE;
                    +    //info->accel_state->vsync = TRUE;
                     
                         (*gc->ops->CopyArea)(&src_pixmap->drawable, &dst_pixmap->drawable, gc,
                                              0, 0, drawable->width, drawable->height, 0, 0);

                    Comment


                    • #20
                      Shouldn't VSync be controllable from user space? There's a "VSync" checkbox in KDE's settings, for example, that's supposed to only work with DRI2.

                      Comment

                      Working...
                      X