Controladores Arc: cómo se corrige en público una generación de GPU

noviembre 26, 2025 • febrero 3, 2026 • Lectura: 29 min • Views: 0

¿Te fue útil?

El problema: compraste una nueva generación de GPU y se comporta como un producto beta. Los juegos pegan tirones. Los codificadores pierden fotogramas. Tus gráficos de monitorización mienten porque el controlador informa “99% GPU” mientras el hilo de la CPU está ardiendo silenciosamente.

Intel Arc es un caso de estudio particularmente público porque llegó a un mercado que espera “instala el controlador y listo.” En cambio, Arc obligó a todos—incluido Intel—a reaprender una lección antigua: una GPU no es solo un chip, es una plataforma de software que contiene un chip.

Qué significa realmente “corregido en público”

Cuando la gente dice “los controladores Arc se están arreglando”, a menudo imagina un equipo monolítico de controladores alternando unos pocos interruptores. La realidad es más desordenada y más interesante.

Un “controlador” moderno de GPU es una pila:

Driver en modo kernel: programación, gestión de memoria, energía, cambio de contexto. En Linux para Arc esto es el driver i915 (para Alchemist) y componentes adyacentes.
Driver en espacio de usuario: implementación de API (Direct3D, Vulkan, OpenGL), compilador de sombreadores, caches de pipeline, capas de traducción.
Firmware: el código del controlador interno de la GPU. Sí, puedes lanzar “un silicio nuevo” y luego corregir comportamientos con firmware, dentro de ciertos límites.
Capas de runtime: DXVK, vkd3d-proton, caches de sombreadores de los juegos, inyectores de overlay, hooks de anti-cheat.
Restricciones de plataforma: ajustes de BIOS como Resizable BAR, peculiaridades de placa base, comportamiento del planificador de Windows, topología PCIe.

“Corregido en público” significa que los usuarios ven la evolución en tiempo real: nuevos controladores cada pocas semanas, listas de problemas conocidos, regresiones, soluciones alternativas y, a veces, el hecho incómodo de que la mejor solución sea “esperar la próxima versión.” En software empresarial fingimos que eso no pasa. En GPUs, todo el mundo lo ve ocurrir.

Arc hizo esto visible porque fue el primer empuje serio de Intel en GPUs discretas en mucho tiempo, y aterrizó en la expectativa moderna de que DX11, DX12, Vulkan, OpenGL, codificación/decodificación de vídeo, streaming, captura, overlays y juegos raros de 2009 deberían funcionar bien desde el primer día. Esa expectativa es poco realista, pero también es el contrato que impone el mercado.

Por qué Arc se lanzó áspero (y por qué no es sorprendente)

Si gestionas sistemas de producción, conoces el patrón: una nueva plataforma se lanza con la “funcionalidad central” correcta, pero los casos límite y la compatibilidad con legado son donde suena el pager. Las GPUs son un santuario de casos límite.

Los problemas tempranos de reputación de Arc no fueron solo “bugs”. Fueron estructurales:

1) DX11 no es “viejo”, es una filosofía diferente

Los juegos de la era DX11 a menudo asumen que los controladores harán mucho trabajo: validación de estado, decisiones de compilación de sombreadores, asistencia en el batching de draw calls y el hábito de “voy a llamar a la API 40,000 veces por fotograma”. Eso no es solo ineficiencia; es una dependencia de un comportamiento históricamente pesado del driver.

La arquitectura y la pila de software de Arc se inclinaron hacia APIs explícitas modernas (DX12/Vulkan) donde los juegos hacen más de la orquestación. Cuando traduces cargas de DX11 a paradigmas modernos, puedes pagar sobrecarga exactamente en el lugar equivocado: el hilo de la CPU que alimenta la GPU.

2) ReBAR no era opcional en la práctica

Arc se benefició de forma inusualmente fuerte de Resizable BAR (ReBAR). Sin ello, puedes acabar con más churn de mapeo PCIe y patrones de acceso a memoria menos eficientes entre CPU y GPU. Muchos informes tempranos de “Arc es lento” eran en realidad “Arc sin ReBAR es lento”, que es un diagnóstico muy distinto.

3) La compilación de sombreadores y el cache de pipeline son donde vive el “stutter”

El stutter rara vez es un único problema. A menudo es una secuencia: aparece una variante de shader nueva, el driver la compila (a veces repetidamente), hay misses en el pipeline cache, la latencia de almacenamiento se dispara y el pacing de cuadros colapsa. La GPU puede estar inactiva mientras el usuario percibe “lag de GPU”.

4) La matriz de pruebas es absurda

Los juegos no son como bases de datos donde pruebas un conjunto conocido de consultas. Son motores hechos a medida con bugs a medida. Añade overlays, herramientas de captura, utilidades RGB y anti-cheat, y básicamente estás fuzzing al driver con software de consumo.

Idea parafraseada, atribuida a John Allspaw: La fiabilidad se construye aprendiendo del fallo en condiciones reales, no asumiendo que puedes probar cada posibilidad por adelantado.

Una verdad operativa: los vendedores de GPU no pueden “terminar” los controladores en un laboratorio. Solo pueden dejarlos lo bastante buenos y luego aprender en producción—es decir, tu escritorio.

La pila de controladores: quién hace qué y dónde se esconden los fallos

Si quieres depurar Arc como un SRE (en lugar de como un hilo de foro), necesitas un mapa mental de la pila y los modos de fallo típicos.

Windows stack (simplificado)

WDDM kernel driver: programación, paginación de memoria, timeouts (TDR), comportamiento de preempción.
Driver en modo usuario: implementación D3D11/D3D12/Vulkan; compilador de sombreadores; gestión del estado del pipeline.
DirectX runtime y motor del juego: pueden ocultar trabajo en llamadas al driver; pueden desencadenar variantes patológicas de sombreadores.

Dónde se esconden los fallos: sobrecarga de traducción DX11, timeouts TDR durante compilación de sombreadores, estados de potencia incorrectos o regresión por “arreglar un juego” que rompe otro.

Linux stack (simplificado)

Kernel: i915 (para Arc Alchemist): gestión de memoria GEM/TTM, carga de firmware GuC/HuC, programación.
Mesa en espacio de usuario: ANV (Vulkan), iris (OpenGL), backends del compilador.
Capas de traducción: DXVK (DX9/10/11 sobre Vulkan), vkd3d-proton (DX12 sobre Vulkan).
Compositor: Wayland/Xorg; VRR; el pacing de frames también puede volverse raro aquí.

Dónde se esconden los fallos: desajustes kernel/firmware, brechas de versión de Mesa, firmware faltante, latencia del compositor y juegos que asumen comportamientos específicos del vendor.

La historia de “corregido en público” de Arc suele verse así:

Los usuarios informan: “El juego X tiene 1% lows infernales.”
El vendor triangula: ¿esto es un cuello de botella de CPU, cache de sombreadores, sobrecarga DX11 o TDR?
La corrección llega en una capa (cambio en el cache de sombreadores de espacio de usuario).
Aparece una regresión (otro juego cae en una nueva ruta, o la invalidación del cache cambió el comportamiento).
La corrección se refina, a veces a través de capas (driver + firmware + perfil del juego).

Hechos y contexto histórico que puedes usar en la cena

Hecho 1: Intel lanzó GPUs discretas mucho antes de Arc—piensa en la i740 a finales de los 90—pero Arc es el primer empuje mainstream en décadas con expectativas modernas de juego.
Hecho 2: Resizable BAR es una extensión del comportamiento de direccionamiento PCIe; es “una idea antigua, recién práctica” gracias a que las plataformas finalmente la estandarizaron en placas consumidoras.
Hecho 3: Los controladores DX11 históricamente hacían mucho trabajo “útil” porque los juegos dependían de ello; las APIs explícitas (DX12/Vulkan) movieron esa responsabilidad a los motores, cambiando dónde aparecen los bugs de rendimiento.
Hecho 4: El stutter por compilación de sombreadores existe desde que hay sombreadores; lo que cambió es la complejidad de los sombreadores y la explosión de permutaciones por las características modernas de render.
Hecho 5: El firmware de GPU se actualiza más como el firmware de una NIC que como microcódigo de CPU—frecuente, dirigido y a menudo acoplado al comportamiento del driver.
Hecho 6: DXVK y vkd3d-proton hicieron viable a escala “juegos de Windows en Linux”, y también se convirtieron en herramientas diagnósticas accidentales para la calidad del driver al ofrecer rutas alternativas.
Hecho 7: La consistencia del tiempo de frame (1% lows) a menudo importa más para la sensación de suavidad que el FPS promedio; los drivers pueden mejorar la “sensación” sin cambiar mucho los benchmarks principales.
Hecho 8: Muchos problemas de “rendimiento” de GPU son en realidad problemas de planificación o sincronización de CPU—spinlocks, contención de mutex y envío de render single-threaded.

Broma #1: Un lanzamiento de driver de GPU es el único lugar donde “estabilidad arreglada” puede significar “dejamos de ser estables a 12 FPS.”

Guía de diagnóstico rápido

Este es el “tengo 30 minutos antes de devolver la tarjeta / revertir el driver / culpar al juego” de la guía. El objetivo es identificar la categoría del cuello de botella rápido, no alcanzar la iluminación.

Primero: clasifica la falla

Crash: app se cierra, reset del driver, pantalla negra, TDR, colgado de GPU.
Stutter: picos en el pacing de frames, tirones al girar la cámara, pausas periódicas.
Bajo rendimiento: FPS consistentemente bajos, baja utilización de GPU, CPU al máximo.
Corrupción visual: artefactos, parpadeos, texturas faltantes, iluminación incorrecta.
Problemas de codificación/decodificación: fotogramas perdidos, desincronización, alto uso de CPU durante la codificación.

Segundo: decide si es plataforma, driver o carga de trabajo

Verificaciones de plataforma: ReBAR habilitado, BIOS al día, velocidad de slot PCIe correcta, conectores de alimentación, térmicas.
Saneamiento del driver: versión correcta, instalación limpia si hace falta, sin conflictos de overlays, sin runtimes antiguos.
Ruta de la carga: DX11 vs DX12 vs Vulkan; prueba APIs de render alternativas; prueba DXVK en Windows como control si sabes lo que haces.

Tercero: recopila dos líneas temporales

Línea temporal de frame: mira si el stutter coincide con compilación de sombreadores o streaming.
Línea temporal del sistema: CPU, IO de disco, uso de VRAM, clocks de GPU, throughput PCIe.

Cuarto: toma una decisión rápida

Si ReBAR está apagado: actívalo y vuelve a probar. Si no puedes: estás en modo “gestión de expectativas”.
Si solo DX11 va mal: prioriza DX12/Vulkan cuando sea posible; si no, prueba versiones de driver conocidas por mejorar rutas DX11.
Si el stutter se alinea con áreas/escenas nuevas: cache de sombreadores/pipeline; opciones de precompilación; reduce ajustes que aumentan permutaciones (RT, sombras).
Si los crashes coinciden con picos de clocks: gestión de energía; prueba un límite de potencia conservador o desactiva boosts agresivos.

Tareas prácticas: comandos, salidas, decisiones

Estas son tareas reales de “haz esto ahora”. Cada una incluye: comando, salida de ejemplo, qué significa y qué decisión tomas. Mezcla según Windows vs Linux. No ejecutes scripts aleatorios de internet; ejecuta comandos dirigidos que respondan una pregunta.

Task 1 (Linux): Confirmar la GPU y el binding del driver

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,/Kernel modules/p'
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:56a0] (rev 05)
	Subsystem: Device [8086:1020]
	Kernel driver in use: i915
	Kernel modules: i915

Significado: El kernel está usando i915 para la GPU Intel. Si ves “vfio-pci” o ningún driver, no estás probando la ruta real.

Decisión: Si no es i915, arregla el binding (o detente—tu problema no son “los controladores Arc”, es la asignación del dispositivo).

Task 2 (Linux): Comprobar si el firmware GuC/HuC realmente cargó

cr0x@server:~$ dmesg | grep -E "i915|GuC|HuC" | tail -n 12
[    2.143210] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/dmc_ver2_20.bin
[    2.198341] i915 0000:00:02.0: [drm] GuC firmware i915/guc_70.5.1.bin version 70.5.1
[    2.198379] i915 0000:00:02.0: [drm] HuC firmware i915/huc_7.10.3.bin version 7.10.3
[    2.207511] i915 0000:00:02.0: [drm] GuC submission enabled

Significado: Firmware cargado y GuC submission habilitado. El firmware faltante puede manifestarse como peor programación, comportamiento de energía y estabilidad aleatoria.

Decisión: Si falla la carga de firmware, instala el paquete linux-firmware correcto para tu distro y reinicia; no sigas benchmarkeando una línea base rota.

Task 3 (Linux): Validar driver Vulkan y exposición del dispositivo

cr0x@server:~$ vulkaninfo --summary | sed -n '1,80p'
Vulkan Instance Version: 1.3.275

Devices:
========
GPU0:
  apiVersion         = 1.3.275
  driverVersion      = 24.1.3
  vendorID           = 0x8086
  deviceID           = 0x56a0
  deviceName         = Intel(R) Arc(TM) A770 Graphics
  driverID           = DRIVER_ID_INTEL_OPEN_SOURCE_MESA
  deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU

Significado: Mesa ANV está en uso, Arc se ve como discreta y Vulkan es funcional.

Decisión: Si el dispositivo aparece como llvmpipe o rasterizador por software, detente y arregla la pila gráfica. Si Vulkan funciona pero los juegos DX11 pegan tirones, sospecha de la traducción o del cache de sombreadores.

Task 4 (Linux): Confirmar la ruta del driver OpenGL (iris vs algo malo)

cr0x@server:~$ glxinfo -B | sed -n '1,25p'
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Intel(R) Arc(TM) A770 Graphics (DG2) (0x56a0)
    Version: 24.1.3
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Arc(TM) A770 Graphics (DG2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.1.3

Significado: La aceleración por hardware está activa, Mesa es el renderer.

Decisión: Si “direct rendering: No” o el renderer es “llvmpipe”, estás depurando lo incorrecto. Arregla tu Mesa/DRM primero.

Task 5 (Linux): Vigilar frecuencia y comportamiento de potencia de la GPU bajo carga

cr0x@server:~$ sudo intel_gpu_top -s 2000
intel-gpu-top: Intel DG2 (Gen12.7) @ /dev/dri/card0

      Render/3D    Blitter     Video     VideoEnhance     EU Array     Frequency
         78.22%      0.00%      2.13%          0.00%        76.90%       2050 MHz

Significado: Estás saturando render; los clocks están subiendo. Si render es bajo pero FPS bajos, estás limitado por CPU o bloqueado en sincronización/sobrehead del driver.

Decisión: Render bajo + FPS bajo → investiga hilo de CPU, sobrecarga DX11 o frame pacing; Render alto + FPS bajo → estás limitado por GPU, reduce ajustes o revisa térmicas/potencia.

Task 6 (Linux): Buscar colgados/resets de GPU en el journal

cr0x@server:~$ sudo journalctl -k -b | grep -E "i915|GPU HANG|reset" | tail -n 20
Jan 21 10:14:22 server kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:85dffffb, in game.exe [4123]
Jan 21 10:14:23 server kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Jan 21 10:14:24 server kernel: i915 0000:00:02.0: [drm] game.exe[4123] context reset due to GPU hang

Significado: Colgado/reset real de GPU, no “el juego se cerró”. Esto puede ser driver, firmware o alimentación/overclock inestable.

Decisión: Reproduce con clocks stock, actualiza kernel/Mesa/firmware y si es un título, prueba otra ruta de API. Si los hangs persisten en varias cargas, trátalo como estabilidad de plataforma.

Task 7 (Windows, via PowerShell): Confirmar versión y fecha del driver

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_VideoController | Select-Object Name,DriverVersion,DriverDate"
Name                                  DriverVersion       DriverDate
----                                  -------------       ----------
Intel(R) Arc(TM) A770 Graphics        31.0.101.5592       20250110

Significado: Tienes un build específico de driver; esa es tu línea base para pruebas de regresión.

Decisión: Si estás con un driver muy antiguo, actualiza antes de depurar. Si estás en el más nuevo y hay una regresión, prueba una versión anterior conocida como estable para confirmar la regresión.

Task 8 (Windows): Detectar eventos TDR (resets del driver) en los logs del Visor de Eventos

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ID=4101} -MaxEvents 5 | Format-Table TimeCreated,Message -AutoSize"
TimeCreated           Message
-----------           -------
1/21/2026 10:02:11    Display driver igdkmdn64 stopped responding and has successfully recovered.
1/20/2026 22:41:58    Display driver igdkmdn64 stopped responding and has successfully recovered.

Significado: Windows reseteó el driver de pantalla. Eso no es “solo un crash”, es un timeout o condición de hang.

Decisión: Reduce vectores de inestabilidad (overclocks, undervolts), luego cambia una variable: versión de driver, API del juego o límite de potencia. Si los TDRs se correlacionan con pantallas de compilación de sombreadores, sospecha de una ruta del driver que se queda bloqueada demasiado tiempo.

Task 9 (Windows): Verificar estado de Resizable BAR

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDeviceProperty -InstanceId (Get-PnpDevice -Class Display | Where-Object {$_.FriendlyName -like '*Arc*'}).InstanceId -KeyName 'DEVPKEY_Device_BusReportedDeviceDesc' | Select-Object Data"
Data
----
PCI Express Root Complex

Significado: Esto no confirma directamente ReBAR; Windows no da una línea clara en todas partes. En la práctica validas ReBAR en BIOS o con herramientas del vendor; en Linux inspeccionas tamaños de BAR directamente.

Decisión: Si no puedes afirmar con confianza que ReBAR está habilitado, deja de benchmarkear y revisa la BIOS: Above 4G Decoding + ReBAR habilitado, CSM off en muchos casos.

Task 10 (Linux): Confirmar sizing de BAR y si ReBAR está activo

cr0x@server:~$ sudo lspci -vv -s 00:02.0 | grep -E "Region 0|Resizable BAR|BAR 0" -A2
Region 0: Memory at 6000000000 (64-bit, prefetchable) [size=16G]
Capabilities: [200 v1] Resizable BAR
		Resizable BAR: current size: 16GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB

Significado: BAR 0 está mapeada a 16G, que es típicamente lo deseable para las características de rendimiento de Arc.

Decisión: Si el tamaño actual es pequeño (256MB/512MB) y lo soportado es mayor, habilita ReBAR/Above 4G Decoding en BIOS y vuelve a probar. Si tu plataforma no puede, acepta que no verás el comportamiento previsto de la tarjeta.

Task 11 (Linux): Identificar si estás limitado por CPU en un juego vía muestreo perf

cr0x@server:~$ sudo perf top -p $(pidof game.exe) -n 5
Samples: 1K of event 'cpu-clock', Event count (approx.): 250000000
Overhead  Shared Object        Symbol
  18.42%  game.exe             RenderThread::SubmitDraws
  12.10%  libvulkan_intel.so   anv_queue_submit
   9.77%  game.exe             ShaderManager::GetVariant
   6.31%  libc.so.6            pthread_mutex_lock

Significado: El hilo de render de la CPU y la sumisión a la cola están calientes; existe contención de mutex. Eso es clásico “overhead driver/API encuentra diseño del motor”.

Decisión: Prueba otra API (DX12/Vulkan), reduce ajustes que generan muchas draw calls (distancia de visión, densidad de multitudes) y asegúrate de que la versión del driver incluya mejoras DX11 conocidas si ese es el camino.

Task 12 (Linux): Observar el crecimiento del cache de sombreadores y si se invalida

cr0x@server:~$ du -sh ~/.cache/mesa_shader_cache ~/.cache/radv_builtin_shaders 2>/dev/null
1.2G	/home/cr0x/.cache/mesa_shader_cache

Significado: El cache de sombreadores existe y es considerable; eso es normal en títulos modernos.

Decisión: Si el stutter persiste tras múltiples ejecuciones en la misma escena, el cache puede estar deshabilitado, constantemente invalidado o el stutter proviene de streaming/CPU. Si el directorio del cache nunca crece, investiga variables de entorno o sandboxing que impidan escrituras.

Task 13 (Linux): Comprobar latencia de almacenamiento cuando ocurre stutter

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server) 	01/21/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.02    0.00    5.21    6.11    0.00   70.66

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await aqu-sz  %util
nvme0n1         520.0  42000.0     0.0   0.00   8.40    80.77     70.0   9000.0   4.10   2.90   88.20

Significado: Alta utilización de NVMe y latencia de lectura elevada pueden correlacionarse con stutter, especialmente al stream de nuevas áreas.

Decisión: Si %util sube al 100% durante los stutters, mueve el juego a almacenamiento más rápido, asegúrate de no estar paginando y considera opciones de precompilación. No persigas “stutter del driver GPU” cuando tu disco está ahogado.

Task 14 (Windows): Validar modo de programación de GPU y estado HAGS (donde se soporte)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers' /v HwSchMode"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
    HwSchMode    REG_DWORD    0x2

Significado: Hardware-accelerated GPU scheduling está habilitado (el valor puede variar según la versión de Windows).

Decisión: Si diagnosticas stutter o latencia, prueba HAGS con ambos estados. Algunos sistemas mejoran; otros empeoran. Trátalo como un flag de característica, no como una religión.

Task 15 (Linux): Confirmar que no estás accidentalmente en una ruta de compositor por software

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Significado: Estás en Wayland. Está bien, pero si un juego específico pega tirones, probar Xorg puede aislar interacción con el compositor.

Decisión: Si los problemas desaparecen en Xorg, has encontrado un bug de compositor/VRR, no un problema bruto de rendimiento de GPU.

Task 16 (Linux): Capturar un informe de depuración GPU mínimo sin adivinar

cr0x@server:~$ sudo intel_gpu_top -J -s 500 -o /tmp/intel_gpu_top.json & sleep 5; head -n 5 /tmp/intel_gpu_top.json
{
  "period_us": 500000,
  "device": "Intel DG2",
  "timestamp": 39421.1201,

Significado: Tienes un registro estructurado de la utilización de motores GPU para correlacionar con momentos de stutter.

Decisión: Si la utilización es baja durante el “lag”, deja de culpar al núcleo de la GPU. Mira la sumisión de la CPU, compilación de sombreadores o IO.

Tres mini-historias corporativas desde el campo

Mini-historia 1: El incidente causado por una suposición errónea

La empresa desplegaba estaciones de trabajo basadas en Arc para un equipo que hacía mezcla de codificación de vídeo y 3D ligero. Nada exótico. El grupo piloto se veía bien: la codificación AV1 era rápida, los escritorios silenciosos y el precio correcto. Procurement sonrió. Eso debería haber sido una bandera roja.

En la semana dos, llegaron una ola de tickets: “La interfaz se congela 2–3 segundos”, “la pantalla se queda negra y vuelve”, “las llamadas se cortan al compartir pantalla”. El equipo lo trató como un problema de la app de conferencias. Reinstalaron la app, la actualizaron, probaron otra webcam. Ping-pong clásico de culpas.

La suposición errónea fue sutil: asumieron que la GPU se comportaría como “solo una iGPU más rápida”. En su entorno, los ajustes de BIOS se estandarizaron años atrás—CSM habilitado para compatibilidad de arranque legacy, ReBAR deshabilitado porque “nunca importó” y las actualizaciones de BIOS se consideraban riesgosas.

Cuando alguien finalmente verificó la línea base de la plataforma, fue obvio: la mitad de la flota tenía ReBAR apagado y firmware desactualizado. Bajo la carga de codificación en tiempo real más composición más overlays de screen-sharing, el driver alcanzó bordes de temporización y se recuperó (TDR en Windows), lo que los usuarios percibieron como congelamientos.

La solución no fue mágica: actualización de BIOS, habilitar Above 4G Decoding + ReBAR, estandarizar versión de driver y dejar de mezclar “lo que Windows Update instaló” con instalaciones manuales. El rendimiento mejoró y las pantallas negras desaparecieron. La lección real: Arc es sensible a la configuración de plataforma de una forma que GPUs más antiguas podían enmascarar con un comportamiento diferente.

Mini-historia 2: La optimización que salió mal

Otra organización manejaba una pequeña granja de render para vistas previas de assets. No hacían render offline completo; ejecutaban renders interactivos de viewport y codificaban clips de revisión. Alguien notó que los directorios de cache de sombreadores crecen a gigabytes en perfiles de usuario y decidió que eran “escrituras SSD desperdiciadas”.

Así que impusieron una política: limpiar caches de sombreadores al cerrar sesión y redirigir caches a un home en red para que los perfiles fueran “stateless”. En papel sonaba como higiene de TI ordenada. El lunes, todos se quejaron de que los primeros 10 minutos de cada sesión estaban llenos de stutter, los ventiladores gritaban y a veces las apps fallaban durante la “carga”.

Qué pasó: los caches de sombreadores y pipeline ahora estaban fríos en cada login y peor—almacenados en una ruta de red con mayor latencia y contención ocasional. Compilaciones que antes se amortizaban en semanas ahora se golpeaban en los primeros minutos de cada día, exactamente cuando los usuarios lanzaban apps y cargaban proyectos.

Arc fue culpado porque era la variable nueva, pero la regresión fue autoinfligida. Restaurar caches locales, excluirlos de la “limpieza” y dejarlos persistir arregló el stutter. Aún gestionaron el crecimiento en disco fijando cuotas realistas y limpiando solo caches huérfanos, no los calientes.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un laboratorio de pruebas de juegos (no un estudio; piensa en compatibilidad y QA tercerizado) tenía que validar una actualización de driver en decenas de títulos. Ya estaban acostumbrados al churn de vendors, así que lo ejecutaron como un despliegue de operaciones, no como un hobby de fin de semana.

Mantenían una imagen dorada por clase de hardware: versión de BIOS fijada, estado de ReBAR fijado, build de Windows fijada, versión de driver fijada. Cada cambio era una solicitud de cambio con una razón corta. Era agresivamente aburrido. También fue cómo evitaron perseguir fantasmas.

Cuando un nuevo driver Arc mejoró rendimiento DX11 en varios títulos pero introdujo un crash en un motor antiguo, el laboratorio lo atrapó en horas. Porque su línea base era estable, pudieron reproducirlo de forma fiable. También tenían una “máquina de control” que se quedó en el driver anterior para confirmar que era una regresión, no aleatoriedad.

El resultado: proporcionaron pasos de repro accionables, logs consistentes y comparaciones claras. El vendor arregló el crash en una versión posterior. El laboratorio no “tuvo suerte”. Hicieron el trabajo poco sexy: fijaron líneas base, midieron deltas y se negaron a mezclar cambios no relacionados en la misma ventana de prueba.

Errores comunes: síntoma → causa raíz → solución

Esta sección es deliberadamente específica. Si reconoces un síntoma, deberías poder hacer algo concreto en una hora.

1) FPS bajos solo en DX11

Síntoma: Títulos DX12/Vulkan funcionan bien; títulos DX11 muestran baja utilización de GPU y malos 1% lows.
Causa raíz: Envío de draw bound por CPU y sobrecarga del driver DX11; a veces las rutas de traducción están menos optimizadas que las de competidores.
Solución: Prefiere modo de render DX12/Vulkan si está disponible. Si no, prueba drivers más nuevos conocidos por mejorar DX11. Reduce ajustes que generan muchas draw calls (distancia de visión, multitudes). Asegura que ReBAR esté activado.

2) Stutter que nunca se va, incluso tras varias ejecuciones

Síntoma: La misma escena pega tirones siempre; el cache de sombreadores no parece ayudar.
Causa raíz: Cache de sombreadores que no persiste (permisos, sandboxing, scripts de limpieza), o cache de pipeline invalidado por actualizaciones de driver/cambios de configuración.
Solución: Verifica que los directorios de cache sean escribibles y persistentes. Detén herramientas de “limpieza” que borran caches. Tras una actualización de driver, espera recompilación única; si se repite, tienes un problema de persistencia de cache.

3) Pantallas negras aleatorias con recuperación

Síntoma: La pantalla se pone negra un segundo y vuelve; Event ID 4101 en Windows, o reset de GPU en logs de Linux.
Causa raíz: TDR / recuperación por hang de GPU disparada por compilación de sombreadores de larga duración, boost/potencia inestable o un bug del driver provocado por una carga específica.
Solución: Revertir a clocks stock. Probar otra versión de driver. Reducir picos de potencia (limitar FPS, reducir ligeramente el límite de potencia). Si es reproducible en un título, cambia la ruta de API e informa con logs.

4) “GPU al 99%” pero se siente lenta

Síntoma: Overlays de monitorización muestran uso máximo de GPU, pero el pacing de frames es horrible.
Causa raíz: Métricas de utilización engañosas durante stalls, o estás saturando un motor específico (copy/video) mientras render está bloqueado por sincronización.
Solución: Usa herramientas a nivel de motor (intel_gpu_top) o gráficos de frame-time. Correlaciona con CPU e IO. No ajustes en base a un único número “GPU %”.

5) El rendimiento se desploma tras un “limpieza” o herramienta de perfiles

Síntoma: Tras ejecutar un optimizador del sistema, los juegos pegan más y cargan más lento.
Causa raíz: Borrado de cache de sombreadores, servicios en segundo plano deshabilitados que el driver necesita, cambios en el plan de energía o ajustes forzados del driver.
Solución: Revierte la limpieza. Restaura planes de energía por defecto. Deja persistir caches de sombreadores. Evita “tweakers” de terceros a menos que puedas revertir cada cambio.

6) La codificación usa demasiada CPU a pesar de tener Arc

Síntoma: OBS/FFmpeg pega la CPU; los motores de vídeo de la GPU muestran bajo uso.
Causa raíz: Encoder equivocado seleccionado (x264 por software en lugar de QSV/oneVPL), ruta de codec no soportada o mismatch driver/runtime.
Solución: Selecciona explícitamente el encoder hardware Intel. Valida con herramientas de utilización (actividad del motor de vídeo). Actualiza driver y runtimes de media como conjunto.

7) Gaming en Linux: “Vulkan funciona, pero Proton se cae”

Síntoma: Apps Vulkan nativas funcionan; algunos títulos Proton se cierran/colgan.
Causa raíz: vkd3d-proton/DXVK interactuando con una versión específica de driver/Mesa; librerías Vulkan de 32-bit faltantes; o Mesa desactualizada en una distro LTS.
Solución: Asegura las librerías Vulkan de 32-bit instaladas. Actualiza Mesa (o usa una pila conocida buena). Mantén kernel + Mesa + firmware alineados.

Broma #2: “Probablemente es el driver” es el equivalente GPU de “probablemente es DNS”—a menudo correcto, y aun así no es excusa para saltarse las comprobaciones básicas.

Listas de verificación / plan paso a paso

Checklist A: Establecer una línea base confiable (haz esto una vez por máquina)

Actualiza el BIOS a una release estable del vendor; habilita Above 4G Decoding y ReBAR.
Confirma que el slot PCIe funcione a la anchura/velocidad esperada (no benchmarquees un error de slot x4).
Instala una versión de driver conocida buena; regístrala (captura de pantalla o log de texto).
Deshabilita overlays/injectores innecesarios para pruebas base (herramientas de captura, overlays RGB, overlays de rendimiento más allá de uno).
Elige 3 cargas: un DX11, un DX12/Vulkan y una prueba de encode/decode.
Registra: FPS promedio, 1% lows y si el stutter ocurre tras la segunda ejecución (cache warm).

Checklist B: Si sospechas una regresión

Cambia una variable: solo la versión del driver. No el build de Windows, no BIOS, no parche del juego, no todo a la vez.
Re-testea la misma escena/benchmark dos veces (cache fría y luego cache caliente).
Revisa TDR/resets de GPU (Event ID 4101 en Windows / GPU HANG en journal de Linux).
Si confirmas regresión, guarda ambos instaladores de driver y documenta: título, modo API, resolución, ajustes, pasos de reproducción.

Checklist C: Si persigues stutter (pacing de frames)

Determina si el stutter es único (solo primera ejecución) o persistente.
Vigila latencia de almacenamiento durante ventanas de stutter; descarta contención de IO.
Valida persistencia del cache de sombreadores (no lo borres; no lo muevas a almacenamiento en red).
Limita FPS para reducir picos y transientes de potencia; vuelve a probar.
Cambia modo de API (DX11 → DX12/Vulkan) como prueba A/B.
Si es persistente y reproducible, recopila logs e informa con versión exacta del driver.

Checklist D: Alineación específica de Linux para “no perder tiempo”

Kernel, Mesa y linux-firmware deben estar razonablemente actualizados y compatibles.
Confirma que ANV/iris se usan (no llvmpipe).
Confirma que GuC/HuC firmware carga (dmesg).
Prefiere Wayland o Xorg según comportamiento reproducible; no discutas en abstracto.

Preguntas frecuentes

Q1: ¿Por qué Arc mejoró tanto con el tiempo comparado con otros lanzamientos de GPU?

Porque Arc entró con mucha “superficie de pila nueva” a la vez: nueva plataforma discreta, funciones de media modernas y fuerte foco en APIs explícitas. Las mejoras más rápidas vinieron de optimizar rutas calientes (especialmente traducción/sobrecarga DX11), comportamiento de cache de sombreadores y workarounds específicos de juegos. Esos son problemas de software—y el software puede moverse más rápido que el silicio.

Q2: ¿Es Resizable BAR obligatorio?

No estrictamente, pero funcionalmente sí si te importa rendimiento consistente. Arc suele sufrir desproporcionadamente cuando el tamaño del BAR es pequeño. Si no puedes habilitar ReBAR, recalibra expectativas y benchmarquea antes de comprometerte.

Q3: ¿Por qué DX11 se comporta peor que DX12/Vulkan en Arc en muchos casos?

DX11 incentiva al driver a hacer más trabajo implícito. Eso puede crear overhead de CPU y costes de sincronización que aparecen como baja utilización de GPU y malos 1% lows. DX12/Vulkan mueven más responsabilidad al motor, lo que puede mapear mejor a las fortalezas de Arc cuando el juego está bien implementado.

Q4: ¿Cuál es la forma más rápida de distinguir cuello de botella de CPU vs GPU?

Baja resolución y ajustes gráficos drásticamente. Si el FPS apenas cambia, probablemente estás limitado por CPU o por overhead del driver. Si el FPS sube mucho, estabas limitado por GPU. Confirma con utilización a nivel de motor (intel_gpu_top en Linux) y gráficos de tiempo de frame.

Q5: ¿Debo instalar siempre el driver más nuevo?

Para Arc, “más nuevo” a menudo significa correcciones reales, pero también puede traer regresiones frescas. Si valoras la estabilidad, elige un driver conocido bueno y actualiza solo cuando necesites una corrección o las notas de la versión mencionen claramente tu carga. Conserva el instalador anterior para revertir fácilmente.

Q6: ¿Son las “optimizaciones específicas de juego” un truco sucio?

Son una realidad. A veces son heurísticas del compilador de sombreadores; otras son flags de workaround para un bug del motor o un mal uso de la API. La alternativa es dejar que los usuarios sufran. El riesgo operativo es la regresión: un workaround puede cambiar comportamiento en otro lugar, por eso las pruebas base importan.

Q7: En Linux, ¿qué importa más: kernel o Mesa?

Ambos, pero para rendimiento diario y compatibilidad de juegos, Mesa suele mover la aguja más rápido (driver Vulkan/OpenGL y compilador). Para estabilidad, la programación y la integración del firmware, kernel y linux-firmware son igualmente críticos. Trátalos como una unidad.

Q8: ¿Por qué tengo stutter después de cada actualización de driver?

Porque los caches de sombreadores y pipeline pueden invalidarse cuando cambia el compilador. Eso es esperado una vez. El error es asumir que una actualización de driver es “gratuita”. Planifica una ejecución de calentamiento tras actualizar y no evalúes el stutter en los primeros cinco minutos con cache frío.

Q9: ¿La madurez del motor de media de Arc sigue la madurez del driver de juegos?

No perfectamente. Las tuberías de media (encode/decode) son rutas de código distintas y pueden estar estables aunque algunos juegos no lo estén. Aun así, comparten partes de la pila: gestión de energía, memoria e integración OS. Si ves resets de GPU durante codificación, trátalo como problema de estabilidad del sistema, no “solo OBS”.

Q10: ¿Qué debo incluir al reportar un bug de driver Arc para que sea accionable?

Versión del driver, build de OS, versión de BIOS, estado de ReBAR, versión exacta del juego, modo API exacto (DX11/DX12/Vulkan), pasos de reproducción y si ocurre en una segunda ejecución (cache caliente). Añade logs (eventos TDR / líneas GPU HANG del kernel) y un video corto si es corrupción visual.

Conclusión: siguientes pasos que realmente reducen el dolor

Si te llevas una cosa: deja de tratar “los controladores Arc” como una sola cosa. Es una pila, y cada capa tiene sus modos de fallo. La mayor parte del tiempo perdido viene de depurar sin antes probar tu línea base: estado de ReBAR, binding correcto del driver, firmware cargado y un caso de prueba reproducible.

Haz esto a continuación:

Fija una línea base: BIOS + ReBAR + una versión de driver. Escríbelo.
Clasifica tu dolor: crash vs stutter vs FPS bajos vs bugs visuales. Herramientas distintas, soluciones distintas.
Ejecuta la guía de diagnóstico rápido: plataforma → saneamiento del driver → ruta de la carga. No te saltes pasos.
Cambia una variable a la vez: así encuentras regresiones y evitas supersticiones.
Mantén caches locales y persistentes: tu yo futuro te lo agradecerá cada vez que una escena cargue suave.

La historia de Arc es lo que parece la evolución de una GPU cuando puedes verla pasar: desordenada, iterativa y ocasionalmente humillante. La buena noticia es que las plataformas de software pueden mejorar dramáticamente—si mides lo correcto y te niegas a depurar por sensaciones.