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

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.

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.

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.

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

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.

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.

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.

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

Colin,

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

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?

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

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)

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

Colin,

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

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.

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.

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.

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.

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

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

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

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

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

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.

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

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.

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

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

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.

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.

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

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.

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!