Es innegable que AMD ha experimentado una revolución desde 2016, cuando puso en marcha la iniciativa GPUOpen. Desde entonces la compañía ha llevado a cabo una profunda transformación de su imagen de cara al FLOSS y los usuarios de Linux, pasando de ser profundamente despreciada a granjearse una buena cantidad de seguidores gracias a que sus gráficas ofrecen un gran rendimiento con drivers de código abierto.

Sin embargo, todo era muy diferente antes del año 2016. AMD era por aquella época bastante despreciada por el movimiento FLOSS y los usuarios de Linux, un sentimiento que estaba bastante justificado debido a que la compañía no era muy dada a liberar tecnologías y la calidad de sus drivers era lamentable. Cierto que AMD consolidó en la segunda década del Siglo XXI la costumbre de liberar documentación de su hardware para facilitar el desarrollo del driver Open Source Radeon, y hasta contribuyó a él, pero aquello era insuficiente para plantar cara a NVIDIA.

A estas alturas no hace falta recordar que el driver AMDGPU, el cual es Open Source y está incluido en el kernel Linux, ha sido el gran puntal de la revolución que ha catapultado a Radeon de lo más bajo a lo más alto entre los usuarios de GNU/Linux. AMD prometió soporte, oficialidad y aprovechamiento de las GPU y cumplió, aunque también forman parte de este éxito RadeonSI y RADV, los drivers incluidos en Mesa y encargados del soporte de OpenGL y Vulkan respectivamente.

La gran mejora de AMD Radeon no es solo teórica, sino que desde hace tiempo se está viendo que las gráficas de esa marca rinden igual que sus equivalentes de NVIDIA, y además eliminando los problemas de integración que tradicionalmente ha adolecido el driver del gigante verde debido a que no ha sido muy tendente a cumplir con los estándares.

El problema con la grabación desde Wayland

Parece que desde 2016 todo es de color rosa por parte de AMD, pero la realidad es que no es oro todo lo que reluce y su situación podría cambiar radicalmente a partir de la segunda mitad de 2022. A pesar de las evidentes y objetivas mejoras, todavía quedan aspectos que son mejorables:

• AMDGPU depende de un firmware privativo para exprimir todo su potencial.
• El hecho de que la compañía empiece a acelerar el desarrollo de sus drivers tras lanzar las gráficas al mercado obliga a los usuarios de Linux a tener que esperar como mínimo seis meses hasta que sean funcionales. Esto no afecta mucho a los usuarios de distribuciones rolling release o de Fedora, pero puede dejar a los de Ubuntu LTS en una situación difícil.
• A pesar de que la combinación de AMGPU, RadeonSI y RADV cumple en teoría con los estándares, los problemas con el soporte de DMA-BUF en GNOME (y a saber si otros entornos y gestores de ventanas) dejan una autopista libre a Intel y NVIDIA.

Para los que anden perdidos, DMA-BUF está relacionado con la captura de la pantalla desde Wayland y como bien explica Georges Stavracas es un búfer que se encarga de evitar la copia de “imágenes entre la GPU y la memoria de la CPU. En un monitor 4K, que es lo que estoy usando en estos días, eso significa que evita copiar innecesariamente casi 2GB de píxeles por segundo”. De esta manera se consigue mejorar el rendimiento de la grabación, aparte que en GNOME es imprescindible para capturar aplicaciones a pantalla completa desde la sesión de Wayland salvo que se esté usando una capturadora.

En un principio el soporte de DMA-BUF iba a ser habilitado para las gráficas Intel y Radeon en GNOME 3.38, pero el soporte para la marca de AMD se quedó en fase experimental debido problemas que se detectaron a última hora. Esto no ha cambiado en GNOME 40 y no parece que la cosa vaya a cambiar en la próxima versión del entorno, si bien siempre queda la opción de forzar el uso de DMA-BUF y asumir los riegos.

El problema de Radeon con DMA-BUF es todo un filón que puede ser explotado la competencia. Intel tiene de lejos los drivers más maduros y funcionales para Wayland, siendo por ahora la única marca de gráficas que tiene habilitado DMA-BUF por defecto y out of the box, sin que sea necesario configurar nada. Por su parte, NVIDIA decidió hace poco adoptar los estándares y empezar a tener gestos hacia los usuarios domésticos de Linux, lo que obviamente apunta directamente a los gamers y a los streamers que transmiten usando la gráfica.

Forzando la activación de DMA-BUF en fase experimental con el editor de Dconf

El problema con la codificación por hardware

Los problemas de Radeon con la captura de contenido no solo abarca Wayland, que a fin de cuentas solo está relativamente maduro en GNOME y Sway que yo sepa, sino también la codificación por hardware, y aquí la situación de la marca es todavía más preocupante porque desde hace años va claramente por detrás de Intel y NVIDIA.

Intel ofrece una codificación por hardware como mínimo decente mediante VA-API, aunque aprovechar esa característica depende de algunos paquetes adicionales que por lo general no suelen ser preinstalados por las distribuciones. Sin embargo, hallarlos no es difícil y gracias a que es un soporte oficial funcionan bastante bien, incluso con la versión Flatpak de OBS Studio (en alusión a los problemas de integración que aún arrastra Flatpak).

Cierto es que las gráficas integradas de Intel no dan para jugar a títulos exigentes, pero eso podría empezar a cambiar con el lanzamiento de las futuras gráficas dedicadas. Si el gigante azul del chip mantiene el soporte en las mismas condiciones y es capaz de cumplir con las elevadas exigencias a nivel de rendimiento, es obvio que el mercado doméstico de Linux que hasta ahora ha apoyado a Radeon se pasará a Intel, sobre todo en caso de realizar tareas de grabación y transmisión con la GPU.

NVIDIA utiliza para la codifiación por hardware su propia tecnología privativa, NVENC, que se puede usar en las versiones para Linux y Windows de OBS Studio. El gigante verde lleva muchos años invirtiendo y mejorando sus tecnologías de codificación por hardware, y si en este frente se muestra claramente superior a Radeon en Windows, en GNU/Linux la situación es todavía más grave debido al pobre aprovechamiento de VA-API que hacen las gráficas de AMD. En versiones de desarrollo de OBS Studio 27 la codificación por hardware empezó a funcionar en Radeon, pero el códec volvió a mostrar problemas en las últimas candidatas de lanzamiento y en la versión estable (o al menos eso me ha pasado con Fedora 34 Workstation).

Sobrecarga al codificar en OBS Studio usando VA-API con una gráfica AMD Radeon en Linux

AMD Radeon: De vuelva al tercer puesto para la segunda mitad de 2022

Las gráficas dedicadas de Intel siguen siendo productos prometedores, más viendo que al menos un modelo de Intel DG2 apunta a igualar el rendimiento de la RTX 3080. Otro punto que tiene la compañía a su favor es el hecho de tener unos drivers al menos relativamente maduros en la fecha de lanzamiento de sus procesadores, cosa que si mantiene para sus gráficas dedicadas le otorgaría una importante ventaja frente a Radeon.

Por otro lado, el rumbo de NVIDIA en el mercado doméstico de Linux puede dar un giro de 180 grados gracias a que, después de muchos años, ha decidido adoptar los estándares de Wayland. En caso de cumplir con las expectativas, las gráficas del gigante verde deberían de funcionar sin configuraciones adicionales en las sesiones de Wayland ya existentes, lo que se sumaría a su buen soporte de codificación por hardware.

Si Radeon no mueve ficha, podría encontrarse volviendo a ocupar el tercer puesto en gráficas para Linux durante el transcurso de la segunda mitad de 2022.