Intel Linux Graphics On Ubuntu Still Flaky

[phoronix]

Phoronix: Intel Linux Graphics On Ubuntu Still Flaky

Back in May we shared that the Ubuntu Intel graphics performance was still in bad shape after testing out very early Ubuntu 9.10 packages. The netbook experience was killed in Ubuntu 9.04 after a buggy Intel Linux graphics stack led to slow performance, stability issues, screen corruption, and other problems. Months have passed since we last exhaustively looked at the Intel Linux graphics stack, but we have just carried out some new tests using Ubuntu 9.10 Alpha 3. This new development release of Ubuntu carries the latest kernel, Mesa, and Intel driver packages as we see how the graphics performance is with an Intel 945 and G43 chipsets.

http://www.phoronix.com/vr.php?view=14082

[combuster]

Somehow I wouldn't agree on performance of intel drivers, with 2.6.31-rc4 and xf86-video-intel 2.8.0 and mesa 7.5 everything works great, I play urban terror almost every day and not once did it froze my system and I have playable fps (25-40). We agree on the bug count, only one affecting me is brightness hotkeys that doesn't work when kms is enabled.

Sure that things could be better but I finally have performance that I had with EXA almost two years back. I have a GM965 chipset with x3100...
Even though I have dual memory channel enabled (and I've heard that it is causing some major performance issues with intel drivers) I'm finally satisfied with current situation and probably just out of curiosity and not because of necessity will I test snapshot's of intel drivers. Stability comes first and I have that now, performance... well I know that x3100 doesn't have any pep for gaming but as long it doesn't tear my video's and doesn't choke on compiz - me happy :)

[Regenwald]

omg ubuntu again...slower than 9.04...9.04 was horrible, it's a *really* heavy regression...intel 2.8 works perfectly with other distri...what do they at canoncial??...how incompetent can they be??! don't get it...ok it's an early alpha version, but it's blind to hope for a heavy improvement...one more reason *not* to use ubuntu!

[FireBurn]

Like I ask on most of your articles, have you raised a bug for any of these regressions? Either on freedesktop or with ubuntu?

Also how do you know it's Mesa 7.5 that's the issue and not libdrm or the drm kernel driver?

MAybe if you spent some time talking to the developers on IRC and less time running the PTS some of these regressions would be fixed

Hope you reply to this

Mike

[Kano]

Well Intel onboard gfx was never top notch, that's clear. It is a chipset for websurfing, office and less demanding games. As it does not support OpenGL 2 not even HoN will run on it. On desktop systems that's definitly no problem as you can add a PCI-E card if needed. Laptops users should know that the chipset is not designed for games before they buy it.

[VisitorQ]

Actually, using the Karmic alpha brings a very good experience from a users point of view. For example, when I connect an external monitor on my laptop, the desktop wasn't extended over the entire second screen, it was cut off somewhere in the middle of the screen. The new drivers fixed that issue, and also I can plug in my monitor, run the display tool from the prefs menu, and the external screen already turns on at the desired resolution before I actually press a button on the display dialog.
Also, the desktop effects work fluently on Karmic, not choppy what-so-ever. Of course this is all subjective information and I'm sure that these tests get a more objective result for certain issues, but the user experience will increase with the next Ubuntu release. I wanted to send a thumbs up to the devvers involved, but Im not sure to use a bug report for that, therefore I'll do it here :)

[fabiank22]

Well Intel onboard gfx was never top notch, that's clear. It is a chipset for websurfing, office and less demanding games. As it does not support OpenGL 2



OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20090114
OpenGL version string: 2.1 Mesa 7.5-devel
OpenGL shading language version string: 1.20

Running a x3100 on Fedora 11, since Rawhide 12 is broken this week :D

So yeah, they have OpenGl 2.

[combuster]

I'm running arch linux with custom 2.6.31-rc4 kernel and as I've said earlier this is the best performance from intel I've seen so far. I've filed around five or six bug reports @bugzilla and they have all been fixed except brightness keys but there is a workaround with acpi_brightness=vendor kernel parametar. Ubuntu is the most popular distro but karmic isn't exactly a perfect enviroment for benchmarking since it's heavy alpha still. I've been following the development of intel drivers for quite some time now and this is by far the best job they did - kms works great, performance is equal to exa and stability is great. As far as the games are concerned I would agree with Kano, as long as users don't expect from their intel gpu's to do wonders I think they'll be satisfied with current performance, I hope it is going to be better in the future but for now I'm happy with the one I have now...

[L33F3R]

I play urban terror almost every day and not once did it froze my system and I have playable fps (25-40).

Thats crap FPS.

[BlackStar]

omg ubuntu again...slower than 9.04...9.04 was horrible, it's a *really* heavy regression...intel 2.8 works perfectly with other distri...what do they at canoncial??...how incompetent can they be??! don't get it...ok it's an early alpha version, but it's blind to hope for a heavy improvement...one more reason *not* to use ubuntu!

Ubuntu 9.04 was easily the best Ubuntu release to date. No, I don't have an Intel IGP, but my two systems (laptop w/ nvidia running from a usb stick, desktop w/ ati on a regular hard drive) run better than 8.10 on all measurable accounts.

Thats crap FPS.
It's an Intel IGP what did you expect? Shared memory tends to kill fps.

[Craig73]

From my brief testing, the performance of the latest Intel drivers is significantly better than what shipped in 9.04. Now I'm running 9.04 with a new kernel, xorg edgers, and an old 855GM chip (so there are limitations :-) ) so it's far from what you are testing, but I think the Alpha status should be taken more seriously. Perhaps, as suggested in many places above, test the Intel drivers on another platform.

[combuster]

@L33F3R

For me anything better then 30fps is great and does not stutter... If it drops below 25fps I can actually see that it's a choppy frame rate. In any case this is not what we are talking about here...

[kxmas]

Like I ask on most of your articles, have you raised a bug for any of these regressions? Either on freedesktop or with ubuntu?

Also how do you know it's Mesa 7.5 that's the issue and not libdrm or the drm kernel driver?

MAybe if you spent some time talking to the developers on IRC and less time running the PTS some of these regressions would be fixed

Hope you reply to this

Mike


The author doesn't know. This article is completely mislabeled. It's comparing Ubuntu 9.04 to Ubuntu 9.10 alpha 3. No other conclusion can be drawn.

Way too many variables changed to know where the bottle neck is. It would be interesting to run the tests with versions 2.6, 2.7 of the intel drivers against the same Ubuntu 9.10 alpha 3 release. Then we'd know something.

[pvtcupcakes]

From what I've heard on the Arch Linux forums is that 2.8 runs much faster on the 2.6.31 kernel than it does on .30.

From my experience on Arch with Linux 2.6.30, I get 850fps on glxgears with 2.7 and 550 with 2.8.

I haven't been able to try 2.6.31 on that system because I wasn't paying attention when I bought the laptop and I ended up with a broadcom wifi chip, and the driver from AUR doesn't support 2.6.31 yet.

[Rip-Rip]

[...]

I haven't been able to try 2.6.31 on that system because I wasn't paying attention when I bought the laptop and I ended up with a broadcom wifi chip, and the driver from AUR doesn't support 2.6.31 yet.

Have you tried the driver included in the kernel, b43?

[slumbergod]

Jaunty was the worst release for me so far. I experience terrible graphics performance (yes, Intel chipset) and regressions with sound (low volume, no physical volume control).

Given the popularity of Intel chipsets on low cost laptops it is hard to believe Jaunty was released - a good argument for releasing when something is ready rather than a regular date.

I hope Koala shapes up to be a better release but this time around I will wait before doing a clean install to see if the important things are fixed.

[pvtcupcakes]

Have you tried the driver included in the kernel, b43?

According to http://linuxwireless.org/en/users/Drivers/b43 my chip isn't supported by the kernel driver.

My PCI ID is 14e4:4315.

[ethana2]

Can PTS run system updates every day at a given time, immediately run benches, and then make line graphs of a release day over day? I think that kind of thing would be fascinating to see.

[ethana2]

..plus that would allow for articles like "Ubuntu 9.10 3d performance jumps 32% today with xorg intel driver update"

[mtippett]

Can PTS run system updates every day at a given time, immediately run benches, and then make line graphs of a release day over day? I think that kind of thing would be fascinating to see.

http://phoromatic.com/

Continous integration and ongoing performance management is something I would dearly love to see lots of OSS projects pick up.

Matt

[7oby]

Thanks, Michael Larabel for continuing to post meaningless benchmarks and drawing wrong conclusions.

From my experience on Arch with Linux 2.6.30, I get 850fps on glxgears with 2.7 and 550 with 2.8.

There is a technical reason of why 2.7 (I assume EXA/DRI1) performs faster in glxgears than 2.8 (UXA/DR2):

The difference between DRI1 and DRI2 is due in part to the context switch necessary to get buffer swap commands from the DRI2 application to the X server which owns the ‘real’ front buffer. For an application like glxgears which draws almost nothing, and spends most of its time clearing and swapping, the impact can be significant (note, glxgears is not a benchmark, this is just one of many reasons). On the other hand, having private back buffers means that partially obscured applications will draw faster, not having to loop over clip rectangles in the main rendering loop.
http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/

But as Keith already mentions: glxgears is not a benchmark. But maybe you need one more:

Nobody measures the performance of "draw the same triangles over and over". And if someone does, (by seriously quoting glxgear fps numbers, for example), then everybody gets a good laugh. In fact, the phrase "glxgears is not a benchmark" is a catchphrase among 3D developers.
http://www.cworth.org/intel/performance_measurement/

Now that we laughed about you and Michael for drawing conclusions from this same benchmark (just ported to QT4):
http://zrusin.blogspot.com/2008/08/fast-graphics.html

Let's consider some serious aspects. We need real application benchmarks such as game engines, firefox rendering or compiz performance. But even in this case, performance may degrade from one version to another. If that's the reason one should check whether one of these reasons apply:

. I noticed in Urban Terror, when performing Mesa benchmarks, that in certain revisions of the Mesa Stack on x3100 GM965 hardware, some visual effects were not drawn e.g. some lightning or the shot of your weapon. If it's not drawn the entire scene draws faster (though with slight visual corruption or flaws) and you get higher fps reports.

. In some of the recent versions of the intel driver tearing disappeared. I'm not aware of in which version exactly and whether it applies only to indirect or direct rendering, but this might may a dfficerence. I remember Jesse talking about double buffering:
http://virtuousgeek.org/blog/index.php/2009/05/
I don't know whether this entered mainline or whether it's related. BUT: I don't see tearing with 2.8.0 in compiz enabled X-Org anymore and I know that double buffering has an impact on reported framerates (compared to tearing withough v-sync):
http://www.anandtech.com/video/showdoc.aspx?i=3591&p=3

--

Michael, please remove QGears2 benchmarks from the benchmark suite that you use for performance evaluation. That applies to the GTK benchmarks as well that you used in this article, which I critized already some time ago:
http://www.phoronix.com/forums/showthread.php?t=17726

[mtippett]

Thanks, Michael Larabel for continuing to post meaningless benchmarks and drawing wrong conclusions.


Out of interest, how do you suggest you provide a quantative answer to the "Is Ubuntu 9.10 looking to be faster or slower than 9.04 for Intel Users?".

[Craig73]

Out of interest, how do you suggest you provide a quantative answer to the "Is Ubuntu 9.10 looking to be faster or slower than 9.04 for Intel Users?".

Why does this question need to be answered on an alpha? (From a publication stand point... I can certainly see it's value from a build quality perspective, but this should be more automated and focused on identifying bottlenecks and regressions, not a "review")

[BlackStar]

Why does this question need to be answered on an alpha? (From a publication stand point... I can certainly see it's value from a build quality perspective, but this should be more automated and focused on identifying bottlenecks and regressions, not a "review")

The alpha already contains most of the components that will make it to the final build. In other words, the performance of the alphas should be indicative of the performance of the final build, unless some specific regression is identified and fixed in the meanwhile (and those tests *do* help in finding regressions).

This was the case with 9.04 for example: the final build had pretty much the same performance as the alphas, at least on my hardware (Ati R500 with the OSS drivers).

[chaos386]

The alpha already contains most of the components that will make it to the final build. In other words, the performance of the alphas should be indicative of the performance of the final build, unless some specific regression is identified and fixed in the meanwhile (and those tests *do* help in finding regressions).

This was the case with 9.04 for example: the final build had pretty much the same performance as the alphas, at least on my hardware (Ati R500 with the OSS drivers).

I had pretty much the opposite experience with the 8.10->9.04 upgrade. The Phoronix review of Intel performance on the 9.04 Alpha indicated a performance regression, but I saw 3x the 3D performance on my G43-based motherboard.

[combuster]

Is ubuntu 9.10 going to be faster then 9.04 for intel users?

You answer: We tested it with phoronix-test-suite and our conclusion is that the performance will be the same but slightly more unstable. But we tested the newest intel drivers and rc kernel on another distro (like arch, gentoo etc) and it showed boost in performance so we can't be sure at this point.

I untill recently was very dissapointed in intel's performance although it has advantages over other gpu's because I can built it straight into kernel and I don't have to worry about will nVIDIA or ATI release a driver that will compile on this rc kernel. I like oss and that is one of many reasons I use linux. But now, when they finally did a decent job I read more dissapointing news here on phoronix... Maybie those guys @canonical are doing something wrong but as I say 2.6.31+2.8.0 works perfectly stable and as fast as intel drivers ever where...

[mtippett]

Why does this question need to be answered on an alpha? (From a publication stand point... I can certainly see it's value from a build quality perspective, but this should be more automated and focused on identifying bottlenecks and regressions, not a "review")

It's called performance management. You maintain visibility on performance during development so that you can track when and if there are performance issues and deal with them before production. Realistically, you do not see any public reference to performance of Ubuntu on an ongoing basis except on Phoronix. I trust that as Ubuntu 9.10 gets closer to release, Michael will extend the testing to include the history and ups and downs as it gets closer.

In general, if you look at some of the "this made some one look really bad" articles, the group with the gap go away, do a few blog postings and discuss what happened. This happened with the SuSE barrier usage. It caused discussion, it caused awareness.

Phoronix is just taking a mid-stream alpha and benchmarking it.

If the numbers are wrong, do a PTS response to show where the numbers are wrong.

If the numbers are right, work with the Ubuntu community to close the gap, offer to help Bryce select the right patch set for the intel drivers. You only have a few milestones left.

If you don't believe the tests are valid, help define some valid ones to improve the quality of the information.

Matt

[combuster]

Ok here are my results:

gtkperf: 2.6.30 - 1676 ; 2.6.31-rc4 - 1573
glmark: 2.6.30 - 64 ; 2.6.31-rc4 - 70
urban terror: 2.6.30 - 20.35 ; 2.6.31-rc4 - 23.70

So I don't think that there is regression on 2.6.31-rc just an improvement

[7oby]

Out of interest, how do you suggest you provide a quantative answer to the "Is Ubuntu 9.10 looking to be faster or slower than 9.04 for Intel Users?".

I answered that already in my previous posting: We need real application benchmarks such as game engines, firefox rendering or compiz performance.

It's not a question of the phoronix test suite itself, but of the benchmarks choosen. If developers itself need profiling software (http://en.wikipedia.org/wiki/Profiler_%28computer_science%29) to recognize which software pieces are used and to detect software hot spots, what do you think what kind of tools a reviewer needs?

Well, Eric Anholt needs cairo-perf-trace:
Thanks to cairo-perf-trace, I've just landed a 10% improvement in firefox performance for UXA
http://anholt.livejournal.com/41306.html

Phoronix needs to recognize that it's low level synthetic benchmarks are meaningless. It needs to focus on real applications, because it's simply not experienced enough to work with other benchmarks in order to draw the right conclusions.

[mtippett]

I answered that already in my previous posting: We need real application benchmarks such as game engines, firefox rendering or compiz performance.

It's not a question of the phoronix test suite itself, but of the benchmarks choosen. If developers itself need profiling software (http://en.wikipedia.org/wiki/Profiler_%28computer_science%29) to recognize which software pieces are used and to detect software hot spots, what do you think what kind of tools a reviewer needs?

Well, Eric Anholt needs cairo-perf-trace:

http://anholt.livejournal.com/41306.html


Profiling is for developers, benchmarking is for users.

Benchmarking determines a macro issue that needs attention, profiling allows developers to deep dive into hotspots that need attention and provide improvements in the benchmark.

Note that cairo-perf-trace generates an application call profile, which then can be played as a benchmark. The developers then profile the benchmark to get the hotspots.


Phoronix needs to recognize that it's low level synthetic benchmarks are meaningless. It needs to focus on real applications, because it's simply not experienced enough to work with other benchmarks in order to draw the right conclusions.

As has been mentioned before, if people are concerned about the quality or correctness of the benchmarks themselves, by all means, invest the effort into getting cairo-perf-trace into PTS. Be part of the solution :).

A final comment...

I don't think Phoronix pulls many conclusions other than the benchmarks presented show a performance delta. What does happen though is the parties that are implicated by the performance issue actually begin to communicate, an example is

http://bugs.freedesktop.org/show_bug.cgi?id=23083#c3

Bryce (Canonical) concurred about a potential performance issue associated with the intel drivers. He raises a bug to track, intel acknowledges and looks to reproduce the issue. The critical part is that a DISCUSSION is now underway to quantify if there is an issue.

That is the value of the Phoronix benchmark articles. It raises to the surface potential issues and triggers a discussion that would most likely not have occured in the past.

Regards,

Matthew

[7oby]

Profiling is for developers, benchmarking is for users.

Benchmarking determines a macro issue that needs attention [...]
Picking the wrong benchmarks you can prove anything. My point was clear from the beginning and you try to argue.

As has been mentioned before, if people are concerned about the quality or correctness of the benchmarks themselves, by all means, invest the effort into getting cairo-perf-trace into PTS.
As I pointed out already: It's not a question of PTS itself, but the chosen benchmarks.

PTS puts to much emphasis on the number of benchmarks they include:
http://www.phoronix.com/scan.php?page=news_item&px=NzI0NQ
Your posting confirms this: "Give me cairo-perf-trace ..."

What does happen though is the parties that are implicated by the performance issue actually begin to communicate
If phoronix would be testing the remaining ~ 100 - 3 = 97 PTS benchmarks and would file a bug report for each of them, we would have even more discussion.

I appreciate digging out performance issues! But given that there are only 12 people working on intel drivers:
http://intellinuxgraphics.org/team.html
we should really stick to relevant ones. Phoronix has a great visibility and with that visibility comes repsonsibility.

[Schugy]

Nice to see some progress even if I don't have an Intel IGP.
Hope the ati drivers will mature faster because the RS690M is no longer supported by Catalyst drivers. I want to go on with my old savegames.

[zareason]

I think Michael just had a bad netbook. I tested Padman, Urban Terror and Tremulous without issue on my netbook. 9.10 Alpha 3 is already a big improvement over 9.04. Results are here:

http://global.phoronix-test-suite.com/index.php?k=profile&u=malmrose-24581-7150-11344

[Linuxhippy]

Picking the wrong benchmarks you can prove anything. My point was clear from the beginning and you try to argue.

However, at least the JXRenderMark tests were developed to emulate common paths of Java2D's XRender pipeline.
So you are right, JXRenderMark is a microbenchmark, however it was been designed to mimik real-world behaviour of real-world to allow driver developers to optimize their drivers for some piece of real software.
Thats why a large GPU manufacturer uses it for nightly regression testing.

The problem is this:
If you report a performance bug against a large piece of software, they won't listen because they don't want to investigate it on their own. If you write small benchmarks you are ignored, because thats only microbenchmarks.
Some JXRenderMark tests show a horrible regression, e.g. scanline based rendering got 50% slower.
So if your app is not cairo based *caught, caught*, you are out of luck!

After all, I don't consider a driver mature which requires a syscall + GPU stall per XPutImage!


> I appreciate digging out performance issues! But given that there are only 12 people working on intel drivers
I don't know any other oss driver, which has 12 full time working on it.

- Clemens

[mtippett]

However, at least the JXRenderMark tests were developed to emulate common paths of Java2D's XRender pipeline.
So you are right, JXRenderMark is a microbenchmark, however it was been designed to mimik real-world behaviour of real-world to allow driver developers to optimize their drivers for some piece of real software.


I agree with aspects of this post.

A suitable analogy is that of a big city. You can look at the macro effeciency of the city's ability to move people around, or to a particular event - this is like a "real world" benchmark. You can then profile different control points to determine if there is some part of the urban planning (the architecture) that is flawed for a particular traffic flow.

To "manage" the urban traffic flow almost every city puts in traffic flow information around traffic lights as well as on the major traffic paths ("known choke points" and "common code paths").

Ideally these paths allow characterization of the bigger problems and if you keep traffic flowing at these check points you can generally keep the city flowing nicely.

Now of course, the difficulty is choosing the check points that represent the common traffic (or performance) conditions that will affect real world usage.

A second issue to consider is relevance of the benchmarks. x11perf - in it's day was a great tool for analyzing the entire Xlib path. There were stippled lines, ellipses and everything that the athena toolkit used on a regular basis, so if you had a performance issue reported, you could contrast old x11perf results agains new results. Most likely in any given performance issue, there was a particular test that lay fair and square on the active path for the performance issue.

Most developers have neither the time, nor the interest to create a test app that covers the large proportion of their API. Consequently we start moving out to large applications and hoping to benchmark them. To benchmark them you need either a higher level benchmark framework to capture a profile, or you need intrinsic benchmarkability somewhere in the pipe.

You still end up creating a representative benchmark for a particular application flow. If you as a user don't have the same usage pattern similar to the "real world application" benchmark, you basically out of luck. Likewise, if the application changes and the benchmark isn't updated, you may be tuning for the wrong thing.

A great example of this is Wine. They have switched recently to using RENDER for doing most of their display compositing. If a representative benchmark doesn't include RENDER, then the real-world benchmark isn't worth anything anymore. *BUT*, you will know that a micro-benchmark (such as, say, JXRenderMark), will probably give you an indication of the RENDER performance.

Each has their place, but something is better than nothing.


The problem is this:
If you report a performance bug against a large piece of software, they won't listen because they don't want to investigate it on their own. If you write small benchmarks you are ignored, because thats only microbenchmarks.
Some JXRenderMark tests show a horrible regression, e.g. scanline based rendering got 50% slower.
So if your app is not cairo based *caught, caught*, you are out of luck!

...


Another great point.

I proxy a large number of issues into AMD. When an issue gets my attention and begins to move into the driver team, I generally refuse to bring in a either a macro benchmark or a monolithic application.

I ask for either a representative benchmark of the bottleneck they are expecting, or I ask for a reduced test case that demonstrates the problem.

Most developers are aware of the behaviour of their code, and what happens under different work loads. Unsurprisingly, due to their understanding of the code getting the above doesn't cause too many issues. We typically get a smaller test-case demonstrating some problem or we get pointed to other micro-benchmarks that can serve as a proxy.

Thanks for the great points.

[7oby]

However, at least the JXRenderMark tests were developed to emulate common paths of Java2D's XRender pipeline.
I appreciate the Java XRender effort and the posted benchmark as well.

It seems the general user or at least I will not profit from it:

. requires "-Dsun.java2d.xrender=True" launch option, which only very few people are aware of and know how to enable. Definitely not the out-of-the-box experience - besides possible visual corruption bugs.

. The only major java app that I use is Eclipse, which is based on SWT for GTK+ and though GTK+ uses XRender I don't know whether there's an intersection of the functions used by GTK+ and JXRender Benchmark.

. Most java apps that I write are headless server apps and backend components. However I once wrote an application for a digital astronomical camera, which made heavy use of Java2D and in particular "BufferedImage" to store and manipulate 16-bit grayscale images (histograms, gamma corrections, zooming). However: "BufferedImageOps are not accalerated because XRender does not provide functionality required to accalerate those features."

Seems I currently don't have a use case for XRender performance for me. But as I said: The effort itself is very valuable.

--

To determine whether Ubuntu Y.X has regressed or improved user performance I suggest four benchmarks measuring

. compiz
. firefox
. Adobe flash
. one OpenGL based game

performance. I also appreciate micro benchmarks, but meaningful ones. Even using 2560 x 1600 displays I can't image of an application that is limited by GTK Radio Button rendering performance, but I immediately recognize if scrolling performance degrades. I don't know whether the latter is included in one of the low level benchmarks.

Storage Review provides a very clear explanation of their testing methodology:
http://www.storagereview.com/Testbed4.sr
You learn what each micro benchmark measures and how to judge whether this particular aspect matters to you or not.

Maybe phoronix can provide something like this and we start a DISCUSSION about which tests to include for reviews.

[combuster]

I'm really confused now...

http://bugs.freedesktop.org/show_bug.cgi?id=23083#c6

[mdmadph]

God, that's horrible performance

[kxmas]

I'm really confused now...

http://bugs.freedesktop.org/show_bug.cgi?id=23083#c6

Me too. Similar hardware should yield similar results.

So, people that use the new driver and kernel don't have proof that the results are wrong, but their experience says they're wrong.

Now, we have someone with the same type hardware fail to reproduce the results. Puzzling....

[squirrl]

Unreal Tournament 2004 -
800x600 it's ok. Playable.
1024x768 it starts stuttering.
1280x1024 forget it.
---------------------------------
Glxgears -
800 -> 1100 fps sometimes 24000 fps <-- weird
----------------------------------
Nexuiz - awful but manages
----------------------------------
Blender 3D latest
trash
----------------------------------
KMS has some quirks. External LCD's suffer.
Kernel Mode Setting.
----------------------------------
I own a few games and I've run a few tests and I'm sick of hearing about performance improvements from the Intel developers. They need to shut up and fix this. No more announcements until it's fixed.

Ubuntu needs to back port fixes!
----------------------------------------------------

http://anholt.livejournal.com/41306.html yeah right

Intel right now sucks on every distrubution.

[squirrl]

Pull the latest mesa git.

It's running smooth in ut2004 now ...
no idea why yet I haven't read the changelog.. sleep

[combuster]

I've posted my results a few pages back, just didn't mentioned them on freedesktop (I was running a full set of gtkperf tests at once)... I don't know how Michael got those results but that could be because of some update that came up in ubuntu repo's for 9.10 and Gordon couldn't replicate it. As for myself I'm runing my test's with GM965 and Arch linux with custom kernel and not with G43 and Ubuntu so first I thought that G43 was the only one affected by this regression but appearantly it wasn't either... But many of my fellow archers are having the same experience with 2.6.31 kernel, Intel gpu's runs faster and that is a fact...

http://www.phoronix.com/forums/showpost.php?p=85128&postcount=28

[Casandro]

I mean I recently switched from 9.4 to 9.10 and it was totally worth it. With 9.4 I had regular screen corruption on KDE and now 9.10 even supports desktop effects, flawlessly.

The only complaint I have is that it doesn't support anything but the VGA output of my motherboard. So no DVI and no dual-monitor setups. That's frustrating.