[Nouveau] [Bug 84759] EXTREME and blocking drawing delay accumulation with certain websites and programs (e.g. rdesktop) since forever

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=84759

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20141010/b87bec4a/attachment.html>