Bug 22740

Needs the usual info (Xorg.0.log, dmesg, sysprof if your performance problem is when the CPU is near 100% busy)

http://pastebin.com/m6b1b70ed - dmesg
http://pastebin.com/m406d6b11 - Xorg.0.log

> --- Comment #2 from Mateusz Tracz <matiqing@gmail.com>  2009-07-14 01:34:56 PST ---
> http://pastebin.com/m6b1b70ed - dmesg
> http://pastebin.com/m406d6b11 - Xorg.0.log

please always attach files directly on bugzilla instead of using
pastebin sites where they can expire…

I'll remember for future

Anybody?

You won't do anything?

Is the CPU near 100% use during scrolling?  If so, could you run sysprof and attach the results?

(please remove NEEDINFO keyword when updating the bug with requested information)

No CPU is less than 15% when scrolling

I note that with KMS enabled it is little better. Of course still it is horrible.

Anybody has a similar problem?...

unblocking Q3 release, but still a high priority bug.

This sounds like Opera may very well be using PutImage when scrolling.

Mateusz, does
commit 19d8c0cf50e98909c533ebfce3a0dd3f72b755c1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Nov 29 21:16:49 2009 +0000

    uxa: PutImage acceleration
    
    Avoid waiting on dirty buffer object by streaming the upload to a fresh,
    non-GPU hot buffer and blitting to the destination.
    
    This should help to redress the regression reported in bug 18075:
    
      [UXA] XPutImage performance regression
      https://bugs.freedesktop.org/show_bug.cgi?id=18075
    
    Using the particular synthetic benchmark in question on a g45:
    
    Before:
       9542.910448 Ops/s; put composition (!); 15x15
       5623.271889 Ops/s; put composition (!); 75x75
       1685.520362 Ops/s; put composition (!); 250x250
    
    After:
      40173.865300 Ops/s; put composition (!); 15x15
      28670.280612 Ops/s; put composition (!); 75x75
       4794.368601 Ops/s; put composition (!); 250x250
    
    which while not stellar performance is at least an improvement. As
    anticipated this has little impact on the non-fallback RENDER paths, for
    instance the current cairo-xlib backend is unaffected by this change.
    
improve performance for scrolling in Opera?

Mateusz, have you had time to try the patch posted in comment #12?

I don't have Opera, hence why it is difficult to determine which paths are causing the slow behaviour whilst scrolling. Even though the cpu is only at 15% utilisation, a perf profile would help identify the hot paths, and an xtrace would like us know the macro requests being issued. Together that might be enough to identity the cause and whether we can improve our driver. Thanks.

I was pointed to an opera package which I duly installed to find the reason for Opera being slow...

They have implemented a client side renderer which uses *PutImage* into a backing store and then CopyArea onto their window. The aforementioned patch will help a lot, but this is always going to be slow (and slower in UXA due to relocation overhead). The driver does now support SHM Pixmaps which can be used by client side software renderers to minimise transport costs.