Unity8 on Intel Atoms performs poorly (falls back to software rendering more than non-Atoms do)

Bug #1580792 reported by Gerry Boland
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
High
Unassigned
unity8 (Ubuntu)
Confirmed
High
Unassigned

Bug Description

(problem forked from bug 1549455)

Unity8 on Intel Pineview performs very poorly. Frame times appears to be up to 900ms, Qt's renderer thread using 100% CPU.

Running unity8 with MESA_DEBUG=1 EGL_LOG_LEVEL=debug reveals a few MESA errors:
http://paste.ubuntu.com/16344427/

Quoting @vanvugt "Those Mesa errors "Mesa: User error:" all look like OpenGL features that Unity8 is hitting but mir-demos don't. So those gl calls are also good candidates for explaining poor performance, especially if Mesa is falling back to software rendering for them."

Since Qt tends to perform just fine on that hardware in X11, something isn't right.

Gerry Boland (gerboland)
Changed in unity8 (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Gerry Boland (gerboland) wrote :

I've reported https://bugs.launchpad.net/mir/+bug/1580277 to raise the GL/GLES combination problem with the Mir team

tags: added: performance
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Unity8 on Intel Atoms performs poorly

Confirmed on Pineview and Diamondville now so just about anyone with a netbook can join in the fun.

https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Single-core_Netbook_processors

In both cases, Mir demos run 60Hz-smoothly (Diamondville requires a workaround in bug 1388490 first). Only Unity8 and mir_demo_client_eglplasma are unbearably slow (first observed in bug 1275684).

summary: - Unity8 on Intel Pineview performs poorly
+ Unity8 on Intel Atoms performs poorly
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Adding INTEL_DEBUG=perf to /etc/environment has seemingly explained the problems. Atoms are falling back to software rendering(!), which is theoretically easy to avoid. Here's a summary of what I get in unity8.log on an Atom N270:

PROBLEM:
old_intel_miptree_blit: Can't use hardware blitter from MESA_FORMAT_B8G8R8A8_UNORM to MESA_FORMAT_A_UNORM8, falling back.
intelCopyTexSubImage - fallback to swrast
CAUSE: Unknown

PROBLEM:
i915_program_error: Exceeded max ALU instructions (76 out of 64)
ENTER FALLBACK 10000: Program
CAUSE: GLSL shaders are approximately 18% larger than the hardware supports.

PROBLEM:
ENTER FALLBACK 10000: Program
LEAVE FALLBACK Program
[PERFORMANCE]: Last frame took 2643 ms to render.
CAUSE: Same as previous issue. Reused a program that ran in software.

Interestingly mir_demo_client_eglplasma has the same issues (bug 1583532) but it sounds like that's easily fixable.

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

The fallback to software rendering also completely explains "Qt's renderer thread using 100% CPU". It would use even more CPU cores if you had them :)

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

This first error is not Atom-specific but also happens on a Haswell i7-4770 desktop:

intel_miptree_blit: Can't use hardware blitter from MESA_FORMAT_R8G8B8A8_UNORM to MESA_FORMAT_A_UNORM8, falling back.
intelCopyTexSubImage - fallback to swrast

I'll move that one to a separate bug.

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

I've moved the first error to bug 1583949.

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

Successful proof of concept fix in eglplasma! Just shortening the shaders to fit i915 makes the error go away, and everything renders orders of magnitude faster:
   https://code.launchpad.net/~vanvugt/mir/fix-1583532/+merge/295564

Revision history for this message
Gerry Boland (gerboland) wrote :

Googling around I found this:
https://bugs.freedesktop.org/show_bug.cgi?id=87478
which puts some blame on Qt's shaders for distance field text rendering.

Happier news is that Qt has options to either use a lower quality distance field rendering approach (fewer ALU instructions) or disabling distance field approach completely.

Env vars to play with (I don't have the hardware to test with):
QSG_DISTANCEFIELD_ANTIALIASING=subpixel/subpixel-lowq/gray (subpixel the default I believe)
QML_DISABLE_DISTANCEFIELD=1

I would also suspect the UbuntuShape is guilty, we probably need a low quality version of it too.

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

Thanks for that.

Unfortunately I see no improvement in performance with those variables. And no reduction in the frequency of:
   i915_program_error: Exceeded max ALU instructions (76 out of 64)

Revision history for this message
Loïc Molinari (loic.molinari) wrote :

Looking at the i915 bug report, it seems like the distance field text rendering shader in Qt has too much instructions (in its HQ version) and exceeds the number of texture indirections, would be interesting to check if the distance field UbuntuShape shader has the same issue.

It would also be interesting to know how much instructions take the alternative (enabled on OpenGL ES 2 when OES_standard_derivatives is not supported) mipmapped UbuntuShape fragment shader (UC_SHAPE_MIPMAPS=1 must be set in the env to force its use).

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

In Unity8 I'm seeing four cases of:
   i915_program_error: Exceeded max ALU instructions (76 out of 64)

So there are potentially four offending shaders.

tags: added: unity8-desktop
summary: - Unity8 on Intel Atoms performs poorly
+ Unity8 on Intel Atoms performs poorly (falls back to software rendering
+ more than non-Atoms do)
Revision history for this message
Guillaume F (marsguo) wrote :

Hi,
I don't know if this is useful, but on my netbook the worst performance comes from black and transparent overlays, like when the Terminal asks for a password or when you want to turn off your computer. In those cases the frame time is more than 1s, sometimes 2s. I have to hard reboot every time because I can't click :(

Revision history for this message
Andrea Bernabei (faenil) wrote :

@Guillame:
that is interesting, it might be useful to see if that happens for all dialogs like that (there should be a few in system settings app). If it does, it's probably worth reporting a bug against ubuntu-ui-toolkit to investigate that

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

Please keep the discussion in this bug and don't log a new one. Just add an ubuntu-ui-toolkit task here.

Revision history for this message
Andrea Bernabei (faenil) wrote :

well, if it is a dialog-specific problem it could be worth having a separate bug, that only tackles dialog. otherwise you end up fixing too many things as part of the same bug

Revision history for this message
Guillaume F (marsguo) wrote :

Did a few tests, dialogs with a black/transparent backgrounds are definitely the worst (Terminal password prompt, shut down dialog, set a code or password in System Settings, connect to a hidden wifi network). The dialog can take up to 20s to fully open. Even then, they remain slow, for example when you type your password to unlock the Terminal (30s from the end of the splash screen to a workable terminal).

Other dialogs also perform very poorly, for example the "new VPN connection" form, or the calendar-app's bottom edge (tested with the snap version) in which you can't really type anything.

The alt-tab switcher is also very (very) laggy and completely unusable. The pointer only move every 1 or 2 seconds which makes it hard to aim correctly at anything. In all those examples, there is some kind of transparency layer involved. Could it be the cause?

As noted in the title, performance is generally slow, so it might also be interesting to see what does work well. For example, tab switching in the browser (bottom-edge style) animates quite nicely once it's opened (though it's a bit slow to open). Moving around in the calendar-app is also quite smooth.

I would have liked to test lists as well, but the address-book-app snap won't work and Dekko isn't in the repos (neither deb nor snap)…

Let me know if there's any kind of test I can do or log I can provide. And let me know if I do have to file another bug!

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

The original bug description is a bit vague here. In comment #3 I was aiming to make this bug very definite. If you add INTEL_DEBUG=perf then you will see the errors I mentioned. I think this bug should be about those errors in comment #3 since the bug description is a bit too vague.

Please add INTEL_DEBUG=perf to your /etc/environment to help us determine if you are experiencing this bug or something different.

Revision history for this message
Guillaume F (marsguo) wrote :

Here is my unity8.log with INTEL_DEBUG=perf. It's quite obscure for me as I'm not a developer, but I did find the problems you mentioned it your comments. I'll let you check!

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

The log seems to indicate that you're experiencing this Atom bug, so here is the right place...

i915_program_error: Exceeded max ALU instructions (76 out of 64)

Although the log also shows you're experiencing general Intel bug 1583949 too.

Changed in canonical-devices-system-image:
importance: Undecided → High
status: New → Confirmed
tags: added: atom
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

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