[performance] Rendering is only smooth while you're touching the screen

Bug #1488386 reported by Daniel van Vugt
26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Incomplete
Undecided
Daniel van Vugt
Unity System Compositor
In Progress
Undecided
Thomas Voß
mir (Ubuntu)
Incomplete
Undecided
Unassigned
qtmir (Ubuntu)
New
Undecided
Unassigned

Bug Description

On some devices (mako at least) it's possible to force double buffering and it will often keep up:

   restart unity8 QML_NO_TOUCH_COMPRESSION=1 MIR_SERVER_NBUFFERS=2

Curiously however it only keeps up smoothly (eg. during a dash scroll) while you're touching the screen. If you lift off or fling the dash then it immediately stutters, quite badly.

So the issue is not that the device can't keep up with double buffering. It seems more like we're not keeping the kernel sufficiently awake and it's clocking down prematurely, as soon as we're not touching it. Certainly adjusting the variables in:
   /sys/devices/system/cpu/cpu0/cpufreq
it is possible to raise the performance and minimum frequency to make double buffering smooth.

The challenge of this bug is to find a way in Mir/QtMir to keep the kernel more awake so it doesn't clock down when we need smooth animations and we're not touching the screen.

Also note that while this bug sounds like bad news for mako, mako is actually the best performing device. Others like arale don't reliably speed up in response to short touches.

Tags: performance
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Could be a simple matter of increasing our concurrency. If that's not kept high enough then the delay between context switches likely becomes unacceptably high. And each frame requires at least 4 context switches (USC -> Unity8 -> app -> Unity8 -> USC).

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Further evidence: mirping gets better results while you're touching the screen:

$ mirping /var/run/mir_socket
Connected to server: /var/run/mir_socket
--- Not touching the screen ---
Round-trip time: 0.854571 milliseconds
Round-trip time: 1.373416 milliseconds
Round-trip time: 1.556539 milliseconds
Round-trip time: 1.617580 milliseconds
Round-trip time: 1.434458 milliseconds
Round-trip time: 1.556539 milliseconds
Round-trip time: 1.342896 milliseconds
Round-trip time: 1.373417 milliseconds
Round-trip time: 1.403937 milliseconds
Round-trip time: 1.464978 milliseconds
Round-trip time: 1.526019 milliseconds
--- Now touching the screen a lot ---
Round-trip time: 0.457805 milliseconds
Round-trip time: 0.427285 milliseconds
Round-trip time: 0.579887 milliseconds
Round-trip time: 0.427285 milliseconds
Round-trip time: 0.579887 milliseconds
Round-trip time: 0.518847 milliseconds
Round-trip time: 0.457805 milliseconds
Round-trip time: 0.457805 milliseconds
Round-trip time: 0.518846 milliseconds

summary: - Double buffering is only smooth while you're touching it
+ [performance] Double buffering is only smooth while you're touching it
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: [performance] Double buffering is only smooth while you're touching it

Even Mir's ClientLatency acceptance test has the same behaviour. The latency is almost halved if you're touching the screen while the test runs.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Three things I have found that solve the stuttering from premature CPU scaling on Android:

  * Don't use nesting. Having a single server architecture seems to keep it smooth.
  * Don't use double buffering (bug 1240909). Staying busy pre-rendering that third buffer keeps clocks higher and smoother.
  * Just wastefully spin a CPU core. Annoyingly, wasting power makes graphics visibly smoother.

Hopefully we can find more options.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

We also have device-specific issues. On mako you will find it spins up secondary CPU cores instantly when you touch the screen. On arale however it waits a few seconds for excessive touching before spinning up the cores, and this keeps frame rates artificially low.

Changed in mir:
assignee: Daniel van Vugt (vanvugt) → Thomas Voß (thomas-voss)
Revision history for this message
Thomas Voß (thomas-voss) wrote :

The issue is device-specific and requires integration with SOC-specific infrastructure. We started wiring up the required functionality across the stack, with the tablet being the first real consumer. The changes you are interested in are:

  * http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/revision/280
  * http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/revision/317

We require changes to the Android portions of the platform API, though, with the tablet being the first device that has the required platform api functions implemented on the Android side. The landing for USC can be found here:

  * https://requests.ci-train.ubuntu.com/#/ticket/1097

With the silo installed, device performance is boosted for interactive scenarios, specifically after deep sleep.

description: updated
Changed in unity-system-compositor:
assignee: nobody → Thomas Voß (thomas-voss)
status: New → In Progress
summary: - [performance] Double buffering is only smooth while you're touching it
+ [performance] Rendering is only smooth while you're touching the screen
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I wonder if this bug might have been solved accidentally in the same way as bug 1388490...

Changed in mir:
assignee: Thomas Voß (thomas-voss) → Daniel van Vugt (vanvugt)
status: New → Incomplete
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Possibly fixed now. But we'll need to wait for Mir release 0.26.1 to be able to verify (due to bug 1661128)

Michał Sawicz (saviq)
no longer affects: qtmir
Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.