Bug 84759 - EXTREME and blocking drawing delay accumulation with certain websites and programs (e.g. rdesktop) since forever
Summary: EXTREME and blocking drawing delay accumulation with certain websites and pro...
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Nouveau Project
QA Contact: Xorg Project Team
Depends on:
Reported: 2014-10-07 15:49 UTC by C0NPAQ
Modified: 2019-12-04 08:50 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Xorg log (130.46 KB, text/plain)
2014-10-07 15:49 UTC, C0NPAQ
no flags Details

Description C0NPAQ 2014-10-07 15:49:20 UTC
Created attachment 107505 [details]
Xorg log

Here you can see a video of it and also more important information is in the youtube description: https://www.youtube.com/watch?v=X_c-26mB304

Like the text says, there seems to be some kind of 2D drawing action in Xorg that takes maybe a thousand times longer with nouveau than usual. But this drawing is rarely used, i.e. mostly only on window creation, so the delay doesn't get as apparent in most cases you run into (I suppose with my limited knowledge that this drawing actions are single Xlib graphic contexts like you can create with XCreateGC, created and rendered for the first time or changes in their palette or something). 

So this makes applications open in a sluggish manner and with certain programs, like in the video example, it causes insane delays (like 10ms becomes 3 minutes) that extremely impair working properly with them.

I only really ran into this on my work PC, which has slower+older GT8400 cards, but at home once I tested it with GT430 also and I would rather say that the same sluggishnes was present, but maybe due to different causes?

00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 8400 GS Rev. 3] (rev a2)
03:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8400 GS] (rev a1)
Linux WORKPAQ 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014 x86_64 GNU/Linux
X.Org X Server 1.16.1
Comment 1 Ilia Mirkin 2014-10-10 15:29:30 UTC
You must be hitting some case that we don't handle with EXA (or worse yet, some case that EXA in general doesn't handle well, but that's less likely).

One quick thing to try is to use GLAMOR -- with xf86-video-nouveau 1.0.11 you can set the AccelMode driver option to "glamor". [Note that I've seen a bunch of X crashes when glamor is enabled, and it apparently locks you out of creating core GL contexts somehow, so it's not a panacea.]

I can't tell your technical level, but if you're up for it, grab the xf86-video-nouveau source, and in nouveau_local.h switch the #if 0 to #if 1 above NOUVEAU_FALLBACK. That will print a ton of stuff in your Xorg log about which actions are falling back. Hopefully it will be easy to identify which ones are hitting the rdesktop silliness.

Also... you appear to have an uncommon X setup. You're using ZaphodHeads, but you're not using xinerama. Does that mean that everything is on separate X screens? But I also see one of the cards being added as a "GPU" card. It's all a little odd... Are you using reverse prime at all? That's probably also not the fastest thing in the world.

By the way, I assume this all works fine when running rdesktop off the intel-connected screen?
Comment 2 Martin Peres 2019-12-04 08:50:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/137.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.