Fwd: Re: [PATCH 0/2] Add New XWayland API

[Axel Davy]

Given the recent discussion on the xorg-devel mailing list,
I think this new API shouldn't be merged within the X server.

The clear goal of the xorg team is toward dri3, and I was told
no patch enabling AsyncSwap for dri2 would be merged.

To implement the Present extension and composite efficiently,
the XWayland API would have to be rewritten anyway. And since
Present redirection shouldn't make it for X 1.15, but 1.16, it's
probably better waiting X 1.16 for a XWayland API rewrite.

I will include this API proposal with wlglamor, and add options to use
AsyncSwap even when vsync is enabled. (and we'll have the choice to
cap to frame rate or not)

I've tried benchmarking AsyncSwap with the phoronix-test-suite,
and I was surprised to see a regression with Openarena and Xonotic.
According to dri devs, it is because, since I do an exchange, the
application
is fullscreen and then Weston uses the buffer as scanout buffer, when
the buffer is
released and we render again in the buffer, L3 caching is disabled.
I don't know if there's similar issues with other drivers, but I think
this is a problem that should be solved, since the problem will occur
for any fullscreen Wayland applications when bypassing
compositing is enabled.

It makes more sense in this case to have AsyncSwap support only as an
option:
Tearings will go away anyway with it, but for some applications you'll
have a gain, and
some others not. When drivers fix this behaviour, it should always be a
gain.

And since Gnome 3.10 doesn't bypass compositing yet, if I have well
understood, then
for them it'll always be a performance benefit.

Axel Davy

> The current XWayland API has no functionality to help the DDXs
> implement ScheduleSwap. This new API proposal introduces functions
> to manipulate the frame event, the release event, and to manipulate
> the buffers that the Wayland compositor sees.
>
> The first patch is not linked directly to XWayland,
> it is a patch initially written by Chris Wilson, that
> enables some useful optimisations DDX side when swap_interval=0
> (AsyncSwap).
>
> The new XWayland API enables to do an efficient implementation
> of AsyncSwap.
>
> I have implemented ScheduleSwap and AsyncSwap in the wlglamor DDX to
> test the API.
>
> For XWayland, applications which benefit from AsyncSwap are applications
> with no decoration window, like fullscreen applications.
>
> For example with an intel hd4000, with a fullscreen glmark2(1920x1080),
> the terrain benchmark goes from 49 fps to 53 fps, and the ideas benchmark
> goes from 397 fps to 645 fps. All this because we avoid a copy. Moreover,
> AsyncSwap allows suppress tearings for fullscreen applications because we
> can respect the Wayland buffer release semantic.
>
> The new function xwl_add_frame_todo_visible_window allows to implement
> ScheduleSwap, and xwl_display_get allows to get the wl_display used by
> XWayland.
>
> The API introduces a new object: xwl_buffer, which is use to manipulate
> the buffers linked with Wayland and the buffer exposed by the
> windows shown to the Wayland compositor.
>
>
> Axel Davy (2):
>    Patch to the Xserver to support AsyncSwap
>    Add new XWayland API.
>
>   hw/xfree86/dri2/dri2.c                 |  36 ++++--
>   hw/xfree86/dri2/dri2.h                 |   8 +-
>   hw/xfree86/xwayland/Makefile.am        |   2 +
>   hw/xfree86/xwayland/xwayland-buffers.c | 114 +++++++++++++++++
>   hw/xfree86/xwayland/xwayland-drm.c     |  10 +-
>   hw/xfree86/xwayland/xwayland-events.c  | 222 +++++++++++++++++++++++++++++++++
>   hw/xfree86/xwayland/xwayland-private.h |  20 ++-
>   hw/xfree86/xwayland/xwayland-window.c  |  21 ++--
>   hw/xfree86/xwayland/xwayland.c         |  23 +++-
>   hw/xfree86/xwayland/xwayland.h         |  68 ++++++++++
>   10 files changed, 496 insertions(+), 28 deletions(-)
>   create mode 100644 hw/xfree86/xwayland/xwayland-buffers.c
>   create mode 100644 hw/xfree86/xwayland/xwayland-events.c
>