Desactivar VT-d en Linux: cuándo mejora Intel Arc y cómo probarlo

Para quienes usan Linux con gráficas Intel Arc o las iGPU de las nuevas generaciones de Intel, hay un consejo que está dando que hablar: desactivar VT-d (IOMMU) puede mejorar el rendimiento en ciertos escenarios. No es magia, ni sirve para todo, pero hay datos y pruebas interesantes que conviene tener en el radar si no necesitas virtualización ni asignación de dispositivos.

Intel ha compartido recomendaciones específicas y varios entusiastas han hecho mediciones comparando con y sin VT-d en sistemas Meteor Lake y Lunar Lake. Las cifras muestran incrementos modestos a notables según la carga: desde pequeños repuntes en glmark2 hasta saltos de alrededor del 10% en Unigine Heaven en Linux, y además se han visto mejoras adicionales al actualizar el kernel y la pila gráfica. Conviene entender el contexto, los pasos y los riesgos antes de tocar nada.

Qué es VT-d/IOMMU y por qué puede influir en la GPU

De forma resumida, VT-d (IOMMU) es la tecnología que permite a un hipervisor controlar y aislar el acceso DMA de dispositivos, mapeando memoria a través de IOMMU. Es esencial cuando haces virtualización con passthrough de GPU u otros dispositivos, y también aporta barreras de seguridad a nivel de DMA. En algunos sistemas recientes, su activación puede añadir cierta latencia/overhead que, en cargas de GPU específicas, se traduce en unos FPS menos.

Intel ha indicado expresamente que en iGPU de Meteor Lake y posteriores puede ser beneficioso desactivar VT-d si no necesitas virtualización. Además recomiendan mantener el sistema al día con el último kernel y Mesa, usar Wayland cuando sea posible (por soporte de modificadores adicionales que benefician el rendimiento) y asegurar que el firmware del SoC está al día.

Para GPUs dedicadas, la guía de Intel añade dos ajustes clásicos de plataforma: activar ReBAR y habilitar ASPM, que ayudan al rendimiento/eficiencia en muchas combinaciones placa-base/GPU modernas. Aunque no están ligados a VT-d, son recomendaciones complementarias que conviene revisar en BIOS.

Las recomendaciones de Intel que debes revisar primero

Antes de meterte a desactivar nada, conviene aplicar lo básico que propone el propio fabricante, porque suelen dar rendimiento gratis sin comprometer seguridad. Estas son las pautas destacadas, con impacto real en Linux:

• Actualiza kernel y Mesa: las mejoras llegan de forma continua; parte del rendimiento depende de controladores y compiladores de shaders recientes.
• Mantén el firmware del SoC al día: hoy por hoy, en algunos equipos las actualizaciones de firmware se distribuyen a través del driver de Windows; el soporte por fwupd está en marcha.
• Usa Wayland cuando puedas: hay soporte de modificadores adicionales que suman rendimiento y eficiencia en la ruta de gráficos.
• En iGPU de MTL y posteriores, si no necesitas virtualización, valora desactivar VT-d (más abajo verás cómo y qué implicaciones tiene).
• En GPUs dedicadas: activa ReBAR y ASPM desde BIOS/UEFI para exprimir el hardware en Linux.

Banco de pruebas con Lunar Lake: cifras con y sin VT-d

Un caso especialmente ilustrativo es el de un equipo compacto basado en Intel Core Ultra 7 258V (Lunar Lake) con gráficos Arc 140V, probado con Ubuntu 24.10. El sistema arrancó con Wayland por defecto y, salvo un contratiempo con el módulo AX211 (se detectó Bluetooth pero no Wi-Fi), permitió ejecutar benchmarks tras actualizar el sistema mediante un adaptador USB-C de 2,5 GbE.

Para verificar si IOMMU estaba activo, se buscó “DMAR” en el registro del kernel, y se comprobó que VT-d figuraba habilitado. A partir de ahí, se ejecutaron pruebas con Unigine y glmark2-wayland. Un detalle curioso: una utilidad de monitorización (sbc-bench.sh) que no ejecuta benchmarks y consume poquísimos recursos empeoró notablemente las puntuaciones cuando se dejaba corriendo a la par, pese a que en teoría no debería afectar; por prudencia, se desactivó para el resto de mediciones.

El objetivo era comparar “con VT-d” frente a “sin VT-d”. En BIOS se intentó primero desactivar Intel (VMX) Virtualization Technology en Advanced → CPU Configuration, pero eso afecta a VT-x (CPU) y no a VT-d (I/O), así que no sirvió. Luego se localizó VT-d en Advanced → System Agent (SA) Configuration → VT-d setup menu, pero en esa UEFI no se podía cambiar a Disabled. Toca, por tanto, la ruta vía kernel.

En Linux, la solución fue añadir un parámetro a la línea del kernel en /etc/default/grub para desactivar IOMMU. Las dos opciones habituales son:

# Opción 1 (específica de Intel)
GRUB_CMDLINE_LINUX="intel_iommu=off"

# Opción 2 (genérica)
GRUB_CMDLINE_LINUX="iommu=off"

Tras editar el archivo, se ejecutó el comando de actualización de GRUB y se reinició el sistema. Al volver a lanzar dmesg, se confirmó que IOMMU ya no aparecía y que VT-d dejaba de figurar en el registro del kernel, indicando que estaba realmente desactivado.

Resultados: Heaven, Superposition y glmark2 con y sin VT-d

Con VT-d habilitado, la métrica de referencia en Unigine Heaven rondó los 42,0 FPS. Al repetir con VT-d desactivado, la cifra subió a 46,4 FPS, lo que supone un incremento de algo más del 10%, nada despreciable para un cambio de configuración del sistema.

En Unigine Superposition (v1.1), en cambio, no se observaron ganancias: el resultado pasó de 3286 puntos con VT-d a 3210 sin VT-d, una ligera caída del 2,4%. Aquí se aprecia el carácter dependiente de la carga: hay escenas y motores donde el cambio ayuda, y otros donde no.

Con glmark2-wayland (off-screen), el marcador también se movió a favor de desactivar VT-d: de 1718 puntos con IOMMU activo a 1794 sin él, lo que supone una mejora en torno al 4,4%. Si bien no es espectacular, sí resulta consistente con la tendencia vista en Heaven.

Para afinar más, se probó además a actualizar el kernel a una versión de desarrollo facilitada por Canonical (Linux 6.13-rc1). En esa transición fue necesario desactivar Secure Boot en BIOS, porque el arranque con un kernel sin firmar arrojaba el error “bad shim signature”. Con el nuevo kernel, Heaven subió aún más hasta los 48 FPS, y glmark2-wayland se fue a 1901 puntos. Tomando como referencia Linux 6.11 con VT-d activo, la suma de actualizar kernel y desactivar VT-d supuso casi un 15% en Heaven y alrededor de un 10,7% en glmark2.

Comparativa con Windows y notas sobre el hardware Arc 140V

Una curiosidad que se observó en el mismo equipo fue que en Windows 11 con DirectX las puntuaciones de Heaven estaban muy por encima: 81,2 FPS / 2.045 puntos, frente a las cifras de Linux en OpenGL. Es normal que haya diferencia entre APIs y stacks, pero aquí la brecha fue especialmente grande en este test concreto.

Comparando con otro mini PC (GEEKOM GT1 con Intel Core Ultra 9 185H, iGPU Arc @ 2,35 GHz con 8 Xe), se vieron en Ubuntu 24.10 unos 77,6 FPS / 1.956 puntos en Heaven. El Arc 140V del Core Ultra 7 258V también monta 8 Xe, pero su reloj máximo se queda en 1,95 GHz, por lo que cabe esperar menor rendimiento; aun así, la diferencia observada fue mayor de lo que dicta solo la frecuencia.

Este contexto refuerza la idea de que en hardware muy nuevo, como Lunar Lake, el software sigue madurando y hay margen para que kernel, Mesa y drivers recorten distancias y pulan la experiencia, especialmente bajo Linux.

Más palancas: mitigaciones de seguridad del stack gráfico

Además de VT-d, existe otra palanca que ha mostrado impacto en cargas de cómputo y gráficos: la opción de desactivar ciertas mitigaciones de seguridad en el software de código abierto de Intel para Linux. Según pruebas internas de la compañía, omitir estas comprobaciones puede aportar hasta un 20% de mejora en algunos casos.

Estas mitigaciones protegen ante vulnerabilidades conocidas como Spectre, y su coste en rendimiento no es gratuito. Aun así, los kernels modernos de Linux incorporan defensas propias y exhaustivas a nivel de sistema, y el software de Intel permite desactivarlas bajo una opción como NEO_DISABLE_MITIGATIONS. Si el sistema detecta un kernel antiguo, se muestra un aviso para que el usuario entienda el riesgo.

Las mejoras observadas al prescindir de esas mitigaciones afectan a rutas como OpenCL y Level Zero, y a tareas frecuentes en la GPU como la compilación de sombreadores, los algoritmos de escalado por IA o ciertas simulaciones físicas. Los ingenieros de Intel valoran que, en un perfil de riesgo asumible, el trade-off rendimiento/seguridad puede compensar en entornos concretos. Ten claro, eso sí, que estás desactivando protecciones: no lo apliques a la ligera en equipos de producción expuestos.

La evolución de los drivers Intel Arc en Linux importa

Más allá de VT-d y mitigaciones, el ritmo de las actualizaciones de drivers de Intel Arc en Linux ha traído mejoras mensuales palpables. En pruebas comparando controladores de mediados de julio frente a los de junio, con una Intel Arc A770 bajo Linux 6.4 y soporte para I915_FORMAT_MOD_4_TILED_DG2_RC_CCS, se vieron subidas relevantes en juegos y benchmarks.

Por ejemplo, CS:GO pasó de 189,7 FPS a 228,7 FPS, alrededor de un 21% de mejora en un solo mes. En resoluciones superiores y ajustes Ultra la ganancia fue menor, pero seguía habiendo movimiento dependiendo del título y la API.

En Unigine Superposition 1.0 se ganó casi un 10%, subiendo de 252 a 276 FPS. En Unvanquished a 2K, los FPS pasaron de 577 a 630. El caso más llamativo fue Warsow 2.5 Beta, donde prácticamente se duplicó el rendimiento: de 532 a 972 FPS.

También hubo progreso en el reboot de Quake II con Vulkan, con mejoras del ~8% (sumas de 20–25 FPS según resolución), y en VKMark 2022 las ganancias alcanzaron el 43%. En Windows, por su lado, estas mejoras pueden ser menores en algunos casos, pero en Linux la evolución es clara y continuada.

Cómo desactivar VT-d de forma segura en Linux

Si no usas virtualización ni pasarela de dispositivos y quieres probar, estos son los pasos tipo para desactivar VT-d/IOMMU en Linux. Haz copia de seguridad de tus cambios y ten a mano cómo revertirlos. Recuerda que esto no es recomendable si dependes de IOMMU para tu flujo de trabajo.

1) Comprobar el estado actual: busca entradas DMAR/IOMMU en el registro del kernel. Si aparecen, VT-d está activo.

dmesg | grep -i dmar
# o bien
dmesg | grep -i iommu

2) Intentar desde BIOS/UEFI: en muchas placas aparece en menús como Advanced → System Agent (SA) Configuration → VT-d. Si puedes, ponlo en Disabled. Si tu BIOS no permite cambiarlo (algunos equipos lo bloquean), pasa al método de kernel.

3) Desactivar vía kernel: edita /etc/default/grub y añade uno de los parámetros siguientes a GRUB_CMDLINE_LINUX:

sudo nano /etc/default/grub

# Ejemplos de línea (usa uno de los dos):
GRUB_CMDLINE_LINUX="quiet splash intel_iommu=off"
# o
GRUB_CMDLINE_LINUX="quiet splash iommu=off"

4) Actualiza GRUB y reinicia. Tras volver al sistema, revisa de nuevo el registro para confirmar que IOMMU está desactivado y ya no aparecen referencias a VT-d.

sudo update-grub
sudo reboot

# Verificación
dmesg | grep -i iommu

5) Comprueba que Wayland está activo (si tu sesión lo permite) e instala actualizaciones de kernel/Mesa antes de medir. Si vas a probar un kernel de desarrollo sin firmar y tienes Secure Boot activo, recuerda que puede fallar el arranque con “bad shim signature” y quizá debas deshabilitarlo temporalmente.

Cuándo no deberías desactivar VT-d

Si utilizas virtualización con KVM/QEMU y haces passthrough de GPU u otros dispositivos, o si dependes de la protección DMA (por ejemplo, ciertos escenarios con Thunderbolt), VT-d es una pieza de seguridad y funcionalidad clave. En estos casos, mantén VT-d activado y prioriza las otras palancas de rendimiento (kernel/mesa/firmware/Wayland/drivers).

También ten en cuenta que algunas BIOS no exponen el interruptor de VT-d o lo fijan en Enabled. Ahí, la alternativa de kernel puede ser la única salida, pero valora los posibles efectos colaterales en tu plataforma concreta antes de automatizar este cambio.

Qué puedes esperar al medir: variabilidad según carga

Los datos recopilados muestran que la ganancia al desactivar VT-d es dependiente del benchmark y del motor gráfico. Heaven reaccionó bien (≈10% sin tocar nada más, y más todavía con kernel nuevo), glmark2 subió algunos puntos porcentuales y Superposition no mejoró e incluso perdió un poco.

Esto encaja con el estado de una plataforma en plena maduración como Lunar Lake en Linux, donde no solo la configuración del sistema, sino la evolución del kernel y la pila gráfica, marcan diferencias sensibles. Si te interesa exprimir FPS, conviene medir en tu propio catálogo de juegos/aplicaciones y decidir con datos.

No olvides, además, el papel de los drivers recientes: en Arc A770, la comparación entre controladores de junio y julio reveló subidas de dos dígitos en títulos populares y benchmarks sintéticos. Sumado a las demás recomendaciones (firmware, Wayland, ReBAR/ASPM), el cómputo global puede ser notable.

En paralelo, existe la posibilidad de desactivar mitigaciones de seguridad del stack de cómputo (NEO_DISABLE_MITIGATIONS) para ganar rendimiento en OpenCL/Level Zero y tareas afines, con el matiz de que se reduce la protección: útil en bancos de pruebas o estaciones aisladas, menos indicado en equipos con exposición a amenazas.

Queda, por último, la cuestión de Windows vs Linux: en ciertas pruebas (Heaven) las puntuaciones en Windows 11 con DirectX fueron mucho más altas. Es una foto de un test concreto, pero recuerda que las APIs, drivers y capas intermedias cambian la película; en Linux, la trayectoria reciente de Intel es positiva y las distancias deberían seguir acortándose con nuevas versiones.

Para quien no usa virtualización, desactivar VT-d es una palanca fácil de probar y revertir, con posibles ganancias de 4–15% según el caso; si sí dependes de ella, céntrate en actualizar kernel/Mesa/firmware, usar Wayland, y mantener los drivers al día, porque la mejora sostenida también viene por esa vía.

La lectura global de todas las pruebas y recomendaciones apunta a que, en Linux y con hardware Intel reciente, hay margen real para rascar rendimiento sin tocar la cartera: desactivar VT-d solo cuando proceda, adoptar Wayland, activar ReBAR/ASPM en dedicadas, valorar (con cautela) la desactivación de mitigaciones en cargas de cómputo, y, sobre todo, estar al día de kernel, Mesa, firmware y controladores.