Announcement

Collapse
No announcement yet.

RV350, compositing and horrible performance.

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

  • RV350, compositing and horrible performance.

    Hey all,

    I probably best ask some opinions here, before bombarding the ML with this.

    I have an ancient laptop, that's still going strong. An IBM T42. This is a 2004 model. It spurts a fast 2.1 GHz Pentium-M and boasts a whopping 2 GiB of ram. There's a pretty fast 32 GiB SLC IDE-SSD in it and the onboard GPU, a Radeon 9600, features 64 MiB dedicated videoram. While yes, it's almost 10 years old, it works really well and runs pretty fast/fast enough.

    Last week I've updated to Ubuntu Gnome 13.04 which features Gnome 3.6 that I upgraded to 3.8. All works well, except I find the video performance appalling. Now I understand very well that it is very old, and r300 architecture is quite dated. I also was able to play 3D games on it (a heavy 3D game via wine for example does about 7-15 FPS, but it worked well) before.

    With the new Gnome the desktop is supposedly fully hardware accelerated (e.g. composited). However things are just really slow, with the CPU sitting at its low ondemand setting mostly, so it's not the CPU being over stressed. Things like opening the 'dash' or is it 'activities' I believe it's called? takes almost 1 to 2 seconds to render. Alt-tab is also equally slow. Dragging a window around however seems fast enough.

    So where to start looking, or is the rv350 really that old that compositing desktops sucks, while 3D applications work fine. Personally I'm more thinking of blaming Gnome, since I think even 3.6 doesn't work composited on ati blobs on more recent hardware, but maybe there's something else amiss.

  • #2
    Be happy and blame gnome

    It likely uses some cpu fallback. How to check that, I have no idea.

    Comment


    • #3
      Regarding the low setting, see Pontostroy's recent thread - it seems 3d load doesn't cause ondemand to bump up.

      Comment


      • #4
        Doesn't seem likly the issue, could be of course.

        No, I think you had the idea that I totally overlooked. CPU rendering. While I have gallium 0.4 on RV350, NOT on llvmpipe, according to the info, it still takes some software fallbacks?

        So the new question arises, how do I check this? I guess I could scrounge the gnome site, and see what extensions mutter relies on and cross-reverence that with that my card supports.
        Last edited by oliver; 05 May 2013, 07:39 AM.

        Comment


        • #5
          Originally posted by oliver View Post
          Doesn't seem likly the issue, could be of course.

          No, I think you had the idea that I totally overlooked. CPU rendering. While I have gallium 0.4 on RV350, NOT on llvmpipe, according to the info, it still takes some software fallbacks?.
          If it's related to CPU governors the issue is that the CPU never ramps up to high enough frequencies to keep the GPU properly fed with data. You can force the CPU to a high performance state and see if that helps.

          Comment


          • #6
            Originally posted by agd5f View Post
            If it's related to CPU governors the issue is that the CPU never ramps up to high enough frequencies to keep the GPU properly fed with data. You can force the CPU to a high performance state and see if that helps.
            The 'low' on demand frequency is 600 MHz with imo should still be beefy enough. I'll use the performance governor and see if that matters. But it didn't matter if (due to other reasons) the CPU clock was 2.1 GHz or anything below, the desktop remained sluggish. Moving a terminal window around was perfectly smooth however. So it's not 'everything' is slugish. Scrollign large pages in FF tends to be slugish, but I'll acredit that fully to firefox.

            Mostly going to the 'hot corner' and bringing up the dash is really slow, clicking on the 'all apps' button is slow and getting text into the search field is bad.

            But first things first, performance governor tonight.

            Comment


            • #7
              Originally posted by oliver View Post
              Scrollign large pages in FF tends to be slugish, but I'll acredit that fully to firefox.
              Preferencies - Preferencies - Advanced - Common - Browsing - [ ] Activate smooth scrolling (ie deactivate it)

              Comment


              • #8
                Originally posted by oliver View Post
                Mostly going to the 'hot corner' and bringing up the dash is really slow, clicking on the 'all apps' button is slow and getting text into the search field is bad.
                How much vram does your card have? You may be running out of vram which causes thrashing in GPU memory manager (i.e., migrating stuff between gart and vram). Modern desktop compositors use a lot of memory.

                Comment


                • #9
                  Originally posted by agd5f View Post
                  How much vram does your card have? You may be running out of vram which causes thrashing in GPU memory manager (i.e., migrating stuff between gart and vram). Modern desktop compositors use a lot of memory.
                  I have a question regarding that. I saw in phoronix test that radeon pretty much is close to catalyst, except on low-end cards like 55xx, 65xx etc. There radeon suddenly is a lot slower. I think this is indeed related to memory transfer, I suspect radeon version of memory manager is inefficient when it comes to caching from system memory.

                  Comment


                  • #10
                    Originally posted by brosis View Post
                    I have a question regarding that. I saw in phoronix test that radeon pretty much is close to catalyst, except on low-end cards like 55xx, 65xx etc. There radeon suddenly is a lot slower. I think this is indeed related to memory transfer, I suspect radeon version of memory manager is inefficient when it comes to caching from system memory.
                    What is your question? vram has much better bandwidth compared to system memory from the GPU's perspective so in most cases it's preferred to store buffers in vram. If we don't have enough vram to cover all the requirements, we may end up with thrashing. There's probably room for improvement with respect to the heuristics used to decide which pools we allocate from and whether we migrate or not. A ttm de-fragmenter would probably also be helpful. Either of these are good projects that don't require low level GPU specific knowledge and could provide nice performance improvements.

                    Comment

                    Working...
                    X