Una reorganización del driver AMD RadeonSI Gallium3D llegó hoy a Mesa 26.2-devel, separando mejor el código de aceleración gráfica del de aceleración multimedia en el resto del driver. El cambio limpia parte del código y facilita casos de uso como compilaciones de RadeonSI sin soporte gráfico (OpenGL) o, ahora, builds de RadeonSI solo para soporte multimedia de aceleración de video.

¿Qué cambia en el código?

Hace algunos meses, AMD ya había agregado soporte para construir el driver RadeonSI sin soporte gráfico si no se necesitaba OpenGL pero sí los demás state trackers de Gallium3D. Hoy, el ingeniero del driver AMD Pierre-Eric Pelloux-Prayer mergeó código que mueve:

  • Todo el código específico de gráficos y compute a una subcarpeta propia llamada gfx.
  • Todo el código multimedia de RadeonSI a una carpeta llamada mm.

A su vez, hay una nueva opción para construir el driver RadeonSI con soporte de hardware multimedia (por ejemplo, para la Video Acceleration API, VA-API) pero sin soporte gráfico ni compute, si la macro PIPE_CONTEXT_MEDIA_ONLY está definida.

El merge request 41133 en el repositorio upstream de Mesa tiene todos los detalles de la reorganización.

¿Para qué sirve esto en el mundo real?

Presumiblemente, este clean-up habilita casos como AMD Instinct, donde el foco está en el stack de compute AMD ROCm pero también se necesita aceleración multimedia. De hecho, en el anuncio del AMD Instinct MI350P AMD le dedicó una slide a las capacidades multimedia de la tarjeta. En ese rack-scale, OpenGL no se necesita ni se soporta, pero la aceleración multimedia puede ser importante para ciertas cargas de trabajo (procesamiento de video con ML, indexación de stream, transcodificación enterprise).

De manera análoga, en un escenario futuro probable podrías querer:

  • Aceleración Vulkan via el driver RADV para gráficos puros.
  • Aceleración VA-API via el driver RadeonSI únicamente para video, sin OpenGL.

Ese stack mixto era difícil de armar antes; con la nueva reorganización se vuelve compilable como configuración estándar.

Implicancias para integradores y workstations en Chile

Para equipos que arman workstations dual-GPU o flotas de servidores compute en Chile, el cambio tiene tres consecuencias prácticas:

  • MI350P como acelerador multimedia + compute: si su organización está evaluando AMD Instinct para reemplazar Nvidia H100/H200 en cargas de trabajo de transcodificación masiva, indexación de archivo o pipelines de video-IA, este cambio en Mesa habilita una pila más limpia en producción, sin tener que arrastrar dependencias de OpenGL.
  • Imagen base mínima para containers: empresas que construyen imágenes Docker/Podman con drivers Mesa para deploy en Kubernetes podrán reducir tamaño y superficie de ataque eliminando libGL.so y compilando solo mm cuando no se necesite gráficos.
  • ROCm + VA-API en una misma máquina: para estaciones de ingeniería que corren entrenamiento ROCm más decoding de datasets de video grandes (común en empresas de seguridad pública, broadcast y vigilancia), la separación gfx/mm reduce conflictos de userspace.

El cambio entrará en Mesa 26.2 —ya disponible en la rama devel— y debería estar empaquetado en distribuciones rolling como Arch Linux y Fedora Rawhide en las próximas semanas. Ubuntu 26.04 LTS y Debian 13 probablemente arrastren los paquetes en sus ciclos de actualización estándar.