[FFe] Mesa 7.9

For resolving the severe kwin compositing issues we are seeing in Kubuntu, fragment_shader=false seems to be a key part of the solution, so it's not just updating to the new snapshot, it's also the configuration change. I've tested this on an intel 945gme (Dell mini 10v) netbook and it is hugely improved. I have some additional 945 systems and both a 965 and 865 sytem that I will try to test with.

Tested with i865:

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

Seems unchanged from the not very bad experience on Lucid or Maverick with the current mesa package.

Tested with another i945:

00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)

This one effects are completely disabled with either mesa (not just suspended), so I assume it's blacklisted somewhere. With the old mesa, once effects are manually enabled they all work (including blur), but there is a very annoying flash on the screen each time an effect is triggered Makes them very distracting at best. This is resolved with the new mesa.

Updating mesa for this system would be a win (it's also better than Lucid even with the current mesa, so progress).

Bug #633261 is the relevant bug that's fixed for the previous comment.

Much improved on a HP Mini 110-1000 (also 945gme), see Bug #630632 for details.

I have run an OpenGL regression test suite (piglit) against what is currently in debian git (ubuntu-maverick branch) against 3 different drivers and all have shown a hugely positive amount of fixes versus mesa 7.8.2.

http://sarvatt.com/downloads/piglit/

Intel 945GME results:
http://sarvatt.com/downloads/piglit/intel-945/

Nvidia 8200M GS (Using nouveau in libgl1-mesa-dri-experimental):
http://sarvatt.com/downloads/piglit/nouveau/

swrast driver:
http://sarvatt.com/downloads/piglit/swrast/

Mesa 7.9 currently has a hard deadline of releasing during the last week in september. There will most likely be weekly RC releases starting next week (the week of 09-13), it is branching from master in git this week.

Can we get some regression tests against nouveau systems? (nouveau may not support acceleration, but we want to make sure software rendering doesn't regress either.)

In my case (nVidia GT220M, nVidia codename NVA5) nouveau support 3D acceleration well and allow run difficult video games like Portal by Valve, and also compositing mode of Compiz and KWin sure.

The nouveau and swrast were both done on the same nvidia system, swrast is the default DRI driver used when libgl1-mesa-dri-experimental isn't installed. I have rebased mesa in debian git (ubuntu-maverick branch) to a 20100909 checkout and plan on rerunning the regression tests on all of my machines and will post the results tomorrow, there have been a significant amount of GLSL fixes commited since the 20100825 checkout used in the previous tests.

Robert,

Sorry, I was looking more for holistic testing of "does the desktop still look the way it's supposed to?" rather than testsuite testing. I'm assuming the piglit testsuite only tests API compatibility and doesn't actually point a camera at your monitor. :) Is there a reason to believe that piglit testing is sufficient to prove that, e.g., compiz will work correctly?

A point to consider for risk/benefit of this change is that if we don't get this update in, for Kubuntu we will have to patch kwin to blacklist the blur/lanczos effects and to revert to indirect rendering from direct. Upstream will help with the patch, but doesn't have hardware to actually test this. Also since direct rendering has been the default for KDE 4.5, the indirect rendering code paths probably aren't very tested. The ScottK risk-o-meter rates this course of action "sporting at best".

On Thu, Sep 09, 2010 at 11:26:12PM -0000, Scott Kitterman wrote:
> A point to consider for risk/benefit of this change is that if we don't
> get this update in, for Kubuntu we will have to patch kwin to blacklist
> the blur/lanczos effects and to revert to indirect rendering from
> direct.

Sure. I'm largely in favor of this going in under the circumstances, but I
want to make sure we're capturing as much information as possible about any
potential regressions before we push it into the archive post-beta and open
the floodgates on reports from end users.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I don't think piglit testing is sufficient to prove that compiz will
work correctly. That said, there's very little that actually *uses* the
software rasteriser - you can't run Compiz on it, you can't run KWin's
OpenGL desktop effects, and many games will fail to run, too.

I'll test swrast on my nouveau system.

Picking up Sarvatt's 7.9 ppa also fixes a serious Radeon bug I'm seeing - bug 626943 - it's the difference between assaultcube and google-earth being unusable on the open Radeon drivers and being normal.

Dave

On advice from ScottK I added this PPA and rebooted to see if it would fix the issue I reported in bug 631413, but it did not.

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA controller])
        Subsystem: Dell Device 01fe
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 45
        Region 0: Memory at fea00000 (64-bit, non-prefetchable) [size=1M]
        Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at eff8 [size=8]
        Expansion ROM at <unassigned> [disabled] ...

It's been pointed out that I haven't actually reported my nouveau results.

Nouveau still falls back to swrast, and compiz, unity, etc still correctly fail to start. There appear to be no regressions here.

With the 3D drivers installed from libgl1-mesa-dri-experimental, compiz & unity start correctly, and work fine. (Tested on an nv4B GPU).

FFe granted, then; please get this in ASAP.

This bug has been fixed by this package.

mesa (7.9~git20100909-0ubuntu1) maverick; urgency=low

  [ Robert Hooker ]
  * New upstream git snapshot up to commit 94118fe2d4b1e5 (LP: #631413)
  * New features include ATI HD5xxx series support in r600, and a vastly
    improved glsl compiler.
  * Remove pre-generated .pc's, use the ones generated at build time
    instead.
  * Remove all references to mesa-utils now that its no longer shipped
    with the mesa source.
  * Disable the experimental ARB_fragment_shader option by default on
    i915, it exposes incomplete functionality that breaks KDE compositing
    among other things. It can be enabled via driconf still. (LP: #628930).

  [ Christopher James Halse Rogers ]
  * debian/patches/04_osmesa_version.diff:
    - Refresh for new upstream
  * Bugs fixed in this release:
    - Fixes severe rendering corruption in Unity on radeon (LP: #628727,
      LP: #596292, LP: #599741, LP: #630315, LP: #613694, LP: #599741).
    - Also fixes rendering in gnome-shell (LP: #578619).
    - Flickering in OpenGL apps on radeon (LP: #626943, LP: #610541).
    - Provides preliminary support for new intel chips (LP: #601052).
  * debian/rules:
    - Update configure flags to match upstream reshuffling.
    - Explicitly remove gallium DRI drivers that we don't want to ship.
  * Update debian/gbp.conf for this Maverick-specific packaging
  * libegl1-mesa-dri-x11,kms: There are no longer separate kms or x11 drivers
    for EGL, libegl1-mesa-drivers now contains a single driver that provides
    both backends.

Date: Tue, 14 Sep 2010 08:55:40 -0400
Changed-By: Robert Hooker <robert.hooker at canonical.com>
Maintainer: Ubuntu X-SWAT <ubuntu-x at lists.ubuntu.com>
Signed-By: Scott Kitterman <ubuntu at kitterman.com>
https://launchpad.net/ubuntu/maverick/+source/mesa/7.9~git20100909-0ubuntu1

Woohoo!

Is it still planned to include Mesa 7.9 final in Maverick as per the "General X.org plans for M" blueprint at https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm ? Mesa 7.9 final is scheduled for release by the end of September - see http://lists.freedesktop.org/archives/mesa-dev/2010-August/002648.html
The Mesa 7.9 release tracker bug is at https://bugs.freedesktop.org/show_bug.cgi?id=30124

If Mesa 7.9 final is not included in Maverick, we will probably want commit e7eff0cfcef5c549678779e3c1def950feae4fb9 by Jesse Barnes. As explained in the earlier commit c121608b6e409fe6c22cb8b05c52cc94d2dfb0af (also by Jesse Barnes), this adds a PCI ID to allow the KMS EGL driver to load on an Intel Pineview.

We might also want to consider commit 9532eea509321d8f88a4e60191a1e659ada40dfe by Alex Deucher. This is titled "r600c: const buffer sizes must be a multiple of 16 consts" and has the comment "This applies to r6xx/r7xx/evergreen".

There are a couple of others to consider too. The first is commit 428dc6d7d2cf6a5da37a2ea7ce436cf521b009a2 by Marek Olšák. This is titled "r300g/swtcl: unlock VBO after draw_flush" and has the comment "https://bugs.freedesktop.org/show_bug.cgi?id=29901 https://bugs.freedesktop.org/show_bug.cgi?id=30132 ". This fixes a crash in Neverball with the r300g driver and also fixes a crash in Nexuiz, and possibly fixes crashes in OpenSceneGraph, Blender 2.5.3, and Make Human. The second is commit 6b5575baaa16563f1ea1ad1821254ce6c412283f by José Fonseca. This is titled "llvmpipe: Fix non SSE2 builds" and has the comment "Should fix fdo 30168."

One last one to consider is commit 5d4409e0e57c280a7b3a0655543e089bcf8da0ed by Marek Olšák. This is titled "r300g: prevent creating multiple winsys BOs for the same handle" and has the comment "This fixes a DRM deadlock in the cubestorm xscreensaver, because somehow there must not be 2 different BOs relocated in one CS if both BOs back the same handle. I was told it is impossible to happen, but apparently it is not, or there is something else wrong. (cherry picked from commit 0b9eb5c9bb03e5134d9a41786178100109e80c5a)". Note that if we add this commit we will also need to add the next commit, namely commit fd4c6bd1357fd9931f6c6bdbcfb01ebc2ba01f1b by Dave Airlie. This is titled "r300g: fix buffer reuse issue caused by previous commit" and has the comment "caused by 0b9eb5c9bb03e5134d9a41786178100109e80c5a. test - run glxgears, resize. (cherry picked from commit 09ef8e9283f17e5dc9fa4a86c659048acda833cb)"

s-j-turner, thanks for the listing of git commits. Have you personally tested the fixes individually that they fix bugs you can reproduce on ubuntu?

I ask because there's always going to be patches upstream that sound from the git changelog entries to be nice cherrypicks, but unless we can confirm both the bug and the fix, we're unlikely to get SRU's accepted for them. Indeed, often helpful sounding patches have undesirable side-effects so this late in the release we have to be careful.

Even if you've not verified them personally yourself, that list might be useful while doing bug triage in coming weeks. If someone else reproduces the bug you could have them try out the patches and if it fixes the issue, it'd be easy to sru the cherrypick at that point.

I agree wholeheartedly about the being careful to avoid undesirable side-effects.

The only one of those commits I would include for sure is the one that adds the PCI ID for the Pineview chip.

The last one that I mentioned is especially risky.

I can't test the first two because I don't have the necessary hardware (I have an ATI R350). I might be able to test the third one, but I don't have any skills at compiling from git. The closest I got was doing a successful git clone of the mesa repository back in the Karmic days. However I might give Mesa 7.9.0+git20100915.e0b6df4f-0ubuntu0sarvatt from the xorg-edgers PPA a try.

Is it still planned to include Mesa 7.9 final in Maverick as per the "General X.org plans for M" blueprint at https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm ?

We have a pre-release snapshot of 7.9 in maverick currently, and are dealing with the resultant bugs. Whether Mesa 7.9 final depends entirely on whether Mesa releases the final version in time for the Ubuntu final freeze. I wouldn't hold my breath.

Final freeze is 3 hours and 20 minutes away, according to https://wiki.ubuntu.com/MaverickReleaseSchedule

It would be good to make an exception for Mesa 7.9 final, given the pre-release testing we are currently doing.

Correction - add 10 hours to that.

It doesn't look like this helps bug #606595.