Bug 59539 - Frame rate drops significantly when changing monitor resolution for plugable hardware
Summary: Frame rate drops significantly when changing monitor resolution for plugable ...
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2013-01-18 01:21 UTC by Stephen Liang
Modified: 2013-01-18 13:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Stephen Liang 2013-01-18 01:21:54 UTC
I have a plugable UD-160 running on udl. It requires me to run a xrandr command before I can use the screen. Once I execute the command, the frame rate drops significantly and the mouse can be seen as moving extremely slowly. This did not occur in an older version of the intel driver, so I bisected the code and the offending commit is:

commit c789d06cf8a0debc67058d7be1483f5b542e2baa

I'm currently running the commit before that, 5891c89ff2be277d1a833d4bc092b65184c1f3d6, and it works fine.

How to reproduce:
1) Have a plugable ud-160
2) Run these xrandr commands:
xrandr --output HDMI1 --mode 1600x1200 --right-of LVDS1
xrandr --output DVI-0 --mode 1600x1200 --right-of HDMI1
3) Monitors set their resolution correctly but the frame rate drops significantly.

Kernel: Linux tigger 3.7.3-030703-generic #201301171415 SMP Thu Jan 17 19:16:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Please let me know if you need anything else from me.
Comment 1 Chris Wilson 2013-01-18 11:30:15 UTC
Which DE are you using, and what app do you feel best captures the performance hit?
Comment 2 Chris Wilson 2013-01-18 13:24:39 UTC
Ah, the issue is that pixregion is only clipped inside PixmapSyncDirtyHelper() and so without performing the clipping ourselves we cannot get the dirty ordering right. So,

commit 828a3a80aa3f0692e7be2831d58bccf02e2c481d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jan 18 13:16:23 2013 +0000

    uxa: Clip dirty region to slave pixmap before appending damage
    Fixes regression from
    commit c789d06cf8a0debc67058d7be1483f5b542e2baa
    Author: Dave Airlie <airlied@redhat.com>
    Date:   Mon Jan 7 13:57:21 2013 +1000
        intel: fixup damage posting to be done correctly around slave pixmap
    which causes the entire slave scanout to be readback from uncached
    memory every time a pixel is modified.
    Reported-by: Stephen Liang <inteldriver@angrywalls.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59539
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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.