Work on improvements to XWayland continues and developers they have made known recently that Xwayland has been modified to allow acceleration of representation by hardware in systems with proprietary graphics drivers from NVIDIA.
For those unaware of X Wayland, they should know that it's an X server running under Wayland and provides backward compatibility for legacy X11 applications that provides startup organization for X.Org server performance X11 applications in Wayland-based environments.
As many of you will know, Wayland is a complete window system unto itself. The Xorg server can be modified to use wayland input devices for input and forward the root window or individual top-level windows as wayland surfaces.
The component is being developed as part of the main X.Org codebase and it was previously released together with the X.Org server, but due to X.Org server stalling and the uncertainty with the release of 1.21 in the context of XWayland's continued active development, it was decided to separate XWayland and publish the accumulated changes in the form of a separate package.
Judging from testing by the developers, after enabling these patches, the performance of OpenGL and Vulkan in X applications launched with XWayland is almost the same as under the control of a normal X server.
The changes were prepared by an NVIDIA employee, In NVIDIA's own driver, support for components required to use acceleration in Xwayland will appear in a future release, presumably in the 470.x branch.
These two patches are intended to accompany the upcoming support in NVIDIA's proprietary driver for hardware-accelerated GL and Vulkan rendering with Xwayland. They shouldn't interfere with current swrast-based GL support, so once the driver-side shifts are out the door, things should start to work. However, I wanted to submit these of ours for your consideration first, in case anyone has any substantial concerns with the overall approach. See the confirmation messages for more details on the implementation.
Performance should be roughly on par with the native X11 based on the benchmarking I did. Annoying extra copy is still required for windowed app presentation, but the impact doesn't seem to be significant, and full-screen apps won't have that problem (as long as the composer supports the required zwp_linux_dmabuf_v1 interface).
Also, various other events related to the Linux graphics stack can be observed, since the Wayland developers plan to rename the master branch in all their repositories from "master" to "main", as the word "master" is considered politically incorrect lately, it reminds of slavery and some members of the community perceive it as offensive. In turn, the freedesktop.org community has decided to use the 'main' repository instead of the default 'master' for new projects.
Interestingly, too there were opponents to this idea. En particular, Jan Engelhardt, who maintains over 500 packages on openSUSE, He called GitHub and SFC's arguments for replacing "master" with "main" as hypocrisy and double standards. He suggested leaving things as they were and focusing on continued development rather than creating a mess of name changes.
According to Ian, for those who cannot accept the term "master", they can simply guarantee the work of two branches with an identical state of commits and do it without breaking the established form.
Another change is in the lavapipe of the Mesa controller which is designed for software rendering and uses LLVM for code generation, implemented the Vulkan 1.1 support graphics API and certain features of the Vulkan 1.2 specification (previously, lavapipe is only fully compatible with OpenGL). what the controller successfully passes all tests covering the new features of Vulkan 1.1, but so far it fails the same tests for Vulkan 1.0, preventing its official certification for Vulkan support.
Source: https://gitlab.freedesktop.org/