Rawhide gets GNOME Shell for all display types [LWN.net]

Rawhide gets GNOME Shell for all display types

Posted Nov 5, 2011 12:09 UTC (Sat) by tuna (guest, #44480)
In reply to: Rawhide gets GNOME Shell for all display types by ikm
Parent article: Rawhide gets GNOME Shell for all display types

How do you know that software rendering will be unusable? Have you actually tested it?

to post comments

Rawhide gets GNOME Shell for all display types

Posted Nov 6, 2011 20:06 UTC (Sun) by jlokier (guest, #52227) [Link] (2 responses)

It's not a given, but it would be surprising if replacing 2d-hardware acceleration (rectangle copies and fills) with software compositing would be just as fast on most older hardware.

Rawhide gets GNOME Shell for all display types

Posted Nov 7, 2011 0:21 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (1 responses)

Rectangular copies and fills are a win, but not by anywhere near as much as you'd expect. A modern desktop (even including Gnome 2) does a lot of work that typically isn't usefully accelerated on older GPUs. Doing that in software on video memory limits you to the bandwidth available over whatever bus the GPU is on, which is going to be massively less than your system memory bandwidth. Using an unaccelerated shadow framebuffer is often faster even if you're only doing 2D.

Rawhide gets GNOME Shell for all display types

Posted Nov 7, 2011 22:07 UTC (Mon) by jlokier (guest, #52227) [Link]

Well it's hardly worth optimising for less-capable hardware now. Anything other than a mid-range dumbphone, set top box, or embedded product with a screen glued on has a half-decent GPU these days, and most of the rest have a CPU that can read/write memory fast enough to do their own blits. I guess I'd class set top boxes and TV chips as exceptions, as they drive big displays with a slow CPU and often no 3d-capable GPU.

If you're running non-OpenGL capable hardware in the last half-decade, it's almost certainly native memory for the framebuffer so the CPU is not disadvantaged. On older hardware, you might use a shadow framebuffer or similar buffering technique, but still keep track of blitted regions via data structures.

Scrolling is still common in apps! With older hardware, or slow current hardware, scrolling large screen areas using blits vs. CPU updates remains user-visible (i.e. slower than vsync rate). It's visible because it's a big animation. Fills are less important (because they're not animations) unless it's a big screen and slow CPU (see "media player"), in which even pretty vector systems can benefit from algorithms which extract big rectangles and leave just the detail to the CPU.

I think the reason blits are no longer of much interest is because applications and toolkits no longer target the class of hardware where it's worth doing, as it's such a minority of systems and shrinking, software rendering is good enough everywhere, and when such systems were more common, there wasn't yet much effort put into optimising desktop rendering performance on Linux. Except for games, but games have different needs.