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

[Gerry Boland]

(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)]

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

[Daniel van Vugt (vanvugt)]

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).

[Daniel van Vugt (vanvugt)]

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.

[Daniel van Vugt (vanvugt)]

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 :)

[Daniel van Vugt (vanvugt)]

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.

[Daniel van Vugt (vanvugt)]

I've moved the first error to bug 1583949.

[Daniel van Vugt (vanvugt)]

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

[Gerry Boland (gerboland)]

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.

[Daniel van Vugt (vanvugt)]

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)

[Loïc Molinari (loic.molinari)]

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).

[Daniel van Vugt (vanvugt)]

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.

[Guillaume F (marsguo)]

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 :(

[Andrea Bernabei (faenil)]

@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

[Daniel van Vugt (vanvugt)]

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

[Andrea Bernabei (faenil)]

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

[Guillaume F (marsguo)]

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!

[Daniel van Vugt (vanvugt)]

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.

[Guillaume F (marsguo)]

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!

[Daniel van Vugt (vanvugt)]

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.