La implementación de Wayland por parte de NVIDIA ha sido una de las mayores batallas tecnológicas que se hayan visto en Linux. El gigante del procesamiento gráfico no daba su brazo a torcer al mantener su apuesta por EGLStreams como búfer para Wayland, mientras que el resto, incluidos Intel y AMD, apostaron por el estándar GBM.

Después de muchos años de tiras y aflojas, el futuro regreso de Intel al mercado de las gráficas dedicadas, la precipitada defunción de Xorg y sobre todo el fracaso del propio EGLStreams forzaron a NVIDIA a rectificar para adoptar GBM, más viendo las altas probabilidades de que Wayland sea establecido por defecto en la próxima LTS de Ubuntu.

NVIDIA todavía tiene trabajo por delante para ponerse al día con su soporte de Wayland, que en teoría debería de permitir que su driver oficial funcione correctamente con las sesiones de Wayland ya existentes, sin necesidad de introducir modificaciones en los compositores (o al menos no tan radicales como los que requería EGLStreams).

James Jones, ingeniero de NVIDIA, ha anunciado que el driver de la compañía ya funciona por defecto en Sway usando GBM. La consecución de este hito ha necesitado de introducir las funciones de ‘gbm_bo_create_with_modifiers2’ y de ‘gbm_surface_create_with_modifiers2’ en el backend de GBM de Mesa debido a que las funciones de ‘gbm_*_create_with_modifiers’ carecían de soporte para flags.

Sway es un gestor de ventanas y compositor de Wayland inspirado en i3 que decidió en el lanzamiento de su versión 1.0 abandonar el soporte de EGLStreams. Drew DeVault, creador de Sway, repitió una archiconocida frase de Linus Torvalds y anunció que el compositor dejaría de soportar el driver oficial de NVIDIA. Por otro lado, el compositor es uno de los mejores exponentes de Wayland, y hay quien lo considera como la mejor implementación del protocolo.

La claudicación de NVIDIA ante los estándares de Wayland ha necesitado de introducir en Mesa un backend alternativo de GBM para soportar el driver de la compañía, que actualmente también se encuentra trabajando en el soporte de DMA-BUF y en otras mejoras relacionadas con Wayland.

La versión 470 del driver del gigante verde ha puesto los cimientos para soportar Wayland, pero hay otros componentes que deben ser parcheados para que todo funcione como se espera (o sea, con las sesiones de Wayland existentes).

NVIDIA, a la caza de Radeon

NVIDIA siempre ha tenido muchos intereses en torno a Linux, pero estos siempre han estado ligados a los servidores, la supercomputación y la inteligencia artificial. Mientras tanto, y hasta hace poco, la corporación no veía a Linux como un sistema de escritorio que pudiese ser usado como Windows y macOS, pero parece que eso está empezando a cambiar, ya que, aparte del soporte de Wayland, la llegada de DLSS a Proton fue la respuesta al anuncio de FidelityFX Super Resolution (FSR).

El soporte de DMA-BUF es uno de los aspectos más interesantes debido a que dicha característica es imprescindible para la grabación de gameplays desde una sesión de Wayland. De momento todo apunta a que no va a estar habilitada por defecto en GNOME 41 para las gráficas Radeon, por lo que se mantendría oficialmente como algo exclusivo de Intel. NVIDIA tiene ahí un frente para explotar una debilidad típica de Radeon que también se da en Windows: las tecnologías asociadas o relacionadas.

Las gráficas Radeon ofrecen una “potencia bruta” comparable a la de NVIDIA, incluso en Linux, pero cuando se trata de tecnologías, NVIDIA siempre va al menos un paso por delante. Las soluciones de codificación por hardware de NVIDIA para Linux son muy superiores a las de AMD, con DLSS y en trazado de rayos el gigante verde parece ir una generación por delante de FSR y la implementación del trazado de rayos de Radeon, y así sucesivamente.

El hecho de que NVIDIA vaya por delante en tecnologías es un buen punto a su favor, por lo que después de que se haya amoldado a los estándares de Wayland y tras sumarse Intel al mercado de las gráficas dedicadas, es muy probable que veamos a Radeon volviendo a ocupar el tercer puesto, aunque en unas circunstancias muchísimo mejores que las que había en los tiempos de Catalyst/FGLRX.