Announcement

Collapse
No announcement yet.

r500 kms performance issues

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

  • #31
    @peapa: bring up the console, enter "/cg_drawFPS 1"

    Comment


    • #32
      Originally posted by bridgman
      There may be an AGP vs PCIE difference here as well. That seems to be the other common factor to people seeing lower performance with the new stack. Make sure you're running the latest -ati (X driver) as well.
      I forgot to mention that I'm running the 6.13.0 driver, so it should be alright.

      Originally posted by curaga
      @peapa: bring up the console, enter "/cg_drawFPS 1"
      Thanks ! I'm now able to provide (still not very precise) FPS numbers :
      With classic mesa, I get about 30 FPS with little drops to 25.
      With gallium, I get 40-50 FPS on average but with drops to 6-7.

      I was positively surprised when testing today, after updating mesa gallium is almost usable ! (at least with openarena) The slowdowns are less frequent and it seems that the min FPS is higher than before.

      I don't know if this is the result of specific work about the AGP performance issue and would like to know in case it isn't if there is any plan on working on this ?

      Comment


      • #33
        I'll join the club here saying that KMS feels slow, running with compositing is not an option in kde, as the redraws are painfully slow. I tried gtkperf -a and it gave a result of ~28 secs I think on my R350 AGP with a few transparent terminals up.

        Things are usually OK, but whenever there's a slight cpu load, redrawing becomes very noticable, switching a 'window' in irssi takes about a second to redraw. This computer isn't very new though, AMD A64 3000+ with 2GB RAM. And I'm running xorg 1.8, mesa 7.8.1 and DDX from a week old git. This is with color tiling enabled.

        Would switching to gallium possibly speed up compositing?

        Comment


        • #34
          Just curious, are you seeing CPU usage spike to 100% at the slow times ?
          Test signature

          Comment


          • #35
            Well, I haven't really checked the cpu, but I'll keep an eye open, I do however often notice high cpu usage by X. when scrolling web pages and similar the cpu usage is usually between 10-30% X.

            I tried to run this command on both my R350 system and an nvidia laptop using their binary blob and got the following results:

            while [ true ]; do dmesg; done

            R350: X used 80-90% cpu, the rest was the terminal and bash
            Nvidia laptop: X was around 6-8% cpu, with bash and the terminal around 20% each.

            I'm not really sure what those numbers mean though. Also when running gtkperf X uses far more cpu than the gtkperf application, usually around 50-60% cpu with gtkperf at around 30%.

            Comment


            • #36
              I can add that scrolling a web page in chromium causes X to use 100% cpu aswell, compared to other browsers that usually put X up at 20-30% when I do heavy scrolling. Maybe there's a code path somewhere that's running in pure software?

              Comment


              • #37
                Sounds strange.

                I am using d-r-t, mesa/xf86-video-ati master, mianly in UMS, but never had scrolling slowdowns. In opposite to nvidia 2D is way better, unlike OpenGL.
                UMS lakcs power management, but Dethkarz, Ignition, Madtrax, NFSHP2 arent runnable under KMS(gallium and classic, with non-glide Ignition as exception), generally Glide Wrappers(Iam using mainly Zeneck) dont like KMS.

                I got T60p with FireGL V5200(r500/256MB), T7200 and 4GB RAM (1GB GART), and using 64bit multilib system, and I can play 2 1080p h264 concurrently under UMS (recently even under KMS, but it likes breaking)

                Comment


                • #38
                  I noticed the problems with chromium went when switching to UMS, but I now get corruption every time I alt+tab between windows in KDE. If I somehow get the window to repaint it self by resizing or similar everything looks OK. gtkperf also had a ~50% speed increase comparing to KMS.

                  Comment


                  • #39
                    Hrm, these repainting issues were Mesa bugs from many months ago. I haven't seen those for a long time. But I run KMS exclusively now.

                    Comment


                    • #40
                      when i install ubuntu lucid with "KMS"=ON the 3D effect with compiz are very slow, the solution for me was to desactived KMS with this command:

                      sudo su
                      echo options radeon modeset=0 > /etc/modprobe.d/radeon-kms.conf

                      Now compiz is working fine, but i hope they gonna solve this bug soon!

                      my graphic card -> ati x1650pro agp

                      my motherboard -> asus A7N8X-Deluxe rev. 2.0

                      you can see others users having the same problem on the launchpad web site.

                      https://bugs.launchpad.net/ubuntu/+s...ti/+bug/496653

                      Comment

                      Working...
                      X