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
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
