llvmpipe software rendering needs blacklisting in unity-support-test

I think you're using unity 3d by "accident", which is now possible with the new llvmpipe software rasterizer. Try choosing the unity-2d session from the login screen, does it work normally?

While this is indeed a bug in mesa, there is already handling in unity-support-test in nux to handle software rendering and it should be extended to also block llvmpipe because it's not going to be able to run unity in 12.04. You can reproduce this bug when using mesa by exporting LIBGL_ALWAYS_SOFTWARE=1. just adding "on llvmpipe" similar to "on softpipe" in this snippet from unity-support-test in nux would be enough

  // Check for software rendering.
  if (results->renderer != NULL &&
      (strncmp (results->renderer, "Software Rasterizer", 19) == 0 ||
       strncmp (results->renderer, "Mesa X11", 8) == 0 ||
       strstr (results->renderer, "on softpipe") != NULL)) {
    results->flags |= FLAG_SOFTWARE_RENDERING;

Here are the strings for llvmpipe:
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300)
OpenGL version string: 2.1 Mesa 8.0-rc2
OpenGL shading language version string: 1.20

I have done update/upgrade with apt/update-manager for the last three days - was not able to get back to check the status of this bug though.

Logging in with unity-2d seems to have corrected all the previous errors I was having though.

Xdiagnose still crashing (unrelated? - bug #903484)

Nah, we are just going to fix the flickering issue. Its trivial to do :)

Jason: Will fixing the flickering also get my CPU usage down from 50% to something reasonable?

I'd like to be able to have my usual 10 VMs running ubiquity without my laptop dying because of the CPU usage of doing compiz in software...

Another use case for you I just got reminded of, LTSP (that ships in Ubuntu Alternate).

In the past we had two categories of thin clients:
 - These that support 3D acceleration over the network (intel based mostly)
 - These that don't

The first would get compiz and unity-3d the other would get unity-2d. This was all fine and we could have somewhere between 70-80 sessions like that opened on a regular server as unity-2d wasn't using much resource and compiz with GL over the network was offloading quite a bit to the thin client, making it pretty lightweight too.

Now, doing similar tests with llvvmpipe, we're pretty much going from 70-80 sessions down to 10 or so, because of the very high CPU and bandwidth requirement that comes with doing all the nice flashy stuff on the server rather than the client and then sending all that over the network. That's for when we can actually get a unity session opened, most of the time, we just get half the panel rendered and it gets stuck there.

Don't get me wrong, I find llvmpipe extremely interesting and I've been looking forward to that for a while, but that's something that should be opt-in, not a default. We have unity-2d and it works really quite well, I see no reason to stop using it and instead running compiz on software rendering.

I'd think making the llvmpipe stuff optional, using a gsettings key or option in the .desktop or whatever would be fine for everyone. People who want llvmpipe will be able to flick that switch, others will get a nice, fast and quiet experience using unity-2d on their non-3D capable hardware.

Some people asked on IRC "why don't you just select unity-2d", well, the problem is that you don't have a choice on a live media, it's always booting in unity 3d and needs the fallback to unity-2d. Currently, forcing to unity-2d requires a hack at boot time in the initramfs... As for LTSP, sure we could change the default session, but that'd be bad as a lot of recent thin clients can actually run compiz with hardware acceleration just fine. I really believe the fix needs to go in unity-support-test.

targeting for Beta 1, it make live session in VMs almost unusable and VMs are widely used by testers.

We will blacklist llvmpipe for -3d in ubuntu right now for beta1.

This bug was fixed in the package nux - 2.4.0-0ubuntu2

---------------
nux (2.4.0-0ubuntu2) precise; urgency=low

  * debian/patches/01_blacklist_llvmpipe.patch:
    - Blacklist llvmpipe (LP: #926859)
 -- Didier Roche <email address hidden> Mon, 27 Feb 2012 12:00:10 +0100

Fixing the flickering plus a repaint fix going into compiz will dramatically lower CPU usage. We have some other fixes that will lower the usage also.

Stephane, just a comment though, Unity 2D will stop being OpenGL-less once Qt5 is out (though we can stick to Qt4).

There are very good reasons to improve the llvmpipe experience, however, I do agree, that if we cannot achieve a decent experience _right now_, we should avoid shipping it by default.

putting the downstream task as "fix released" as the release team tracker open downstream tasks which are invalid in this case.

No longer affects Unity. This is a Nux issue.

@Daniel: if it's a nux issue, please open a nux upstream task

Remember that comment as well: https://bugs.launchpad.net/nux/+bug/926859/comments/5
Jason told it was an issue in unity itself

Fix released in Nux.

Also note this entire bug is now irrelevant. Because LLVMpipe now works (bug 1021104) and should not be blacklisted any more.