If the surface window already uses automatic redirection, we can upgrade
to manual redirection and save some blits with common use cases.
This fixes a minor performance regression from a65bb8480a ('Revert
"xwayland/glamor: Avoid implicit redirection with depth 32 parent
windows"') with mutter >= 44.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1570>
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.
v2:
* Don't try to redirect a depth 32 descendant of different-depth
ancestors, the alpha channel wouldn't be handled correctly.
(Olivier Fourdan)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1300>
This protocol allows for explicit synchronization of GPU operations by
Wayland clients and the compositor. Xwayland can make use of this to
ensure any rendering it initiates has completed before the target image
is accessed by the compositor, without having to rely on kernel-level
implicit synchronization.
Furthermore, for X11 clients that also support explicit synchronization
using the mechanisms exposed in the DRI3 and Present extensions, this
Wayland protocol allows us to simply forward the timeline, acquire, and
release points directly to the compositor, ideally avoiding any
premature stalls in the presentation pipeline.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
Together, DRI3 1.4 and Present 1.4 allow clients to explicitly
synchronize GPU rendering with presentation using DRM syncobjs. Here we
add the necessary support to Xwayland's glamor and Present
infrastructure to enable this functionality.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967>
GLAMOR needs that, and the function returns TRUE unless GLAMOR is not
used.
Drop the function xwl_glamor_needs_buffer_flush() and call
glamor_block_handler() when glamor is used.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that we have only one backend, there is no need to initialize or
select between different backends.
Drop the corresponding functions.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that we have only one GBM backend, either it is available and
usable, or we cannot use GLAMOR.
Therefore we can drop the flag "is_available".
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
And call xwl_glamor_gbm_init_egl() directly instead.
Yet, keep the function separate rather than merging it back into
xwl_glamor_init() for clarity of the code.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
That will be used between the generic Xwayland GLAMOR functions and the
GBM implementation.
Move the definition of xwl_glamor_init_gbm() to that new header rather
than in the generic Xwayland GLAMOR header.
This is preparation work to eventually replace the xwl_egl_backend now
that we have only one backend left.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
Now that the NVIDIA proprietary driver has grown support for GBM, the
EGLStream backend for NVIDIA GPUs is now superseded by the standard
GBM backend in Xwayland.
This code path is therefore not used and hardly ever tested.
Remove support for EGLStream in Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386>
The dmabuf support code is scattered across different source files,
making it hard to follow and bloating unrelated sources.
Move the dmabuf related source code to its own source files.
This is just a cleanup aimed at helping with code readability, no
functional change intended.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1111>
Each function can get the damage region from the xwl_window instead.
Add xwl_window_get_damage_region helper for this.
v2:
* Use xwl_window_get_damage_region in xwl_window_attach_buffer as well
(Olivier Fourdan)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1314>
And other 32-bit architectures, where uint32_t and CARD32 are
not the same type. Otherwise the build will fail with GCC 14
with errors like:
../hw/xwayland/xwayland-glamor.c: In function ‘xwl_glamor_get_formats’:
../hw/xwayland/xwayland-glamor.c:291:43: error: passing argument 3 of ‘xwl_get_formats_for_device’ from incompatible pointer type [-Wincompatible-pointer-types]
291 | num_formats, formats);
| ^~~~~~~~~~~
| |
| CARD32 * {aka long unsigned int *}
../hw/xwayland/xwayland-glamor.c:238:38: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘CARD32 *’ {aka ‘long unsigned int *’}
238 | uint32_t *num_formats, uint32_t **formats)
| ~~~~~~~~~~^~~~~~~~~~~
../hw/xwayland/xwayland-glamor.c:291:56: error: passing argument 4 of ‘xwl_get_formats_for_device’ from incompatible pointer type [-Wincompatible-pointer-types]
291 | num_formats, formats);
| ^~~~~~~
| |
| CARD32 ** {aka long unsigned int **}
../hw/xwayland/xwayland-glamor.c:238:62: note: expected ‘uint32_t **’ {aka ‘unsigned int **’} but argument is of type ‘CARD32 **’ {aka ‘long unsigned int **’}
238 | uint32_t *num_formats, uint32_t **formats)
| ~~~~~~~~~~~^~~~~~~
../hw/xwayland/xwayland-glamor.c:295:28: error: passing argument 3 of ‘xwl_get_formats’ from incompatible pointer type [-Wincompatible-pointer-types]
295 | num_formats, formats);
| ^~~~~~~~~~~
| |
| CARD32 * {aka long unsigned int *}
../hw/xwayland/xwayland-glamor.c:217:26: note: expected ‘uint32_t *’ {aka ‘unsigned int *’} but argument is of type ‘CARD32 *’ {aka ‘long unsigned int *’}
217 | uint32_t *num_formats, uint32_t **formats)
| ~~~~~~~~~~^~~~~~~~~~~
../hw/xwayland/xwayland-glamor.c:295:41: error: passing argument 4 of ‘xwl_get_formats’ from incompatible pointer type [-Wincompatible-pointer-types]
295 | num_formats, formats);
| ^~~~~~~
| |
| CARD32 ** {aka long unsigned int **}
../hw/xwayland/xwayland-glamor.c:217:50: note: expected ‘uint32_t **’ {aka ‘unsigned int **’} but argument is of type ‘CARD32 **’ {aka ‘long unsigned int **’}
217 | uint32_t *num_formats, uint32_t **formats)
| ~~~~~~~~~~~^~~~~~~
This allows e.g.
xfwm4 --vblank=xpresent
to hit the page flip path instead of copies.
In the future, Mesa might also use the Present extension with software
rendering.
Assuming the same number of window buffers, this results in one less
pixmap per toplevel window, saving pixmap storage.
v2:
* Preserve xwl_window_buffer_get_available behaviour (Olivier Fourdan)
v3:
* Leave RegionEmpty call where it was in xwl_window_buffers_get_pixmap,
so it takes effect for a newly allocated struct xwl_window_buffer.
* Consolidate xwl_window_buffer->pixmap assignment in the same place.
Use xwl_window_buffers_dispose instead. The pixmaps will need to be
re-created anyway, so keeping around the xwl_window_buffers doesn't
buy much. And dropping this makes the next commit simpler.
Also fold xwl_window_buffer_destroy_pixmap into its only remaining
caller, xwl_window_buffer_maybe_dispose.
v2: (Olivier Fourdan)
* Fix up indentation in xwl_window_set_window_pixmap
* Leave xwl_window_buffer_destroy_pixmap helper
This code is almost entirely ddx-agnostic already, and I'd like to use
it from the other EGL glamor consumers. Which, right now that's just
Xorg, but soon it'll be Xephyr too.
This commit adds an ability to store a glvnd vendor in Glamor
structures, which can be used for initialize some vendor-based values
without hooking into DDX internals. Also this adds setting this value
into Xorg and Xwayland
Signed-off-by: Konstantin Pugin <ria.freelander@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Emma Anholt <emma@anholt.net>
glamor ensures that a depth 32 pixmap backing a depth 24 window contains
fully opaque alpha channel values for the window's pixels, so we can
allow this without implicit redirection, saving pixmap storage and
intermediate copies.
Second attempt, after fixing a few regressions from the first attempt.
glamor ensures that a depth 32 pixmap backing a depth 24 window contains
fully opaque alpha channel values for the window's pixels, so we can
allow this without implicit redirection, saving pixmap storage and
intermediate copies.
This will be needed with the next commit: If a child window completely
obscures a toplevel ancestor of different depth, the child window can
use page flipping only if the depth of the presented pixmap matches that
of the window's backing pixmap, or the former may contain pixel values
which are not suitable for the toplevel window's depth.
Add a new API similar to xwl_glamor_get_drawable_modifiers() but also
returning whether the format and modifiers are from a tranche which
supports scanout.
This is preparation work for adding scanout support with
gbm_bo_create_with_modifiers2() when supported.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Whenever the linux-dmabuf v4 feedback changes, we need to recreate the
existing buffers so they use the current linux-dmabuf v4 feedback.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With linux dmabuf v4 support, for direct scanout support, we need more
context that just what CreatePixmap() provides, as we need the actual
drawable to invoke xwl_glamor_get_drawable_modifiers().
Add a specific hook in Xwayland's glamor implementation that we can use
for that purpose.
This is preparation work for the direct scanout fixes.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With implicit modifiers, DRM_FORMAT_MOD_INVALID is an allowed modifier,
to indicate that the server can support the format.
When looking for a scanout capable tranche with implicit modifiers, we
ought to check for the availability of a tranche with an invalid
modifier for the given format.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The helper function xwl_feedback_is_modifier_supported() walks all the
formats of a feeedback tranche and checks for format/modifier support
availability.
Add scanout support to that so that a caller can easily restrict the
tranches to those which support scanout.
This is preparation work for the implicit scanout support, no functional
change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Separate the callbacks for the default's feedback from the one for
regular windows.
This is preparation work to recreate the window buffer of feedback
updates, no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
The linux_dmabuf_v1 protocol doesn't guarantee any DRM node type:
the compositor may send a primary node or a render node. Use
drmDevice so that device comparisons are node-type-insensitive.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1447
If the dmabuf protocol's feedback object gave us a new list of
modifiers, send PresentCompleteModeSuboptimalCopy to the client
to inform them that they need to call GetSupportedModifiers.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This adds to xwl_glamor_is_modifier_supported, where if feedback
is in use we will check that the format/mod is allowed in any
device advertised by the compositor.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
[ Michel Dänzer:
* Move dev_formats declaration to where it's used in
xwl_feedback_is_modifier_supported
* Add curly braces around multi-line statement in
xwl_glamor_is_modifier_supported ]
If protocol version 4 of linux_dmabuf is in use, then the compositor
may not return anything with the modifiers event. We instead
will return the formats/mods reported for the main device.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
[ Michel Dänzer:
* Move main_dev declaration to where it's used in
xwl_glamor_get_formats
* Add empty line between variable declaration and comment ]
Michel Dänzer
Olivier Fourdan
Erik Kurzinger
Enrico Weigelt, metux IT consult
Florian Weimer
Adam Jackson
Konstantin Pugin
Simon Ser
Austin Shafer