Benchmark of Wayland
jonsmirl at gmail.com
jonsmirl at gmail.com
Wed Nov 17 11:47:01 PST 2010
On Sat, Nov 13, 2010 at 4:23 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 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 core compositing model in Cairo is built on is the exactly same
operations supported by render. Cairo was designed to be a perfect
render client. It was not designed to be a perfect GL client. Some
render operations don't map cleanly to GL, especial sub-pixel level
ops (anti-aliasing). So with perfect drivers I would expect cairo-xlib
to always beat cairo-gl. Right now we don't have perfect drivers so
driver quality is dominating.
But this gets back into the issue of anti-aliasing. Who should be
doing the anti-aliasing? The app or the graphics subsystem? Without a
global policy on anti-aliasing it is probably always going to be
messed up somewhere.
How are apps going to handle sub-pixel anti-aliasing? We have CRTs,
LCDs (hor and vet), ePaper, Sharp Yellow, PixelQi, etc all with
different pixel arrangements.
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
--
Jon Smirl
jonsmirl at gmail.com
More information about the wayland-devel
mailing list