Page 1 of 4 123 ... LastLast
Results 1 to 10 of 31

Thread: RV350, compositing and horrible performance.

  1. #1
    Join Date
    Jan 2007
    Posts
    418

    Default 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. #2
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,182

    Default

    Be happy and blame gnome

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

  3. #3
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,182

    Default

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

  4. #4
    Join Date
    Jan 2007
    Posts
    418

    Default

    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-05-2013 at 07:39 AM.

  5. #5
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote 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.

  6. #6
    Join Date
    Jan 2007
    Posts
    418

    Default

    Quote 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.

  7. #7
    Join Date
    Jan 2013
    Posts
    1,021

    Default

    Quote 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)

  8. #8
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote 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.

  9. #9
    Join Date
    Jan 2013
    Posts
    1,021

    Default

    Quote 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.

  10. #10
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •