[ubuntu-x] Jaunty upgrade report

Bryce Harrington bryce at canonical.com
Wed Apr 1 20:26:35 BST 2009

On Wed, Apr 01, 2009 at 07:11:01PM +0100, Chris Jones wrote:
> In the case of the X40, this is because it has an 855GM chipset, which
> is well known to be problematic with the Intel driver in Jaunty (as
> mentioned in the beta release notes). Disabling DRI generally helped. I

Yesterday I put in a Legacy3D disablement patch which purportedly
improves things on i855 (and maybe other 8xx chips).  I would appreciate
if you could test this (esp. if you could compare with and without the
patched version of the driver, either qualitatively or quantitatively.)

> In the case of the X300 (which has a 965 chipset), the 3D performance is
> generally sluggish in all but very simple usage. It seems to be closely
> I think this is bug #339555, but without a more simple test case it's
> hard to be sure.

Yes, one of the troubles with these performance bugs is it is hard to
find a good measure.  As they say, "If you can't measure it, you can't
improve it."

Indeed, one of the major reasons I've been focusing my time on crash
bugs rather than performance is that crash bugs are a lot more
definitive to sort out since once you have a full backtrace there is
solid data to work from.  (The other reason being that crashing
behaviors seem the more vexing of a problem.)

It would help a lot if someone could come up with some solution for

> I have tried using UXA instead of EXA (which made no difference, and has

I haven't been able to reproduce the performance problems on my own
hardware, but others have shown me briefly on their systems so I know
it's a legitimate problem.

I wish the situation was a black-and-white "Switch to UXA, and you're
guaranteed to get better performance".  As you point out though, some
people see no performance benefit.  Others on the same chipsets have
reported seeing major performance regressions.  Same with XAA.

So, even knowing it's a legitimate problem, how do you even approach
such a situation, where changing a key parameter simultaneously has no
effect, improves things, and makes things worse!  ;-)

> I have subsequently pulled xf86-video-intel from git and identified the
> revision that matches up with the 2.6.3 release currently in Jaunty. My
> plan for this evening is to install the xorg-edgers snapshot of DRM and
> then attempt to bisect xf86-video-intel in the hope that there is a
> simple change which fixes things; With the diff between 2.6.3 and tip
> being ~8k5 lines, I am not expecting a miracle one-liner, nor have I
> tested the xorg-edgers PPA on Matt Barker's X61.

If you find a simple change fixes things, that would be great.  I have a
suspicion though that solving this is going to require a number of
different changes.

Also, given that you saw the performance troubles in 3D stuff (compiz),
that would suggest mesa as the more likely source of the improvement.
(Although, there is enough coupling between -intel and mesa that it may
require something changed in each.)

> I am also curious if the Intrepid version of the driver will perform
> well and will attempt to rebuild this in Jaunty [confidence on #ubuntu-x
> for this being a good idea, is low, as I write this].

Various quarters have suggested holding back -intel to the Intrepid (or
even Hardy) version.

I'm skeptical it would actually help though.  -intel is the *2D* DDX
driver, so alone is probably not the component causing the performance
regressions.  More likely would be the changes in mesa, xserver, libdrm,
or even the kernel, each of which has a key role in the 3D pipeline
needed for making compiz perform well.

There are also a lot of interdependencies between these pieces (and with
-intel).  So by reverting any one of the pieces, it increases the chance
that the pieces don't work together quite right, which would show up as
new bugs.  The safest thing would be to revert them all to a state we've
tested previously.

However, I could easily be wrong.  Building and testing with the
Intrepid driver (or even the Hardy driver) would be straightforward to
do and would be productive no matter how it turns out - either we
confirm what we already suspect, or best case gain an option we can


More information about the Ubuntu-x mailing list