El ecosistema del kernel de Linux vuelve a mover ficha en el terreno del soporte a largo plazo (LTS). La política de mantenimiento de versiones estables, clave para servidores, dispositivos embebidos y distribuciones empresariales en España y el resto de Europa, se ajusta de nuevo tras la decisión de ampliar la vida útil de varias ramas recientes del kernel.

Con la última actualización de los calendarios de mantenimiento, el responsable de las series estables, Greg Kroah-Hartman, ha decidido prolongar el periodo de soporte de los kernels Linux 6.18, 6.12 y 6.6. Esta ampliación de plazos no es un simple detalle técnico: condiciona las decisiones de administradores de sistemas, proveedores de servicios cloud y responsables de TI que necesitan estabilidad durante años.

Revisión del calendario LTS: así quedan las versiones clave

En el nuevo esquema publicado por el mantenedor del kernel estable, se concreta el horizonte de soporte para varias versiones relevantes, con una foto clara del estado actual de las ramas LTS. Según el propio Kroah-Hartman, la situación pasa a ser la siguiente, reflejando el compromiso con un ciclo de vida más largo en las ediciones más recientes:

• Linux 5.10: soporte fijado en un total de 6 años.
• Linux 5.15: periodo de mantenimiento establecido en 5 años.
• Linux 6.6: se asegura ahora un ciclo de 4 años.
• Linux 6.12: también contará con 4 años de soporte oficial.
• Linux 6.18: tendrá mantenimiento durante al menos 3 años, con posibilidad de prolongarse si hay demanda suficiente.

Esta actualización de plazos llega tras múltiples conversaciones con empresas, grupos de trabajo y otros mantenedores del núcleo, que han presionado para conservar durante más tiempo determinadas versiones críticas para sus productos y distribuciones.

Extensión del soporte: nuevos finales de vida para 6.18, 6.12 y 6.6

Uno de los cambios más comentados es la prolongación concreta de los periodos de fin de vida (EOL) de las ramas LTS más recientes. A partir de ahora, Linux 6.18 LTS amplía su horizonte de mantenimiento hasta diciembre de 2027, ganando un año extra respecto al plan anterior. Además, se deja la puerta abierta a extender ese plazo si el interés por parte de la industria y la comunidad se mantiene alto.

El kernel Linux 6.12 LTS es, sin embargo, el mejor parado. Su fecha de fin de soporte se alarga dos años completos, pasando de diciembre de 2026 a algún momento de 2028. Este salto lo sitúa como una de las ramas más estratégicas para los próximos años, especialmente para distribuciones con un fuerte enfoque en estabilidad en Europa, donde ciclos largos son habituales en la administración pública y en entornos corporativos.

En paralelo, Linux 6.6 LTS también ve ampliada su vida útil. En lugar de finalizar en 2026, como estaba inicialmente previsto, su soporte se extiende hasta finales de 2027. Este cambio otorga un margen adicional a quienes ya han apostado por 6.6 como base para infraestructuras críticas, tanto en centros de datos como en dispositivos de red y sistemas embebidos.

Frente a estos cambios, las ramas 5.10 y 5.15 mantienen sus planes originales de soporte, con 6 y 5 años respectivamente, sin modificaciones en sus EOL. El foco de la revisión ha estado claramente en las series de la familia 6.x más recientes.

La realidad del soporte LTS: no se puede mantener todo para siempre

Aunque la comunidad del software libre tiene fama de cuidar sus proyectos durante muchos años, incluso después de nuevas publicaciones, existe un límite práctico. Mantener un sistema operativo y su kernel indefinidamente no es viable, especialmente cuando se acumulan cambios de seguridad, nuevas arquitecturas y requisitos de hardware.

Por este motivo, cada versión del kernel Linux cuenta con una fecha de fin de vida a partir de la cual deja de recibir parches oficiales. Esta caducidad obliga a planificar migraciones y actualizaciones, pero a cambio permite concentrar recursos en las ramas que realmente se utilizan en producción. Las extensiones anunciadas ahora son una forma de ajustar ese equilibrio según la adopción real de cada versión.

En la práctica, para administradores de sistemas en España o en otros países europeos, esto significa que pueden permanecer en un mismo kernel LTS durante varios años sin necesidad de saltar continuamente a ediciones más recientes. Las ampliaciones para 6.6, 6.12 y 6.18 ofrecen más margen para alinear las actualizaciones con ventanas de mantenimiento, contratos de soporte y requisitos regulatorios.

Por qué 6.12 LTS se convierte en la estrella del nuevo plan

Entre todas las versiones afectadas, la que más protagonismo gana es Linux 6.12 LTS. No solo recibe la ampliación más generosa de su periodo de soporte, sino que se está consolidando como una base tecnológica clave en varios frentes. La razón principal es que esta versión ha logrado congregar un interés muy fuerte tanto de grandes empresas como de proyectos comunitarios de primer nivel.

Una de las grandes novedades que llegaron con 6.12 fue la incorporación de PREEMPT_RT como parte del kernel principal, una mejora en el comportamiento en tiempo real que ha tardado unos veinte años en completarse. Este avance es especialmente relevante para sectores que exigen baja latencia y respuesta determinista, como la industria, las telecomunicaciones, el ámbito sanitario o la automoción, donde Europa tiene una presencia notable de fabricantes y proveedores.

A esto se suma que Red Hat Enterprise Linux 10 (RHEL 10) también se apoyará en 6.12, lo que multiplica la presión para un soporte extendido. Cuando grandes distribuciones empresariales basan sus ciclos de vida en un kernel concreto, resulta lógico que se solicite una ventana de mantenimiento acorde, que se mida en años y no en meses.

La versión 6.12 ha recibido incluso atención en el campo del hardware de consumo, con soporte para dispositivos como Raspberry Pi 5. Esto la coloca en una posición interesante para proyectos educativos, makers y pequeñas empresas que utilicen estas placas como parte de sus soluciones, también muy habituales en Europa en ámbitos como la automatización ligera o la monitorización remota.

Un modelo de soporte guiado por la adopción y el compromiso

Greg Kroah-Hartman ha dejado claro que no concede ampliaciones de soporte de forma indiscriminada. La decisión de prolongar la vida de una rama LTS depende de si las compañías y grupos de usuarios la adoptan y contribuyen activamente a su mantenimiento. En otras palabras, para que un kernel LTS reciba años extra de soporte, tiene que tener detrás una comunidad e industria dispuestas a implicarse.

En este contexto, la extensión del soporte para las versiones 6.6, 6.12 y 6.18 es una señal de que estas ramas han logrado un nivel de implantación relevante. La combinación de uso en distribuciones de referencia, despliegues en centros de datos, integración en productos comerciales y su utilización en sistemas de misión crítica ha pesado en la decisión.

Este modelo de soporte, en el que el calendario de EOL se ajusta en función del grado de adopción real, resulta especialmente útil para las organizaciones europeas que planifican a largo plazo. Permite alinear la elección de un kernel LTS con la estrategia tecnológica, sabiendo que si la versión se consolida como estándar de facto, el ecosistema de mantenimiento tenderá a reforzarse.

Impacto práctico para distribuciones y entornos de producción

En entornos de producción, esto se traduce en que las empresas pueden optar por una rama como 6.12 LTS o 6.6 LTS sabiendo que no tendrán que precipitar una migración al poco tiempo. Esto es especialmente importante en sectores regulados o con altos requisitos de certificación, donde los cambios de versión implican validaciones, auditorías y pruebas extensas.

Para los responsables de sistemas que gestionan infraestructuras mixtas en Europa, la combinación de kernels LTS con largos periodos de estabilidad y un flujo continuo de correcciones de seguridad resulta atractiva. Permite adoptar una estrategia de «menos saltos, pero mejor planificados», algo que encaja con la realidad de muchas organizaciones que no pueden permitirse sorpresas en producción.

Con este ajuste en los planes de soporte, el panorama del Linux LTS extended ofrece ahora más opciones para quienes necesitan estabilidad a medio y largo plazo. La ampliación de los ciclos de vida de 6.6, 6.12 y 6.18 refuerza la idea de que, cuando comunidad e industria reman en la misma dirección, el calendario del kernel puede adaptarse a esas necesidades, proporcionando un margen adicional para planificar despliegues, actualizaciones y estrategias de mantenimiento con menos prisas.

from Linux Adictos https://ift.tt/3EXaUMx
via IFTTT

La última entrega del conocido framework multimedia de código abierto GStreamer ya se puede descargar como paquete fuente gstreamer-1.28.1.tar.xz a través del archivo especializado Fossies. Esta publicación consolida a GStreamer como una de las piezas clave en la construcción de tuberías de audio y vídeo en entornos GNU/Linux, BSD y otras plataformas ampliamente utilizadas en Europa y España, tanto en escritorio como en servidores y dispositivos embebidos.

El archivo alojado en Fossies reproduce el contenido del proyecto original hospedado en gstreamer.freedesktop.org, pero añade servicios adicionales pensados para desarrolladores y administradores de sistemas: informes de diferencias entre versiones, análisis de conteo de líneas de código, revisión ortográfica del código fuente y documentación generada con Doxygen. Todo ello facilita revisar qué trae exactamente esta versión 1.28.1, validar cambios y preparar integraciones en distribuciones o proyectos internos.

Qué es GStreamer y qué incluye la versión 1.28.1

GStreamer es una biblioteca diseñada para crear gráficos de procesamiento multimedia, es decir, cadenas de elementos (plugins) que permiten desde la simple reproducción de Ogg/Vorbis hasta flujos complejos de mezcla de audio, edición no lineal de vídeo o streaming en tiempo real. El paquete 1.28.1 proporciona el núcleo de la librería, junto a un conjunto amplio de componentes básicos, utilidades y herramientas de línea de comandos necesarias para desarrollar y depurar estas tuberías multimedia.

Dentro del archivo comprimido se encuentran los ficheros habituales de cualquier proyecto maduro: un extenso ChangeLog con los cambios acumulados, los textos de licencia (COPYING), los documentos de mantenimiento (MAINTAINERS) y varios README orientados a usos específicos como la vinculación estática o la construcción de la biblioteca.

La estructura interna del paquete revela una separación clara entre núcleo, librerías complementarias y plugins. El directorio gst/ alberga el corazón del framework (gestión de elementos, pads, buffers, mensajes y reloj interno), mientras que el conjunto de librerías en libs/gst/ proporciona bloques listos para reutilizar en proyectos de terceros: utilidades de base, control, networking y un sistema de pruebas propio.

Librerías base, control y red incluidas en el paquete

El contenido de libs/gst/base/ reúne las librerías fundamentales sobre las que se apoyan la mayoría de elementos de GStreamer: adaptadores para manejo de datos (gstadapter), colas de mensajes y datos (gstqueuearray, gstdataqueue), parsers genéricos, elementos base de entrada (gstbasesrc), salida (gstbasesink) y transformación (gstbasetransform), así como utilidades para lectura y escritura de bits y bytes. Estas piezas sirven tanto a los plugins oficiales como a los módulos desarrollados por terceros que se integran en productos multimedia en España y el resto de Europa.

En el ámbito del control, el árbol libs/gst/controller/ incorpora mecanismos como fuentes de control por interpolación, sonidos LFO, valores temporizados y bindings ARGB. Estas herramientas permiten automatizar parámetros de filtros, volúmenes o efectos en el tiempo, lo que resulta especialmente útil para aplicaciones de producción audiovisual, radio por Internet o herramientas de edición que se apoyan en GStreamer como motor.

Por su parte, la librería de red ubicada en libs/gst/net/ proporciona relojes de red, sincronización PTP, soporte NTP y metadatos de red. Ficheros como gstnetclientclock.c, gstnettimeprovider.c, gstptpclock.c o gstntppacket.c evidencian que esta versión sigue apostando por la sincronización precisa en entornos distribuidos, clave para streaming de baja latencia o producciones remotas, escenarios cada vez más habituales también en broadcasters y proveedores de servicios OTT europeos.

Plugins esenciales y elementos del núcleo

El directorio plugins/elements/ concentra un buen número de elementos básicos de GStreamer que forman la columna vertebral de cualquier pipeline: fuentes y sumideros de archivos (filesrc, filesink), fuentes y destinos de descriptores de fichero (fdsrc, fdsink), colas (queue, queue2, multiqueue), filtros de capacidades (capsfilter), elementos de replicación (tee) y selección de flujo (inputselector, outputselector), entre otros.

La versión 1.28.1 incluye también elementos orientados a tareas más específicas como buffer de descarga para streaming (gstdownloadbuffer), lectura de datos desde URIs (dataurisrc), gestión de archivos dispersos (sparsefile) o demultiplexado de identificadores de flujo (streamiddemux). Estos componentes permiten que aplicaciones de escritorio, servicios web y soluciones embebidas construidas en España o en el resto de Europa puedan adaptar sus pipelines a distintos protocolos y necesidades de red sin depender de soluciones cerradas.

Junto a los elementos de datos, los plugins trazadores en plugins/tracers/ aportan herramientas para medir y analizar latencias, uso de memoria, consumo de CPU, fugas de recursos y estadísticas internas. Archivos como gstlatency.c, gststats.c, gstleaks.c o gstrusage.c se integran con el sistema de tracing de GStreamer para ofrecer una visión detallada del comportamiento en producción, lo que facilita la optimización de pipelines complejos en infraestructuras de streaming o plataformas de vídeo bajo demanda.

Herramientas de línea de comandos y soporte para desarrolladores

Además de las bibliotecas y plugins, el paquete gstreamer-1.28.1 incorpora varias herramientas de línea de comandos ampliamente utilizadas por desarrolladores, integradores y administradores de sistemas. Entre ellas destacan gst-inspect para inspeccionar plugins y elementos disponibles, gst-launch para construir y ejecutar pipelines desde la terminal, gst-stats para recopilar métricas y gst-typefind para detectar tipos de medios a partir de datos de entrada.

Estas utilidades vienen acompañadas de scripts de autocompletado para Bash, lo que agiliza el trabajo diario al probar configuraciones o depurar problemas en sistemas Linux. En el paquete se incluyen archivos bajo data/bash-completion/ que proporcionan completado automático de comandos y opciones, una ayuda práctica para técnicos y desarrolladores que trabajan con GStreamer de forma intensiva.

En el plano del desarrollo, se suministran múltiples ficheros de integración con sistemas de construcción: un módulo CMake (cmake/FindGStreamer.cmake), reglas para Meson (meson.build distribuidos por todo el árbol) y scripts auxiliares de distribución y empaquetado en el directorio scripts/. Este enfoque facilita que proyectos europeos basados en distintos entornos de compilación puedan detectar y enlazar GStreamer sin mayores complicaciones.

La nueva publicación de gstreamer-1.28.1 en Fossies ofrece a la comunidad europea y española un paquete fuente completo, bien documentado y fácil de integrar, con todo lo necesario para compilar, probar y desplegar el framework multimedia en una amplia variedad de entornos. Entre la organización del código, la abundante documentación, los sistemas de pruebas, el soporte de red y los servicios de verificación, este lanzamiento refuerza el papel de GStreamer como base tecnológica sólida para proyectos de audio y vídeo en el ecosistema del software libre.

from Linux Adictos https://ift.tt/soIXKNw
via IFTTT

Si juegas en Linux y te va la arqueología de los videojuegos, el nombre D7VK 1.4 seguramente te empiece a sonar cada vez más. Esta pequeña gran capa de traducción se ha convertido en una pieza clave para disfrutar de títulos clásicos basados en Direct3D 5, 6 y 7 a través de Vulkan, normalmente usando Wine o Proton como base. Además, llega en un contexto en el que DXVK también fue evolucionando en su propia versión 1.4, reforzando todo el ecosistema de traducción DirectX → Vulkan.

En las siguientes líneas vamos a repasar las novedades más importantes de D7VK 1.4, cómo encaja dentro del ecosistema DXVK/Wine, qué aporta a nivel de compatibilidad y rendimiento con juegos antiguos, qué limitaciones tiene y cómo puedes empezar a usarlo en tu sistema Linux (e incluso en Windows, aunque sea un uso secundario). También veremos de pasada las claves de DXVK 1.4, porque muchas ideas y conceptos son compartidos y se complementan.

¿Qué es exactamente D7VK y qué problema resuelve?

D7VK es una capa de traducción basada en Vulkan pensada para ejecutar aplicaciones y juegos 3D antiguos que utilizan Direct3D 7, 6 y 5 sobre Linux mediante Wine. En lugar de implementar desde cero todo el stack de Direct3D y DirectDraw, D7VK se apoya en el backend de D3D9 de DXVK y en la implementación de DDraw de Wine (o incluso en la nativa de Windows) para actuar como un proxy minimalista entre ambos mundos.

De forma simplificada, podríamos decir que D7VK hace de “intérprete” entre los viejos juegos Direct3D 5/6/7 y DXVK, que a su vez traduce todo a Vulkan. De esta forma, muchos títulos clásicos pueden aprovechar las ventajas de Vulkan (menor sobrecarga, mejor uso de la CPU, mejor gestión de recursos) sin que sus desarrolladores tengan que tocar una sola línea de código.

Es importante entender que el objetivo central de D7VK es ofrecer compatibilidad decente para D3D7, añadiendo soporte “experimental” para D3D6 y D3D5, precisamente porque cuanto más atrás se retrocede en la historia de DirectX, más “malditas” se vuelven las APIs y más raras son sus interacciones con DDraw y GDI.

Arquitectura y alcance de D7VK

La arquitectura de D7VK se basa en un enfoque muy pragmático: se apoya en DXVK (sobre todo en el backend de D3D9) y en el DDraw de Wine para construir una capa fina que implemente lo justo y necesario de D3D7/6/5. En lugar de reescribir DirectDraw y todas las APIs anteriores a D3D8, integra lo mínimo indispensable para que los juegos puedan comunicarse correctamente con DXVK.

Esto significa que no se pretende cubrir todos los recovecos más oscuros de DDraw, especialmente en lo referente a aplicaciones que mezclan sin pudor D3D con GDI o con distintas versiones de DirectX. En esos casos, el propio autor de D7VK recomienda sin tapujos tirar de WineD3D, que aunque sea algo menos eficiente en rendimiento, implementa prácticamente todo y gestiona mucho mejor esas interacciones “malditas”.

Al apoyarse en DXVK para D3D9, todas las opciones de configuración de DXVK para D3D9 resultan aplicables a D7VK, incluyendo parámetros como límites de FPS, control del VSync, HUD con estadísticas de rendimiento o ajustes de comportamiento internos. D7VK hereda así buena parte de la madurez y rendimiento que DXVK ha ido ganando a lo largo de los años.

Novedades más destacadas de D7VK 1.4

La versión 1.4 de D7VK introduce una serie de mejoras clave orientadas a la compatibilidad con juegos concretos y a pulir pequeños detalles del comportamiento gráfico. No hay un cambio radical de arquitectura, pero sí un conjunto de avances que, sumados, hacen que bastantes títulos “problemáticos” pasen a ser plenamente jugables.

Soporte de color key transparency

Una de las grandes estrellas de D7VK 1.4 es la implementación del soporte para color key transparency, una técnica muy usada en los inicios de Direct3D como alternativa barata al alpha testing. En lugar de canales alfa, se usaba un color específico para marcar píxeles transparentes, lo que con traducciones incompletas acababa generando bloques de color opacos donde debería haber transparencia.

Gracias al trabajo de la comunidad, especialmente de @CkNoSFeRaTU, ahora D7VK es capaz de manejar correctamente ese tipo de transparencia por color clave. Esto soluciona los artefactos de color sólido que aparecían en títulos como Arx Fatalis, Messiah, Darkstone, Divine Divinity, Mortal Kombat 4 y un buen puñado de juegos más que tiraron de este truco gráfico en su momento.

Mejor interoperabilidad con DDraw y juegos “cabezones”

Otro frente donde se ha avanzado bastante es en la consolidación de la interoperabilidad entre DDraw y las distintas versiones soportadas de D3D. Los antiguos APIs de DirectDraw y Direct3D se entremezclaban de formas muy poco ortodoxas, y muchas veces los juegos hacían cosas que, desde la perspectiva actual, no tienen ningún sentido.

En D7VK 1.4 se ha dedicado bastante trabajo a unificar y robustecer la forma en que se gestionan esas interacciones entre DDraw y D3D7/6/5, lo que se traduce en que juegos como Plants vs Zombies y otros títulos de PopCap de la misma época hayan pasado de ser inestables o injugables a funcionar correctamente.

También gracias a contribuciones de la comunidad se han corregido bugs relacionados con la instanciación de DDraw vía IClassFactory, fallo que impedía el funcionamiento de juegos como Re-Volt y Sea Dogs. Ahora estos títulos entran en la categoría de jugables, lo que amplía aún más la biblioteca de clásicos que pueden ejecutarse sobre D7VK sin dramas.

Mejoras de profundidad, limpieza y correcciones para juegos concretos

Aprovechando pistas aportadas por colaboradores como @Trass3r, en D7VK 1.4 se ha añadido soporte para clears de profundidad iniciados desde DDraw. Esta característica, que puede sonar bastante específica, es clave para que algunos juegos gestionen correctamente su buffer de profundidad y no muestren glitches de z-fighting o elementos mal dibujados.

Además, se ha incorporado un soporte preliminar para la escritura de profundidad de vuelta (depth write-back), por ahora centrado en el formato D16. Esta mejora se ha traducido en la corrección de problemas de oclusión de fuentes de luz en juegos como Star Wars Episode I: Racer, donde antes las luces se comportaban de forma irreal o directamente no se ocultaban cuando correspondía.

El changelog de D7VK 1.4 también recoge la corrección de un cuelgue en el arranque de V-Rally 2 Expert Edition, así como un buen número de fixes de “casos esquina” que podían provocar cierres, congelaciones o comportamientos extraños en títulos antiguos de D3D o DDraw. Entre los beneficiados se mencionan Revenant, Powerslide o Slave Zero, además de un workaround específico para un posible cuelgue al volver al menú principal en GTA 2.

Instalación básica y uso de D7VK

Poner en marcha D7VK en un prefijo de Wine es relativamente sencillo: basta con copiar el archivo ddraw.dll junto al ejecutable del juego o aplicación y luego configurar los overrides apropiados en Wine para que use esa DLL de forma prioritaria.

En concreto, en winecfg hay que añadir un override “native, builtin” para la biblioteca ddraw en la pestaña de Libraries, asegurándote de indicar exactamente ese orden. No es necesario preocuparse por la arquitectura, ya que DDraw y sus compañeros de D3D antiguos siempre fueron exclusivamente de 32 bits.

También existe una vía alternativa de despliegue necesaria para ciertos juegos especiales como GTA 2, StarLancer o Midtown Madness 2. En ese caso, hay que renombrar el ddraw.dll de sistema de Wine a ddraw_.dll y copiar el ddraw.dll de D7VK al directorio system32 o syswow64 dentro del prefijo, según su bitness. D7VK intentará primero cargar ddraw_.dll desde el path actual antes de recurrir al ddraw.dll del sistema, permitiendo así coexistir ambas piezas.

En Windows también es posible usar D7VK, aunque no es la plataforma principal para la que se desarrolla ni se prueba. En ese caso basta con copiar ddraw.dll junto al ejecutable del juego, pero se desaconseja totalmente colocarlo en directorios de sistema de Windows, ya que se requiere una implementación real de DDraw y se podrían provocar daños serios en la instalación.

DXVK 1.4: contexto y sinergias con D7VK

La historia de D7VK está fuertemente ligada a la evolución del propio proyecto DXVK, que es la gran columna vertebral de la traducción Direct3D → Vulkan para juegos más modernos (especialmente Direct3D 10 y 11). La versión 1.4 de DXVK supuso un salto relevante que afectó también a cómo se integran capas como D7VK o D8VK.

DXVK 1.4 actualizó la interfaz de Direct3D 11 hasta la versión 11.4 incluida en Windows 10 (build 1903), lo que permitió resolver problemas concretos con juegos como Plants vs Zombies – Battle for Neighbourville. Las nuevas APIs introducidas en D3D11.4 se implementan parcialmente, centrándose solo en aquellas características que tienen sentido sobre la funcionalidad de Vulkan existente.

También se actualizó la interfaz DXGI a la versión 1.5, incluyendo la posibilidad de comprobar soporte HDR (aunque sin salida HDR nativa todavía). Además, se añadieron métodos de interacción DXGI-GDI que, entre otras cosas, facilitaron el arranque de clientes como Rockstar Game Launcher, siempre que se acompañen de correcciones específicas en Direct2D dentro de Wine.

Rendimiento y mejoras internas de DXVK 1.4

En el plano del rendimiento, DXVK 1.4 trajo varias optimizaciones interesantes que afectan a muchos juegos Direct3D 11, mejorando la fluidez y reduciendo la carga de CPU. Una de las más destacadas es la activación por defecto de la opción d3d11.allowMapFlagNoWait, que incrementa el rendimiento en determinados títulos al permitir un manejo más eficiente de ciertos recursos mapeados.

Se solucionaron también los problemas que impedían lanzar correctamente The Witcher 3, ajustando el comportamiento de sincronización para acercarlo al del controlador D3D11 original. Además, se abordaron posibles cuellos de botella en juegos que hacen un uso intensivo de contextos diferidos, como Dark Souls III y Sekiro: Shadows Die Twice.

DXVK 1.4 mejoró de forma notable el seguimiento interno de recursos, reduciendo ligeramente el consumo de CPU al gestionar buffers, texturas y otros elementos gráficos. Todo este trabajo interno, aunque no siempre visible de cara al usuario, siembra el terreno para una integración aún más limpia con capas como D7VK, que necesitan un backend D3D9/D3D11 lo más sólido posible.

Instalación práctica de DXVK 1.4 sobre Wine

Para quienes quieran usar DXVK directamente sobre Wine, el flujo típico consiste en descargar el paquete estable de DXVK, extraerlo y ejecutar su script de instalación sobre el prefijo de Wine deseado. Por ejemplo, con la versión 1.4 se puede hacer algo así:

Primero se descarga el archivo con una herramienta como wget desde el enlace oficial de GitHub:

wget https://github.com/doitsujin/dxvk/releases/download/v1.4/dxvk-1.4.tar.gz

Luego se descomprime el paquete con tar y se accede a la carpeta descomprimida:

tar -xzvf dxvk-1.4.tar.gz
cd dxvk-1.4

Por último, se ejecuta el script de instalación contra el prefijo activo de Wine mediante un simple sh setup-dxvk.sh install con privilegios adecuados:

sudo sh setup-dxvk.sh install

El script también permite usar la implementación DXGI de Wine en lugar de la de DXVK si se desea utilizar vkd3d para juegos Direct3D 12 y DXVK para Direct3D 11. Para ello se puede ejecutar:

setup-dxvk.sh install --without-dxgi

Otra opción práctica que ofrece el script es instalar las DLL como enlaces simbólicos (mediante la opción --symlink), lo que facilita mucho la actualización simultánea de múltiples prefijos de Wine: basta con actualizar una única copia central de DXVK.

Mirando el conjunto, D7VK 1.4 y DXVK 1.4 refuerzan un ecosistema en el que Linux y Wine se consolidan como una plataforma muy seria para jugar tanto a clásicos de Direct3D 5/6/7 como a títulos modernos de D3D10/11, ofreciendo un rendimiento muchas veces sorprendentemente cercano a Windows y, sobre todo, una compatibilidad cada vez más amplia con APIs históricas que parecían condenadas al olvido.

from Linux Adictos https://ift.tt/5d1plc3
via IFTTT

La llegada de Mesa 26.0.1 marca la primera revisión puntual de la serie 26, con un cambio especialmente sensible: un parche de seguridad crítico que corrige un posible acceso fuera de límites (OOB) de memoria en contextos WebGPU utilizados desde navegadores web. Este tipo de vulnerabilidad podría permitir que una página maliciosa intente leer o corromper memoria indebida, comprometiendo la estabilidad y la seguridad del sistema cuando la aceleración gráfica es pieza clave.

Más allá de este fix urgente, la actualización mantiene el ritmo habitual de Mesa: correcciones de errores, ajustes de rendimiento y mejoras de compatibilidad para distintas GPU y configuraciones gráficas. Aunque muchos de estos cambios pasan desapercibidos para el usuario final, son fundamentales para garantizar una experiencia más sólida en juegos, aplicaciones 3D y navegadores modernos que dependen cada vez más de APIs avanzadas como WebGPU dentro del ecosistema Linux.

Mesa 26.0.1: primera revisión puntual con un fix de seguridad crítico

En esta ocasión, la actualización tiene más urgencia de lo habitual porque incluye una corrección de seguridad para un posible acceso fuera de límites (OOB) de memoria en contextos WebGPU cuando se usa desde navegadores web. Este tipo de fallo puede permitir que una página maliciosa intente leer o corromper memoria a la que no debería tener acceso, con riesgos claros para la estabilidad y la seguridad del sistema.

Además de ese parche clave, Mesa 26.0.1 recoge el típico lote de correcciones de errores, pequeños ajustes de rendimiento y mejor compatibilidad con distintas GPU y stacks gráficos. Aunque muchos cambios no son espectaculares de cara al usuario, sí suponen una mejora real en fiabilidad, sobre todo en combinaciones concretas de hardware y juegos o aplicaciones.

PanVK y Mali: acelerón considerable con MSAA en Mesa 26.1

En paralelo a la rama 26.0.x, el desarrollo de Mesa sigue adelante y ya se han fusionado cambios para 26.1. Uno de los avances más llamativos llega en el driver PanVK, que proporciona soporte Vulkan para las GPU Arm Mali modernas.

Una serie de optimizaciones recientes han permitido lograr aceleraciones de hasta 25,7 veces en pruebas con multi-sample anti-aliasing (MSAA) en Vulkan. Hablamos de un salto enorme en escenarios donde se usa MSAA para suavizar bordes y mejorar la calidad de imagen, algo muy relevante para juegos y aplicaciones 3D en dispositivos con GPU Mali.

Estas mejoras refuerzan la tendencia de los últimos años: el soporte gráfico open source en plataformas Arm está madurando a buen ritmo, tanto para sobremesa como para dispositivos embebidos y soluciones en la nube, reduciendo la dependencia de drivers privativos y permitiendo una integración más limpia con el resto del stack Linux.

Drivers gráficos AMD e Intel: evolución constante en Linux

Mientras Mesa avanza, el resto de la pila gráfica en Linux tampoco se queda quieta. En el caso de AMD, el driver AMDGPU del kernel ha alcanzado recientemente una cifra significativa: más de seis millones de líneas de código en Linux 7.0, lo que supone alrededor del 15% de todo el código del kernel, convirtiéndose en el driver individual más grande.

Este crecimiento refleja la enorme inversión en funcionalidades para GPU modernas, soporte de cómputo, integración con AMDKFD y compatibilidad con múltiples generaciones de tarjetas Radeon. El resultado práctico es un soporte sólido para gaming, cómputo GPGPU y uso profesional, especialmente cuando se combina con Mesa y RADV.

Además, se han seguido integrando mejoras específicas para GPUs AMD antiguas. Un desarrollador de Valve ha impulsado múltiples parches que han mejorado de forma notable el rendimiento y la estabilidad de las Radeon GCN 1.0/1.1, hasta el punto de que se usa AMDGPU por defecto en lugar del antiguo driver Radeon, habilitando también RADV Vulkan y ofreciendo una experiencia bastante más redonda.

Por el lado de Intel, el driver ANV para Vulkan ha recibido correcciones en la codificación de vídeo H.265 con Vulkan Video dentro de Mesa 26.1 en desarrollo. Estas mejoras son cruciales para quienes dependen de la aceleración de vídeo moderna en Intel, ya sea para transcodificación, streaming o aplicaciones multimedia profesionales.

El conjunto de cambios que rodea a Mesa 26.0.1 dibuja un ecosistema Linux especialmente dinámico: desde el parche de seguridad en WebGPU y los avances en drivers gráficos como PanVK, AMDGPU e Intel ANV, hasta la nueva oleada de kernels 7.0 y LTS extendidos, pasando por mejoras en entornos de escritorio, compiladores, almacenamiento, virtualización, IA y gaming. Tener todo este stack al día no solo aporta rendimiento, sino que refuerza la seguridad y abre la puerta a nuevas funciones que hace pocos años eran impensables en Linux como plataforma generalista.

from Linux Adictos https://ift.tt/WfK0E28
via IFTTT