Mesa 25.3.4 se presenta como una actualización clave dentro de la rama Mesa 25.3, pensada para afinar estabilidad, corregir errores importantes y pulir el trabajo introducido en las versiones anteriores. No trae grandes novedades rompedoras, pero sí un conjunto de cambios que, en la práctica, pueden marcar la diferencia para quien juega en Linux, usa Vulkan o OpenGL de forma intensiva o depende de los controladores de código abierto para su día a día.

Esta entrega se construye sobre la base de Mesa 25.3, una serie que ya había introducido gran cantidad de extensiones nuevas para Vulkan y OpenGL, mejoras en controladores como RADV, ANV, NVK, Zink, Panfrost, V3D, PVR y muchos otros, así como avances en Rusticl, soporte de NPUs Arm Ethos y herramientas de depuración avanzadas. Mesa 25.3.4 llega precisamente para apuntalar ese ecosistema: corrige regresiones que afectaban a juegos concretos, resuelve cuelgues de drivers y arregla problemas de compatibilidad que podían fastidiar la experiencia tanto en títulos comerciales como en aplicaciones profesionales.

Novedades generales de Mesa 25.3.4

De entrada, Mesa 25.3.4 se presenta oficialmente como una versión de mantenimiento centrada en la corrección de bugs. Es la siguiente parada tras la 25.3.3 y, tal y como se explica en el anuncio, su función es atajar los errores detectados desde esa revisión anterior. Aunque el núcleo del proyecto sigue ofreciendo la implementación de las APIs gráficas más importantes, esta versión pone el foco en asegurar que todo lo que ya se había incorporado funcione como es debido.

En lo que respecta a las APIs soportadas, la biblioteca continúa ofreciendo una implementación completa de OpenGL 4.6 y de Vulkan 1.4. Eso sí, el nivel concreto que verá cada usuario depende del driver que emplee: el valor devuelto por glGetString(GL_VERSION), por glGetIntegerv(GL_MAJOR_VERSION) y glGetIntegerv(GL_MINOR_VERSION) o por el campo apiVersion en VkPhysicalDeviceProperties variará según las capacidades reales de cada controlador. Algunas GPUs no implementan todas las características obligatorias de OpenGL 4.6, por lo que la versión anunciada por el contexto puede ser inferior.

Un detalle importante es que OpenGL 4.6 únicamente se expone cuando se solicita explícitamente en la creación del contexto. En otros casos, especialmente con contextos de compatibilidad, el driver puede anunciar una versión más baja en función de lo que soporte de forma estable. De manera similar, en Vulkan 1.4, el número de versión visible para el usuario se ajusta al nivel que el controlador declara de forma efectiva para cada dispositivo físico.

Ampliación del soporte de hardware

En el apartado de hardware, Mesa 25.3 y sus subversiones, incluida Mesa 25.3.4, continúan la tendencia de abrir el abanico de dispositivos soportados y mejorar la integración con plataformas existentes. El controlador PVR ha alcanzado la compatibilidad con Vulkan 1.2, algo crucial en determinados SoC donde este driver es la base de toda la pila gráfica.

En el lado de Intel, el driver ANV amplía su alcance con soporte para plataformas como Wildcat Lake, lo que asegura que equipos relativamente recientes mantengan una interoperabilidad adecuada con Vulkan y sigan beneficiándose de las novedades del ecosistema. De manera paralela, la parte de gráficos integrados de Intel obtiene ajustes de rendimiento y correcciones para juegos ejecutados a través de Proton, reduciendo artefactos y fallos de renderizado.

AMD no se queda atrás: RADV, su controlador Vulkan de código abierto, sigue recibiendo optimizaciones en trazado de rayos y mejoras de vídeo. En la rama 25.3 se ha avanzado en la aceleración de vídeo para las GPUs de la compañía, además de integrar ajustes que mejoran el rendimiento en juegos exigentes y en escenarios donde la latencia es un factor clave.

En el ecosistema NVIDIA de código abierto, el controlador NVK ha dado pasos importantes hasta llegar a compatibilidad con Vulkan 1.4 en GPUs Blackwell. Esto sitúa al stack abierto en una posición más competitiva frente al controlador propietario, sobre todo para quienes quieren usar únicamente software libre sin renunciar a capacidades modernas de la API.

Mesa 25.3.4 introduce nuevo controlador Gallium para NPUs y otras herramientas avanzadas

Una de las novedades técnicas más llamativas de la serie 25.3 es la aparición de un driver Gallium específico para las NPUs Arm Ethos, diseñado para funcionar junto con el framework Teflon. Aunque pueda sonar muy de nicho, este movimiento apunta hacia un futuro donde el hardware especializado (como aceleradores de IA) se integre de forma más natural en sistemas GNU/Linux.

Otra funcionalidad avanzada que se ha agregado es la posibilidad de reemplazar shaders SPIR-V en controladores Vulkan. Esta característica está orientada a depuración y diagnóstico: permite intercambiar ciertos shaders en tiempo de ejecución para entender mejor qué está fallando en determinadas cargas de trabajo. Para desarrolladores de motores, herramientas de profiling y estudios que portan juegos, esto supone una ayuda muy significativa.

Cambios simbólicos y limpieza técnica

Entre los cambios estructurales de la familia 25.3 destaca la retirada definitiva del frontend VDPAU, que llevaba tiempo considerado tecnología heredada. Este movimiento simplifica la base de código, reduce mantenimiento y empuja a los usuarios hacia interfaces más modernas para la aceleración de vídeo, en línea con la evolución del resto del ecosistema.

La serie también incorpora soporte mejorado para Vulkan WSI con atomic mode-setting, lo que proporciona una gestión más precisa de los modos de pantalla y la sincronización. Estos detalles resultan fundamentales para entornos donde la experiencia de escritorio, el rendimiento en juegos y la consistencia en la presentación de fotogramas son prioritarios, como en Steam Deck, PCs de juego o estaciones de trabajo gráficas.

Para completar este proceso de modernización, se han añadido extensiones como VK_KHR_pipeline_binary a ANV y NVK, que ayudan a reducir tiempos de carga de shaders y aportan más estabilidad al gestionar pipelines precompilados. Esto es una buena noticia para quienes sufren stuttering en determinados juegos, ya que forma parte del esfuerzo por suavizar la compilación de shaders en segundo plano.

Correcciones de errores y regresiones específicas en Mesa 25.3.4

Más allá de la base funcional de la serie 25.3, la versión 25.3.4 introduce una lista significativa de correcciones dirigidas a problemas muy concretos que se habían detectado. Una de las más visibles afecta al controlador RADV: existía una regresión que provocaba cuelgues de Resident Evil 4 cuando se utilizaban comprobaciones de instrucciones QA en vkd3d-proton, algo especialmente molesto para quienes juegan a este título mediante Proton.

Se ha solucionado igualmente un cuelgue del driver en una RX Vega 64 al manejar un gran número de shaders de vértice, caso detectado con el proyecto OpenGOAL ejecutando Jak and Daxter 1. Este tipo de errores suele manifestarse como bloqueos completos de la GPU o del sistema de gráficos, por lo que su corrección tiene un impacto directo en la estabilidad.

Otro problema abordado afecta a RADV en el juego Kingdom Come Deliverance 1 sobre hardware RDNA4, donde las capturas de RGP carecían de contadores de caché para determinadas operaciones de dispatch. Además, se ha corregido una situación en la que el proceso de lowering de NIR en RADV podía provocar un segfault si se encontraba con una consulta de rayos que intentaba continuar antes de estar correctamente inicializada.

La versión 25.3.4 también atiende una regresión en el driver Vulkan para GPUs integradas de Intel, mejorando de nuevo la fiabilidad en entornos donde la gráfica integrada es el recurso principal. Asimismo, se ha activado el uso de shaders SIMD32 con ray queries en el contexto de ANV/Intel-brw, completando el trabajo previo para habilitar este tipo de shaders con consultas de rayos.

En el ámbito de la memoria, se ha corregido una fuga de memoria GTT al ejecutar juegos o software OpenGL en una AMD RX 6600 XT, algo que a largo plazo podía degradar el rendimiento o provocar comportamientos inesperados después de sesiones de juego prolongadas.

En la parte de presentación sin cabeza (headless), el componente wsi_common_headless ahora se asegura de rellenar correctamente la estructura VkSurfacePresentModeCompatibilityKHR al usar VK_EXT_headless_surface. Antes no se completaba esa información, lo que podía causar problemas de compatibilidad en aplicaciones que dependían de esos datos.

Se ha solucionado también un fallo visual en WITCH ON THE HOLY NIGHT, donde algunos elementos de la interfaz mostraban cuadros parpadeantes en GPUs con identificadores gfx1150/1151 usando RADV. En vídeo, se corrige un problema por el cual VA ya no convertía bien de YUV a RGB, y se soluciona un fallo de página de VCN y un timeout de anillo durante la codificación VAAPI HEVC con scale_vaapi en una RX 9060 XT / gfx1200.

En el terreno de NIR, se resuelve un caso de comportamiento indefinido al usar una tabla range_minimum_query_table realojada, y se ataja una regresión en matrices cooperativas con RADV. Además, se clarifica la opción de compilación gallium-rusticl-enable-drivers para evitar confusiones a la hora de habilitar drivers en Rusticl.

Ajustes internos y contribuciones de desarrolladores

El changelog de Mesa 25.3.4 refleja el trabajo de una gran cantidad de desarrolladores, cada uno aportando correcciones puntuales, mejoras de estabilidad y pequeños retoques internos. Entre los cambios firmados por Daniel Schürmann, por ejemplo, se encuentran arreglos en aco/lower_to_hw para corregir las clases de registro de operandos SGPR en copias de subpalabra y en operaciones de empaquetado 2×16, así como una limitación para evitar usar dos operandos SGPR en una sola instrucción VOP3 antes de GFX10 en do_pack_2x16().

Dave Airlie añade cambios como una opción de capa para desactivar la lógica de selección de dispositivo en device-select, su aprovechamiento en Zink para deshabilitar esa selección cuando sea necesario, una corrección en radv/coopmat relacionada con strides de dereferencias y un ajuste en gallivm para intercambiar coordenadas de arrays 1D antes del casting.

Eric Engestrom, por su parte, introduce una corrección en la opción de meson “enable-drivers” para Rusticl, evitando configuraciones inconsistentes, y limita la integración de RenderDoc en Vulkan runtime y Zink únicamente a plataformas donde está soportado oficialmente, reduciendo errores en otros entornos.

En el área de controladores para GPU Mali, Faith Ekstrand realiza ajustes como el uso de bi_emit_collect_to() para load_const en pan/bi, la eliminación de llamadas a blend_emit_descs() cuando no existe fragment shader en panvk/csf y el marcado de variables planas completas en pan/bi, lo que ayuda a evitar errores de interpolación.

Ian Romanick soluciona varias cuestiones relacionadas con las transformaciones algebraicas de NIR y la gestión de programas en Mesa. Entre sus cambios destacan la detección de F-strings que les faltaba la “f” en las reglas algebraicas, una corrección de segfaults en _mesa_delete_program y _mesa_reference_program_, y la añadidura de mecanismos para detectar precisamente esos F-strings mal formados.

Icenowy Zheng aporta una serie de arreglos centrados en Vulkan WSI y en el manejo de contextos GLES1/2: se evita destruir imágenes nunca creadas en el backend headless de Vulkan, se añade un workaround para GL_INVALID_OPERATION en draws de GLES 2.0, se arregla un GL_INVALID_OPERATION asociado al uso conjunto de GLES1/2 y Kopper, y se corrige otro caso de GL_INVALID_OPERATION al liberar un búfer en contextos GLES1/2.

El trabajo de Lionel Landwerlin se concentra en buena parte en ray queries y SIMD32 en la pila de Intel: añade la liberación pendiente de shaders en device_memory_report, asegura que puedan cargarse dos estructuras RT_DISPATCH_GLOBALS, incorpora tratamiento de divergencia para ray_query_global_intel en NIR, prepara la base para ray queries SIMD32, permite el spilling de ray queries en SIMD32, maneja el lowering de ciertos opcodes adicionales, habilita opcodes de topología en SIMD32, activa shaders de cómputo SIMD32 con ray queries y corrige el cálculo de derivadas en floats que no son de 32 bits.

Desde el lado de AMD, Marek Olšák corrige varios problemas en radeonsi y en utilidades de NIR: arregla la interpolación de color cuando finalize_nir se llama dos veces, evita un segfault en ac/lower_ngg_mesh al acceder fuera de los límites de out_variables, corrige aserciones ligeramente incorrectas en si_shader_ps, soluciona una clave de shader PS errónea relacionada con sample shading y repara fallos de aserción en nir/clip_cull_distance_utils cuando se utiliza GL_EXT_mesh_shader.

Mike Blumenkrantz continúa puliendo Zink con cambios como el uso correcto del layout GENERAL en borrados de texturas dinámicos, la eliminación de comprobaciones no operativas al reescribir operaciones de borrado, la creación de nuevas imágenes transitorias si el número de muestras no coincide y el establecimiento explícito de pipe_resource::next a nulo cuando se generan recursos transitorios.

Samuel Pitoiset aporta una batería de correcciones relacionadas con contadores de rendimiento, SPM y operaciones de copia en hardware AMD: corrige el broadcasting GRBM para bloques globales en ac/spm, desactiva ENABLE_PING_PONG_BIN_ORDER en GFX11.5 dentro de ac/cmdbuf, arregla copias únicamente de stencil en GFX9 bajo ac/sdma, corrige la captura de contadores de rendimiento usando SPM en RADV, retrasa la reserva de VMID en SQTT al momento de captura, hace que RADV meta use texturas 2D array para resoluciones de color con compute y corrige el cálculo de derivadas de cubemaps cuando el eje principal es negativo.

En lo referente a la capa WSI, Yiwei Zhang realiza mejoras orientadas a el manejo de dmabuf y la sincronización de presentación. Se endurecen las rutas de exportación que exigen soporte real de dmabuf en Zink, se añade respeto explícito a VK_SUBOPTIMAL_KHR devuelto por la adquisición de imágenes de WSI en Venus, se incorpora un workaround que tiene en cuenta ALIAS en la caché de requisitos de memoria de imágenes, se corrige la caché de requisitos de memoria para imágenes alias en Venus, se evita usar la etapa de host en ciertos blits hacia colas externas y se arreglan las condiciones de soporte de espera de presentación y creación de IDs de presentación en la capa Vulkan WSI.

Finalmente, el usuario llyyr contribuye con mejoras clave para entornos headless en Vulkan: se asegura de que VkSurfacePresentModeCompatibilityKHR se rellene correctamente, se añade un stub para VkSurfacePresentScalingCapabilitiesKHR en configuraciones sin pantalla y se implementa vkReleaseSwapchainImagesKHR para el backend headless, completando así el soporte de swapchains en escenarios sin salida de vídeo directa.

Impacto práctico en juegos y uso diario

Todos estos cambios en Mesa 25.3.4, aunque en muchos casos parezcan técnicos y muy específicos, se traducen en una experiencia más estable y pulida para quienes usan controladores de código abierto. Títulos como Resident Evil 4, WITCH ON THE HOLY NIGHT, Kingdom Come Deliverance 1 y otros que hacen uso intensivo de Vulkan, ray tracing, vkd3d-proton o características avanzadas de la GPU ven corregidos cuelgues, artefactos gráficos o comportamientos extraños.

En el caso de los usuarios de GPUs Intel, AMD o NVIDIA bajo la pila abierta, la suma de correcciones en ANV, RADV, NVK, Zink, Rusticl y WSI headless conforma un ecosistema donde juegos modernos, aplicaciones de renderizado y software de cómputo general funcionan con menos sobresaltos. Junto con las optimizaciones introducidas durante el ciclo de Mesa 25.3, se percibe una mejora notable en tiempos de carga de shaders, reducción de stuttering y mayor consistencia en la latencia.

Las plataformas basadas en ARM, SBCs y SoCs específicos también se benefician de la ampliación de soporte en V3D, Panfrost y PVR, así como de la aparición del driver Gallium para NPUs Arm Ethos, que abre la puerta a escenarios futuros donde tareas de inteligencia artificial y gráficos convivan de forma más integrada en Linux. Quienes trabajen con desarrollo embebido o dispositivos compactos verán una base más sólida sobre la que construir.

En conjunto, Mesa 25.3.4 cierra varias heridas abiertas tras 25.3.3 y consolida el camino de una serie 25.3 que ya venía cargada de novedades importantes. Sin necesidad de grandes titulares, el proyecto sigue empujando la pila gráfica de Linux hacia un terreno más maduro, donde cada pequeña corrección cuenta para que juegos recientes, hardware moderno y herramientas avanzadas funcionen de forma cada vez más fiable.