Unity fails to load on old hardware (blank desktop; only wallpaper). Missing automatic fallback to LLVMpipe when unity_support_test fails

Bug #1039155 reported by Colin Law on 2012-08-20
82
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Unity Distro Priority
High
Unassigned
compiz (Ubuntu)
High
Daniel van Vugt
Quantal
High
Daniel van Vugt

Bug Description

Since recent updates to Quantal which removed unity-2d, Unity will not run if the hardware does not support 3d. On login I get the background image but no launcher or panel.
.xsession-errors has the lines

compiz (unityshell) - Error: OpenGL 1.4+ not supported
compiz (unityshell) - Error: GL_ARB_fragment_program not supported
compiz (core) - Error: Plugin initScreen failed: unityshell
compiz (core) - Error: Failed to start plugin: unityshell
compiz (core) - Info: Unloading plugin: unityshell

Related branches

Colin Law (colin-law) wrote :
Colin Law (colin-law) wrote :
tags: added: quantal rls-q-incoming
Daniel van Vugt (vanvugt) wrote :

Colin,

If your system fails the support test:
    /usr/lib/nux/unity_support_test -p
Then compiz/unity should be started with LLVMpipe instead, which does support all those features in software. The point is the Unity3D should always start, somehow.

So this is a problem with the session/login scripting. I'm not sure what the correct package is yet.

Daniel van Vugt (vanvugt) wrote :

Hmm, in precise it was the responsibility of:
nux-tools: /etc/X11/Xsession.d/50_check_unity_support

But that file seems to be gone in quantal.

affects: unity → nux (Ubuntu)
summary: - Unity will not run on hardware that does not support 3d
+ Unity is started without LLVMpipe on unsupported hardware
summary: - Unity is started without LLVMpipe on unsupported hardware
+ Unity fails to load: compiz (unityshell) - Error: OpenGL 1.4+ not
+ supported

Yes, it looks like in quantal, we should have modified:
   /etc/X11/Xsession.d/50_check_unity_support
to export LIBGL_ALWAYS_SOFTWARE=1 if the support test fails, thus enabling LLVMpipe.

It seems what we've done instead is just delete the file. So hardware that doesn't support UnityShell won't automatically fall back to LLVMpipe like it should.

Changed in nux (Ubuntu):
importance: Undecided → High
Daniel van Vugt (vanvugt) wrote :

I suspect that we want /etc/X11/Xsession.d/50_check_unity_support to be something like this (untested):

# This file is sourced by Xsession(5), not executed.
# Select the right session if we have already done
# an unity check, try to check it other

if [ "x$DESKTOP_SESSION" = "xubuntu" ] && [ ! -f "/tmp/unity_support_test.0" ]; then
    if [ -f "/tmp/unity_support_test.1" ]; then
        export LIBGL_ALWAYS_SOFTWARE=1
    else
        /usr/lib/nux/unity_support_test
        if [ $? -ne 0 ]; then
     export LIBGL_ALWAYS_SOFTWARE=1
        fi
    fi
fi

summary: Unity fails to load: compiz (unityshell) - Error: OpenGL 1.4+ not
- supported
+ supported. Missing automatic fallback to LLVMpipe
Changed in nux:
importance: Undecided → High

Confirmed. I disabled unity_support_test on my system by pointing it to /bin/false. However failing the support test is now ignored in quantal and it tries to start Unity3D anyway.

Changed in nux:
status: New → Confirmed
Changed in nux (Ubuntu):
status: New → Confirmed
summary: - Unity fails to load: compiz (unityshell) - Error: OpenGL 1.4+ not
- supported. Missing automatic fallback to LLVMpipe
+ Unity fails to load on old hardware. Missing automatic fallback to
+ LLVMpipe

Colin, FYI, even when this bug is fixed, the LLVMpipe driver only works if Mesa is your default OpenGL driver.

This means you should make sure that no proprietary drivers like nvidia-current or fglrx are installed.

Daniel van Vugt (vanvugt) wrote :

Affects Unity too. I get the feeling that /etc/X11/Xsession.d/50_check_unity_support should not be restored to its old home in nux. Putting the script in Unity might make more sense.

Changed in unity:
status: New → Confirmed
importance: Undecided → High
milestone: none → 6.4
Colin Law (colin-law) wrote :

There must still be a test in the system somewhere because on my Toshiba laptop with i945 graphics it will support unity on the laptop screen, but if an external screen is plugged in so that the virtual desktop is greater then 2048 pixels the hardware will not support it. In that case (on quantal) a dialog pops up telling me that the I cannot do this and I must select unity-2d at login prompt (!). See bug #1039051

Daniel van Vugt (vanvugt) wrote :

Colin,

What do you get (with the external screen plugged in) from:
   /usr/lib/nux/unity_support_test -p
?

Colin Law (colin-law) wrote :

This machine has not got an external monitor (the laptop in bug #1039051 is a different pc)

$ /usr/lib/nux/unity_support_test -p
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300)
OpenGL version string: 2.1 Mesa 8.0.4

Not software rendered: no
Not blacklisted: yes
GLX fbconfig: yes
GLX texture from pixmap: yes
GL npot or rect textures: yes
GL vertex program: yes
GL fragment program: yes
GL vertex buffer object: yes
GL framebuffer object: yes
GL version is 1.4+: yes

Unity 3D supported: no

Does that mean it /is/ trying to use llvmpipe but just not succeeding fully?

Changed in unity:
milestone: 6.4 → 6.6
Didier Roche (didrocks) wrote :

@Daniel: no, normally we don't have to "force" software rendering, xorg/the driver should provide and fallback to that if needed. I'm subscribing RAOF to have some inputs on that.

Didier Roche (didrocks) wrote :

RAOF, just subscribed you, please can you have a look at why llvmpipe is not automatically triggered when the 3D is not supported in this case? (it is in virtualbox for instance apparently)

Chris Halse Rogers (raof) wrote :

As I see it, there are three situations we need to care about here:

1) There's no hardware 3D support at all. In this case llvmpipe *will* kick in automatically; see @Colin's unity-support-test output. In this case there's no need to set LIBGL_ALWAYS_SOFTWARE

2) There *is* 3D hardware support provided by mesa, but it's insufficient to run Unity. In this case, we *do* need to force software with LIBGL_ALWAYS_SOFTWARE=1. Setting that in the global environment is a bit hostile, though; they may have enough 3D support for other programs, and this will disable it.

3) The user has a non-mesa 3D stack enabled, and it doesn't provide enough 3D for Unity. In this case there's pretty much nothing we can do. Non-mesa 3D stacks replace libGL, so we can't load llvmpipe, and even if we tried LD_LIBRARY_PATH hacks to get mesa's libGL, non-mesa 3D stacks generally also replace X server components with incompatible versions.

Ubuntu QA Website (ubuntuqa) wrote :

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

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

tags: added: iso-testing
Didier Roche (didrocks) wrote :

So, in summary:
1) -> it seems there is an issue in unity for not starting in Colin's case, even if unity_support_test tells he's using llvmpipe, needs to be checked upstream

2) we shouldn't export LIBGL_ALWAYS_SOFTWARE=1 to the environment using a checker. Because that means that all software that can't maybe use unity under hw acceleration but can use smaller apps with hw acceleration will be defaulted to llvmpipe. If we set that to the environment with the checker, all applications will be impacted.
So unity itself should do the check at initiliziation time, force and reinitialize with this env variable and then unset it.

3 and 4) can't really be dealt with unfortunately

Didier Roche (didrocks) wrote :

4 being:
 RAOF | Oooh, actually, I guess there's a 4th situation I didn't cover: the user has unity-grade 3D, but only as long
         | as the desktop is <= MAX_TEXTURE_SIZE, and has a low MAX_TEXTURE_SIZE.

Changed in unity-distro-priority:
status: New → Fix Committed
importance: Undecided → High
Daniel van Vugt (vanvugt) wrote :

2) I think is most elegantly handled using the aforementioned shell scripting (comment #6). Because LIBGL_ALWAYS_SOFTWARE needs to be set before compiz (opengl plugin) starts. To allow other apps to use hardware acceleration while Unity can't, just unset LIBGL_ALWAYS_SOFTWARE in unity itself, before spawning programs from the launcher/dash.

4) Should not be solved using LLVMpipe. It should be discussed in bug 824099 instead.

Chris Halse Rogers (raof) wrote :

There's actually a 4th possible case, which it seems Colin is hitting:

4) The user has unity-capable 3D support, but runs into the GL_MAX_TEXTURE_SIZE limitation.

What we can do here is either (a) fix bug #824099, so Unity no longer has this limitation, or
(b) rework the existing patch to set LIBGL_ALWAYS_SOFTWARE=1 and respawn compiz, with unity then stripping that variable out of the environment before spawning children. One problem here is that we'll be switching to software rendering at the same time as we're making bigger demands on GL performance; I'm not sure how much that'll matter in practise, though.

Daniel van Vugt (vanvugt) wrote :

A better fix for GL_MAX_TEXTURE_SIZE would be in hardware. Which would require:
  1. Fix bug 1040478.
  2. Conditionally(?) load compiz plugin copytex to work around bug 824099.
  3. Fix any remaining limitations/bugs in Nux/Unity.

But that's better discussed in bug 824099.

Changed in unity:
assignee: nobody → Ted Gould (ted)
Colin Law (colin-law) wrote :

Is it possible to work around this problem on my non-working system by doing something clever with LIBGL_ALWAYS_SOFTWARE?

Colin Law (colin-law) wrote :

Just to clarify, my question about a workaround relates to the machine described in the initial description of this bug, not the GL_MAX_TEXTURE_SIZE problem described in bug #824099 when I add a second monitor to a different machine. Unless that is I have missed something and the problem in the machine in the description relates to max texture size.

Daniel van Vugt (vanvugt) wrote :

Colin,

Yes indeed. In theory you should be able to work around this problem by adding a line to /etc/environment:
    LIBGL_ALWAYS_SOFTWARE=1
And reboot.

Colin Law (colin-law) wrote :

Daniel, thanks, adding LIBGL_ALWAYS_SOFTWARE=1 to /etc/environment does provide a working system. The performance is very poor however, taking seconds to re-draw menu dropdowns for example. Is that what I should expect once the bug is fixed fully or am I overly slugging the system by setting that flag? Performance was perfectly acceptable with untity-2d.

Daniel van Vugt (vanvugt) wrote :

Colin,

Unfortunately, yes. Performance is poor with LLVMpipe. We are working to improve it as much as possible before the 12.10 release.

Daniel van Vugt (vanvugt) wrote :

Although, I personally think the right solution here is to make the Nux/unityshell more compatible so systems like yours will pass unity_support_test and be able to use hardware acceleration.

Daniel van Vugt (vanvugt) wrote :

Colin,

If possible, try experimenting with different graphics drivers. Look in Super+A > Additional Drivers for starters.

The source of your problem is a limitation in your current graphics driver, which may not be your only option.

Colin Law (colin-law) wrote :

Daniel

It is not showing any additional drivers, though I could not find a way of forcing it to go and check, additional drivers is now a tab in s/w sources, and not accessible directly from Dash.

Probably this is not the place to discuss this but it is a pity if Ubuntu is not to satisfactorily run on hardware more than a few years old. It has always previously been the case that if h/w would run XP then it would run Ubuntu better. It is not a big issue for me, the machine is just for testing purposes not for production use, but I understood that a lot of machines running Ubuntu are re-furbished machines, particularly in the developing world, and if the latest Ubuntu will not run then this may be a bit of a public relations disaster. Presumably one could advise that Lubuntu is used instead, but still it gives a poor impression if the standard version is not usable.

Daniel van Vugt (vanvugt) wrote :

I agree, Ubuntu should support a wider range of hardware than it does.

The good news is that the problem is localized to the unityshell plugin and the Nux library. Fixing those should make the Unity desktop compatible with any/old hardware. Though I'm not aware of any effort to do that right now.

Omer Akram (om26er) on 2012-09-11
Changed in unity (Ubuntu Quantal):
importance: Undecided → High

Hi, I'm from Colombia, I don't speak english O.o, I have this problem,
help me ;)

Colin Law (colin-law) wrote :

@Jose did you realise this bug only affects Ubuntu Quantal, currently at Beta release? There is a workaround described in comment #24 which should allow Unity to function, but screen updating may be very slow.

Omer Akram (om26er) on 2012-09-12
tags: added: pspriority
Changed in unity:
milestone: 6.6 → 7.0
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu):
status: New → Confirmed
Omer Akram (om26er) on 2012-09-24
Changed in unity:
assignee: Ted Gould (ted) → Unity Team (unity-team)
Omer Akram (om26er) on 2012-09-24
Changed in unity:
assignee: Unity Team (unity-team) → nobody
Neil J. Patel (njpatel) wrote :

Just to update on some current efforts, we are working on trying to make Unity skip as many of the effects as possible when it detects software rendering. This branch should hopefully land this week and be in for Quantal. It won't be a magic bullet, but hopefully you should start seeing some improvements with it (and lots more to come).

Daniel van Vugt (vanvugt) wrote :

njpatel: That comment might be appreciated in bug 1046497 too.

summary: - Unity fails to load on old hardware. Missing automatic fallback to
- LLVMpipe
+ Unity fails to load on old hardware (blank desktop, only wallpaper).
+ Missing automatic fallback to LLVMpipe
summary: Unity fails to load on old hardware (blank desktop, only wallpaper).
- Missing automatic fallback to LLVMpipe
+ Missing automatic fallback to LLVMpipe where unity_support_test fails
Changed in nux:
milestone: none → 4.0

I tested Unity on old hardware (Pentium 4, Intel 82865G), using the workaround in comment #24:
It is so slow there is no thought of using it. It takes seconds until the dash even opens, and 10-20 seconds more, until it displays any icons.
This system was very well usable with Unity 2d.

If this is the performance users of older hardware get from quantal, there *will* be a public relations problem. Performance must be drastically improved.

summary: - Unity fails to load on old hardware (blank desktop, only wallpaper).
- Missing automatic fallback to LLVMpipe where unity_support_test fails
+ Unity fails to load on old hardware (blank desktop; only wallpaper).
+ Missing automatic fallback to LLVMpipe when unity_support_test fails
Daniel van Vugt (vanvugt) wrote :

I found all the offending code lives in the Ubuntu branch of Nux. No upstream changes required.

Changed in unity (Ubuntu Quantal):
status: Confirmed → Invalid
Changed in nux (Ubuntu Quantal):
assignee: nobody → Daniel van Vugt (vanvugt)
milestone: none → quantal-updates
milestone: quantal-updates → ubuntu-12.10
Changed in nux:
status: Confirmed → Invalid
Changed in unity:
status: Confirmed → Invalid
Changed in nux (Ubuntu Quantal):
status: Confirmed → In Progress
Changed in nux:
milestone: 4.0 → none
Changed in unity:
milestone: 7.0.0 → none
Timo Jyrinki (timo-jyrinki) wrote :

The nux branch's script isn't being run anymore, so a solution inside compiz either as a distro patch or otherwise is being pondered by Daniel.

Changed in compiz:
milestone: none → 0.9.8.6
importance: Undecided → High
status: New → Confirmed
Changed in compiz (Ubuntu Quantal):
status: New → Confirmed
Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
milestone: 0.9.8.6 → 0.9.9.0
status: Confirmed → In Progress
Omer Akram (om26er) on 2012-10-09
no longer affects: nux
no longer affects: nux/3.0
no longer affects: unity
no longer affects: unity/6.0
no longer affects: unity (Ubuntu)
no longer affects: unity (Ubuntu Quantal)
no longer affects: nux (Ubuntu Quantal)
no longer affects: nux (Ubuntu)
Changed in compiz (Ubuntu Quantal):
assignee: nobody → Daniel van Vugt (vanvugt)
importance: Undecided → High
milestone: none → quantal-updates
status: Confirmed → In Progress
no longer affects: compiz
no longer affects: compiz/0.9.8
Didier Roche (didrocks) wrote :

Retargetting to 12.10 finale. Would be nice to get it into the iso

Changed in compiz (Ubuntu Quantal):
milestone: quantal-updates → ubuntu-12.10
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.9.8.4-0ubuntu2

---------------
compiz (1:0.9.8.4-0ubuntu2) quantal; urgency=low

  * debian/patches/unity_support_test.patch:
    - force llvmpipe in the unity profile if we are in the grey zone, meaning:
      the card and drivers have opengl support, however, it doesn't met unity
      requirements (opengl < 1.4, no vertex shaders support…). Thanks duflu
      (LP: #1039155)
      Note that we already discourage them to upgrade from precise to quantal
      with a warning before the upgrade, however let's get a slow ui rather
      than none on the iso as well.
 -- Didier Roche <email address hidden> Tue, 09 Oct 2012 15:26:52 +0200

Changed in compiz (Ubuntu Quantal):
status: In Progress → Fix Released
Colin Law (colin-law) wrote :

Should there be a warning in the installer saying that it would really be better to install 12.04 for the moment? Also a note on the download page.

Changed in unity-distro-priority:
status: Fix Committed → Fix Released
Colin Law (colin-law) wrote :

I am afraid this is still not fixed for me, .xsession errors attached. It appears to be recognising that it needs to use s/w rendering but is failing.

Colin Law (colin-law) wrote :

Re-opening the bug as it is not fixed for me. See .xsession-errors in comment #42

Changed in compiz (Ubuntu Quantal):
status: Fix Released → New
Daniel van Vugt (vanvugt) wrote :

Colin,

As the fix works for a few of us and your new observations are different to the original problem, please log a new bug with those log details. It creates a lot of trouble if we re-open bugs after they're marked fix released. Even if the fix itself is flawed.

Changed in compiz (Ubuntu Quantal):
status: New → Fix Released
Colin Law (colin-law) wrote :

Sorry Daniel I was not sure of the appropriate action. See bug #1066764

Similar problem here. I had fully desinstalled llvm-3.1, including libllvm-3.1; this triggered desinstallation of libgl1-mesa-dri (which I did not pay attention to). At next reboot, no GLX acceleration, and when logging in, Unity does not start (nothing except wallpaper and desktop background menu).

In the absence of GLX acceleration, for whatever reason, there should be a fallback. I could not even browse the web to search for this bug!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers