Announcement

Collapse
No announcement yet.

r600g makes kwin eat 100% CPU

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

  • r600g makes kwin eat 100% CPU

    I compiled the latest r600g and kwin (4.5.1) immediately starts (ab)using 100% CPU when desktop effects are enabled. It's interesting that kwin does this even when every desktop effect is turned off. Small OpenGL I've tried appear to be faster and do not do this.

    I also see this in dmesg, only once, the first time kwin starts:

    radeon 0000:01:05.0: ffff88015781b000 reserve failed for wait

    My 2.6.36-rc5-git4 kernel is old, but not that old, so it should be new enough.

    Is there more incriminating evidence I can provide? Are there any fancy commands I can run to gather any usefull information regarding what is going on?

  • #2
    start with "top" to see which task uses all those cpu cycles. If you can run that task isolated, try doing so with a debugger or profiler attached to narrow down the heavily used functions.

    Comment


    • #3
      Originally posted by rohcQaH View Post
      start with "top" to see which task uses all those cpu cycles. If you can run that task isolated, try doing so with a debugger or profiler attached to narrow down the heavily used functions.
      As said, the process using 100% CPU is named "kwin"...

      Comment


      • #4
        Hello,

        I second this bug with mesa r600g from git and ddx driver from git,

        my card is rv770.

        Comment


        • #5
          mmmm, i have this issues too on my 4850x2. remember that kde 4.5.1 is heavier on the gpu than the previous 4.4 branch.

          this optimization doesn't only apply to the desktop effects area like lanczos filter which seems to be quite rough on the gpu(if the gpu fallback to the cpu), so go to K->System Settings->Application appereance->fine tuning and set graphical effects to "Low display resolution and Low cpu" this should effectively disable the lanczos filters.

          i haven't tested it in my home yet (where i have my radeon card) but sometime ago i got that issues with r600c too and disabling lanczos effectively give my performance back. ofc maybe ou have another set of issues around too but is chuck norris can be wrong me too

          Comment


          • #6
            another solution you could use is download this tool

            http://kde-apps.org/content/show.php...content=129817

            and set qt to draw through raster system (opengl can get messy) instead of X11, to me the difference is amazing in the render speed (specially with nouveau)

            another one is try to run kwin from konsole after setting mesa to debug mode, maybe you can get some info on the fallbacks

            Comment


            • #7
              Originally posted by xiando View Post
              As said, the process using 100% CPU is named "kwin"...
              then you can run
              Code:
              kwin --replace
              in a profiler.

              You could use valgrind's callgrind or oprofile or sysprof or anything you like.

              Comment


              • #8
                Originally posted by rohcQaH View Post
                then you can run
                Code:
                kwin --replace
                in a profiler.

                You could use valgrind's callgrind or oprofile or sysprof or anything you like.
                Thanks.

                Looks like it'll take a while before I do this, it appers I will need to rebuild a whole range of packages before I can get anything from valgrind. I strip symbols and compile with CFLAGS "-march=amdfam10 -O2 -pipe" and use LD flags "-Wl,--as-needed"... :-(

                Code:
                $ valgrind kwin --replace
                ==26485== Memcheck, a memory error detector
                ==26485== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
                ==26485== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
                ==26485== Command: kwin --replace
                ==26485==
                
                valgrind:  Fatal error at startup: a function redirection
                valgrind:  which is mandatory for this platform-tool combination
                valgrind:  cannot be set up.  Details of the redirection are:
                valgrind:
                valgrind:  A must-be-redirected function
                valgrind:  whose name matches the pattern:      strlen
                valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
                valgrind:  was not found whilst processing
                valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
                valgrind:
                valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
                valgrind:  package on this machine.  (2, longer term): ask the packagers
                valgrind:  for your Linux distribution to please in future ship a non-
                valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
                valgrind:  that exports the above-named function using the standard
                valgrind:  calling conventions for this platform.
                valgrind:
                valgrind:  Cannot continue -- exiting now.  Sorry.
                I'll probably have to do FEATURES="nostrip", not sure if CFLAGS and LD flags matter.. do they?

                Comment


                • #9
                  I just love
                  FEATURES="splitdebug"

                  It'll install lean stripped binaries to your system, but dumps debug symbols to /usr/lib/debug/ if they're ever needed.

                  Keep your other flags as they are.

                  re-emerging glibc, mesa and kwin should be enough for a quick glance.

                  Comment


                  • #10
                    Originally posted by rohcQaH View Post
                    I just love
                    FEATURES="splitdebug"

                    It'll install lean stripped binaries to your system, but dumps debug symbols to /usr/lib/debug/ if they're ever needed.

                    Keep your other flags as they are.

                    re-emerging glibc, mesa and kwin should be enough for a quick glance.
                    The Valgrind just dies on me. "vex amd64->IR: unhandled instruction" and some bytes.

                    http://www.phoronix.com/forums/showthread.php?p=150268

                    I also have some strange feeling I should be trying to figure out what gdb is and how that works instead of the valgrind, but what do I know, I'm just this guy on the internet(s).

                    Comment


                    • #11
                      https://bugs.freedesktop.org/show_bug.cgi?id=30483

                      Comment


                      • #12
                        Originally posted by rohcQaH View Post
                        I just love
                        FEATURES="splitdebug"


                        It'll install lean stripped binaries to your system, but dumps debug symbols to /usr/lib/debug/ if they're ever needed.

                        Keep your other flags as they are.

                        re-emerging glibc, mesa and kwin should be enough for a quick glance.
                        indeed !

                        I haven't enabled it yet but will do in the features in case anything goes wrong I can quickly debug it

                        didn't know of that flag / feature yet

                        thanks !

                        Comment


                        • #13
                          kwin with desktop effects enabled + r600g (current git) is now down to using 20% CPU when doing absolutely nothing on an idle desktop, which is much better but still way too high. It is still slow and jerky when used, but atleast it can be (ab)used at this point.

                          Comment


                          • #14
                            Note that splitdebug only takes hard disk space, it doesn't slow down runtime so you can as well keep it always on since hard disk space is cheap and recompiling takes time.

                            Comment

                            Working...
                            X