IntelPerformance
Symptoms:
- With compiz enabled, some animations such as desktop switching or compiz cube view are not smooth and take longer to complete than previously.
- Scrolling in firefox is laggy
- Switching to UXA or XAA makes performance issues go away
- Switching to UXA makes performance issues worse
- Switching compiz off makes performance significantly better
- 3D video game FPS measures are significantly lower than previously
Non-Symptoms:
- glxgears FPS drops. glxgears is not a benchmark, don't use it!
CPU usage is high. Rather, see X/Troubleshooting/HighCPU instead.
How It Works
Historically, a distinction has been made between 2D and 3D acceleration. 2D acceleration was provided by the venerable XFree86 Acceleration Architecture (XAA), which makes the video card's 2D hardware acceleration available to the X server. In cases where this was broken or unavailable, one could fall back to software rendering (e.g. the NoAccel option).
3D acceleration was provided via the Direct Rendering Manager, which worked by mapping 3D rendered pictures on top of the 2D picture.
This had some buggy corner cases, but more or less worked... until compositing (compiz, kwin) entered the picture. This blurs the distinction between 2D things and 3D, as it adds 3D effects into what was once exclusively 2D. Thus the distinction has become the source of a lot of brittleness, bugs, and performance problems.
A better solution is to move to 100% hardware accelerated OpenGL 3D support, with 2D becoming just a subset of 3D rendering. Unfortunately, switching entirely over is not so simple, and not without some major pitfalls.
EXA was introduced as a stopgap measure, to provide better integration with XRender than XAA did. In practice, while this proved quite advantageous in some respects, it also exhibited a number of corner cases and regressions.
The next stage of development, UXA, reimplements the EXA api using the new Graphics Execution Manager (GEM), a memory manager that better leverages the Linux kernel.
Current/Ongoing Development
Upstream, Intel is in the midst of a long re-architecture effort. The end goal of this work is to solve a myriad number of long standing issues relating to multi-head, dynamic configuration, 3D support, and performance.
Part of this architecture work includes moving functionality from its traditional location to places where it will be more optimally able to support new capabilities. For example, graphics mode/resolution setting is moving out of the 2d video driver into the kernel. These changes are pretty significant, and can either uncover or generate bugs that regress previously working behavior; these bugs either emerge directly (bugs in the code) or indirectly from irregularities in how they're integrated together in the overall operating system.
Another part of the work involves introducing more efficient algorithms, experiment with bypassing low-performance legacy code, and timing events to occur more optimally, with the hope that this will net huge performance benefits. In some cases, this can be akin to balancing on a pin; and when the optimization fails, it can make performance much worse than if it hadn't been done to begin with. Sadly, the corner cases often don't appear until the code is deployed into the wild in real-world situations.
A third factor is hardware variability. In general, recent model chips (945, 965, etc.) are thoroughly tested, whereas older cards (8xx) are less widely tested and thus problems aren't found until the driver ships. More particularly, even with common models like 945 and 965, there are myriad little variations within the families that aren't always accounted for in testing.
All these things together conspire to make a witch's brew of performance regressions...
Problem: /dev/dri/card0 is missing
The /dev/dri/card0 device file is provided by the Linux kernel. If the file is missing, it prevents hardware acceleration from working. See if reloading the kernel module makes it work:
# Save your work first! $ sudo rmmod i915 $ sudo modprobe i915 $ lsmod | grep i915 i915 65412 1 drm 96424 2 i915 $ sudo pkill X
Problem: /dev/dri/card0 permissions are incorrect
In early Jaunty development, libdrm switched to using udev for creating the /dev/dri/card0 device node; an early error in the udev rules caused this node to be created with mode 660 (crw-rw
) rather than 666 as needed. Since then the udev rules have been corrected (bug #306014), but if you upgraded to or installed jaunty early on you may still have the legacy settings. Fixing this can have a small but measurable impact on performance with 3D games in some cases.
bryce$ ls -l /dev/dri/card0 crw-rw----+ 1 root video 226, 0 Mar 30 14:37 /dev/dri/card0 bryce$ sudo chmod 666 /dev/dri/card0 bryce$ ls -l /dev/dri/card0 crw-rw-rw-+ 1 root video 226, 0 Mar 30 14:37 /dev/dri/card0
Note that since udev now takes care of these permissions, setting DRI permissions in your xorg.conf is no longer necessary.
The udev rule is in the file /lib/udev/rules.d/50-udev-default.rules and should look like this:
KERNEL=="card[0-9]*", MODE="0666", NAME="dri/%k"
Problem: Falling back to OpenGL software rendering
Check if you're using software or hardware 3D rendering via glxinfo|grep render.
1. Is properly using hardware rendering:
bryce$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20090114 x86/MMX/SSE2
2. Is falling back to software rendering:
bryce$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Software Rendering
Having DRI disabled can lead to this. Check if it has been loaded; your Xorg.0.log should show something like this:
bryce$ egrep "(GLX|DRI)" /var/log/Xorg.0.log (==) AIGLX enabled (II) Loading extension GLX (II) Loading extension XFree86-DRI (II) Loading extension DRI2 (WW) intel(0): DRI2 requires UXA (II) intel(0): [DRI] installation complete (II) intel(0): 0x0077f000-0x0cd3ffff: DRI memory manager (202500 kB) (II) intel(0): direct rendering: XF86DRI Enabled (II) AIGLX: Screen 0 is not DRI2 capable (II) AIGLX: enabled GLX_SGI_make_current_read (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control (II) AIGLX: enabled GLX_texture_from_pixmap with driver support (II) AIGLX: Loaded and initialized /usr/lib/dri/i965_dri.so (II) GLX: Initialized DRI GL provider for screen 0
GLX and DRI need to be loaded and enabled. DRI2 doesn't matter unless you're using UXA.
If you have an i865 graphics card (check lspci |grep VGA), in Jaunty we've disabled DRI intentionally due to an X freeze-on-boot bug (see bug #317457).
3. Has no direct 3D rendering:
bryce$ glxinfo | grep render direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) OpenGL renderer string: Mesa GLX Indirect
Having DRI disabled can cause this, as in #2, if mesa is unable to fallback to software rendering.
Configuration issues are another common cause for this. Check that Xgl is not installed, and check your xorg.conf for extraneous settings (often these days on -intel you can run with no xorg.conf at all.)
Problem: Sync to VBlank
VBlank synchronization is an optimization technique that balances the output rate of your graphics card with the rate that your monitor displays images on the screen. Your monitor's refresh rate -- also called the vertical blanking interval (VBlank) -- is the maximum speed your monitor can present images. If your graphics card renders faster than this rate, the extra images are rendered for naught, as you'll never actually see them. So if your monitor's VBlank is 60 Hz, and your graphics card is rendering 1000 frames-per-second, then 940 frames are getting drawn for no purpose. So theory synchronizing the two makes a lot of sense.
HOWEVER, things are not so simple, and vblank syncing can actually make performance worse. For a deeper discussion, see http://www.tweakguides.com/Graphics_9.html
To turn off vblank sync, use any of the three methods:
1. Setting vblank using compizconfig-settings-manager: Go to System->Preferences-> Compiz config settings manager -> general options -> Display settings-> Sync to VBlank. Turn it to 'off'.
2. From the compiz gconf configuration:
sync_to_vblank = false
3. Via driconf: 'Synchronization with vertical refresh (swap intervals)' -> set to 'Never synchronize with vertical refresh'.
Problem: glxgears has low FPS
It is important to note and remember that glxgears is *not* a benchmark tool. It simply measures how fast the driver writes images to the screen, whereas most 3D applications are limited by render speed, not merely blit speed. Instead use a 3D game (flightgear, tremulous, etc.) that has a real rendering workload to make comparisons.
glxgears is installed by default, easy to run, and generates results that are easy to read, so users like to utilize it as a rough measure of performance, and thus the question of why these numbers change comes up quite a bit.
For discussion we can categorize the fps changes into four groups:
1. glxgears drops from XXXX to YYY
This is generally nothing to worry about. High glxgears numbers generally indicate excessively high screen repainting, so if this drops from say 1500 fps to 500 fps, it should not produce any noticeable performance impact.
2. glxgears drops from XXX to YYY
As in #1, these drops are *usually* nothing to worry about, especially if you haven't noticed any change in performance. In *some* cases if you notice a performance drop, glxgears numbers may drop as well, and there may indeed be a correlation. However, glxgears isn't a benchmark, so it does little good to post the numbers (indeed, if anything it flags your post as ill-informed on the subject!)
Instead, get before and after FPS measurements using a 3D game, such as sauerbraten, tuxracer, tremulous, or the like.
3. glxgears drops from XXX to YY (e.g. usually around ~50-60fps)
This may indicate that you have vblank syncing turned on. Is the glxgears fps roughly equal to the refresh rate of your monitor? (LCDs tend to operate at 60Hz, so 50-60fps is common in these cases)
If so, see the previous section for a discussion of vblank settings. Normally vblank is a GOOD thing, but it can cause side-effects. If you are experiencing performance impacts, try disabling vblank.
4. glxgears drops to 30fps or below
Any time glxgears returns fps less than your monitor's refresh rate, it definitely indicates a performance problem.
If the fps seems to hit at about half your monitor refresh rate, it indicates the graphics card is not synchronizing properly, and is missing every other frame request by the monitor.