Bug 46213

To put your results in context, my 855gm achieves 470fps and 55fps fullscreen (1024x768). So I judge yours to be in line with what to expect from the hardware, if a little subpar.

The secret with these gen2 devices is not to use GL at all! For instance, with video use the video overlay (by using Xv). And compiz is just going to be a waste of time and energy.

The numbers in this report talking about glxgears just reflect surprise at vsync.  It is an intentional choice to avoid tearing, and not something we will change by default.  If you're excited about seeing tearing in your apps and rendering frames you'll never see, you can disable vsync in driconf.

If you can come up with a specific application that is using CPU where it didn't before and a sysprof profile showing that CPU usage (and probably INTEL_DEBUG=fallback output explaining the software fallback), then we might be able to do something.

Created attachment 57960 [details]
Xorg.0.log

Created attachment 57961 [details]
dmesg output (no drm.debug=0x06 option)

Created attachment 57962 [details]
xorg.conf

Created attachment 57963 [details]
xrandr --verbose

Created attachment 57966 [details]
VBIOS dump

Sorry for answer so late, this is not my main computer (it's my parents one).

Ok, after some regular usage (reading mail, surfing web...) with System Monitor at panel to see how system evolutes:

* CPU is always about 5-10% and system load about 0.5-1
* just moving the mouse CPU increases to 40%
* browser scrolling (Chromium 17.0.963.56) increase CPU to 80-100%
* loading a webpage with about 100 thumbnails freezes browser with CPU 100% about two seconds
* Gnome Mahjongg gets frozen with CPU 100% at refreshing window when going from windowed to maximized and viceversa for about 2 seconds

Also i'm thinking about try with old Ubuntu Live-CDs to look for when started the regression.

I'll try to do the sysprof this afternoon (i need to learn to use it). Where must i use the INTEL_DEBUG=fallback flag? As kernel parameter un Grub?

And no, i'm not excited about rendering frames i will not see ;-) I disabled vsync just for try and it was the only thing that did relative small YouTube videos (320x240) didn't drop frames and get frozen... :-/ I really would love to have vsync back... :-D Oh, and i don't want to use compiz (i hate it and in fact i'm using a plain no-effects Gnome panel desktop), maybe just some games like Warmux or Quake 3 (this would be a good performance test to put in perspective since my old P3 1.1GHz computer with an i815 graphic card played it very good, i'll try later). Compiz was just an example that the graphic card was enought powerful to use it without problems... :-)

P.D.: i've attached the pending log files. It keeps some with boot flags, i'll try to upload later.

Created attachment 57977 [details]
dmesg

Created attachment 57978 [details]
Chromium scrolling

Created attachment 57979 [details]
Mahjongg going from window to maximized

Created attachment 57980 [details]
Mahjongg going from maximized to windowed

Added attachements for dmesg with drm.debug=0x06 flag enabled and profilings of Chromium scrolling (just this bug page) and maximizing and windowing Gnome Mahjongg.

In those examples, the driver is not the bottleneck.

Should i do the tests with a fresh install of Ubuntu? What would be a good example?

You need to find something that performs absymally due to a mistake in the driver. Otherwise, we will continue to insist that everything is as good as it is going to get on that hardware...

The best examples will be taken from your usual workloads as that will give the greatest perceived improved, and that's the challenge you face.