Si alguna vez has enviado una característica gráfica que “funciona en mi máquina” a una flota de PCs muy diferentes,
ya conoces la sensación: una actualización de controlador puede desatar el caos, una opción ambiciosa puede provocar fotogramas de 45 ms,
y una base de usuarios que absolutamente hará benchmark de tu peor escena para siempre.
El trazado de rayos (RT) aterrizó exactamente en esa realidad operativa. Para AMD, “ponerse al día” no fue un problema de marca;
fue una decisión de secuenciación con gestión de riesgos. En términos de producción: primero lograr corrección, compatibilidad y rendimiento predecible,
y luego escalar las cosas llamativas.
Por qué “ponerse al día” fue la jugada inteligente
En tecnología, “ponerse al día” se usa a menudo como insulto por personas que nunca han tenido que ejecutar una hoja de ruta bajo restricciones:
presupuesto de potencia, área de silicio, tiempo de verificación, madurez del ecosistema software, paridad con consolas, y la encantadora realidad de que
los juegos los envían estudios con plazos, no teóricos con pizarras blancas.
La decisión de AMD de entrar en el trazado de rayos en hardware más tarde —y de una forma más conservadora— tiene sentido si tratas las GPU como sistemas de producción.
Una GPU no es una sola característica. Es una pila: ISA, cachés, controladores de memoria, planificación, firmware, controladores, compiladores de shaders,
APIs del sistema operativo, motores de juego y canalizaciones de contenido. RT estresa casi todo eso a la vez.
“Ponerse al día” significa que puedes dejar que alguien más tome la primera ola de unknown-unknowns: bordes tempranos de APIs, errores de integración en motores,
nuevos errores en autoría de contenido (materiales malos explotan en trazadores de rutas), estabilidad de controladores bajo patrones de shader novedosos,
y los extraños precipicios de rendimiento que ocurren cuando estructuras de aceleración se enfrentan a escenas del mundo real.
La jugada inteligente no es “enviar RT primero”. La jugada inteligente es:
- Enviar RT cuando tu pila de software pueda sobrevivirlo (controlador, compilador, herramientas, cobertura de QA).
- Enviar RT cuando tu mercado lo necesite (consolas, motores, adopción por parte de desarrolladores).
- Enviar RT de forma que no destruya el rendimiento raster (porque la mayoría de los píxeles siguen siendo rasterizados).
- Enviar RT con una estrategia de escalado (porque RT por fuerza bruta es un impuesto de rendimiento).
Desde una perspectiva SRE, AMD optimizó para fiabilidad y resultados predecibles en una gran base instalada, no sólo para la tabla de benchmarks top.
Eso no es cobardía. Eso es operaciones.
Broma #1: El trazado de rayos es como observabilidad: una vez que lo activas, descubres inmediatamente cuánto no querías saber.
Hechos y contexto histórico que realmente importan
Aquí hay puntos concretos (no trivia) que explican por qué la estrategia de “ponerse al día” de AMD fue racional:
- RT fue “offline” durante décadas: los pipelines de cine/VFX usaron trazado de rayos mucho antes que las GPU en tiempo real, porque intercambiaban tiempo por calidad.
- DXR formalizó una API mainstream: DirectX Raytracing convirtió “RT como pipeline” en un estándar, no en una demo de proveedor.
- Las estructuras de aceleración BVH son el verdadero caballo de batalla: RT rápido depende de construir y recorrer BVH eficientemente; no es solo “añadir núcleos RT”.
- El RT en tiempo real temprano fue híbrido: casi todos los juegos que salieron usan raster + efectos RT limitados (sombras, reflejos, AO) en lugar de path tracing completo.
- Las consolas importaron: las consolas con AMD llevaron hardware RT a una plataforma fija masiva, empujando a los motores a tratar RT como una característica real, no opcional.
- El escalado se convirtió en parte del paquete RT: técnicas estilo DLSS/FSR convirtieron “demasiado lento” en “enviable” al intercambiar resolución por reconstrucción temporal.
- La madurez de controladores/compiladores es una ventaja competitiva: las cargas RT estresan los compiladores de shaders y la asignación de registros de forma diferente al raster clásico.
- El rendimiento RT suele estar limitado por memoria/latencia: la traversal puede ser incoherente; las cachés fallan; la latencia de memoria se vuelve el asesino silencioso.
- La consistencia del tiempo de frame supera el FPS pico: el stutter por compilación de shaders o picos de reconstrucción de BVH es lo que sienten los jugadores y de lo que vienen los tickets de soporte.
Lo que realmente cuesta el trazado de rayos: una taxonomía de cuellos de botella
1) Coste de construir/actualizar la estructura de aceleración (BVH)
RT no empieza con rayos. Empieza con estructuras de datos. El BVH (o similar) debe construirse o actualizarse para la geometría.
Las escenas dinámicas —personajes animados, objetos destructibles, props en movimiento— añaden coste de construcción/actualización, y ese coste puede variar por fotograma.
En términos operativos: el trabajo de BVH es un trabajo por lotes variable en tu camino crítico. Si no lo acotas, te hará recibir informes aleatorios de stutter a las 2 AM.
2) Incoherencia en traversal y sombreado
La rasterización tiene coherencia: píxeles vecinos suelen buscar texturas similares, seguir flujo de control parecido, impactar geometría similar.
RT puede destruir eso: los rayos rebotan a partes no relacionadas de la escena. Eso significa divergencia en la ejecución de shaders y una terrible localidad de caché.
Por eso “más cómputo” no arregla RT linealmente. A veces esperas memoria. A veces esperas fallos de caché.
A veces esperas ejecución divergente porque la mitad de la wavefront tomó una rama distinta.
3) Desruido y acumulación temporal
El RT en tiempo real suele usar pocos rayos por píxel. Sin desruido obtienes un desastre de puntos.
Los denoisers son cargas de cómputo con su propio comportamiento de ancho de banda y caché. También introducen problemas de estabilidad temporal:
ghosting, smearing y el dolor especial de “se ve bien en movimiento, se rompe cuando te detienes”.
4) Sobrecarga del controlador y compilación de pipeline
Los pipelines RT pueden aumentar variantes de shaders y la complejidad de compilación. Si pillas compilación en tiempo de ejecución —o peor, envías sin caché de shaders caliente—
tu bug de “RT es lento” es en realidad un incidente de “compilaste un shader en medio de la pelea”.
5) El impuesto oculto: huella de memoria
Los BVH requieren memoria. G-buffers adicionales requieren memoria. Efectos RT de mayor calidad significan más buffers intermedios.
Cuando la presión de VRAM aumenta, ves expulsiones, paginación y picos súbitos en el tiempo de frame.
Enfoque de AMD en RT: ingeniería pragmática, no apariencias
La entrada de AMD en RT con RDNA2 pareció un compromiso práctico: añadir soporte hardware (Ray Accelerators por CU) mientras se mantiene
la arquitectura más equilibrada para rendimiento raster y restricciones de consola.
Esa es la clave: AMD no construyó una GPU que sea “un dispositivo RT que también puede rasterizar”.
Construyeron GPUs que siguen siendo fundamentalmente raster-first, porque así es la mayor parte del contenido.
El “ponerse al día” está intencionalmente limitado por la realidad: coste, consumo, rendimiento de silicio y compatibilidad amplia.
Si manejas sistemas de producción, reconoces el patrón. No reconstruyes toda la plataforma para soportar una nueva característica.
Haces que la característica funcione dentro del sobre operativo existente. Luego iteras.
AMD también tenía un ancla estratégica distinta: las consolas. Cuando tu arquitectura está en consolas, optimizas para:
controladores estables, comportamiento de memoria predecible y eficiencia por vatio en una caja térmica fija.
Eso tiende a producir elecciones conservadoras y escalables en lugar de “lanzar transistores al problema y rezar”.
Aquí está la verdad incómoda: la adopción temprana de RT fue en parte un problema de relaciones con desarrolladores. Si los motores no envían rutas RT ampliamente,
el hardware RT es una casilla brillante. Una vez que las consolas hicieron RT más común, el momento de AMD pareció menos “tarde” y más “alineado”.
Medir primero: qué recopilar antes de “optimizar”
La forma más rápida de perder semanas es discutir el rendimiento RT basado en capturas de FPS promedio.
Quieres distribuciones de tiempo de fotograma, divisiones GPU/CPU, margen de VRAM y comportamiento de compilación de shaders.
Un flujo de trabajo fiable:
- Empieza con una escena reproducible: misma trayectoria de cámara, mismo punto de guardado, mismo clima/hora, mismo estado de NPC si es posible.
- Captura tiempos de fotograma, no solo FPS.
- Separa casos CPU-limitados de GPU-limitados.
- Prueba efectos RT individualmente (reflejos vs sombras vs GI) y registra las diferencias.
- Sigue la presión de VRAM y la memoria del sistema.
- Valida el comportamiento de la caché de shaders después de actualizaciones de controladores.
Cita (idea parafraseada): Werner Vogels popularizó la idea de que deberías construir sistemas esperando fallos, y diseñar para la resiliencia en lugar de la perfección.
— Werner Vogels (idea parafraseada)
Tareas prácticas: comandos, salida, significado, decisión
Estas tareas están escritas como si estuvieras de guardia y necesitas respuestas, no sensaciones. Se inclinan hacia Linux porque es scriptable y honesto,
pero los principios se aplican. Cada tarea incluye: comando, salida de ejemplo, qué significa y qué decisión tomar.
Tarea 1: Identificar la GPU y la pila de controladores
cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
0b:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [1002:744c]
Qué significa: Estás confirmando la GPU real (y el PCI ID), no lo que dicen las diapositivas de marketing.
Decisión: Si el dispositivo no coincide con el objetivo (RDNA2 vs RDNA3), detente. Tu “regresión RT” podría ser “host equivocado”.
Tarea 2: Confirmar versión del driver del kernel y Mesa/AMDGPU
cr0x@server:~$ uname -r
6.5.0-21-generic
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: AMD (0x1002)
Device: AMD Radeon RX 7900 XTX (navi31, LLVM 16.0.6, DRM 3.54, 6.5.0-21-generic) (0x744c)
Version: 23.2.1
Qué significa: El rendimiento y la estabilidad RT son extremadamente sensibles al controlador/compilador. Esto identifica la pila.
Decisión: Si estás en una Mesa/controlador antiguo y te quejas de RT, puede que estés benchmarking arqueología.
Tarea 3: Verificar que las extensiones de Vulkan para trazado de rayos estén presentes
cr0x@server:~$ vulkaninfo --summary | sed -n '1,80p'
Vulkan Instance Version: 1.3.275
Devices:
========
GPU0:
apiVersion = 1.3.275
deviceName = AMD Radeon RX 7900 XTX
driverVersion = 2.0.279
deviceType = DISCRETE_GPU
Device Extensions: count = 182
VK_KHR_acceleration_structure
VK_KHR_ray_tracing_pipeline
VK_KHR_deferred_host_operations
Qué significa: La ruta Vulkan RT está disponible. Si faltan estas extensiones, el juego/motor caerá silenciosamente a una alternativa.
Decisión: Extensiones faltantes significa que depuras empaquetado de controladores o entorno, no “rendimiento RT”.
Tarea 4: Comprobar relojes GPU y estado de potencia (para detectar “bloqueo en bajo consumo”)
cr0x@server:~$ cat /sys/class/drm/card0/device/pp_dpm_sclk
0: 500Mhz
1: 1500Mhz
2: 2400Mhz *
Qué significa: El asterisco muestra el nivel de rendimiento actual.
Decisión: Si estás atascado en relojes bajos bajo carga RT, tu problema es gestión de energía/termal, no núcleos RT.
Tarea 5: Detectar señales de throttling térmico
cr0x@server:~$ cat /sys/class/drm/card0/device/hwmon/hwmon*/temp1_input 2>/dev/null | head -n 1
78000
Qué significa: Temperatura en milidegrados Celsius (78°C aquí). Las cargas RT pueden cambiar la distribución de potencia y causar puntos calientes.
Decisión: Si las temperaturas son altas y los relojes bajan, arregla la refrigeración o los límites de potencia antes de cambiar ajustes.
Tarea 6: Comprobar uso de VRAM y presión de expulsión (señal rápida)
cr0x@server:~$ cat /sys/kernel/debug/dri/0/amdgpu_vram
VRAM size: 24576M
VRAM used: 21234M
GTT size: 32768M
GTT used: 6120M
Qué significa: Estás cerca de llenar la VRAM; vertidos a GTT (memoria del sistema) pueden provocar picos en el tiempo de fotograma.
Decisión: Reduce resolución de texturas/calidad RT, o aumenta margen cerrando apps. Si VRAM está cerca del tope, deja de perseguir ajustes de shader.
Tarea 7: Detectar cuello de botella CPU vs GPU con MangoHud
cr0x@server:~$ mangohud --dlsym ./game_binary
... MangoHud: GPU 98% CPU 35% frametime 21.3ms fps 47 ...
Qué significa: La GPU está saturada. Si la CPU estuviera al máximo y la GPU baja, estarías limitado por CPU.
Decisión: GPU limitado: ajusta opciones RT, resolución, denoiser. CPU limitado: reduce draw calls, mejora el threading o baja coste de simulación.
Tarea 8: Capturar la distribución de tiempos de fotograma (no el FPS promedio)
cr0x@server:~$ cat frametimes.csv | awk -F, 'NR>1{sum+=$2; if($2>p99) p99=$2} END{print "max_ms="p99, "avg_ms="sum/(NR-1)}'
max_ms=78.1 avg_ms=19.6
Qué significa: Un solo pico de 78 ms es un stutter visible por el usuario aunque el promedio esté bien.
Decisión: Si max/p95/p99 son malos, prioriza fuentes de stutter: compilación de shaders, paginación, reconstrucción de BVH, picos de CPU.
Tarea 9: Verificar que los directorios de caché de shaders existan y sean escribibles
cr0x@server:~$ ls -ld ~/.cache/mesa_shader_cache
drwx------ 12 cr0x cr0x 4096 Jan 13 09:12 /home/cr0x/.cache/mesa_shader_cache
Qué significa: Si la caché de shaders no puede persistir, recompilarás constantemente y obtendrás hitches “aleatorios”.
Decisión: Si los permisos son erróneos o la caché está en un sistema de archivos lento, corrige eso primero.
Tarea 10: Buscar picos de compilación de shaders en tiempo de ejecución en los logs (patrón de ejemplo)
cr0x@server:~$ journalctl --user -n 200 | grep -i -E "shader|pipeline|compile" | tail -n 5
Jan 13 09:22:41 gamehost game_binary[8123]: vkCreateRayTracingPipelinesKHR: compiling pipeline cache miss
Jan 13 09:22:41 gamehost game_binary[8123]: stutter-warning: pipeline compilation took 145ms
Qué significa: La compilación de pipeline ocurrió en el camino crítico.
Decisión: Precompila pipelines, distribuye una caché de pipeline, o reestructura para compilar asíncronamente antes de que la escena lo necesite.
Tarea 11: Comprobar velocidad del enlace PCIe (culpable clásico de “por qué el streaming es malo?”)
cr0x@server:~$ sudo lspci -s 0b:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16
Qué significa: Estás a la velocidad/anchura PCIe esperada. Si cae (x4 o menos), el streaming y las cargas pueden bloquearse.
Decisión: Si el enlace está degradado, recoloca la GPU, arregla ajustes BIOS o cambia de ranura antes de culpar a RT.
Tarea 12: Detectar presión de memoria e intercambio (amplificador de stutter)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 28Gi 1.2Gi 1.0Gi 2.8Gi 2.1Gi
Swap: 8.0Gi 2.1Gi 5.9Gi
Qué significa: Estás intercambiando. RT + texturas de alta resolución pueden empujar la memoria del sistema también, especialmente con apps en segundo plano.
Decisión: Cierra apps que consumen memoria, aumenta RAM, reduce ajustes de textura o corrige fugas. El intercambio hace que todo parezca un problema de RT.
Tarea 13: Inspeccionar latencia de I/O para caché de shaders y streaming de assets
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
18.21 0.00 4.12 6.70 0.00 70.97
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await wareq-sz aqu-sz %util
nvme0n1 58.0 4120.0 0.0 0.0 1.20 71.0 42.0 2048.0 9.80 48.8 0.55 62.0
Qué significa: Write await es alto (9.8 ms). Si tu caché de shaders está en un disco lento o muy ocupado, verás hitches.
Decisión: Mueve la caché a almacenamiento más rápido, reduce I/O en segundo plano o ajusta opciones del sistema de ficheros.
Tarea 14: Confirmar comportamiento del sistema de archivos para la caché (noatime reduce escrituras inútiles)
cr0x@server:~$ mount | grep " /home "
/dev/nvme0n1p2 on /home type ext4 (rw,noatime,errors=remount-ro)
Qué significa: noatime evita actualizar tiempos de acceso en lecturas, reduciendo la carga de metadatos.
Decisión: Si tu directorio de caché vive en un montaje con muchas actualizaciones de metadatos, considera ajustes. No es glamuroso, pero es medible.
Tarea 15: Validar que los toggles de RT realmente cambien el trabajo en GPU
cr0x@server:~$ grep -E "rt_enabled|rt_reflections|rt_shadows" ~/.config/game/settings.ini
rt_enabled=1
rt_reflections=0
rt_shadows=1
Qué significa: Te sorprendería con qué frecuencia los toggles de UI no se aplican hasta reiniciar, o son sobrescritos por presets.
Decisión: Si los toggles no persisten, detén A/B testing hasta arreglar la canalización de configuración.
Tarea 16: Prueba rápida de cordura: baseline solo raster vs delta con RT activado
cr0x@server:~$ ./bench_scene.sh --preset raster --runs 3
run1 avg_fps=124 p99_ms=11.3
run2 avg_fps=122 p99_ms=11.9
run3 avg_fps=123 p99_ms=11.6
cr0x@server:~$ ./bench_scene.sh --preset rt_medium --runs 3
run1 avg_fps=68 p99_ms=24.8
run2 avg_fps=66 p99_ms=26.1
run3 avg_fps=67 p99_ms=25.4
Qué significa: RT añade tanto una penalización de rendimiento (FPS) como una penalización en latencia cola (p99).
Decisión: Si p99 empeora más que el promedio, enfócate en picos (reconstrucción BVH, fallos de caché, compilación) antes de perseguir velocidad bruta.
Broma #2: Activar configuraciones RT ultra para “probar estabilidad” es como poner tu base de datos a prueba de carga incendiándola—técnicamente informativo, emocionalmente caro.
Guía rápida de diagnóstico
Este es el flujo “tienes 30 minutos antes de la reunión”. Está ordenado para aislar primero las mayores categorías.
Primero: demuestra qué estás ejecutando
- Confirma GPU + pila de controladores (Tarea 1–2). Si no puedes nombrarlo, no puedes arreglarlo.
- Confirma la ruta API: DXR/extensiones Vulkan RT presentes (Tarea 3). Sin extensiones, no hay ruta RT.
- Confirma que los ajustes se aplican (Tarea 15). La UI miente; los archivos de configuración rara vez lo hacen.
Segundo: clasifica el cuello de botella (CPU, GPU, memoria, I/O)
- GPU vs CPU (Tarea 7). Esto determina si ajustas settings o hilos.
- Margen de VRAM (Tarea 6). Si estás cerca del límite, “RT es lento” puede ser “la paginación es lenta”.
- Swap del sistema (Tarea 12). El swapping empeora las colas de tiempo de fotograma.
- Latencia de almacenamiento (Tarea 13). Hitches por shader/assets pueden ser I/O, no GPU.
Tercero: busca picos, no promedios
- Distribución de tiempos de fotograma (Tarea 8). p95/p99 son la verdad.
- Evidencia de compilación de shaders/pipelines (Tarea 10, Tarea 9). Arregla cachés y estrategia de precompilación.
- Termales/estado de potencia (Tareas 4–5). Si los relojes caen, pierdes la carrera antes de empezar.
Cuarto: solo entonces ajusta RT
- Desactiva un efecto RT a la vez (sombras, reflejos, GI).
- Reduce cuentas de rebotes y distancia de rayos.
- Prefiere presets de denoiser estables sobre los agresivos que generan shimmer.
- Usa escalado inteligentemente; no trates de presumir nativo 4K RT como logro moral.
Tres microhistorias corporativas (de las que se aprende)
Microhistoria 1: El incidente causado por una suposición errónea
Un estudio mediano lanzó un parche RT para un título multiplataforma. Probaron en unas pocas GPUs de alta gama, vieron buenos promedios
y declararon victoria. Los tickets de soporte llegaron como lluvia: “RT provoca stutter cada vez que entro en una nueva zona.”
La suposición errónea fue simple: asumieron que “la compilación de shaders sucede durante las pantallas de carga”.
En su integración con el motor, las variantes de pipeline RT para ciertos materiales solo se solicitaban la primera vez que aparecía una combinación específica
de luces y superficies. Eso ocurrió a mitad del juego.
En algunos sistemas, el directorio de caché de shaders estaba en un SSD SATA lento y casi lleno. En otros, vivía en una carpeta home sincronizada por red.
La compilación en sí era cara; las escrituras de caché lo empeoraban. Los jugadores no veían un juego lento. Veían uno inconsistente.
La solución no fue sintonía mágica de RT. Fue disciplina operativa: distribuir una caché de pipeline calentada, compilar por adelantado durante
transiciones conocidas y registrar fallos de caché con suficiente contexto para reproducirlos. También añadieron una opción para ejecutar un pase de “calentamiento de shaders”
después de actualizaciones de controladores.
Su mayor victoria fue cultural: el equipo dejó de usar FPS promedio como puerta de lanzamiento y empezó a usar umbrales p99 por escena.
Las quejas por stutter bajaron drásticamente, aunque el FPS promedio apenas cambió.
Microhistoria 2: La optimización que salió mal
Un equipo gráfico interno intentó “optimizar reflejos RT” aumentando la longitud de los rayos y reduciendo el número de muestras,
confiando en el denoiser para rellenar los huecos. En papel: menos rayos, fotogramas más rápidos.
En la práctica, los rayos más largos golpearon más geometría, causaron más pasos de traversal y produjeron entradas más ruidosas para el denoiser.
El denoiser entonces necesitó más acumulación temporal para estabilizarse. Eso introdujo ghosting durante movimientos rápidos de cámara.
El equipo respondió con más pasadas de denoiser. La utilización GPU subió, no bajó. Peor aún: el ancho de banda de memoria se disparó, porque el denoiser
movía muchos datos a través de múltiples buffers. En ciertas tarjetas AMD, la carga se volvió más sensible al comportamiento de caché y mostró picos p99 mayores.
Revirtieron y tomaron el enfoque aburrido pero efectivo: rayos más cortos, ligeramente más muestras y un preset de denoiser diseñado para estabilidad.
El rendimiento no “ganó” en una diapositiva, pero el juego se sintió mejor y produjo menos artefactos en casos límite.
La lección: las “optimizaciónes” RT que aumentan la varianza son deuda operativa. Si no puedes predecirlo, no puedes enviarlo con seguridad.
Microhistoria 3: La práctica aburrida pero correcta que salvó el día
Un equipo de plataforma mantenía un laboratorio de máquinas de prueba GPU. No era glamuroso. Mayormente cables, etiquetas y una hoja de cálculo.
Pero hacían cumplir una política: cada ejecución de rendimiento registra versión de driver, versión del kernel, hash de build del juego, archivo de configuración y una trayectoria de cámara fija.
Durante una actualización mayor, alguien informó “RT está 20% más lento en AMD ahora.” Internet habría convertido eso en una carrera hacia la pared.
El laboratorio no lo hizo. Rehicieron la misma prueba con la misma trayectoria de cámara y luego compararon pilas de drivers.
La regresión se correlacionó con una actualización de driver que cambió el comportamiento del compilador de shaders. El build del juego no cambió.
El equipo lo reprodujo en múltiples máquinas, capturó trazas y entregó al proveedor un paquete de repro muy ceñido.
Mientras tanto, lanzaron una mitigación: un cambio menor de contenido que redujo la divergencia de materiales en el paso RT,
más un ajuste de preset por defecto que recuperó latencia de cola de fotogramas. Los usuarios vieron mejora rápidamente.
La práctica aburrida —metadatos estructurados de prueba y reproducibilidad— convirtió una potencial tormenta de culpas en un ticket de ingeniería resoluble.
No hizo titulares. Salvó la release.
Errores comunes: síntoma → causa raíz → solución
Esta sección es deliberadamente específica. Estos son los modos de fallo que hacen perder tiempo a equipos reales.
1) Síntoma: RT “mata el FPS” pero la utilización GPU es baja
Causa raíz: Frame limitado por CPU, a menudo por aumento de draw calls, BVH construido en CPU o threading pobre.
Solución: Reduce trabajo en CPU (culling, batching), mueve trabajo BVH a GPU cuando sea aplicable, perfila hilos y valida que no estés compilando pipelines en el hilo principal.
2) Síntoma: Microstutter al entrar en nuevas áreas
Causa raíz: Compilación de pipeline/shader en tiempo de ejecución y fallos de caché; stalls por streaming de assets.
Solución: Precompila pipelines, calienta cachés de shaders, mueve caché a almacenamiento local rápido y prepara assets con antelación.
3) Síntoma: FPS promedio suave, picos p99 feos
Causa raíz: Evicción de VRAM, picos de reconstrucción BVH, I/O en segundo plano o tareas periódicas del SO.
Solución: Asegura margen de VRAM, reduce número de buffers RT, limita coste de actualización de BVH y aisla el entorno de pruebas de carga en segundo plano.
4) Síntoma: Reflejos RT “chispeantes” o inestables
Causa raíz: Muy pocos rayos por píxel, ajustes de denoiser demasiado agresivos o vectores de movimiento desincronizados.
Solución: Incrementa ligeramente el número de muestras, ajusta distancia de rayos, verifica vectores de movimiento y elige ajustes de denoiser que prioricen estabilidad temporal.
5) Síntoma: Tras una actualización de driver, el rendimiento RT cambia dramáticamente
Causa raíz: Cambios en el compilador de shaders e invalidación de cachés; diferente asignación de registros y ocupación de waves.
Solución: Reconstruye cachés de shaders, reejecuta baselines y trata los drivers como parte de tu matriz de releases.
6) Síntoma: RT activado provoca crashes o device lost bajo carga
Causa raíz: Uso de VRAM no acotado, estructuras de aceleración demasiado grandes o bugs en driver/firmware activados por shaders raros.
Solución: Añade guardrails: limita geometría en el pase RT, reduce resolución RT, valida asignaciones de memoria y construye repros mínimos.
7) Síntoma: RT parece peor en un proveedor “sin razón”
Causa raíz: Patrones de shader específicos del proveedor, sensibilidad a la divergencia o dependencia de una función de upscaler con comportamiento distinto.
Solución: Usa perfiles neutrales al proveedor, prueba con presets de escalado equivalentes y evita asumir cómo se acelera la traversal.
Listas de verificación / plan paso a paso
Lista A: Si estás comprando/eligendo hardware para cargas RT
- Define el objetivo: 60 fps bloqueados, 120 fps competitivos o “cinemático 40 fps”. No finjas que son el mismo requisito.
- Elige escenas que coincidan con tu carga real: follaje, multitudes, interiores reflectantes, neón nocturno—todos estresan RT de forma distinta.
- Mide p95/p99 del tiempo de fotograma, no solo promedios.
- Presupuesta margen de VRAM (al menos unos GB) para buffers RT y parches futuros.
- Decide tu política de escalado desde el inicio (FSR/DLSS/nativo). RT sin escalado es un lujo.
- Valida la madurez de drivers para tu SO y versión de motor.
Lista B: Si eres un estudio que envía RT en AMD (y en todas partes)
- Construye una ruta de benchmark reproducible (trayectoria de cámara fija, semilla fija, archivo de settings fijo).
- Envía un camino de calentamiento de shaders/pipelines y registra fallos de caché.
- Expone características RT como toggles independientes (sombras/reflejos/GI) y mantiene presets sensatos.
- Limita coste de construcción/actualización de estructuras de aceleración por fotograma; difiere actualizaciones no críticas.
- Prefiere denoising estable sobre hacks agresivos de pocas muestras que shimmer.
- Prueba presión de VRAM explícitamente: “casi lleno” es un modo de prueba separado.
- Mantén una matriz de drivers y reejecuta baselines tras cambios de driver.
- Haz de “tiempo de fotograma p99” una puerta de lanzamiento para presets RT.
Lista C: Si estás resolviendo “RT es lento” como operador
- Confirma hardware y pila de controladores (Tareas 1–2).
- Confirma disponibilidad de API RT (Tarea 3).
- Clasifica el cuello de botella (Tarea 7, 6, 12, 13).
- Mide colas de tiempo de fotograma (Tarea 8, 16).
- Busca compilación (Tarea 10) y problemas de caché (Tarea 9).
- Comprueba termales y relojes (Tareas 4–5).
- Sólo entonces ajusta settings RT; no ajustes a ciegas.
Preguntas frecuentes
1) ¿AMD es “mala en trazado de rayos”?
No. El rendimiento RT de AMD depende mucho del juego, la integración del motor y los ajustes. Cuanto más una carga esté limitada por latencia de memoria y divergencia,
más se notarán las diferencias arquitectónicas. Trátalo como un problema de ajuste de carga, no como una pelea moral.
2) ¿Por qué RT se siente peor que raster incluso cuando el FPS parece estar bien?
Porque RT a menudo empeora la latencia de cola. Los tiempos de fotograma p99 importan más para la percepción de fluidez que el FPS promedio.
Los picos vienen de compilación, reconstrucción de BVH y presión de memoria.
3) ¿Por qué los reflejos cuestan tanto más que las sombras a veces?
Los reflejos suelen requerir rayos más largos, sombreado más complejo y más impactos incoherentes. Las sombras pueden ser más baratas si son
de rango limitado y de un solo rebote.
4) ¿Debería siempre activar el escalado con RT?
En la mayoría de títulos en tiempo real, sí. El escalado forma parte del presupuesto de rendimiento RT. Ejecuta a una resolución interna menor y usa
el tiempo ahorrado en efectos RT y desruido estable.
5) ¿Cuál es la mayor “trampa” en pruebas de rendimiento RT?
Caché de shaders y compilación de pipelines. Si tu primera ejecución incluye compilación y la segunda no, no benchmarkeaste RT;
benchmarkeaste tu pipeline de build.
6) ¿Por qué una actualización de driver puede cambiar tanto el rendimiento RT?
Los pipelines shader RT estresan a los compiladores de forma distinta: asignación de registros, scheduling y ocupación pueden cambiar.
Además, las actualizaciones de driver pueden invalidar cachés, causando stutter en la primera ejecución.
7) ¿Qué deberían priorizar los estudios: FPS pico o consistencia del tiempo de fotograma?
Consistencia. Un 60 fps estable con buen p99 se siente mejor que un promedio de 90 fps con picos regulares de 40 ms.
La estabilidad también reduce la carga de soporte y las reseñas negativas.
8) ¿Significa “más hardware RT” automáticamente mejor RT?
No automáticamente. La traversal y el sombreado pueden verse limitados por latencia de memoria, comportamiento de caché, divergencia y coste del denoiser.
El hardware ayuda, pero la carga y la pila de software deciden el resultado.
9) Si estoy limitado por GPU con RT activado, ¿qué ajuste suele dar la mejor ganancia?
Reduce la resolución RT (a menudo mediante modo de escalado), luego reduce distancia de rayos y número de rebotes.
Desactivar el efecto RT más costoso (a menudo reflejos/GI) puede recuperar mucho tiempo de fotograma.
Próximos pasos prácticos
Si te llevas una cosa de la historia RT de AMD, que sea esta: la secuenciación importa. Enviar RT más tarde con una pila robusta no es fracaso;
es un intercambio disciplinado entre ambición de característica y corrección operativa.
Haz esto a continuación, en orden:
- Deja de discutir sobre el FPS promedio. Recopila p95/p99 de tiempos de fotograma y toma decisiones desde las colas.
- Construye una ruta de benchmark RT reproducible y registra la pila completa: driver, kernel, hash de build, settings.
- Guarda margen de VRAM. Si estás a un par de GB del límite, tu próximo parche se convertirá en generador de stutter.
- Arregla el comportamiento de compilación de shaders/pipelines. Calienta cachés, precompila y mantén el hilo principal limpio.
- Sintoniza RT como un operador: aísla una variable a la vez, mide deltas y prioriza estabilidad sobre victorias frágiles.
“Ponerse al día” es lo que llamas cuando sólo miras la carrera. Cuando ejecutas el sistema, lo llamas gestión de riesgos.