Mir

[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow

Bug #1216472 reported by Daniel van Vugt on 2013-08-25
98
This bug affects 18 people
Affects Status Importance Assigned to Milestone
Mir
Critical
Alexandros Frantzis
mir (Ubuntu)
Critical
Alexandros Frantzis
xorg-server (Ubuntu)
Critical
Unassigned

Bug Description

Using multiple monitors, eventually the frames you see get slightly out of order and slightly lagged. Particularly when only one monitor is updating.

TEST CASE:
Open a terminal in XMir, move it onto a single monitor, and hold down a key.
Expected: Key appears to repeat smoothly.
Observed: Key sometimes appears to skip one character/frame ahead, and then back again.

WORKAROUND (1)
1. sudo apt-get install compizconfig-settings-manager
2. ccsm &
3. CCSM > OpenGL > (untick everything except maybe "Sync To VBlank")

WORKAROUND (2)
Use simpler single buffering desktop environment, like Xfce.

WORKAROUND (3)
Unplug all external monitors. Use a single monitor :(

Related branches

Daniel van Vugt (vanvugt) wrote :

Sounds like bug 1216337

tags: added: multimonitor
Changed in mir:
importance: Undecided → Critical
Changed in xmir:
importance: Undecided → Critical
summary: - Frames eventually get slightly out of order, look like glitches
+ [multimonitor] Frames eventually get slightly out of order, look like
+ glitches
Changed in mir:
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → In Progress
summary: - [multimonitor] Frames eventually get slightly out of order, look like
- glitches
+ [multimonitor] Frames eventually get slightly out of order on one
+ monitor, look like glitches
summary: - [multimonitor] Frames eventually get slightly out of order on one
- monitor, look like glitches
+ [multimonitor] Frames eventually get slightly out of order, look like
+ glitches
kevin gunn (kgunn72) on 2013-08-26
Changed in xmir:
status: New → In Progress
assignee: nobody → Daniel van Vugt (vanvugt)
summary: - [multimonitor] Frames eventually get slightly out of order, look like
+ xmir multimonitor Frames eventually get slightly out of order, look like
glitches
kevin gunn (kgunn72) on 2013-08-26
summary: xmir multimonitor Frames eventually get slightly out of order, look like
- glitches
+ glitches or typing will feel slow
Changed in xmir:
status: In Progress → Confirmed
assignee: Daniel van Vugt (vanvugt) → nobody

Confirmed here with Intel Arrandale. Typing in weechat is ridiculously slow (I get more than half a second of delay between pressing a key and actually seeing the letter), and mouse-scrolling in firefox causes a lot of flicker.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/1216472

tags: added: package-qa-testing
summary: - xmir multimonitor Frames eventually get slightly out of order, look like
- glitches or typing will feel slow
+ [xmir] [multimonitor] Frames eventually get slightly out of order, look
+ like glitches or typing will feel slow
Daniel van Vugt (vanvugt) wrote :

I just noticed this seems to happen on systems where the monitor refresh rates are slightly different. No wonder I could never reproduce it on the desktop where they're identical...

description: updated
Daniel van Vugt (vanvugt) wrote :

I've now written a native Mir client that simulates the test case from the bug description...
lp:~vanvugt/mir/progressbar

Strangely, mir_demo_client_progressbar does not exhibit the bug at all even when connected to the same unity-system-compositor. XMir is still the only client that shows the bug.

Daniel van Vugt (vanvugt) wrote :

Progress!

I've now discovered the bug only happens in X desktop environments that use page flipping. So that's Compiz/Unity and sometimes Gnome. If you use Xfce the bug does not occur, and if you disable page flipping in Compiz then the bug does not occur. Workaround added to the Bug Description.

Changed in mir:
status: In Progress → Invalid
description: updated
Daniel van Vugt (vanvugt) wrote :

Actually the above comment may not be entirely accurate. But at least disabling page flipping in your X compositor seems to almost entirely eliminate the problem.

Daniel van Vugt (vanvugt) wrote :

It's starting to look like the issue might be in:
xserver-xorg-video-intel 2:2.21.14-4ubuntu2+xmirMM7
and how it schedules it's own double/triple buffers to Mir...

Changed in xmir:
assignee: nobody → Daniel van Vugt (vanvugt)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mir (Ubuntu):
status: New → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mir - 0.0.10+13.10.20130827.1-0ubuntu1

---------------
mir (0.0.10+13.10.20130827.1-0ubuntu1) saucy; urgency=low

  [ Alan Griffiths ]
  * ipc: add a protocol version to the wire protocol so that we can bump
    it in future.
  * graphics::nested: Handling of output configuration changes.
  * graphics.nested: Hookup NestedDisplay to display change
    notifications.

  [ Daniel van Vugt ]
  * Introducing mir_demo_client_progressbar. It's pretty boring;
    designed to simulate key repeat scrolling in a terminal, as an aid
    for tracking down bug 1216472. . (LP: #1216472)

  [ Eleni Maria Stea ]
  * changed the GBMBufferAllocator constructor and class to use the
    gbm_device instead of the GBMPlatform to remove the dependency from
    the mg::Platform interface - this way we can use the
    GBMBufferAllocator with the NativeGBMPlatform (nested mir).

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 1025
 -- Ubuntu daily release <email address hidden> Tue, 27 Aug 2013 18:04:47 +0000

Changed in mir (Ubuntu):
status: Confirmed → Fix Released
Daniel van Vugt (vanvugt) wrote :

Ignore the previous comment. Nothing is fixed. Silly robot.

Changed in mir (Ubuntu):
status: Fix Released → Confirmed
importance: Undecided → Critical
Daniel van Vugt (vanvugt) wrote :

Please be careful not to confuse this with bug 1218735. It will happen at the same time, unless you're using the workaround.

Changed in mir:
status: Invalid → Confirmed
description: updated
Changed in mir:
status: Confirmed → In Progress
description: updated
Daniel van Vugt (vanvugt) wrote :

I can now debug this from within Mir. Almost disappointingly I can't see any incorrect frame ordering within Mir. The client (XMir) always gets frame 0,1,2,0,1,2,... and the server always composites frame 0,1,2,0,1,2... starting with the latest one released by the client. So everything looks correct from within the server.

Next week I will come at it with fresh eyes, and also try to devise some logical assertions to verify ordering.

Changed in xorg-server (Ubuntu):
status: New → Confirmed
importance: Undecided → Critical
Changed in mir:
status: In Progress → Invalid
Changed in mir (Ubuntu):
status: Confirmed → Invalid
Daniel van Vugt (vanvugt) wrote :

OK, I've figured out a terrible hack that seems to solve the problem (although it generates constant damage and constant CPU usage):

_X_EXPORT RegionPtr
xmir_window_get_dirty(xmir_window *xmir_win)
{
    return &xmir_win->region; /* Terrible hack */

This seems to solve the bug, suggesting xmir_window_get_dirty is returning incorrect damage regions.

It's not definitive and not a fix. But looks like good progress.

Changed in xmir:
status: Confirmed → In Progress
kevin gunn (kgunn72) on 2013-09-04
tags: added: make-xmir-default
Daniel van Vugt (vanvugt) wrote :

Further notes... The issue seems to occur on frames where some but not all of the outputs are dirty. So one output makes it through to callback (sna_xmir_copy_to_mir), but the other does not:

_X_EXPORT void
xmir_screen_for_each_damaged_window(xmir_screen *xmir, xmir_window_proc callback)
{
    xmir_window *xmir_win, *tmp_win;
    xorg_list_for_each_entry_safe(xmir_win, tmp_win, &xmir->damage_list, link_damage) {
        if (xmir_window_has_free_buffer(xmir_win) &&
            xmir_window_is_dirty(xmir_win))
            (*callback)(xmir_win, xmir_window_get_dirty(xmir_win));
    }
}

XMir is intentionally designed to only redraw dirty outputs. So not all get swapped every frame. I wonder however if that is somehow incompatible with how the intel DDX works?

Daniel van Vugt (vanvugt) wrote :

Also affects the intel DDX.

I keep finding myself tracing this bug into the Intel SNA code, which I don't yet understand. The issue seems to occur on frames where not-quite-all outputs are dirty, so sna_xmir_copy_to_mir() is only called for some of them (but not all).

The bug goes away if I ensure sna_xmir_copy_to_mir() is called for all outputs. So this seems to suggest that the Intel SNA code is keeping track of frames/buffers and expecting a precise number of kgem_submit's, which of course doesn't always happen with multimonitor.

description: updated
Chris Halse Rogers (raof) wrote :

Ok. I think I've convinced myself from a manual run-through that the XMir damage logic is sound. Next up: Intel DDX.

Changed in mir:
assignee: Daniel van Vugt (vanvugt) → Chris Halse Rogers (raof)
Changed in xmir:
assignee: Daniel van Vugt (vanvugt) → Chris Halse Rogers (raof)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Confirmed
Changed in mir:
status: Invalid → In Progress
assignee: Chris Halse Rogers (raof) → Alexandros Frantzis (afrantzis)
Changed in mir (Ubuntu):
status: Invalid → Confirmed
no longer affects: mir (Ubuntu)
Daniel van Vugt (vanvugt) wrote :

I've just tried an experimental change from Alexandros which looks like a good solution. It needs some polish and test cases but should be fully ready next week....
http://paste.ubuntu.com/6132595/

affects: xserver-xorg-video-intel (Ubuntu) → mir (Ubuntu)
Changed in mir (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Critical
Changed in xmir:
status: In Progress → Invalid
Changed in xorg-server (Ubuntu):
status: Confirmed → Invalid
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:~mir-team/mir/development-branch at revision None, scheduled for release in mir, milestone Unknown

Changed in mir:
status: In Progress → Fix Committed
kevin gunn (kgunn72) on 2013-10-01
Changed in mir (Ubuntu):
status: Triaged → Fix Committed
no longer affects: mir (Ubuntu)
Daniel van Vugt (vanvugt) wrote :

Definitely seeing this in Ubuntu.

Daniel van Vugt (vanvugt) wrote :

I don't think this fix has hit Ubuntu yet. Our automated changelogs and multiple branches make it very unclear...

Changed in mir (Ubuntu):
importance: Undecided → Critical
status: New → Triaged
Daniel van Vugt (vanvugt) wrote :

Confirmed the fix is not in Ubuntu or lp:mir yet. Only the development branch.

Daniel van Vugt (vanvugt) wrote :

Fix committed to lp:mir revision 1088. Ubuntu packages coming soon I guess.

Changed in mir (Ubuntu):
status: Triaged → Fix Committed
Daniel van Vugt (vanvugt) wrote :

The changelog is inaccurate, due to our current (temporary) merging process. But I assure you the fix was just released, in:

mir (0.0.13+13.10.20131003-0ubuntu1) saucy; urgency=low

Changed in mir (Ubuntu):
status: Fix Committed → Fix Released
assignee: nobody → Alexandros Frantzis (afrantzis)
Changed in mir:
milestone: none → 0.0.13
Daniel van Vugt (vanvugt) wrote :

Saucy's now up to 0.0.14 so I think we can assume 0.0.13 good as released.

Changed in mir:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers