RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-drv-nouveau
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Ben Skeggs
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2010-07-15 15:57:05 UTC
Target Upstream Version:
Embargoed:

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
View All

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):
3.2.0-12.4.el6

How reproducible:
Always

Steps to Reproduce:
1. Open the presentation and attempt to navigate around.
2.
3.
  
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.

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]
binary
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]
/var/log/Xorg.0.log
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.