xserver merge requestshttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests2021-12-04T20:31:25Zhttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/209Internal ftrace marker2021-12-04T20:31:25ZRoman GilgInternal ftrace markerThis is an internal interface for ftrace on Linux. The original idea is to allow us analyzing frame-by-frame timings of XServer's internal processes intertwined with other external processes and hardware.
For example look at this output...This is an internal interface for ftrace on Linux. The original idea is to allow us analyzing frame-by-frame timings of XServer's internal processes intertwined with other external processes and hardware.
For example look at this output via [GPUVis](https://github.com/mikesart/gpuvis) of ftrace markings in Present together with some additional ones in KWin presenting Neverball in windowed mode:
![example](/uploads/d97a35725ebb1b01761a997b96b0107e/example.png)
We can clearly see that flip 4623 for some reason does not hit the next vblank although there should be enough time for that. And from this point on KWin's internal logic is broken leading to an additional delay of one frame. The marked long pause is a single call into GLX to receive buffer age information on the current back-buffer.
This new ftrace interface can be fed at arbitrary places in the XServer with the `ftrace_print` and `ftrace_print_begin/end` calls. It is always available on Linux allowing us to get traces from users. It is started by providing the new `-ftrace` option when launching the XServer. It might be a good idea to provide a D-Bus interface as well so it can be toggled on/off while the XServer is running.
I thought it would be smart to use function pointers instead of conditionals and switching these pointers around when enabling/disabling the interface in order to improve performance. But my research later on showed that it probably does not make a difference with modern branch prediction. So as it is now with the pointers it works, but if public opinion prefers not to use function pointers, I can do this too.https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/847Fixed building when --disable-present option is used2022-01-27T10:19:07ZHans MüllerFixed building when --disable-present option is usedSince a few years (since 09230a2d), the X server wasn't compileable when
--disable-present was passed to the autogen script.
This commit aims to fix this by adding directives and conditions
around some code introduced in 09230a2d, cef12e...Since a few years (since 09230a2d), the X server wasn't compileable when
--disable-present was passed to the autogen script.
This commit aims to fix this by adding directives and conditions
around some code introduced in 09230a2d, cef12efc and 16571b89.
Signed-off-by: Hans Müller <schreibemirhalt@gmail.com>https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967Explicit GPU Synchronization for DRI3, Present, and Xwayland2024-03-29T04:31:37ZErik Kurzingerekurzinger@nvidia.comExplicit GPU Synchronization for DRI3, Present, and XwaylandHere is our proposal for adding explicit GPU synchronization to the DRI3 and Present extensions, along with an implementation for Xwayland. While we at NVIDIA may be particularly keen to have this in place, since our driver lacks implici...Here is our proposal for adding explicit GPU synchronization to the DRI3 and Present extensions, along with an implementation for Xwayland. While we at NVIDIA may be particularly keen to have this in place, since our driver lacks implicit sync support, a general consensus seems to be forming around the idea that explicit sync is the best path forward for the Linux graphics stack. Xwayland will likely remain an important component in that stack for some time yet, and therefore I feel that this work will be of long-term benefit to the community more broadly.
The design takes inspiration from the proposed Wayland wp_linux_explicit_sync_v2 protocol [1], making use of DRM syncobjs as the main primitive. I believe this offers a few benefits. One, having both X11 and Wayland use a similar mechanism for explicit sync will simplify development for client-side drivers, and two, it will also hopefully make it fairly straight-forward for Xwayland itself to add support for the Wayland explicit sync protocol, presumably once it's more widely implemented by compositors.
I've tried to keep this initial proposal focused on getting a usable GPU synchronization primitive in place, and adding support for it to the PresentPixmap request, believing this to be the most important part of the presentation pipeline. Other use-cases for this primitive are conceivable, for instance perhaps in the Damage extension, but I feel that those are best left for later.
Any and all feedback is appreciated.
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1183Present: Bump xserver Present version to 1.32023-12-27T16:01:04ZOlivier FourdanPresent: Bump xserver Present version to 1.3Now that the Xserver supports PresentOptionAsyncMayTear, the current
Present minor version that the xserver supports is 1.3.
Yet the version advertised by the Xserver is still 1.2. Bump the minor
version to 3 to reflect on the actual Pr...Now that the Xserver supports PresentOptionAsyncMayTear, the current
Present minor version that the xserver supports is 1.3.
Yet the version advertised by the Xserver is still 1.2. Bump the minor
version to 3 to reflect on the actual Present support in the Xserver.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: commit 2adc5c45 - add support for PresentOptionAsyncMayTearhttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1260drop some unused / obsolete code2024-03-04T17:04:20ZEnrico Weigeltinfo@metux.netdrop some unused / obsolete codedrop some functions not needed anymoredrop some functions not needed anymorehttps://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300xwayland/present: Redirect surface window as needed for page flips2024-03-21T11:47:17ZMichel Dänzerxwayland/present: Redirect surface window as needed for page flipsIt's needed when the surface window is a depth 24 descendant of a depth
32 toplevel window.
`xwl_source_validate` ensures the toplevel window pixmap has valid
contents when a client reads from it, or when the window hierarchy /
geometry...It's needed when the surface window is a depth 24 descendant of a depth
32 toplevel window.
`xwl_source_validate` ensures the toplevel window pixmap has valid
contents when a client reads from it, or when the window hierarchy /
geometry changes. It's never called in the normal fullscreen application
case, so there's no GPU copy overhead with that.xwayland-24.1.0