[RESOLVED] Poor performance on Ironlake compared to old Intel GPU

ScionicSpectre · 2012-01-06 05:34:53

I have a brand new Acer Aspire TimelineX 1830T with an Intel HD video card, which I bought to replace my Fujitsu T4220, which also has an Intel HD card. According to all the information I can gather, they are quite similar. The TimelineX uses Intel® Ironlake Mobile, according to GNOME 3's System Info. The Fujitsu uses Intel® 965GM.

However, despite all this, my new TimelineX has jittery performance, while the Fujitsu is silky smooth. Both are using GNOME 3, but the TimelineX clearly has fewer frames reaching the screen when going to the overview, moving between workspaces, and dragging windows to other workspaces. Also, I can't play 1080p videos as I did on the Fujitsu, and changing screen brightness seems to freeze any video playback for a second. The TimelineX has an i5 with far more processing power, so it's obviously a driver setting or something else with the video card preventing the smooth experience I was having on the older Fujitsu. Also, this is a widescreen, so there are some more pixels being rendered, but both act the same (smooth or not) when making use of an extra monitor, so I don't think the pixel density is the issue.

Ironlake (TimelineX 1830t)

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device 040e
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3050 [size=8]

...

OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile 
OpenGL version string: 2.1 Mesa 7.11.2
OpenGL shading language version string: 1.20

965GM (Fujitsu T4220)

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev03) (prog-if 00 [VGA controller])
	Subsystem : Fujitsu Limited. Device 13f9
	Flags: bus master, fast devsel, latency 0, IRQ 42
	Memory at fc000000 (64-bit, non-prefetchable) [size=1M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 1800 [size=8]

...


OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM
OpenGL version string: 2.1 Mesa 7.11.2
OpenGL shading language version string: 1.20

I've tried to remedy the issue by turning off VSync, but all I noticed was a small increase in frames (not silky smooth) and frequent tearing (which I haven't seen when turning off VSync on the Fujitsu, presumably because it renders the frames fast enough that tears are infrequent).

So, I'm at a loss. It appears that the Windows 7 that came with the computer didn't have any issues with Aero's effects, but I won't be using that any time soon. Are there some obvious differences between these GPUs that I'm not aware of? Any assistance or information would be greatly appreciated, since I'd love to have the same great experience I've had with other Intel cards.

Last edited by ScionicSpectre (2012-03-18 04:47:37)

ScionicSpectre · 2012-01-06 07:47:20

So, after looking around for a while, I found the kernel option i915.semaphores=1, tried it out, and saw very little improvement in compositing or video playback, although I think it improved a bit. Then I kept reading and found out about the SNA rendering architecture (for SandyBridge), and discovered it may be relevant to this specific video card.

I built the xf86-video-intel-git package, passing --enable-sna in the PKGBUILD (as noted in the PKGBUILD) to enable the architecture. So far, everything is skippier, and I very rarely find an issue with slowness. However, there is a bit more tearing than usual (not so much I can't live with it), and there are stability issues, as the architecture is quite young (after using it for a while, there was an unprovoked crash of gnome-shell).

However, unless it crashes frequently, I think I'd rather use this. I'm getting higher frame rates in every game, glxgears, and there aren't any obvious graphical flaws. I'd consider this solved, although the solution isn't at all advisable. I'll leave the thread up one more day to gather your input and give my final thoughts/tweaks, so people don't have to look at as many threads for this. Of course, an SNA thread itself may be a worthy idea, since the rendering architecture isn't entirely stable yet.

David Batson · 2012-01-06 15:22:13

Try adding this to /etc/environment for the tearing issue in Gnome 3 (or else run Compiz with Gnome Classic). Both solutions work for me.

CLUTTER_PAINT=disable-clipped-redraws:disable-culling

https://bugzilla.gnome.org/show_bug.cgi?id=657071#c2

ScionicSpectre · 2012-01-06 21:53:18

Thanks David, it appears to be working without the tearing. However, I should let everyone know that I underestimated SNA's stability issues. In GNOME 3, it tends to crash with SNA within about 15 minutes of use, no matter what it is I'm doing. Fallback Mode is fine, but I obviously don't want to use that all the time. Also, when mutter windows are maximized, the titlebar buttons get washed out with SNA enabled.

I'll keep researching SNA to see if there are any options I could change, but if I can't configure it to fix these issues I'll just head back to near-perfect compositing.

ScionicSpectre · 2012-01-08 08:07:57

Well, I can't seem to solve these issues, so I'm going back to good ol' UXA (I believe that's what xf86-video-intel uses by default). As the newer Intel drivers shape up for Sandy Bridge in 2012, I suspect many of the issues I see here will be addressed, and maybe SNA will be much more stable. I must say, I would be happy just to see my 2D rendering improve- I'm surprised at how using SNA seems to improve compositing performance.

Either way, I don't think this thread should necessarily be marked as 'solved'. Maybe 'unsolvable for the moment' would be more accurate.

MadCat_X · 2012-01-08 21:26:10

The SNA and semaphores are both considered unstable at the moment. Perhaps you can try i915.i915_enable_rc6=1 which both saves power and improves framerate a bit (although it doesn't work with certain HW configurations). As for video acceleration, consider using a player that supports VAAPI (mplayer-vaapi or VLC for instance).

Does this problem occur outside GNOME 3 as well? Perhaps you could run some benchmarks just from TWM to check if the GPU is really slow for some reason or if there is a problem with Intel HD + GNOME 3 setup.

BTW here is a list of all(?) i915 module parameters, maybe you can play around with them and find if any of them gives you some significant speed boost

fbpercrtc:0
i915_enable_rc6:1
lvds_downclock:1
lvds_use_ssc:1
modeset:-1
powersave:1
reset:Y
semaphores:0

ScionicSpectre · 2012-01-09 05:37:33

Thank you, MadCat_X, that's just the kind of information I needed. I'll try these out and see if there is a significant change. Intel HD on the older card works great, of course, but I will certainly try just TWM with Totem to see if the 1080p playback improves. Also, I plan to try KDE and Unity soon to see what the compositing performance is like there, since it may only be an issue with GNOME 3 rendering. After all, most of the 3D applications I used had shockingly smooth results, even before SNA.

I'll report back with the results. It appears modinfo i915 gives a bit more information about what each of these options mean, if anyone is interested. A few of the options you list are default, but I think I'll try them anyway just to be safe.

ScionicSpectre · 2012-01-09 06:31:33

Only three of those settings seemed to make an impact:

i915_enable_rc6=1	Maybe slightly smoother, not silky.
powersave=1		Maybe a bit slower.
reset=Y			Maybe a tiny bit smoother, pauses sometimes.

It seems none of these could resolve the issue to a satisfactory amount. Also, I notice that when windows are scaling larger to their original size, they tend to resize smoothly in the Activities overview, but when scaling smaller is when I see the noticeable changes in framerate. I've also tried using only an external monitor to be sure the pixel density isn't an issue. The same problems still occured.

I'll be trying KDE and Unity next, and if they don't present me with any performance degradations, I guess I'll be reporting a bug to clutter, mutter, or something or other. Thanks for the attention you've paid to this issue- I hope it won't last forever.

Last edited by ScionicSpectre (2012-01-09 06:33:28)

ScionicSpectre · 2012-02-05 18:44:08

Turns out KDE and Unity do peform better. However, it still seems to be a tiny bit less flawless than the older Intel GPU. That said, I could hardly notice the difference- it only occured during some very complex tasks. The resizing of windows in Kwin was flawless, whether going smaller or larger. So it may very well be that clutter just doesn't like this specific card very much (which would be sad, since Ironlake isn't too far behind in Intel's GPU lineup).

I really hope this card gets some attention, since it's still being sold in retail, and it's a great performer. It should deliver a much better experience than the older card. I can't really stand to use Unity or KDE right now, since I keep thinking back to GNOME 3 and all I'm missing out on. It really has gotten to me. XD

ScionicSpectre · 2012-02-05 20:56:50

Some other interesting news for anyone with this card, or anyone interested in Wayland in general. I tried Rebecca Black OS (the Wayland LiveCD) on this computer, and it ran absolutely flawlessly, even with many tests open, including smoke and the 3D tests. Also, this was will a full X11 KDE 4 running well on tty7. The performance on Wayland is absolutely astounding- I thought it would only be a modest improvement over X11, but I think we're all in for quite a surprise when Wayland 1.0 comes out and we can start shipping our DEs with it.

Truly amazing. I can't wait for X11 to die. XD

Seeing as how this is the case, the performance degradation I have on GNOME 3 isn't significant enough that I won't be able to wait for Wayland, or the various Intel driver improvements coming soon. In fact, it's almost more exciting to wait and see how much things improve. Too bad I still can't mark this [SOLVED].

pmd · 2012-02-14 19:19:57

I've got the same problem with my Intel card. Please update this topic if you find something new. I will do the same.

ScionicSpectre · 2012-02-15 04:38:50

Thanks for contributing to the discussion- I was feeling a bit lonely in here. XD

It turns out quite a few people are reporting performance increases in the Shell's development version. I'm going to try building an environment with JHBuild to try it out and see how things have improved in the next few days.

pmd · 2012-02-15 13:46:59

Thanks for help. If you have enough time to test some development versions and let us all know how it's improving it will be very nice. Unfortunately I don't have time for that.

The funny thing is that compiz seems to be more resistant to this issue. It's just shows some not-annoying artifacts on some actions. For ex. when resizing windows - border is blinking on white but everything is running smooth, I can live with this. Gnome devs should learn from that

Last edited by pmd (2012-02-15 13:50:19)

ScionicSpectre · 2012-02-15 19:46:27

To be fair, this is the first GPU I've used where Clutter or the Shell (whichever it is) has performed worse than Compiz, in terms of smoothness, FPS, and low resource use. The ATI Catalyst drivers are the only case where I have no source for comparison. EDIT: I lied- the beginning of OpenGL 2 cards and back seem to have better framerates with compiz, so far as I've tested- may be a scaling issue.

Clutter's pretty slick. Compiz is much more stable than people give it credit for, however (too many people association Unity performance with Compiz performance). Either way, the difference is rarely perceptible to users, even on very old machines.

Unfortunately, while building GNOME last night, I got errors due to JHBuild using the wrong Python (specifically, WebKit was using the print function without parentheses during the install phase, which only works in Python2). I followed all the instructions in the wiki to get it working, however, so I'm thinking it may be due to WebKit's build/install script calling python in a generic fashion, rather than JHBuild. Either way, I should be able to build the Shell without WebKit/Epiphany.

I'll try again later tonight- I sure hope I won't need to open a new thread just to get GNOME-Shell 3.3.5 running.

Last edited by ScionicSpectre (2012-02-16 01:17:39)

nawitus · 2012-02-15 21:37:16

If you want to watch 1080p videos, install mplayer-vaapi from AUR (and libva-driver-intel) and play videos with -vo vaapi parameter. Vsync should be *on* to get rid of tearing. I also have i5 processor, but my intel card seems to be newer ( 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) ). I don't have the problems you describe though. You could try disabling triple buffering.

ScionicSpectre · 2012-02-16 01:21:49

Just read up on it (triple buffering)- I may just try turning it off. I'm too in love with Totem to use mplayer consistently, but it will be good to see if it actually works. I believe VLC has similar functionality. Also, it appears gstreamer has VA API plugins in the AUR, but I installed those previously and saw no change (with libva-intel-driver as well)- it may have been because it's optional, I'm not sure...

Just tried it out and nope, still seeing no improvement. :\ Too bad.

Last edited by ScionicSpectre (2012-02-16 01:32:00)

David Batson · 2012-02-16 01:26:41

ScionicSpectre wrote:

To be fair, this is the first GPU I've used where Clutter or the Shell (whichever it is) has performed worse than Compiz, in terms of smoothness, FPS, and low resource use.

As I reported in post #3 of this thread, adding the appropriate environment variable for Clutter fixes vsync issues and eliminates tearing when watching videos in Gnome 3 (with Clutter/Mutter). At least this is true for Fedora 16 Gnome on my Intel Core i5-2540M Sandy Bridge laptop.

ScionicSpectre · 2012-02-16 01:44:23

We're talking about performance now (visible FPS), not tearing. In fact, I hadn't witnessed any perceptible tearing until I turned off VSync, and with SNA enabled I still couldn't watch 1080p without some lag. This is all with the environment variable you mentioned.

Everyone I know with a SandyBridge GPU has perfect stability and performance- I'm sure you're having an amazing time with it, SNA or not. The premise of this post is that even the previous generation can play 1080p videos and run GNOME Shell smoother than silk. :\ Unfortunately, it seems Intel on Linux hasn't had as much attention with Ironlake. I really don't want to shell out even more money for an Ivy Bridge laptop this year, but I may just end up doing that if the situation doesn't improve. It was a big letdown considering Intel's amazing support in the past.

I guess it's really not too bad, but as a Multimedia Designer, I need my desktop compositing to be totally slick, on principle. I figured an i5 with higher specs than my old laptop would be enough. Oh well, I guess I can't always have my GNOME and eat it. I will continue to investigate and maybe get in contact with the mailinglist.

UPDATE: Tried to use JHBuild with no success. Aside from the not-so-necessary packages that needed Python2, there are some utterly necessary packages that I just couldn't build due to unrelated build errors. I don't even think a GNOME developer could make out how to fix them very easily, so I'm gonna' give up on that road for the moment. I'm going to see if there's a way to upgrade just gnome-shell, mutter, and clutter through the AUR.

Last edited by ScionicSpectre (2012-02-16 05:39:28)

ScionicSpectre · 2012-02-20 07:41:05

It appears the only way to get GNOME 3.3.5 packages is to use JHBuild, which I still can't get to work. So I may try the Ubuntu Alpha on my USB with more recent packages to see if there's a difference. That's really the most obvious option available to me without waiting over a month for 3.4 to be released.

ScionicSpectre · 2012-03-18 04:43:58

Using GNOME 3.3.91 from the gnome-unstable repository. There's no real improvement to the problems I mentioned previously. It seems maybe a bit smoother, but I'm not sure if it's just GTK having a bit better performance. Clutter was supposed to have some performance improvements as well.

Still, KDE 4 composites flawlessly. However, this isn't worse by an extremely notable margin. I can deal with it until the Intel drivers are refined or I move onto my next laptop. I'll see if I can't report some bugs on the driver and clutter just to help out, but I'm really at the end of my give-a-damn meter. Thanks everyone who gave me resources and suggestions- you've been more than helpful, and you've made me even more proud to be part of this community. Hopefully we won't see issues like this in the future.

Last edited by ScionicSpectre (2012-03-18 04:49:17)

ewtoombs · 2015-11-30 14:34:52

My ironlake also performed very poorly compared to on Windows. I used ut2004 for comparison. It worked perfectly in Windows and was unplayable in linux under comparable graphics settings. Something weird was going on with it. I switched to UXA as per the post-install instructions and now, ut2004 is ultra-twitchy again! These were the post-install instructions:

>>> This driver uses SNA as the default acceleration method. You can try
    falling back to UXA if you run into trouble. To do so, save a file with
    the following content as /etc/X11/xorg.conf.d/20-intel.conf :
      Section "Device"
        Identifier  "Intel Graphics"
        Driver      "intel"
        Option      "AccelMethod"  "uxa"
        #Option      "AccelMethod"  "sna"
      EndSection

Anyway, clearly still work to be done with SNA on Ironlake.

Trilby · 2015-11-30 15:18:25

ewtoobms - please do not necrobump old threads. This has been dormant for 3 years - the drivers have completely changed, and there is nothing new in your post that isn't already covered by pacman output and the wiki.

Closed.

Arch Linux

#1 2012-01-06 05:34:53

[RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#2 2012-01-06 07:47:20

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#3 2012-01-06 15:22:13

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#4 2012-01-06 21:53:18

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#5 2012-01-08 08:07:57

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#6 2012-01-08 21:26:10

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#7 2012-01-09 05:37:33

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#8 2012-01-09 06:31:33

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#9 2012-02-05 18:44:08

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#10 2012-02-05 20:56:50

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#11 2012-02-14 19:19:57

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#12 2012-02-15 04:38:50

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#13 2012-02-15 13:46:59

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#14 2012-02-15 19:46:27

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#15 2012-02-15 21:37:16

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#16 2012-02-16 01:21:49

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#17 2012-02-16 01:26:41

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#18 2012-02-16 01:44:23

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#19 2012-02-20 07:41:05

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#20 2012-03-18 04:43:58

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#21 2015-11-30 14:34:52

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

#22 2015-11-30 15:18:25

Re: [RESOLVED] Poor performance on Ironlake compared to old Intel GPU

Board footer