Thursday, August 16, 2007

Compiz and Fedora

There was a big discussion about enabling compiz by default in Fedora on fedora-devel list a couple of days ago. Reading through the thread I realized that we never really communicated our plans here very well. I sent out the writeup below to explain a bit where we're going with Fedora and what the road blocks are, but I figured it wouldn't harm to also blog it.

We are working towards being able to enable a compositor by default.

Redirected direct rendering, Xv, Java problems, these are problems in the drivers and X server and affects all compositors. To get this done, we need to land a big chunk of code in the kernel (the DRM memory manager), we need to update the X server, the 2D drivers and the 3D drivers to take advantage of the new memory manager. We need to fix Xv. Hopefully the OpenGL support will broaden to support more chipsets (nouveau, avivo). Getting all this to a shippable state may take years, and in the mean time, the composited desktop, whether it's compiz, kwin4 or something else will only be an opt-in tech demo.

Once we get there, the default compositor will be compiz.

Some people can't get over on the wobbly windows and spinning cube, and claim it's over the top or apparently get nauseous. At the core, compiz is just a very efficient OpenGL redraw loop with a flexible plugin architecture. Compiz allows burning windows and spinning cubes, but we ship it in a very toned down default configuration that looks a lot like good old metacity. Consider xeyes; like wobbly windows, it's a neat tech demo and shows off the flexibility of X, but just because nobody runs xeyes for more that 2 minutes at a time that doesn't mean that X (or shaped windows) isn't useful.

A valid point about compiz is that it is not yet a great window manager. Metacity has a few years of head start there, but that doesn't mean that we can't fix compiz or that it'll be duplicated effort. For now, our (Red Hat) efforts have gone towards fixing the big underlying shortcomings in the X and OpenGL stack, which has left compiz in Fedora with a set of minor (but certainly annoying) windows manager bugs. Other spins (Fedora KDE or Fedora XFCE) can set up different default compositing managers, and they will of course benefit from the infrastructure work mentioned above.

We're not working on making metacity a compositing manager.

We tried it and decided that the metacity code base was not a welcoming place for a compositor. When we put down the work in metacity, the conclusion was to leave this very stable and well tested code base alone instead of injecting an OpenGL based compositor. The flip side of this decision is that we can now do a clean break in compiz and assume throughout the code that we're an OpenGL based combined compositing and window manager.

Compiz fusion and configuration tools.

desktop-effects is close to what we want to ship by default, perhaps we want to fold it into the new gnome-appearance-properties capplet as a new tab. The default compiz configuration and the set of options we expose outside gconf-editor is intended to be very conservative. At the same time, we want to allow installation of other compiz configuration managers and the compiz fusion plugins for people who like the tweak-ui kind-of tools.

Power consumption and other hand-wavey fud arguments.

Clearly running a 3D screen saver at the full frame rate is going to burn more battery than the blank screen saver, but that's not really relevant here. When idling, compiz and metacity use exactly the same amount of power. There are no code paths anywhere in the stack that "turn on 3d powerplanes". My bet is that it's more power consuming to wake up all applications to redraw their exposed areas under the window you're dragging than it is for compiz to just recomposite that out of textures already in video memory.

7 comments:

Anonymous said...

When idling, compiz and metacity use exactly the same amount of power. There are no code paths anywhere in the stack that "turn on 3d powerplanes". My bet is that it's more power consuming to wake up all applications to redraw their exposed areas under the window you're dragging than it is for compiz to just recomposite that out of textures already in video memory.

This is not quite the way I see things currently.

First, about the "3d powerplanes". Some drivers (for example the nvidia binary driver) will clock the card higher when in 3D mode, which results in faster battery drain. More generally, OpenGL implementations are tuned for performance and not for power efficiency, and make heavy use of busy waits for example.

Second, about waking up applications. Although your point is true, re-compositing a screen from a number of pixmaps laying in VRAM is not exclusive to 3D compositing managers like compiz, but can be achieved via a 2D compositing manager as well. So this is not an advantage of 3D compositing managers either.

Real world power usage benchmarks would surely be very interesting, but I'm quite confident what the results look like today.

Now what if one wants to solve that power & heat issue. Today, the driver has no way to know if the full power is needed (for that doom 5 game) or not (doing word processing). Maybe the application should tell what it wants, but no mechanism for that currently exists.

Anonymous said...

Good post, thanks for the update Kristian!

Thorsten Leemhuis said...

On "Once we get there, the default compositor will be compiz." and "We're not working on making metacity a compositing manager.": That afaics and iow means: some people (those with composing-capable hardware and drivers) will run compiz, the other stick to metacity. That's not a problem per se, but the two often feel and react differently -- that's utterly confusing for the users, as a action on the same distribution might result in a different behavior on different machines.

I'm wondering if it would make sense to support normal 2d-rendering (not sure if that's the proper tem, but I suppose you'll know what I mean) in compiz, so everyone can use the same window manager and everything feels and acts similarly.

Anonymous said...

I think giving "support normal 2d-rendering" will be useless, compiz base some parts of code from metacity, it support metacity themes, it got powerful keyboard shortcuts management, but this is compositing manager, it gives a lot more that metacity in user experience, and functionality. If there is some group of users that feel there is functionality in metacity that they can't live without and they want to use compiz then compiz should provide it, in form of plugin "metacity" for compiz with that functionality(for example). You dont need to write that plugin, just write request for that plugin and specs what that plugin should provide, compiz community will bring it. I thnik plugin that will provide functionality compatybility of "kwin,metacity" for compiz is greate idea.

Anonymous said...

I sat down and use a Gutsy beta to do some power testing last week. I have a small "Energy Monitor" adapter from Maplins (a gadget inspired by the world famous Dave Jones) and I used that to try and monitor power consumption through the mains by booting the machine without a battery installed. All testing was done with Ubuntu Tribe 4 on a Thinkpad T60 (graphics card is an Intel 940). I will put the wattage the monitor measured on the left and the action being done on the right. The monitor isn't perfect but I'd guess it's accurate to within 2W.

4W - Laptop was off.

Ubuntu Feisty fresh install
25-26W - Laptop was idling at Grub boot menu.
27W - Laptop doing fsck during boot.
24W - Idling in X at GDM.
(metacity is the window manager)
23-24W - Idling in X at GNOME backdrop.
19W - Idling in X at GNOME backdrop with brightness set to 0.
15-16W - Idling in X at GNOME backdrop with lid shut.
30W - Within X and glxgears is running brightness set to 0.
39W - cat /dev/shm/words in X within a GNOME terminal.
(compiz is the window manager)
19-20W - Idling in X at GNOME backdrop with brightness set to 0.
30W - Within X and glxgears is running.
(disable DRI in xorg.conf, metacity as window manager)
19-20W - Idling in X at GNOME backdrop with brightness set to 0.

18-19W - Idling at a virtual terminal, cursor blinking disabled with cron/anacron turned off.
20W - Idling at virtual terminal, cursor blinking disabled after using telinit 1 to go to single user mode (strange - perhaps powersaved being disabled didn't help?)

Gutsy Tribe 4 fresh install
(45W peak during installation)
24-25W - Idling in X at GDM.
(compiz is the window manager)
24-25W - Idling in X at GNOME backdrop.
19-20W - Idling in X at GNOME backdrop with brightness set to 0.
16-17W - Idling in X at GNOME backdrop with lid closed.
39-40W - cat /dev/shm/words in X within a GNOME terminal, brightness 0.
31W - Within X and glxgears is running.
(metacity is the window manager)
19-20W - Idling in X at GNOME backdrop with brightness set to 0.
31W - Within X and glxgears is running.
(disable DRI in xorg.conf, metacity as window manager)
19-20W - Idling in X at GNOME backdrop with brightness set to 0.

20W-21W - Idling at virtual terminal, cursor blinking disabled after using telinit 1 to go to single user mode.

After putting the battery back in and unplugging the mains I used powertop of Gutsy to get some more results. powertop estimated that the energy draw was 10.8W with metacity and when DRI was on, 10.8W with compiz and when DRI was on and 10.6W with metacity and when DRI was off.

(it is very hard to post results using this very small comments box)

Anonymous said...

More statistics but this time gleaned from powertop. System tested is as before. Headings generally apply to all subsequent tests unless another heading says otherwise.

All wake up hog programs killed
-------------------------------
Laptop mode on
--------------
Backlight off
-------------
Powersave max
16.5 wakeups per second, 11W
Powersave ondemand
21.7 wakeups per second, 10.9W
Backlight on, 100%
------------------
Powersave ondemand
------------------
20.8 wakeups per second, 13.0W
Bluetooth and wifi on (via soft killswitch)
175.6 wakeups per second, 15.4W
Bluetooth and wifi on, compiz on
240.5 wakeups per second, 15.4W
Bluetooth and wifi off, compiz on
94.0 wakeups per second, 13.1W
Bluetooth and wifi off, compiz off (once AIGLX is turned on your interrupts will rise until Xorg is restarted)
80.2 wakeups per second, 13.0W
(reboot, default programs running)
Brightness 100%, metacity, wifi on, bluetooth on
231.1 wakeups 15.5W
Hardware killswitch
69.9 wakeups 13.2W
killall thinkpad-keys
51.7 wakeups 13.0W, 55.4 wakeups 13.1W
kill hald-addon-storage
21.4 wakeups 13.0W
(could try killing mixer_applet2 but it doesn't seem worth it)
101.4 wakesups 13.1W
(blinking cursor in vi seems to use up 0.1W)
(reboot) hardware killswitch, killall thinkpad-keys, kill hald-addon-storage, disabled laptop-mode
19.0 wakeups 13.4W

auzieman said...

Hi there,
Looks like you may have gotten glxcompmgr in fc6? I was searching re compiz and e17 and thought you may be able to help..

Where can I get an fc6 or 7,8 etc rpm that has glxcompmgr? Have you tried to get it going with e17 yet?

Feel free to email me