Announcement

Collapse
No announcement yet.

r500 kms performance issues

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

  • r500 kms performance issues

    i recently upgraded to 2.6.33 with it's newly "unstaged" r500 kms - and i have to wonder, does this mean that this is as good as it'll get ?..

    when i had last tried kms i had to disable it because of numerous bugs and deep performance loss. that was back in the 2.6.31 days.

    although things seem pretty stable, i have to say that performance hasnt really improved. compositing with kwin is bareable but nowhere near "smooth" ... playing video is choppy, opengl performance is at best acceptable but often times hangs and drops ... and one time trying to play a small cell phone video full screen caused my whole computer to die.

    so obviously, alot of work still has to be done. but im afraid this whole 'leaving of stading' means that you guys consider this driver 'good enough' ..

    i just have to say, it just isnt good enough ..

  • #2
    ???

    Asking if something is considered to be "good enough" is totally meaningless. Good enough for what ?

    Good enough in terms of kernel API maturity that it's safe to freeze the internal APIs and move it out of staging ? Yes.

    Good enough on balance (improvements vs drawbacks) that most major distros consider it worth using instead of the UMS code paths ? Yes.

    Good enough that it's never going to be improved ? Highly unlikely.

    Comment


    • #3
      Note that the KMS performance hits are highly system-specific - eg on balance my system feels as fast or faster with KMS than with UMS.

      I think the limiting factor is CPU power (ie the KMS code uses more CPU cycles than the UMS code), so it's extra important to make sure that your power management settings aren't slowing down the CPU when you need it.

      Comment


      • #4
        Originally posted by pedepy View Post
        i recently upgraded to 2.6.33 with it's newly "unstaged" r500 kms - and i have to wonder, does this mean that this is as good as it'll get ?..

        when i had last tried kms i had to disable it because of numerous bugs and deep performance loss. that was back in the 2.6.31 days.

        although things seem pretty stable, i have to say that performance hasnt really improved. compositing with kwin is bareable but nowhere near "smooth" ... playing video is choppy, opengl performance is at best acceptable but often times hangs and drops ... and one time trying to play a small cell phone video full screen caused my whole computer to die.

        so obviously, alot of work still has to be done. but im afraid this whole 'leaving of stading' means that you guys consider this driver 'good enough' ..

        i just have to say, it just isnt good enough ..
        you have something wrong in your pc, you checked the firmware is loading? cuz for me the OSS driver is just peachy both in my big pc and my crappy x1200 laptop

        try ubuntu 10.04 with xorg crackers and 2.6.34 kernel, maybe you have something old in your graphic stack like drm or mesa or even the ddx

        Comment


        • #5
          Originally posted by bridgman View Post
          I think the limiting factor is CPU power (ie the KMS code uses more CPU cycles than the UMS code), so it's extra important to make sure that your power management settings aren't slowing down the CPU when you need it.
          This is, I hope, a temporary feature.

          Comment


          • #6
            Make sure every graphic stack component on your system is up-to-date.
            2.6.33 or 2.6.34rc alone is not enough.
            For a smooth KMS experience you need :
            - last libdrm
            - xserver 1.8 or at least 1.7.x
            - latest xf86-video-ati
            - a reasonably recent MESA snapshot

            As for the CPU I indeed noticed myself that "Dynamic / Ondemand" CPU policy makes GTK (Firefox) scrolling a bit sluggish and cuts 60% of glxgears. I guess it's better to stick to "performance" mode for now.
            On the bright side, radeon.dynpm=1 doesn't bring any visible performance drawbacks and seems to make the laptop surface a bit cooler.

            Comment


            • #7
              I have to agree. Not to dismiss your experience, which sounds less than perfect, but full-screen HD video works just fine here with KMS, and while I too hope for performance improvements in the future, there is no problem whatsoever with any window effects, compositing, or most 3D stuff I use daily. Granted, my GPU is a r700 generation, but I haven't heard r500 owners experience these problems either.

              Like dmfr says, try updating all the parts of the stack to the latest stable versions. There must be some problem hidden somewhere.

              Comment


              • #8
                1) KMS is slower because color tiling in DDX is disabled by default. You need to enable it in xorg.conf, see "man radeon". The man page is for UMS so it lies sometimes.
                2) You might try the R300 Gallium3D driver, it's generally faster than the classic one and has much more features (the feature set is similar to fglrx).
                3) Newer kernels like 2.6.34-rcN might improve performance a bit, but not much.

                Comment


                • #9
                  4) You don't need the latest X server, I mean even 1.6.x should be fine.

                  Comment


                  • #10
                    Originally posted by marek View Post
                    4) You don't need the latest X server, I mean even 1.6.x should be fine.
                    I'm no dev, just a happy end user...

                    From my humble point of view, KMS became usable after upgrading to xserver 1.7. Before that it worked, but it sucked.
                    Now full HD, kwin compositing work alright and, most important, KDE4 feels "sharp".
                    Don't know if it's DRI/DRI2 related or anything, I'm just sure of the facts.

                    Besides, when it comes to play with bleeding edge features, I guess it's worth the shot upgrading the whole stack, to avoid performance related reports or complaints (major or minor) on issues solved in recent versions.

                    Comment


                    • #11
                      Hmm, every gallium test I've done has shown it to be slower.

                      Originally posted by marek View Post
                      You might try the R300 Gallium3D driver, it's generally faster than the classic one and has much more features (the feature set is similar to fglrx).
                      I've got an AGP RV350 card and a dual P4 Northwood PC, and for simple loads like celestia and OpenGL xscreensavers I am finding that classic Mesa is still beating Gallium hands down. That's for both "performance" and "correctness"; obviously Gallium beats classic Mesa on "features" ;-).

                      For example, try right-clicking on the Earth in celestia and rotating it: it's wonderfully responsive with classic Mesa, but drags horribly with Gallium.

                      Gallium renders the stars wrongly, too.

                      And don't even think of trying to play World of Warcraft using Gallium, although it can be "persuaded" to play more-or-less correctly under classic Mesa if you're prepared to hack it around slightly:
                      Code:
                      diff --git a/src/mesa/drivers/dri/r300/r300_cmdbuf.c b/src/mesa/drivers/dri/r300
                      index c40802a..7f009d9 100644
                      --- a/src/mesa/drivers/dri/r300/r300_cmdbuf.c
                      +++ b/src/mesa/drivers/dri/r300/r300_cmdbuf.c
                      @@ -452,7 +452,7 @@ static void emit_zb_offset(GLcontext *ctx, struct radeon_sta
                              uint32_t dw = atom->check(ctx, atom);
                       
                              rrb = radeon_get_depthbuffer(&r300->radeon);
                      -       if (!rrb)
                      +       if ((rrb == NULL) || (rrb->cpp == 0))
                                      return;
                       
                              zbpitch = (rrb->pitch / rrb->cpp);
                      diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c b/src/mesa/drivers/dri/
                      index 13f1f06..e00c995 100644
                      --- a/src/mesa/drivers/dri/radeon/radeon_common.c
                      +++ b/src/mesa/drivers/dri/radeon/radeon_common.c
                      @@ -1126,7 +1126,7 @@ void radeonFlush(GLcontext *ctx)
                                      rcommonFlushCmdBuf(radeon, __FUNCTION__);
                       
                       flush_front:
                      -       if ((ctx->DrawBuffer->Name == 0) && radeon->front_buffer_dirty) {
                      +       if ((ctx->DrawBuffer != NULL) && (ctx->DrawBuffer->Name == 0) && radeon-
                                      __DRIscreen *const screen = radeon->radeonScreen->driScreen;
                       
                                      if (screen->dri2.loader && (screen->dri2.loader->base.version >=

                      Comment


                      • #12
                        Was that second part of diff horizontally truncated?

                        Comment


                        • #13
                          Possibly - I'll try again...

                          Originally posted by nanonyme View Post
                          Was that second part of diff horizontally truncated?
                          Code:
                          diff --git a/src/mesa/drivers/dri/r300/r300_cmdbuf.c b/src/mesa/drivers/dri/r300/r300_cmdbuf.c
                          index c40802a..7f009d9 100644
                          --- a/src/mesa/drivers/dri/r300/r300_cmdbuf.c
                          +++ b/src/mesa/drivers/dri/r300/r300_cmdbuf.c
                          @@ -452,7 +452,7 @@ static void emit_zb_offset(GLcontext *ctx, struct radeon_state_atom * atom)
                                  uint32_t dw = atom->check(ctx, atom);
                           
                                  rrb = radeon_get_depthbuffer(&r300->radeon);
                          -       if (!rrb)
                          +       if ((rrb == NULL) || (rrb->cpp == 0))
                                          return;
                           
                                  zbpitch = (rrb->pitch / rrb->cpp);
                          diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c b/src/mesa/drivers/dri/radeon/radeon_common.c
                          index 13f1f06..e00c995 100644
                          --- a/src/mesa/drivers/dri/radeon/radeon_common.c
                          +++ b/src/mesa/drivers/dri/radeon/radeon_common.c
                          @@ -1126,7 +1126,7 @@ void radeonFlush(GLcontext *ctx)
                                          rcommonFlushCmdBuf(radeon, __FUNCTION__);
                           
                           flush_front:
                          -       if ((ctx->DrawBuffer->Name == 0) && radeon->front_buffer_dirty) {
                          +       if ((ctx->DrawBuffer != NULL) && (ctx->DrawBuffer->Name == 0) && radeon->front_buffer_dirty) {
                                          __DRIscreen *const screen = radeon->radeonScreen->driScreen;
                           
                                          if (screen->dri2.loader && (screen->dri2.loader->base.version >= 2)
                          I don't know if either is "correct" in any sense other than they stop Mesa core-dumping when I play WoW.

                          Comment


                          • #14
                            Both of them make sense anyway. Division by zero protection and NULL dereference protection. You probably checked that both are needed for it to work and not just one?

                            Comment


                            • #15
                              Yes, but I still think they paper over deeper problems

                              Originally posted by nanonyme View Post
                              Both of them make sense anyway. Division by zero protection and NULL dereference protection. You probably checked that both are needed for it to work and not just one?
                              The "division by zero" protection produces lots of "no rrb" messages on my console log, which makes me suspect that it should really be trying to divide by something non-zero instead. (Some "state" is probably not being set.)

                              The "NULL protection" affects the context's clean-up path.

                              These bugs have already been raised in FDO's bugzilla as #27199 and #27141 respectively.

                              Comment

                              Working...
                              X