La llegada de Mesa 25.3.5 supone el último coletazo importante de la rama 25.3 antes de que la esperada serie 26.0 tome el relevo como nueva versión estable del stack gráfico. Aunque pueda parecer una actualización menor, estamos ante un punto de mantenimiento muy pulido que concentra un buen puñado de correcciones críticas pensadas para dar estabilidad máxima a quienes prefieren no vivir al filo de la navaja con las versiones más recientes.

Esta versión se centra en arreglar fallos, mejorar la fiabilidad de los drivers Vulkan (tanto en AMD como en Intel y Qualcomm), pulir aspectos de Vulkan Video, y añadir pequeñas correcciones en drivers más veteranos como R600. Además, se publica en un momento clave dentro del calendario de lanzamientos de Mesa, con un histórico de versiones muy activo que va encadenando ramas 23.x, 24.x y 25.x, y ya con las primeras candidatas de Mesa 26 rodando por ahí. Muchos de estos cambios remiten a nuevos drivers y ajustes en ramas previas que han ido allanando el camino.

Novedades clave de Mesa 25.3.5

La base de Mesa 25.3.5 está centrada en la estabilidad, pero eso no quiere decir que sea una actualización irrelevante. Entre las mejoras más notables están las relacionadas con Vulkan Video en los drivers RADV (AMD) e Intel ANV, así como múltiples arreglos de bugs distribuidos por varios drivers, incluyendo R600, TURNIP (Qualcomm Adreno) y NVK. En particular se recogen arreglos clave en RADV y soporte mejorado en códecs.

Tal y como detallan las notas y los anuncios de terceros, esta versión incorpora un «wide assortment of different fixes» para los drivers Vulkan de Intel y AMD, así como algún retoque para hardware Radeon antiguo. A ello se suman ajustes concretos en la forma de calcular tamaños de tiles para el códec de vídeo en RADV, correcciones de parámetros específicos como maxActiveReferencePictures en decodificación H.264 y una decisión bastante conservadora por parte del driver Intel ANV en lo referente a la codificación de vídeo con Vulkan; de hecho, al igual que en versiones previas como Mesa 25.2.6, se observa la tendencia a priorizar la estabilidad sobre la exposición temprana de funciones.

El resultado global es una versión que apunta de forma directa a quienes necesitan un entorno gráfico lo más estable posible, tanto en equipos de escritorio como en portátiles con GPU integrada, o en dispositivos que tiran de Qualcomm Adreno. Si vienes de 25.3.4 o anteriores dentro de la misma rama, tiene todo el sentido del mundo actualizar.

Cambios en RADV y Vulkan Video (AMD)

Una de las áreas más trabajadas en Mesa 25.3.5 es el soporte de Vulkan Video sobre RADV, el driver Vulkan para GPUs AMD dentro de Mesa. El texto original del anuncio comenta que ahora se utiliza un método «more reliable» para calcular los tamaños de tile, algo que resulta crucial para garantizar que la decodificación de vídeo funcione sin artefactos ni bloqueos extraños.

Este cambio responde a problemas detectados en el cálculo previo de esos tiles, que podían provocar errores en la reproducción de vídeo acelerada por GPU en determinadas combinaciones de hardware y códec. Al pasarse a un esquema más robusto de cálculo, se minimizan los riesgos de lecturas fuera de rango, corrupción de memoria o fallos sutiles que luego se traducen en glitches en el vídeo.

Además, se menciona de forma específica una corrección relacionada con maxActiveReferencePictures en la decodificación H.264 dentro del código de Vulkan Video de RADV. En códecs como H.264, la cantidad de imágenes de referencia simultáneamente activas es un parámetro clave para el correcto funcionamiento de la decodificación: si se gestiona mal, puede haber frames perdidos, tirones o incluso cuelgues del proceso.

Con estos ajustes, Mesa 25.3.5 apunta de manera directa a mejorar la experiencia de quienes utilizan Linux como plataforma multimedia y confían en la aceleración por GPU para reproducir contenidos H.264. No es un cambio vistoso a nivel de interfaz, pero sí muy importante de cara a la estabilidad en el día a día.

Intel ANV y la desactivación de la codificación de vídeo

En el lado de Intel, las notas destacan un movimiento llamativo: el driver Intel ANV deshabilita la codificación de vídeo vía Vulkan Video para las generaciones de hardware más recientes, al menos de forma temporal. Concretamente, se habla de Meteor Lake, las GPUs discretas Alchemist (Arc) y hardware aún más nuevo.

El motivo principal es que la implementación de Vulkan Video encode no ha sido suficientemente probada en esas plataformas. En lugar de exponer una funcionalidad potencialmente inestable a los usuarios, el equipo de Mesa ha optado por ocultarla hasta que esté mejor testeada y pulida. Es una decisión conservadora, pero muy sensata si lo que se busca es dar confianza a los administradores de sistemas y a usuarios avanzados; recuerde que recientemente se discutieron cambios relacionados con un parche muy importante para el driver Intel que también priorizaba la fiabilidad.

Esto quiere decir que, si tienes un portátil o sobremesa con Intel Meteor Lake o una GPU Arc y dependes de Mesa, en la versión 25.3.5 no verás disponible la parte de encode de Vulkan Video, aunque sí podrás aprovechar el resto de capacidades del driver ANV. Esta medida no afecta a la decodificación ni al uso «normal» de Vulkan para juegos y aplicaciones 3D.

Más allá de esta desactivación, también se integran varias correcciones de bugs en el driver ANV que no se detallan una a una en el resumen, pero que forman parte de ese «variety of other random bug fixes» mencionado. En la práctica, podemos esperar una mejora en estabilidad y en el cumplimiento estricto de la especificación Vulkan, lo que reduce el riesgo de crashes en juegos punteros o en benchmarks exigentes.

Mejoras generales en los drivers RADV y ANV

Además de los cambios concretos en Vulkan Video, el lanzamiento de Mesa 25.3.5 incluye un buen puñado de arreglos generales en los drivers Vulkan de AMD (RADV) e Intel (ANV). El anuncio habla de «a variety of other random bug fixes», que normalmente cubren desde pequeños fallos de validación hasta correcciones de regresiones introducidas en versiones anteriores.

En RADV, este tipo de correcciones suelen tener que ver con títulos concretos de juegos o aplicaciones que exhiben comportamientos raros (cuelgues, errores visuales, problemas de sincronización, etc.). Muchas veces, estas correcciones se documentan como patches específicos para algunos motores gráficos o para ciertas extensiones de Vulkan utilizadas de forma intensiva en juegos AAA.

En ANV, el enfoque es similar: reforzar el cumplimiento con la especificación Vulkan y garantizar que las optimizaciones de rendimiento no rompan nada. Es frecuente ver parches que evitan contentions de memoria, ajustes en el manejo de pipelines gráficos complejos o pequeñas optimizaciones que reducen el overhead del driver en determinadas situaciones.

La suma de todas estas pequeñas piezas convierte a 25.3.5 en una actualización clave para cualquier usuario que juegue en Linux con GPU AMD o Intel modernas, incluso aunque no le preocupe especialmente la parte de vídeo. A menudo, una simple corrección de sincronización puede marcar la diferencia entre un juego perfectamente estable y un infierno de cuelgues esporádicos.

Soporte para hardware antiguo: driver R600

Aunque buena parte del foco mediático cae sobre Vulkan y los GPUs actuales, esta versión también dedica atención a un viejo conocido: el driver R600 de Gallium3D. Este driver cubre las antiguas tarjetas AMD/ATI Radeon HD 2000 hasta HD 6000, hardware que sigue presente en muchos equipos reciclados, PCs secundarios o estaciones de trabajo veteranas.

Las notas indican que Mesa 25.3.5 integra «a few fixes» para ese driver, lo que significa que se siguen corrigiendo problemas puntuales incluso en hardware de hace más de una década. Esto refleja bastante bien la filosofía de Mesa: no abandonar del todo a los usuarios de GPUs antiguas, aunque evidentemente el grueso del desarrollo se centre en hardware moderno y en APIs como Vulkan.

En la práctica, estos arreglos pueden suponer que una distro reciente con Mesa actualizado continúe dando bajo nivel de incidencias en equipos con tarjetas Radeon HD antiguas, ya sea para tareas de escritorio, reproducción de vídeo o incluso juegos ligeros. No es un salto revolucionario, pero se agradece que la compatibilidad no se rompa de un día para otro.

TURNIP (Qualcomm Adreno), NVK y otros drivers

Mesa 25.3.5 también trae novedades para el ecosistema móvil y para el soporte de GPUs NVIDIA a través de drivers open source. En concreto, se mencionan varias correcciones en el driver TURNIP, responsable del soporte Vulkan para GPUs Qualcomm Adreno, muy habituales en teléfonos y algunos dispositivos ARM.

Este tipo de actualizaciones apuntan sobre todo a mejorar la estabilidad en sistemas basados en SoCs Qualcomm, que pueden estar ejecutando Linux convencional, Android u otras variantes. TURNIP ha ganado peso en los últimos años como alternativa open source potente para Vulkan en móviles, y cada bug corregido ayuda a que la experiencia sea menos dependiente de drivers propietarios.

Por otro lado, se habla de «a few NVK fixes», es decir, unos cuantos ajustes en NVK, el driver Vulkan open source para GPU NVIDIA dentro de Mesa que todavía se considera relativamente joven y en constante evolución. Estos arreglos suelen ir en la línea de mejorar compatibilidad con juegos y benchmarks, así como de cubrir huecos en la implementación de la API.

En conjunto, estas correcciones en TURNIP, NVK y otros drivers menores redondean el lanzamiento para que Mesa 25.3.5 no sea solo una actualización centrada en PC clásico, sino también en dispositivos ARM, portátiles ligeros y otras plataformas donde el soporte gráfico abierto es especialmente crítico.

Mesa 25.3.5 como parte de un ecosistema en movimiento

El lanzamiento de Mesa 25.3.5 no llega solo, sino acompañado y mencionado en contextos más amplios del ecosistema Linux. Algunas recopilaciones de noticias, como los resúmenes semanales tipo «Weekly Roundup» de medios especializados, suelen agruparlo junto a lanzamientos de otros proyectos clave como GParted, Transmission, GStreamer, OpenSSL, Proton, VirtualBox, Calibre, Tails, Linux Lite, Shotcut o TigerVNC.

Que Mesa aparezca en estas listas refleja su enorme importancia dentro del stack gráfico de Linux: casi cualquier distro moderna se apoya en sus drivers y en su implementación de OpenGL/Vulkan para acelerar escritorio, juegos y multimedia. Un simple «bug fix release» de Mesa puede tener un impacto mucho mayor que nuevas características de proyectos más pequeños.

Como complemento, el entorno de comunicación alrededor de Mesa incluye noticias breves en la web oficial, listas de correo para los anuncios de lanzamiento y actividad en redes sociales donde a veces se difunden las novedades. Si JavaScript está desactivado en el navegador, algunas de estas plataformas incluso te avisan de que actives JS o uses un navegador compatible, lo que deja ver la importancia que tiene hoy la web dinámica incluso en proyectos tan técnicos.

Por qué actualizar a Mesa 25.3.5

Si ya estás en la rama 25.3 de Mesa, la respuesta rápida es que tiene todo el sentido del mundo actualizar. Esta versión no rompe compatibilidades, no introduce cambios drásticos en APIs y se limita a corregir fallos, reducir riesgos y afinar comportamientos en drivers clave.

Quienes utilizan GPUs AMD con RADV se benefician de mejoras concretas en Vulkan Video y de correcciones generales que afectan tanto a juegos como a aplicaciones 3D. Los usuarios de Intel con ANV ven cómo se prioriza su estabilidad, aunque eso suponga renunciar temporalmente a la codificación de vídeo Vulkan en las plataformas más nuevas, hasta que esté todo más que probado.

Los propietarios de hardware antiguo Radeon HD 2000-6000 siguen recibiendo pequeños mimos a través del driver R600, mientras que los dispositivos con Qualcomm Adreno y las GPUs NVIDIA que tiran de NVK también notan un entorno un poco más robusto. El conjunto hace de 25.3.5 una actualización muy recomendable en casi cualquier escenario.

Además, teniendo en cuenta que Mesa 26.0 está a la vuelta de la esquina, mantenerse al día dentro de la rama 25.3 ayuda a que el salto a la próxima serie estable sea mucho más suave y predecible, sin arrastrar bugs viejos que ya están resueltos en el último punto de mantenimiento.

Con todo lo anterior sobre la mesa, se puede decir que Mesa 25.3.5 cierra con buen sabor de boca la etapa final de la rama 25.3: consolida el soporte para Vulkan Video en AMD, adopta una postura prudente con la codificación en Intel ANV, cuida a los usuarios de hardware antiguo mediante R600 y continúa puliendo drivers como TURNIP y NVK, todo ello enmarcado en un ciclo de lanzamientos frenético que prepara el terreno para Mesa 26.0 sin descuidar, ni un momento, la estabilidad del presente.

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.

Mesa 25.3.3 llega como una de esas actualizaciones que, sin hacer demasiado ruido, marcan la diferencia en el día a día de quienes juegan o trabajan con gráficos en Linux. Aunque se trata de un lanzamiento centrado en correcciones y estabilidad, se apoya sobre una base muy potente: toda la serie Mesa 25.3, que introdujo cambios importantes en Vulkan, OpenGL, controladores Gallium y soporte de hardware. Si usas Linux para jugar, desarrollar o ejecutar aplicaciones 3D, esta versión te interesa más de lo que parece a primera vista.

Esta entrega combina por un lado los grandes saltos funcionales de Mesa 25.3 y, por otro, el enfoque conservador de un punto de mantenimiento como Mesa 25.3.3, pensado para pulir errores, afinar el rendimiento y reforzar la compatibilidad. En este artículo repasamos a fondo qué aporta la serie 25.3 y qué corrige específicamente la versión 25.3.3: desde nuevas extensiones Vulkan y soporte avanzado de OpenGL 4.6 y Vulkan 1.4, hasta arreglos muy concretos que evitan cuelgues, fugas de memoria o fallos gráficos en juegos y aplicaciones reales.

Novedades generales de Mesa 25.3.3

La versión Mesa 25.3.3 se publica como un lanzamiento de mantenimiento de la rama 25.3, centrado en solucionar errores detectados desde la salida de Mesa 25.3.2. No introduce grandes características nuevas, sino que depura lo ya existente para que el conjunto sea más estable, fiable y consistente en distintas combinaciones de hardware y software.

En términos de API, Mesa 25.3.3 sigue ofreciendo una implementación completa de OpenGL 4.6, aunque el número de versión que reporta cada contexto depende del driver concreto y del tipo de contexto (core o de compatibilidad). Algunos controladores no cumplen todos los requisitos de OpenGL 4.6 y, por tanto, pueden anunciar una versión algo inferior, especialmente en contextos de compatibilidad. Además, el contexto con OpenGL 4.6 solo se expone cuando se solicita explícitamente al crearlo, lo que da algo más de control a las aplicaciones y evita sorpresas en software antiguo.

En el lado de Vulkan, Mesa 25.3.3 implementa la API Vulkan 1.4, de nuevo condicionada por cada driver. El valor devuelto en el campo apiVersion de VkPhysicalDeviceProperties puede ser distinto según el controlador en uso: algunos alcanzan Vulkan 1.4, otros se quedan en 1.3 o 1.2, pero toda la infraestructura común de Mesa ya está preparada para esta versión moderna de la API. Esta capacidad se complementa con extensiones y funciones añadidas en la rama 25.3, de las que hablaremos más adelante.

En términos de API, Mesa 25.3.3 sigue ofreciendo una implementación completa de OpenGL 4.6, con mejoras para Vulkan y OpenGL, aunque el número de versión que reporta cada contexto depende del driver concreto y del tipo de contexto (core o de compatibilidad). Algunos controladores no cumplen todos los requisitos de OpenGL 4.6 y, por tanto, pueden anunciar una versión algo inferior, especialmente en contextos de compatibilidad. Además, el contexto con OpenGL 4.6 solo se expone cuando se solicita explícitamente al crearlo, lo que da algo más de control a las aplicaciones y evita sorpresas en software antiguo.

Correcciones de errores y mejoras internas en Mesa 25.3.3

Uno de los problemas solucionados afecta al controlador iris (OpenGL para GPUs Intel modernas) con la extensión GL_ARB_texture_cube_map, que provocaba reflejos incorrectos en títulos antiguos como Unreal Tournament 2004. Este tipo de bugs, aunque parezcan menores por impactar en juegos veteranos, sigue siendo importante para quienes reutilizan hardware o mantienen bibliotecas de juegos clásicas.

También se aborda un fallo crítico relacionado con Ghost of Tsushima, donde se producían errores de memoria (page faults) bajo ciertas condiciones. Este tipo de problemas pueden traducirse en cierres inesperados, cuelgues o incluso efectos colaterales en el sistema, por lo que su corrección es clave para quienes utilizan Mesa y Proton/Steam Play con títulos AAA recientes.

En el ámbito de la compilación, Mesa 25.3.3 soluciona un bloqueo en la construcción del driver Gallium Ethos en sistemas de 32 bits, lo que devolvía coherencia a un entorno que, aunque minoritario, sigue existiendo en ciertos dispositivos y entornos embebidos. Además, se corrige un fallo en el controlador v3d (usado entre otros en Raspberry Pi) cuando se deshabilitaba ENABLE_SHADER_CACHE pero el código accedía igualmente al disco_cache, una incoherencia que podía hacer fallar la compilación o generar comportamientos indeterminados.

Otros ajustes destacados incluyen la corrección de fallos en los tests automáticos es1-ABI-check y es2-ABI-check, que verifican la compatibilidad binaria de las implementaciones OpenGL ES 1 y 2. Que estas pruebas funcionen correctamente es clave para asegurar que futuras actualizaciones no rompan aplicaciones existentes sin darse cuenta.

En la parte de drivers Vulkan aparece un problema particularmente delicado: la fragmentación de memoria de GPU en dispositivos con poca RAM cuando se activaba el sistema de “slab” en ANV (driver Vulkan de Intel). En entornos de memoria ajustada, esto llevaba a una utilización ineficiente de la memoria gráfica y potenciales problemas de estabilidad; la corrección introduce una gestión más cuidadosa de los recursos.

También se aborda un bug muy serio relacionado con la extensión GL_AMD_framebuffer_multisample_advanced, que podía llegar a congelar todo el sistema. Este tipo de fallo no afecta solo al juego o aplicación concreta, sino al escritorio completo, por lo que se consideran de máxima prioridad y se han resuelto en esta versión.

Por último, se corrige un error en el controlador panvk (Vulkan para cierta familia de GPUs Arm) relacionado con el manejo de FAU en cómputo (fau compute), que podía provocar resultados incorrectos o inestables en cargas de trabajo compute sobre estas GPUs. Aunque este tipo de drivers se usan mucho en sistemas integrados, cualquier fallo a nivel de shaders compute puede impactar en juegos, aplicaciones científicas o de IA.

Seguimiento de cambios y contribuciones en Mesa 25.3.3

La versión 25.3.3 llega acompañada por la habitual lista de cambios agrupados por autor, donde se refleja cómo decenas de desarrolladores van puliendo el proyecto con pequeños parches. Aunque muchos de esos commits parezcan triviales (por ejemplo, cambios en .pick_status.json para marcar parches como backportados), en realidad forman parte de la maquinaria que mantiene estable la rama.

Nombres como Ahmed Hesham, Alyssa Rosenzweig, Boris Brezillon, Dylan Baker, Emma Anholt, Georg Lehmann o Samuel Pitoiset firman desde actualizaciones de documentación (como la inclusión de checksums para versiones anteriores) hasta ajustes internos de drivers. En particular, varios parches de Dylan Baker actualizan los ficheros .pick_status.json, que indican qué commits se han ido trasladando desde la rama principal a la rama estable 25.3.x, incluyendo marcas explícitas de que ciertos cambios ya han sido incorporados.

Otros colaboradores, como Lucas Stach, Marek Olšák, Tapani Pälli o Yuxuan Shui, participan en parches dispersos que afectan a diferentes controladores y subsistemas. Aunque el listado simplificado de esta versión no detalla cada cambio uno por uno, sí deja claro el carácter colectivo y continuo del mantenimiento de Mesa: cada lanzamiento puntual es la suma de muchas contribuciones pequeñas que, en conjunto, sostienen la calidad del proyecto.

Impacto en juegos y experiencia con Proton

Un punto clave de la serie 25.3 y sus posteriores parches, incluida 25.3.3, es la mejora real y visible en juegos concretos. No se trata solo de benchmarks sintéticos: se han abordado problemas que afectaban a títulos muy populares y recientes.

La lista de juegos beneficiados incluye nombres como Indiana Jones y el Gran Círculo, Hades 2, Dying Light, Baldur’s Gate 3, Cyberpunk 2077 o Shadow of the Tomb Raider, donde se han corregido bugs de renderizado, fallos de compatibilidad o pequeñas inestabilidades que empañaban la experiencia. A esto se suman muchos otros títulos: desde grandes superproducciones como Horizon Forbidden West Complete Edition, Assassin’s Creed Valhalla, Final Fantasy XVI o Red Dead Redemption 2, hasta juegos de culto como Hollow Knight: Silksong o The Witcher 3.

La lista se amplía aún más con Penumbra: Overture, Borderlands 4, Resident Evil 4: Separate Ways, Doom: The Dark Ages, Endless Legend 2, No Man’s Sky, Age of Wonders 4, Call of the Wild: The Angler, Elite Dangerous, Midnight Club 3, Dragon Age: The Veilguard, Ratchet & Clank, Counter‑Strike 2, Ghost of Tsushima, Like a Dragon: Infinite Wealth y otros muchos. En la mayoría de estos casos, los cambios se traducen en menos artefactos visuales, menos cuelgues, mejor rendimiento sostenido o una reducción del stuttering provocado por compilación de shaders en caliente.

Para quienes juegan vía Proton/Steam Play, la serie 25.3 ha sido especialmente positiva: se han aplicado correcciones específicas en ANV (Intel) para títulos Direct3D ejecutados sobre Vulkan, reduciendo glitches y fallos molestos. Junto con las optimizaciones en RADV y los avances en NVK, esto hace que el combo Linux + Proton siga ganando terreno como plataforma de juego viable frente a Windows, especialmente en equipos con GPUs de Intel, AMD y NVIDIA soportadas por Mesa.

Mirando el conjunto, la serie Mesa 25.3 y su actualización 25.3.3 representan una combinación muy potente: por un lado, grandes saltos en extensiones Vulkan, mejoras en OpenGL, nuevos controladores Gallium, soporte ampliado de hardware y herramientas avanzadas para desarrolladores; por otro, una capa sólida de correcciones de errores que se notan directamente en juegos como Ghost of Tsushima o Unreal Tournament 2004, así como en el comportamiento general de drivers como ANV, RADV, NVK, PanVK, v3d, Panfrost o PVR. Todo ello mantiene a Mesa como pieza central de la pila gráfica de Linux, con un desarrollo vivo, colaborativo y claramente orientado a que jugar y trabajar con gráficos en este sistema operativo sea cada vez menos una aventura y más una experiencia cómoda y fluida.

La nueva versión Fwupd 2.0.18 ya está disponible como actualización de mantenimiento dentro de la rama 2.0 de esta herramienta abierta para gestionar el firmware en sistemas GNU/Linux, precedida por la versión Fwupd 2.0.17. Este lanzamiento se centra en pulir la experiencia de actualización, ampliar la compatibilidad con más dispositivos y mejorar el manejo de situaciones habituales como los reinicios requeridos tras instalar nuevo firmware.

En un momento en el que las actualizaciones de firmware son clave para la seguridad, estabilidad y soporte de hardware Fwupd 2.0.18 avanza en ofrecer un proceso más ágil y menos problemático, tanto para equipos de sobremesa y portátiles como para periféricos y estaciones de acoplamiento.

Nuevos dispositivos compatibles con Fwupd 2.0.18

Una de las novedades más visibles de Fwupd 2.0.18 es la incorporación de soporte para nuevos dispositivos de hardware que se suman al catálogo ya disponible a través del Linux Vendor Firmware Service (LVFS). Entre los equipos y periféricos añadidos destacan el Lenovo Legion Go 2, reconocido como dispositivo HID, el hub HP Portable USB-C 4K HDMI y diversos dispositivos Synaptics HapticsPad.

La inclusión de estos equipos resulta relevante para usuarios de portátiles, docks USB-C y mandos o paneles táctiles que buscan mantener todo su hardware actualizado desde Linux, sin depender de herramientas externas o sistemas operativos adicionales. Esta integración continúa la línea de trabajo de LVFS como repositorio centralizado de firmware para múltiples marcas.

Gestión mejorada de reinicios tras actualizaciones

Fwupd 2.0.18 introduce varios cambios pensados para gestionar mejor los casos en los que una actualización de firmware exige un reinicio del equipo. La herramienta puede ahora mostrar un mensaje MOTD (Message of the Day) específico para aquellos dispositivos que necesitan reiniciarse tras aplicar actualizaciones en modo «staged».

Además, la nueva versión es capaz de crear de forma automática un fichero «reboot-required» cuando el firmware instalado requiere reinicio, algo que facilita la integración con scripts de administración de sistemas y con políticas de mantenimiento en organizaciones. También se ha afinado el comportamiento al actualizar estaciones de acoplamiento USI, permitiendo completar el proceso sin necesidad de desconectar y volver a conectar manualmente el dispositivo.

Fwupd 2.0.18 introduce mejoras internas y rendimiento del motor de firmware

Más allá de las nuevas compatibilidades, Fwupd 2.0.18 se centra en optimizar su funcionamiento interno. Una de las mejoras señaladas es el incremento notable en la velocidad de búsqueda de flujos de firmware, lo que reduce el tiempo necesario para localizar e identificar actualizaciones disponibles en sistemas con múltiples dispositivos o repositorios.

Esta versión también añade un problema específico para dispositivos MTD cuando se detecta que el bloqueo Intel SPI BIOS está activado, reforzando así las comprobaciones de seguridad a la hora de gestionar firmware del sistema. Paralelamente, se incorpora soporte para cambiar el nombre de los dispositivos hijos cuando se emplea la opción PARENT_NAME_PREFIX, lo que mejora la claridad y consistencia en la identificación de hardware dentro del sistema.

Avances en soporte UEFI, BIOS y arquitecturas

En el terreno UEFI, Fwupd 2.0.18 ajusta el tratamiento de varios elementos clave. A partir de ahora, la herramienta analiza correctamente la estructura EFI_CAPSULE_RESULT_VARIABLE_HEADER, evitando interpretaciones incorrectas de los resultados de las cápsulas UEFI tras las actualizaciones.

Se ha limitado además la conversión del campo de versión de tipo uint32_t al formato de versión de dispositivo exclusivamente a los dispositivos UEFI, lo que reduce posibles incoherencias con otros tipos de hardware. Otra mejora importante es la caída controlada al uso de la versión SMBIOS para los dispositivos BIOS basados en MTD cuando es necesario, garantizando una detección más fiable en situaciones donde los datos de firmware no son homogéneos.

En lo que respecta a las arquitecturas, Fwupd ahora establece el valor de PlatformArchitecture usando la arquitectura de CPU real en máquinas RISC-V, lo que permite integraciones más precisas con herramientas de inventario, monitorización y despliegue de firmware en sistemas que utilizan esta plataforma emergente.

Refinamiento de UpdateCapsule y funcionamiento sin Secure Boot

La función UpdateCapsule, empleada para aplicar cápsulas de firmware en sistemas que utilizan UEFI, también recibe atención en este lanzamiento. Fwupd 2.0.18 mejora su funcionamiento en equipos que no cuentan con Secure Boot habilitado, ampliando así el rango de sistemas que pueden beneficiarse de actualizaciones automatizadas sin requerir cambios complejos en la configuración del firmware.

Este refuerzo del soporte en escenarios sin Secure Boot es de interés para muchas instalaciones de Linux en entornos mixtos o heredados, donde el arranque seguro no siempre está activado, pero sí se necesita un método fiable para mantener al día el firmware de la placa base y otros componentes.

Fwupd 2.0.18 y las mejoras en herramientas, detección de entorno y tiempos de espera

En el plano de las herramientas complementarias, se ha ajustado el comportamiento del comando fwupdtool para que solo intercepte la señal SIGINT cuando resulta estrictamente necesario, evitando interferencias con otros procesos o scripts que gestionen señales en paralelo.

Asimismo, se ha introducido un tiempo de espera más razonable en las peticiones HID qc-s5gen2, con el objetivo de reducir bloqueos o esperas excesivas en ciertos dispositivos. El código responsable de detectar si el sistema se ejecuta en un hipervisor o dentro de un contenedor ha sido también reestructurado, de modo que esa lógica pueda aprovecharse desde distintos complementos (plugins) de Fwupd.

Correcciones de errores y robustez general

La versión 2.0.18 incorpora un amplio conjunto de correcciones con impacto directo en la estabilidad. Entre ellas se incluye una mejora en el análisis de los descriptores USB BOS, que son claves para identificar las capacidades avanzadas de los dispositivos USB durante las operaciones de actualización de firmware.

También se han corregido los flags de cápsula específicos para x86_64 al desplegar firmware UEFI, asegurando que las actualizaciones en sistemas de 64 bits se apliquen con los parámetros adecuados. La compatibilidad de las páginas de manual con herramientas como apropos y whatis se ha ajustado, facilitando que administradores y usuarios encuentren rápidamente la documentación relevante desde la línea de comandos.

Otras correcciones abordan incidencias con las actualizaciones de dispositivos Huddly cuando se producen cambios de versión mayor, así como un fallo que provocaba cierres inesperados al intentar registrar una emulación i2c. Todo ello contribuye a una experiencia más sólida y predecible en el uso diario del servicio.

Contexto del proyecto LVFS y apoyo de fabricantes

El desarrollo de Fwupd está estrechamente vinculado al Linux Vendor Firmware Service (LVFS), plataforma que actúa como punto central para distribuir firmware a millones de equipos Linux. LVFS supera ya ampliamente las cien millones de descargas de firmware, impulsando que más fabricantes de hardware se involucren y colaboren, bien mediante aportación de ingeniería o mediante acuerdos de patrocinio económico.

En este contexto, Framework Computer se ha convertido en uno de los nuevos patrocinadores destacados del ecosistema LVFS/Fwupd, bajo un modelo de cuotas anuales que ayuda a sostener el proyecto. Esta colaboración se suma a la aportación continuada de Red Hat, que emplea al desarrollador principal Richard Hughes, y al soporte de la Linux Foundation, que acoge el proyecto bajo su paraguas. También participan contribuyentes relevantes como AMD a través de su personal de ingeniería, y empresas interesadas como Dell quiso llevar las actualizaciones a Linux.

Más allá de la parte económica, Framework ha ejercido presión sobre sus proveedores para que integren soporte nativo de Fwupd y LVFS en sus productos, con el objetivo de simplificar la actualización de firmware en portátiles como Framework 16 y otros equipos compatibles con Linux. Esta dinámica empuja al resto de fabricantes a ofrecer una experiencia de actualización más homogénea y accesible para usuarios y empresas.

Disponibilidad de Fwupd 2.0.18 para usuarios de Linux

Fwupd 2.0.18 se distribuye como tarball de código fuente a través de GitHub, donde también se puede consultar el listado completo de cambios y notas de la versión. No obstante, la vía recomendada sigue siendo la instalación y actualización desde los repositorios estables de la distribución GNU/Linux utilizada, ya sea mediante gestor gráfico o por línea de comandos.

Distintas distribuciones irán incorporando Fwupd 2.0.18 en sus canales estables a medida que se completen las pruebas e integraciones, lo que permitirá recibir automáticamente las novedades de esta versión junto al resto de actualizaciones habituales del sistema. De este modo, tanto equipos domésticos como estaciones de trabajo y servidores podrán beneficiarse de los avances en compatibilidad, rendimiento y fiabilidad sin cambios drásticos en su flujo de administración.

Con esta actualización, Fwupd consolida su papel como herramienta de referencia para mantener el firmware al día en entornos Linux, combinando un soporte creciente de hardware, mejoras en la gestión de reinicios, optimizaciones en UEFI y BIOS y un esfuerzo constante por pulir errores. En paralelo, el refuerzo del ecosistema LVFS mediante la implicación de fabricantes y organizaciones ayuda a construir una base más sólida para que usuarios, empresas y administraciones públicas puedan gestionar sus dispositivos de forma más segura, transparente y centralizada.