Wayland and Weston 1.0

[Pekka Paalanen]

On Wed, 24 Oct 2012 13:21:52 +0200 (CEST)
Jan Engelhardt <jengelh at inai.de> wrote:

> A few folks around me, and myself included, have pondered...
> 
> It would seem that wayland and its possible compositors all require 3D 
> support, which may require, if no accelerating GPU is installed, 
> the use of software rendering.
> 
> This however, it is feared, would unnecessarily consume computational 
> power when doing purely "2D workloads", such as libreoffice - xterms - 
> and simple web page browsing, especially in a scenario-idea I was shown 
> that consists of a workstation with one graphic chip and a DisplayLink 
> multiplexer, intended for use in a 4-people multi-seat setup.
> 
> That also prompted me to think about server consoles; these often have 
> some lo-power chip, popular example is (last decade's) ATI Rage XL, the 
> Intel GMA in Netbooks and NanoITX boards, and so on.
> 
> I would love to hear your thoughts about this.

Hi Jan,

what issues do you have in mind, exactly? That Wayland is not at all
usable without a performant GPU (software GL considered too slow or
power-hungry)?

A Pixman-based software renderer for Weston has been talked about in
passing several times, that it would be good to have. No-one just got
around to it yet, AFAIK. It could also allow to run Weston on legacy
(dumb) framebuffers. The GLESv2 renderer has been somewhat separated
from the compositor core, but is not a clean cut yet.

If we start waving our hands very hard, I could foresee dynamic
switching between software and hardware based renderers, on-demand,
coupled with multi-GPU-support. Though if any client uses EGL,
I don't know how you could switch to a software renderer in the server.
Maybe some EGL feature or extension that signals losing the whole EGL
context, so the application needs to fall back to software?

I don't see any reason why Wayland could not support optimized software
compositing. But it does mandate compositing, clients cannot render to
the screen directly, nor submit partially rendered buffers (buffer
re-use and damage tracking in clients will help). The protocol also has
damage tracking, so the server can be efficient in compositing.


Thanks,
pq