Posted Mar 28, 2013 10:49 UTC (Thu) by sheepdestroyer (subscriber, #54968)
In reply to: GNOME 3.8 released by bojan
Parent article: GNOME 3.8 released
I want to point out that it is not only a problem on vm or remote systems.
My recent core i7 (sandybridge) has all the horsepower needed but effectively consumes more watts with 3D acceleration on. I Use Fallback mode not for it's "classic" layout but to conserve battery on my ultrabook.
This is i think a valid concern, especially if targeting mobility.
Posted Mar 28, 2013 12:28 UTC (Thu) by ovitters (subscriber, #27950)
[Link]
There is no need for your system to requires more power, no matter if GNOME uses "3D" or not. Only the most basic stuff is used. It should barely make an impact.
In practice, it does. But that is something that should be fixed at the right level. Unfortunately despite GNOME being out for years, not much has happened with drivers/X/whatever causes this.
Reference point is to try Windows 7+ on the same system. It uses "3D", but overall it'll likely have a better power usage while needing more from the "3D" bits.
GNOME 3.8 released
Posted Mar 29, 2013 22:39 UTC (Fri) by drag (subscriber, #31333)
[Link]
> In practice, it does. But that is something that should be fixed at the right level. Unfortunately despite GNOME being out for years, not much has happened with drivers/X/whatever causes this.
What is happening is called 'Wayland' and 'DRI 3.0'.
With X Windows as the display manager you have to have write out buffers multiple times, copy textures, do texture conversions, and do multiple rendering passes for things like 'server side decorations' if you want to have a composited desktop... for each time the display needs to be rendered, which is usually each screen refresh. You can't fix this without breaking X.
With the current drivers they have different sorts of video memory management schemes, which are not optimal from a security and performance perspective. Live and learn.
With Wayland and DRI 3 drivers all that copying/writing/converting and incrementing/deincrementing should be replaced by simply passing a file descriptor from the client application to the display server. So instead of shuffling around MBs of textures around you end up replacing it all with the copying of a couple bytes.