Los trabajos para las mejoras en XWayland continúan y los desarrolladores han dado a conocer recientemente que Xwayland se ha modificado para permitir la aceleración de la representación por hardware en sistemas con controladores de gráficos patentados de NVIDIA.
Para quienes desconocen de XWayland, deben saber que es un servidor X que se ejecuta bajo Wayland y proporciona compatibilidad con versiones anteriores para aplicaciones X11 heredadas que proporciona organización de puesta en marcha para aplicaciones X11 rendimiento X.Org servidor en entornos basados en Wayland.
Tal y como muchos de ustedes sabrán, Wayland es un sistema de ventanas completo en sí mismo. Por su parte el servidor Xorg se puede modificar para usar dispositivos de entrada wayland para la entrada y reenviar la ventana raíz o ventanas individuales de nivel superior como superficies wayland.
El componente se está desarrollando como parte del código base principal de X.Org y se lanzó anteriormente junto con el servidor X.Org, pero debido al estancamiento del servidor X.Org y la incertidumbre con el lanzamiento de 1.21 en el contexto del desarrollo activo continuo de XWayland, se decidió separar XWayland y publicar los cambios acumulados en forma de un paquete separado.
A juzgar por las pruebas realizadas por los desarrolladores, después de habilitar estos parches, el rendimiento de OpenGL y Vulkan en aplicaciones X lanzadas con XWayland es casi el mismo que bajo el control de un servidor X normal.
Los cambios fueron preparados por un empleado de NVIDIA, en el propio controlador de NVIDIA, la compatibilidad con los componentes necesarios para utilizar la aceleración en Xwayland aparecerá en una versión futura, presumiblemente en la rama 470.x.
Estos dos parches están destinados a acompañar el próximo soporte en el controlador propietario de NVIDIA para GL acelerado por hardware y renderizado Vulkan con Xwayland. No deberían interferir con el soporte GL actual basado en swrast, por lo que una vez que los cambios del lado del conductor salgan por la puerta, las cosas deberían comenzar a funcionar. Sin embargo, quería enviar estos nuestros para su consideración primero, en caso de que alguien tenga alguna preocupación sustancial con el enfoque general. Consulte los mensajes de confirmación para obtener más detalles sobre la implementación.
El rendimiento debería estar aproximadamente a la par con el X11 nativo según la evaluación comparativa que hice. Todavía se requiere una copia adicional molesta para la presentación de aplicaciones con ventanas, pero el impacto no parece ser significativo, y las aplicaciones de pantalla completa no tendrán ese problema (siempre que el compositor admita la interfaz zwp_linux_dmabuf_v1 requerida).
Además, se pueden observar varios otros eventos relacionados con la pila de gráficos de Linux, ya que los desarrolladores de Wayland planean cambiar el nombre de la rama maestra en todos sus repositorios de «master» a «main», ya que la palabra «maestro» se considera políticamente incorrecta últimamente, recuerda la esclavitud y algunos miembros de la comunidad la perciben como ofensiva. A su vez, la comunidad freedesktop.org ha decidido utilizar el repositorio ‘main’ en lugar de ‘maestro’ por defecto para nuevos proyectos.
Curiosamente, también hubo opositores a esta idea. En particular, Jan Engelhardt, quien mantiene más de 500 paquetes en openSUSE, calificó los argumentos de GitHub y SFC para reemplazar «master» por «main» como hipocresía y doble rasero. Sugirió dejar las cosas como estaban y centrarse en el desarrollo continuo en lugar de crear un lío de cambios de nombre.
Según Ian, para aquellos que no pueden aceptar el término «master», simplemente pueden garantizar el trabajo de dos ramas con un estado idéntico de confirmaciones y hacerlo sin romper la forma establecida.
Otro de los cambios es en lavapipe del controlador Mesa el cual está diseñado para renderizado de software y utiliza LLVM para la generación de código, implementó la API de gráficos de soporte Vulkan 1.1 y ciertas características de la especificación Vulkan 1.2 (anteriormente, lavapipe solo es totalmente compatible con OpenGL), en él se observa que el controlador pasa con éxito todas las pruebas que cubren las nuevas características de Vulkan 1.1, pero hasta ahora falla las mismas pruebas para Vulkan 1.0, lo que impide su certificación oficial para el soporte de Vulkan.
Fuente: https://gitlab.freedesktop.org/