Benchmark of Wayland

[Chris Wilson]

Take a step back. It's time to review the system architecture once more.
Wayland is a input/output [de-]multiplexer. It does no rendering on the
behalf of the client, only compositing the many clients onto the scanouts.
The clients must prepare for themselves the shared memory buffers that
they pass to Wayland for compositing. (Under GEM those shared memory
buffers are merely GEM objects and therefore can also be used with
hardware accelerated rendering.)

On Sat, 13 Nov 2010 12:20:29 +0800, Justin Lee <justinlee5455 at gmail.com> wrote:
> Yep, I guess cairo-gl used by Wayland should get similar performance
> boosts as cairo-drm if it's also direct-rendered (by mesa-dri?). It
> seems that mixing 2D drawings with 3D drawings makes problems,
> therefore we want to draw everything by OpenGL even if for 2D
> graphics. Maybe that's the purpose of cairo-gl i.e. being a wrapper
> library which use OpenGL to draw 2D graphics.

The difference between theory and practice...

To put it bluntly, cairo-gl on my fastest boxes [g45, ironlake] is still
slower than cairo-xlib on one of my slowest boxes [q35, for pnv it's
close but the Atom is just no match for the CPUs in the desktop boxes].

This is all due to driver quality and the fact that RENDER is much easier
to accelerate than a full GL implementation. This also implies that there
is less opportunity for acceleration of RENDER because so much information
is thrown away upfront. (Having said that cairo-xlib on g45/ilk is
atrocious and much slower than cairo-gl on the same platforms, again due
to driver quality.)

The promise of GL is that we only need to write one good driver per
chipset...

The promise of Wayland is that every pixel is perfect. It takes the
architecture that X has organically developed over the last 25 years and
aims to implement that in a small footprint, low latency system.

One of the killer ideas of Wayland is that it is self-hosting.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre