Bug 595405 - [nouveau] XCopyArea with GXand approx 1000 times slower than GXcopy (affects openoffice.org-impress performance)
Summary: [nouveau] XCopyArea with GXand approx 1000 times slower than GXcopy (affects ...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-drv-nouveau
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Ben Skeggs
QA Contact: desktop-bugs@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-24 14:30 UTC by Jay Turner
Modified: 2015-01-08 00:17 UTC (History)
5 users (show)

Fixed In Version: xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-07-15 15:57:05 UTC
Target Upstream Version:

Attachments (Terms of Use)
Sample presentation (67.63 KB, application/vnd.oasis.opendocument.presentation)
2010-05-24 14:30 UTC, Jay Turner
no flags Details
standalone demo, compile with gcc XCopyArea.c -lX11 (1.15 KB, text/plain)
2010-05-26 12:04 UTC, Caolan McNamara
no flags Details
binary (6.30 KB, text/plain)
2010-05-26 12:05 UTC, Caolan McNamara
no flags Details
dmesg output from Sony Vaio (121.80 KB, text/plain)
2010-05-27 12:23 UTC, Jay Turner
no flags Details
/var/log/messages from Sony Vaio (16.27 MB, text/plain)
2010-05-27 12:25 UTC, Jay Turner
no flags Details
/var/log/Xorg.0.log (31.17 KB, text/plain)
2010-05-27 12:26 UTC, Jay Turner
no flags Details

Description Jay Turner 2010-05-24 14:30:46 UTC
Created attachment 416143 [details]
Sample presentation

Description of problem:
Impress is really slow when working with the attached (redacted) slide deck.  I did not get a chance to dig in too much, but everything from opening the presentation to navigating the slides themselves takes an inordinate amount of time under RHEL6 as well as F13.  RHEL5.5 users seem to indicate acceptable performance.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open the presentation and attempt to navigate around.
Actual results:

Expected results:

Additional info:

Comment 1 Caolan McNamara 2010-05-24 14:44:52 UTC
Speedy for me, this is only a fairly trivial 7 slide deck. I hate any potentially subjective bugs, real nightmare to state a win position on. Is there any particular hard numbers which we can attach to this, e.g. starting on slide 1, click on slide 2, takes X seconds to redraw ?.

caolanm->dtardon: Is this obviously slow for you ?

Comment 2 Jay Turner 2010-05-24 17:20:35 UTC
Sorry, been meaning to add some more data here and got side-tracked.  I'm seeing the slowness on both of my machines (Sony VAIO laptop and Intel SDV.)  Both machines have nVidia graphics cards.  I have another Intel SDV (with Intel graphics) which does not exhibit the lag.

7-8 seconds for OOo to launch and finish rendering the first slide
2-3 seconds attempting to switch to the VC with OpenOffice open
2-3 seconds attempting to switch between slides

Just discovered that unchecking the "Display Objects from Master" which has the effect of removing the background gradient, remedies the situation.

Comment 3 Caolan McNamara 2010-05-24 18:55:59 UTC
I've an Intel card here, hence the likely "speedy for me". And this is not full-screen presentation mode, but normal mode right ? (full-screen uses cairo while non-full uses normal traditional X). 

Its the nouveau driver used on the nvidia cards I assume ?

Comment 4 Jay Turner 2010-05-24 19:43:50 UTC
Yes, non-full and using the "nouveau" driver on both machines.  However you did lead me to another interesting discovery.  Full-screen works perfectly fine.

Comment 5 David Tardon 2010-05-25 05:35:53 UTC
I see nothing obvious on Rawhide with radeon driver. Will try RHEL 6 after update has finished (but that machine does have ATI card too...)

Comment 6 David Tardon 2010-05-26 08:09:57 UTC
No visible slowdown on RHEL 6 with radeon driver either.

Comment 7 Jay Turner 2010-05-26 11:16:45 UTC
Any other debugging suggestions?  From the data to this point, appears this is directly related to the Xorg driver itself (as opposed to an issue in openoffice.org itself.)

Comment 8 Caolan McNamara 2010-05-26 11:25:22 UTC
Maybe fiddle with x11perf, e.g. the -copypixwin500 options and see if there's any ridiculously different numbers on nouveau vs say intel. Though note bug 596081 for where my effort came a cropper. I'll try and see if I can make a standalone demo, which has eluded me so far

Comment 9 Caolan McNamara 2010-05-26 12:04:03 UTC
Created attachment 416784 [details]
standalone demo, compile with gcc XCopyArea.c -lX11

Comment 10 Caolan McNamara 2010-05-26 12:05:03 UTC
Created attachment 416787 [details]

Comment 11 Caolan McNamara 2010-05-26 12:07:30 UTC
caolanm->jturner: Can you run the above demo on your nouveau and report the output.

What I get for my nouveau is approx 650 milliseconds to 1 second 349 milliseconds. 
For my intel I get approx 0 to 5 milliseconds :-)

If you get a big number here, which I expect, then that's our problem I believe.

Comment 12 Matěj Cepl 2010-05-26 14:27:05 UTC
OK, I will bite a bit. Jay, could you please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* output of the dmesg command,
* system log (/var/log/messages), and
* X server log file (/var/log/Xorg.*.log)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above?

Thanks in advance.

Comment 13 Jay Turner 2010-05-26 14:48:03 UTC
Weird.  On both of my nouveau-based systems, I'm getting anywhere from 0 to 5 milliseconds.

Attempting to poke through some other stuff now.

Comment 14 Jay Turner 2010-05-27 12:23:17 UTC
Created attachment 417217 [details]
dmesg output from Sony Vaio

Comment 15 Jay Turner 2010-05-27 12:25:41 UTC
Created attachment 417220 [details]
/var/log/messages from Sony Vaio

Comment 16 Jay Turner 2010-05-27 12:26:31 UTC
Created attachment 417221 [details]

Comment 17 Ben Skeggs 2010-06-02 05:38:44 UTC
I took a bit of a look into this today.  OpenOffice appears to be doing some rendering operation that isn't accelerated by EXA (ie. it's not a driver-caused fallback), and this is *extremely* expensive on G80+ as we have to do a massive amount of math *per-pixel* to deal with pixmap tiling.

The only immediate solution I have is that for RHEL6 we switch to using the GPU to handle tiling/detiling of pixmaps as we need to do transfers for software rendering, rather than allowing the CPU to access the tiled pixmaps.

I've tested that solution, and it fixes the slowness in the presentation in question.  However, there's some slight performance regressions in the general case as a result.  Though, nothing too extreme.

Comment 18 Ben Skeggs 2010-06-02 06:00:52 UTC
A scratch build with the above-mentioned solution here: https://brewweb.devel.redhat.com/taskinfo?taskID=2486433

Comment 19 Jay Turner 2010-06-02 11:14:35 UTC
Indeed performance is significantly better with the scratch build referred to in comment 18.  Will run with that code today and see if the overall performance regression is noticeable.

Comment 20 Ben Skeggs 2010-06-08 04:12:36 UTC
Any comments on how you fared with that patch in general?

Comment 21 Jay Turner 2010-06-08 11:36:18 UTC
All apologies.  I have been meaning to update this bug and it kept slipping my mind.  Almost a week later and really have not noticed any performance issues.  From my perspective this is a candidate for release.

Comment 22 Ben Skeggs 2010-06-09 03:19:16 UTC
No worries, and I agree.  The performance impact of the change in the general case is minimal, and prevents extreme slowness in other cases.

Comment 23 Ben Skeggs 2010-06-09 04:41:33 UTC
MODIFIED xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.el6 is in brew.

Comment 24 Tomas Pelka 2010-06-22 12:40:39 UTC
No visible slowdown on xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.el6.

Jay or others could somebody confirm?

Comment 25 Jay Turner 2010-06-28 10:39:26 UTC
As I indicated in comment 21, I have not noticed any slow down at all.

Comment 26 Tomas Pelka 2010-06-28 11:10:46 UTC
Thank you, marking as verified (version in comment 24).

Note You need to log in before you can comment on or make changes to this bug.