Comment 14 for bug 19711

(In reply to comment #7)
> (In reply to comment #6)
> >
> > well presumably, if the the display has entered the DPMS off state, then you
> > aren't using the GUI, so the it should be safe to shut down the CP.
>
> Ahh, o.k. But I think this would not really make a big difference, as then CPU
> power saving would only occur when the screen has turned off. However, as long
> as one is actively working, there will be no benefit. E.g. at the moment I am
> writing this text, I have some six to seven apps running (several open office
> docs, firefox, kontact and a vmware winxp session). Nonetheless, the cpu is in
> c3 about 33% of the time, thus giving me nearly 20 min more battery life (2:35
> instead of 2:15).
>

Ah, I didn't realize you were trying to use c3 while you were working. I
thought you were seeing bus master activity when the computer was not being
used. If you are working, windows are updating and stuff is getting drawn (2D
or otherwise). That's what's causing the bus master activity.

>
> However, if bus mastering is absolutely necessary for 3D, then with the advent
> of xgl, when the whole desktop will use 3D commands, there will be no
> possibility to enter c3 power saving mode, I guess. In this case, it's maybe not
> worth the work to find out what's the cause for the bus mastering activity in
> pure 2D apps with the dri module.
>
> What do you think? Is it much work to find out what's the cause of the bus
> mastering activity?

In this case, I know what's causing the activity. It's the 2D drawing engine
drawing stuff on the screen while you work. As I said, when the DRI is enabled,
the 2D engines uses the CP to send commands as well (just like 3D). To get
around that you'd have to implement a way to switch the accel code between CP
and MMIO dynamically, or implement 3D using MMIO.