FSR explicado: cómo AMD popularizó el upscaling

Por qué ganó el upscaling (y por qué FSR importó)

Renderizar en la resolución nativa es la historia más limpia que puedes contar. También es la más cara que puedes enviar.
Las pilas de render modernas son glotonas: materiales basados en física, volumetría, trazado de rayos, postprocesado profundo y suficientes
shaders como para que tu GPU parezca que está haciendo impuestos.

El upscaling ganó porque es la única palanca que mueve de forma fiable tanto la calidad de imagen como el rendimiento sin rediseñar todo el frame.
Reduce la resolución interna, reconstruye el detalle faltante y gasta el presupuesto ahorrado en otra parte: mejor iluminación, mayor distancia de visión,
tiempos de frame más estables. Es un compromiso, pero en producción todo lo es.

AMD hizo que el upscaling fuera mainstream no porque FSR fuera “el mejor” en cada comparación de instantánea, sino porque era desplegable.
Era abierto, multiplataforma y no exigía un camino específico de acelerador AI. Eso permitió que los estudios lo trataran como una característica,
no como una negociación de asociación.

Qué significa “mainstream” en términos operativos

Mainstream significa que tu característica se vuelve parte del árbol de solución de problemas por defecto. Se convierte en algo que QA activa,
en algo sobre lo que soporte pregunta y en algo que los presupuestos de rendimiento asumen que estará activado en una gran parte de sistemas.
Mainstream también significa que no puedes tratarlo como “opcional y bonito”. Cuando falla, falla en voz alta.

Si gestionas un producto en vivo, ya conoces el patrón: se lanza una nueva característica gráfica; la mitad de tu base de jugadores nunca la toca;
un cuarto la activa y está satisfecho; un diez por ciento tercamente la usa en combinaciones extrañas con overlays, herramientas de captura, modos VRR
y ramas de controladores que se actualizaron por última vez en otra administración. Ese diez por ciento es donde vive tu pager.

FSR 1, 2, 3: el árbol familiar sin la niebla del marketing

FSR 1: upscaling espacial y realce

FSR 1 es un upscaler espacial. Observa un solo frame e intenta escalarlo usando lógica consciente de bordes, luego aplica un realce
(RCAS) para contrarrestar el desenfoque. No “entiende” el movimiento. No usa historial. Es rápido, simple y fácil de integrar.
También puede parecer una conjetura muy segura cuando el contenido es complejo.

La ventaja operativa es enorme: menos entradas, menos minas de integración, menos formas de estar sutilmente equivocado.
La desventaja es igualmente práctica: solo puedes reconstruir hasta cierto punto desde un solo frame. El detalle fino a resoluciones de entrada bajas se vuelve
deseo. Un upscaler espacial puede ser estable o nítido, pero a menudo le cuesta ser ambas cosas.

FSR 2: reconstrucción temporal (la versión adulta)

FSR 2 es upscaling temporal. Usa múltiples frames, vectores de movimiento, profundidad e información de exposición para reconstruir detalle a lo largo del tiempo.
Esta es la categoría “seria”: es donde la calidad salta, y donde los errores de integración se vuelven visibles como ghosting, shimmering,
UI rota o desoclusión ruidosa.

Las técnicas temporales son poderosas porque aprovechan información del tiempo. También son frágiles porque el tiempo es donde cada
motor tiene sus pecados: patrones de jitter, manejo de histórico de TAA, masking reactivo, transparencias, partículas y postefectos que
nunca fueron diseñados para ser “reproyectados”.

FSR 3: la generación de frames entra en escena

FSR 3 añade generación de frames (interpolación) más gestión de latencia al estilo anti-lag (según la implementación).
Puede incrementar dramáticamente los FPS mostrados sintetizando frames intermedios a partir del movimiento.
Esto no es lo mismo que “más rendimiento”. Son más frames mostrados; tu simulación puede seguir ejecutándose a la misma tasa.

La generación de frames es donde dejas de hablar de FPS promedio y empiezas a hablar de pacing de frames, latencia de entrada y artefactos
bajo movimiento rápido. También es donde “mi benchmark marca 160 FPS” se encuentra con “¿por qué se siente como 60?”.

Una regla práctica corta: si tu tasa base de frames es inestable o baja, la generación de frames puede hacer que la inestabilidad parezca más suave
mientras tu latencia de entrada sigue sin impresionarse.

Cómo funciona FSR por dentro (qué necesita y qué rompe)

Espacial vs temporal: la diferencia real

El upscaling espacial es una transformación por frame. Ve píxeles y bordes. No tiene memoria.
Por eso es robusto y por qué no puede reconstruir mágicamente detalle subpíxel.

El upscaling temporal trata el frame actual como una muestra en una serie temporal. Asume que los vectores de movimiento son correctos,
que la profundidad es coherente, que el jitter es conocido y consistente, y que tu motor le está dando entradas limpias.
Cuando esas suposiciones se mantienen, el resultado es impresionante. Cuando no, el resultado es “¿por qué mi arma deja una estela atrás?”

Las entradas que esperan los upscalers temporales tipo FSR 2

• Vectores de movimiento que representen el movimiento de píxeles/geometría entre frames.
• Buffer de profundidad para manejo de desoclusión y decisiones de reconstrucción.
• Offset de jitter y un patrón de jitter de cámara consistente.
• Exposición / preexposición para que el mezclado de histórico no explote con cambios de brillo.
• Masks reactivas / transparencia para reducir ghosting en partículas, agua y elementos tipo UI.

Fallar una de estas, y puede que aún envíes. Simplemente envías un misterio.

Dónde suele fallar la integración

El mayor modo de fallo no es “el algoritmo es malo”. Es “las entradas mienten”.
Vectores de movimiento que no incluyen meshes skinneados animados. Vectores generados en un espacio distinto al esperado.
Profundidad postprocesada o invertida sin configuración coincidente.
Jitter aplicado a un pase pero no al que alimenta los vectores.
UI dibujada antes del upscaling y luego tratada como parte del mundo.

Los upscalers son como el monitoreo: amplifican fielmente lo que les das, incluidos tus errores.

Nitidez: una perilla de calidad que también genera quejas de clientes

El realce es seductor. Hace que las capturas se vean nítidas. También hace más visibles el shimmer en movimiento, el aliasing de texturas y el ruido especular.
Tu mejor valor por defecto de nitidez rara vez es “el más nítido”. Es el que no convierte el follaje en un enjambre de abejas.

Chiste #1: Poner la nitidez al 100% es como gritar en una reunión—técnicamente estás más claro, pero nadie está más contento.

Generación de frames: por qué debería importarle a la gente de ops

La generación de frames cambia la forma de las quejas. Verás menos tickets de “bajos FPS” y más “se siente con lag”,
“el ratón está flotando” y “artefactos al girar rápido”.
Si gestionas dashboards de rendimiento, deja de tratar FPS como el KPI único. Empieza a rastrear:
tiempo de frame p99, varianza de tiempo de frame, y marcadores de latencia.

Una cita de fiabilidad que debe aparecer en cada revisión de rendimiento:
“La esperanza no es una estrategia.” — General Gordon R. Sullivan

No “esperas” que el motor provea vectores correctos. Lo verificas con herramientas de captura y pruebas repetibles.

Benchmark práctico: medir lo que sienten los jugadores

Por qué el FPS promedio es una trampa

El FPS promedio es un valor medio que oculta lo que los jugadores realmente perciben: la inconsistencia.
Un juego puede promediar 120 FPS y aun así sentirse mal si hay picos en los tiempos de frame cada pocos segundos.
El upscaling puede subir el promedio mientras deja los picos intactos porque los picos vienen de bloqueos de CPU, compilación de shaders,
streaming o puntos de sincronización.

Haz benchmarks como un SRE, no como una diapositiva de marketing

El ciclo es simple:
define la carga → controla las variables → captura tiempos de frame → compara distribuciones → interpreta el cuello de botella.
Si no puedes volver a ejecutar exactamente la misma ruta de escena, tu benchmark es una comprobación de vibes, no datos.

Toma decisiones basadas en:
tiempo de frame mediano, p95, p99, y p99.9 si puedes.
Luego valida con una medición de latencia de entrada si estás usando generación de frames.

Los modos de calidad no son solo “rendimiento vs calidad”

Los modos clásicos (Quality, Balanced, Performance, Ultra Performance) son en realidad diferentes resoluciones de entrada y presupuestos de reconstrucción.
Bajar la resolución de entrada puede exponer problemas:
geometría delgada que parpadea, patrones de moiré, popping agresivo de LOD, aliasing especular.
A veces “Balanced” se ve mejor que “Performance” no porque el algoritmo cambie, sino porque la entrada deja de dejarlo hambriento.

Decide qué estás optimizando

Si apuntas a TVs a 60 Hz, optimizas por estabilidad y pacing consistente.
Si apuntas a monitores competitivos de alta frecuencia, optimizas por latencia y artefactos mínimos bajo movimiento rápido.
Las configuraciones de FSR (y si usar generación de frames) deben seguir esa decisión, no al revés.

Tareas prácticas: 12+ comandos reales, salidas y decisiones

Estas son tareas prácticas que puedes ejecutar en una caja Linux de juego/workstation o en una máquina de build/QA para diagnosticar problemas de GPU/CPU/controlador y
pacing alrededor del upscaling. El objetivo no es “probar que FSR es bueno”. El objetivo es encontrar la restricción y arreglar la canalización.

Tarea 1: Confirmar GPU, driver y básicos del kernel

cr0x@server:~$ uname -r
6.8.0-41-generic

Qué significa: La versión del kernel puede afectar el comportamiento del scheduler y la compatibilidad del driver GPU.

Decisión: Si estás en un kernel LTS antiguo con GPUs más nuevas, prueba un stack de kernel/driver más reciente antes de culpar a artefactos de FSR.

cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700 XT] [1002:73df]

Qué significa: Confirma el modelo real de GPU. Esto importa para soporte de características y rendimiento esperado.

Decisión: Usa esto para agrupar máquinas de prueba; no compares resultados entre diferentes tiers de GPU y lo llames “variación de FSR”.

Tarea 2: Comprobar versiones de Mesa/driver (culpable silencioso común)

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 6700 XT (radeonsi, navi22, LLVM 17.0.6, DRM 3.57, 6.8.0-41-generic) (0x73df)
    Version: 24.1.3
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.1.3

Qué significa: Identifica la versión de Mesa y la ruta del driver. Muchas quejas sobre FSR son regresiones de driver o rarezas del compilador de shaders.

Decisión: Si aparecen artefactos “tras una actualización”, fija o bisecta versiones de Mesa/driver. No ajustes la nitidez para ocultar una regresión.

Tarea 3: Verificar identidad del driver Vulkan (FSR se usa a menudo en títulos Vulkan)

cr0x@server:~$ vulkaninfo --summary | sed -n '1,40p'
VULKANINFO SUMMARY
==================
Instance Version: 1.3.283

Devices:
========
GPU0:
    apiVersion         = 1.3.280
    driverVersion      = 2.0.310
    vendorID           = 0x1002
    deviceID           = 0x73df
    deviceName         = AMD Radeon RX 6700 XT

Qué significa: Confirma la versión de Vulkan y el dispositivo en uso.

Decisión: Si ves la GPU incorrecta (iGPU), fuerza la selección de la discreta antes de investigar calidad/rendimiento de FSR.

Tarea 4: Identificar si estás bound por CPU o GPU en tiempo de ejecución

cr0x@server:~$ sudo apt-get install -y mangohud
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  mangohud
0 upgraded, 1 newly installed, 0 to remove and 12 not upgraded.

Qué significa: MangoHud proporciona gráficos de tiempo de frame y un overlay de métricas GPU/CPU para Vulkan/OpenGL.

Decisión: Úsalo para determinar si FSR (una palanca del lado GPU) realmente puede ayudar a tu cuello de botella.

cr0x@server:~$ mangohud --dlsym vkcube
MangoHud: Uploading is disabled (permit_upload = 0)

Qué significa: Puedes inyectar el overlay en una app Vulkan. En un juego lo lanzarías mediante las opciones de lanzamiento de Steam de forma similar.

Decisión: Si la utilización GPU es baja mientras los tiempos de frame son altos, deja de tocar FSR primero; probablemente estás limitado por CPU/IO.

Tarea 5: Capturar lo básico del pacing de frames (modo de presentación y refresco)

cr0x@server:~$ xrandr --verbose | sed -n '1,40p'
Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 32767 x 32767
DisplayPort-0 connected primary 2560x1440+0+0 (0x4a) normal (normal left inverted right x axis y axis) 597mm x 336mm
	2560x1440     165.00*+  144.00    120.00    60.00

Qué significa: Muestra la tasa de refresco y el modo actual.

Decisión: Al evaluar FSR 3 y generación de frames, bloquea la prueba a un objetivo de refresco fijo (p. ej., 120 Hz) para interpretar el pacing.

Tarea 6: Comprobar el governor de CPU (el clásico “¿por qué tartamudea en portátiles?”)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Qué significa: La CPU está priorizando ahorro de energía; la respuesta de boost puede ser más lenta, incrementando picos en tiempos de frame.

Decisión: Cambia a performance para benchmarks; de lo contrario estás midiendo política de energía, no upscaling.

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Qué significa: Establece el governor de rendimiento para pruebas estables.

Decisión: Vuelve a ejecutar tu captura tras este cambio. Si los picos se reducen, documenta la política de energía como parte de los pasos para reproducir.

Tarea 7: Confirmar que no estás limitando térmicamente

cr0x@server:~$ sensors | sed -n '1,40p'
amdgpu-pci-0300
Adapter: PCI adapter
edge:         +76.0°C  (crit = +100.0°C, hyst = -273.1°C)
junction:      +92.0°C  (crit = +110.0°C, hyst = -273.1°C)

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +83.5°C

Qué significa: Temperaturas de junction altas pueden inducir bajadas de reloj GPU; Tctl de CPU puede limitar el boost.

Decisión: Si los relojes bajan en escenas pesadas, arregla la refrigeración o límites de energía antes de juzgar los modos FSR.

Tarea 8: Observar relojes de GPU y utilización bajo carga

cr0x@server:~$ sudo radeontop -d - -l 1 | head -n 10
Dumping to stdout
gpu 99.12%  ee 0.00%  vgt 92.45%  ta 88.12%  sx 61.33%  sh 97.44%  spi 72.88%  sc 55.11%
vram  512.00mb  gtt  238.00mb  mclk 2000.00MHz  sclk 2450.00MHz

Qué significa: La GPU está cerca de saturación; FSR (bajar resolución interna) puede ayudar.

Decisión: Si la GPU está al tope, prueba FSR Quality vs Balanced y compara tiempos de frame p99, no solo FPS promedio.

Tarea 9: Comprobar presión de VRAM (stutter que parece “FSR roto”)

cr0x@server:~$ cat /proc/meminfo | grep -E "MemAvailable|SwapTotal|SwapFree"
MemAvailable:   11248320 kB
SwapTotal:       2097148 kB
SwapFree:        2097148 kB

Qué significa: La disponibilidad de RAM del sistema es saludable; swap sin usar.

Decisión: Si MemAvailable es bajo y swap está en uso, los stalls por streaming pueden dominar; reduce ajustes de texturas antes de culpar al upscaling.

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/amdgpu_vram | head
VRAM total size: 12272 MiB
VRAM usable size: 12272 MiB
VRAM used: 10384 MiB

Qué significa: El uso de VRAM es alto. El upscaling puede reducir tamaños de render target, pero texturas y geometría siguen dominando.

Decisión: Si VRAM usada está cerca del total, reduce la resolución de texturas o características RT; no esperes que solo FSR arregle los hitching.

Tarea 10: Detectar compilación de shaders o problemas de caché de pipeline

cr0x@server:~$ journalctl --user -b | grep -iE "shader|pipeline|vulkan" | tail -n 10
Jan 13 09:11:22 desktop steam[4121]: Fossilize INFO: Using read-only directory: /home/cr0x/.steam/steam/steamapps/shadercache
Jan 13 09:11:29 desktop steam[4121]: Fossilize INFO: Processed 128 pipeline cache entries

Qué significa: La actividad de caché de pipeline indica que se están compilando shaders/creando pipelines.

Decisión: Si el stutter coincide con misses de caché, calienta las cachés en ejecuciones de QA; no atribuyas el stutter de la primera ejecución a modos de FSR.

Tarea 11: Medir latencia de IO en disco (cuellos de botella de streaming de assets)

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    3.10    2.55    0.00   82.04

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         85.00   9200.00     0.00   0.00    1.20   108.24   42.00   2100.00     5.00  10.64    3.80    50.00    0.30  22.00

Qué significa: r_await/w_await son bajos; el disco no es el cuello de botella aquí.

Decisión: Si los await se disparan (decenas de ms) durante los hitching, resuelve IO/streaming primero. El upscaling no arreglará un disco lento.

Tarea 12: Buscar procesos que roban CPU y ruido de scheduling

cr0x@server:~$ top -b -n 1 | head -n 20
top - 09:22:10 up  2:11,  1 user,  load average: 3.02, 2.41, 2.12
Tasks: 356 total,   2 running, 354 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.3 us,  2.8 sy,  0.0 ni, 84.9 id,  0.8 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :  32036.7 total,  13420.2 free,  10412.1 used,   8204.4 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  21624.6 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 4121 cr0x      20   0 4102328 512844 142112 S   3.3   1.6   1:12.44 steam
 2210 cr0x      20   0  834520  94128  62152 S   2.7   0.3   0:33.10 chrome

Qué significa: La CPU global está mayormente idle; no hay hogs obvios. Pero navegadores y overlays aún pueden introducir jitter.

Decisión: Para una repro limpia, detén apps de fondo y overlays. Si el problema desaparece, documenta el conflicto en lugar de decir “FSR inestable”.

Tarea 13: Validar compositor/tipo de sesión (diferencias Wayland/Xorg)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Qué significa: La sesión es Wayland. Algunas herramientas de captura/overlay se comportan diferente que en Xorg.

Decisión: Si los problemas de pacing aparecen solo en un tipo de sesión, reproduce en el otro antes de cambiar ajustes de upscaling dentro del juego.

Tarea 14: Capturar una métrica básica de FPS y tiempo de frame usando logs de MangoHud

cr0x@server:~$ mangohud --output_folder /tmp/mhud --log_duration 30 --dlsym vkcube
MangoHud: writing output to /tmp/mhud

Qué significa: Crea un log corto en /tmp/mhud con estadísticas de tiempo de frame.

Decisión: Ejecuta una vez a nativo, otra con modo FSR activado (en tu juego). Compara tiempos p99 para decidir si el modo mejora realmente la sensación.

Chiste #2: “En mi máquina va bien” no es un benchmark; es un rasgo de personalidad.

Guía de diagnóstico rápido: encuentra el cuello de botella rápidamente

Cuando un jugador dice “FSR lo empeoró”, necesitas una vía de triaje que no requiera una semana debatiendo capturas.
Aquí está el orden que ahorra tiempo.

Primero: clasifica la queja

• Borroso / emborronado / suave → probablemente resolución de entrada demasiado baja, nitidez desactivada o escala de render incorrecta.
• Ghosting / estelas → vectores de movimiento malos, máscara reactiva faltante o problemas con transparencias.
• Shimmering / bordes que se arrastran → aliasing, sobre-nitidez o historial/jitter inestable.
• FPS alto pero se siente laggy → generación de frames sin control de latencia, base de frames limitada por CPU, desajuste VRR.
• Stutters / tirones → streaming, compilación de shaders, presión de VRAM, tareas en segundo plano, política de energía.

Segundo: decide si estás GPU-bound

El upscaling es principalmente un reductor de tiempo GPU. Si estás limitado por CPU, FSR puede cambiar poco o incluso empeorar las cosas al desplazar
la carga a diferentes pases. Usa métricas del overlay (utilización GPU, desglose de tiempo de frame si está disponible).

• Si la GPU está al tope y los tiempos de frame bajan al reducir resolución → GPU-bound. FSR probablemente ayuda.
• Si la GPU tiene baja utilización y los tiempos de frame no cambian con la resolución → CPU/IO-bound. Arregla eso primero.

Tercero: verifica las entradas temporales (tipo FSR 2)

Si los artefactos son temporales (ghosting, detalle inestable), asume que las entradas están mal hasta demostrar lo contrario.
Revisa vectores de movimiento en objetos animados, partículas, transparencias y cortes de cámara.

• ¿Los vectores incluyen meshes skinneados?
• ¿Están en el espacio de coordenadas correcto y con la escala adecuada?
• ¿Se aplica jitter de manera consistente a color, profundidad y generación de vectores?
• ¿Se autorizaron máscaras reactivas para materiales problemáticos?

Cuarto: aisla problemas de presentación

La generación de frames y VRR pueden crear reportes de “se ve suave pero se siente mal”. Prueba con:
refresco fijo vs VRR, VSync activado/desactivado, límite de frames activado/desactivado y compara escenarios consistentes.

Quinto: solo entonces ajusta nitidez y valores por defecto

La nitidez y la selección de modo son el último paso. No las uses para ocultar vectores rotos o stutter.
Si lo haces, enviarás una configuración que fallará con la próxima actualización del driver de todos modos.

Tres micro-historias corporativas desde el campo

Micro-historia 1: El incidente causado por una suposición incorrecta

Un estudio mediano lanzó un parche que activaba por defecto un upscaler temporal en “GPUs compatibles”.
QA había validado la función en un conjunto limpio de escenas y la declaró estable. Los números de rendimiento se veían bien.
El lanzamiento salió un jueves por la tarde, porque, por supuesto, así fue.

En pocas horas, los tickets de soporte describían “estelas fantasma” detrás de personajes en niveles lluviosos.
Los jugadores publicaron clips donde gotas y salpicaduras de partículas dejaban manchas a lo largo de la pantalla, como si la lente de la cámara estuviera cubierta de jarabe.
El equipo asumió que el algoritmo del upscaler tenía un bug y abrió un ticket al proveedor, luego empezó a redactar un hotfix para desactivarlo.

La causa real fue más pequeña y más humillante: los vectores de movimiento para los sistemas de partículas se habían desactivado meses antes como microoptimización.
Estaba bien en resolución nativa con TAA estándar, porque las partículas eran mayormente ruidosas y transitorias.
El upscaling temporal hizo visible esa falta de datos al intentar reutilizar historial donde no debía.

La solución no fue “apagar el upscaling”. Fue restaurar vectores de movimiento para el pase de partículas y añadir máscaras reactivas para
materiales de agua específicos. También cambiaron el despliegue: habilitar por defecto solo después de una puerta de telemetría y una semana de canary.

La lección: el upscaler no rompió el juego. Reveló una suposición: “las partículas no necesitan vectores.”
En el terreno temporal, todo necesita vectores—o debes decirle al upscaler que no confíe en el historial.

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

Una app de visualización empresarial (piensa: cercana a CAD, muchas líneas finas) integró FSR 1 como una ganancia rápida de rendimiento
en GPUs integradas. Alguien tuvo la brillante idea de subir la nitidez agresivamente para hacer que los wireframes “resaltaran”.
Las demos se veían nítidas en capturas estáticas.

En uso real, los usuarios panoramaban y hacían zoom constantemente. La nitidez amplificó el aliasing e hizo que los bordes centellearan en movimiento.
La gente se quejó de “fatiga visual” y “parpadeo”, que es el tipo de feedback con el que no puedes discutir porque es literalmente una señal del sistema nervioso humano.

El equipo respondió subiendo la escala de render, lo que mejoró la calidad pero recuperó rendimiento—contradiciendo la razón por la que se adoptó FSR 1.
Peor aún, la nueva escala provocó presión de VRAM en sistemas de gama baja debido a render targets más grandes.
Ahora tenían shimmer y, además, stutter ocasional.

La solución final fue aburrida: bajar la nitidez, añadir un pase de antialiasing para líneas finas adaptado a su contenido,
y exponer un deslizador de “estabilidad vs nitidez” con valores por defecto sensatos. También documentaron que FSR 1 no es una varita mágica
para arte lineal subpíxel.

La lección: la nitidez no es detalle gratis. Es un amplificador de contraste. Si tu contenido ya es propenso al aliasing,
la nitidez es gasolina.

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

Un gran equipo de juego tenía la costumbre que parecía excesiva en procesos: cada característica gráfica tenía un “repro pack”.
Era un conjunto zip con rutas de cámara deterministas, ajustes de hora del día fijos y un script para ejecutar capturas con los mismos
settings de driver, el mismo cap de frames y el mismo estado de caché de shaders.

Cuando integraron un upscaler temporal (tipo FSR 2), añadieron algunas escenas diseñadas específicamente para romperlo:
cercas de malla, follaje fino, partículas sobre fondos de alto contraste, cortes de cámara rápidos y charcos reflectantes.
Cada escena tenía umbrales esperados de artefactos y patrones “conocidos malos” vinculados a fallos comunes de integración.

Meses después, una actualización del driver causó reportes esporádicos de shimmering. El equipo no debatió opiniones.
Ejecutaron el repro pack en dos versiones de driver, encontraron que la regresión se aislaba a una interacción particular con un post-process,
y enviaron una pequeña mitigación mientras archivaban un bug limpio al proveedor con capturas.

Los jugadores vieron un parche rápido. El equipo de ingeniería evitó una reescritura alarmada. La gerencia obtuvo una línea de tiempo con evidencia.
Y nadie tuvo que “fiarse de las vibes” de la captura de pantalla de un revisor.

La lección: los harnesses de prueba deterministas se sienten aburridos hasta el día en que previenen un festival de culpas entre equipos.

Errores comunes (síntomas → causa raíz → solución)

1) La UI se ve suave o emborronada

Síntomas: El texto del HUD pierde nitidez; el minimapa se ve borroso; los subtítulos centellean durante el movimiento.

Causa raíz: UI renderizada en la escena 3D antes del upscaling, o UI tratada como contenido reproyectable por historial.

Solución: Renderiza la UI a resolución de salida después del upscaling; si debes componerla antes, etiqueta la UI en máscaras reactivas y evita la reutilización de historial.

2) Ghosting detrás de personajes en movimiento

Síntomas: Estelas detrás de jugadores/NPCs, especialmente contra fondos de alto contraste.

Causa raíz: Vectores de movimiento incorrectos o faltantes para meshes skinneados; vectores en espacio equivocado; clamp de velocidad demasiado agresivo.

Solución: Valida el pase de vectores para animación skinneada; asegúrate de que los vectores coincidan con la proyección con jitter; ajusta la máscara reactiva para materiales emisivos.

3) Follaje y geometría delgada que centellea

Síntomas: Hojas que brillan; cercas que se arrastran; cables delgados que aliasan durante el movimiento de cámara.

Causa raíz: Resolución de entrada demasiado baja para el contenido; nitidez excesiva; secuencia de jitter TAA inestable; mip bias demasiado agresivo.

Solución: Usa un modo FSR de mayor calidad; reduce la nitidez; revisa mip bias y LOD; asegura jitter estable y pesos de historial correctos.

4) “FSR aumentó FPS pero el juego se siente peor”

Síntomas: Los FPS reportados suben, pero el ratón se siente retrasado o inconsistente.

Causa raíz: Base de frames limitada por CPU; generación de frames sin controles de latencia; cola de presentación; ajustes VRR/VSync desajustados.

Solución: Mide la tasa base (no generada) de frames; aplica cap apropiado; habilita reducción de latencia si está disponible; arregla cuellos de botella de CPU; valida gráficos de pacing.

5) Stutters aleatorios tras activar el upscaling

Síntomas: Microcongelamientos cada pocos segundos; peor en la primera ejecución o tras un parche.

Causa raíz: Compilación de shaders/pipeline; IO de streaming; sobrecommit de VRAM; tareas de fondo.

Solución: Calienta cachés de shaders en QA; envía caches de pipeline donde sea posible; reduce presión de VRAM vía texturas; perfila IO; detén overlays de fondo durante la prueba.

6) Imagen “crujiente” sobre-nitida con reflejos ruidosos

Síntomas: Superficies metálicas brillan; reflejos se arrastran; la imagen se ve granulada.

Causa raíz: La nitidez amplifica inestabilidad temporal y aliasing especular; el contenido no está filtrado para baja resolución interna.

Solución: Baja la nitidez; mejora el antialiasing especular (ajuste de roughness, mapas de entorno prefiltrados); considera una escala de render más alta.

7) Artefactos en partículas, humo, agua y transparencias

Síntomas: Humo que se emborrona; bordes del agua dejan estelas; partículas “se pegan” a la pantalla.

Causa raíz: Los upscalers temporales tienen dificultades con transparencias que no tienen movimiento/profundidad fiables; faltan máscaras reactivas.

Solución: Autor máscaras reactivas para estos materiales; renderiza algunos efectos después del upscaling; limita la contribución de historial en esas regiones.

8) Resultados de benchmark que no coinciden con los reportes de jugadores

Síntomas: Los números de laboratorio dicen que mejoró; los jugadores siguen quejándose de stutter.

Causa raíz: La ruta del benchmark evita hotspots de streaming; las cachés están calientes en laboratorio; ajustes de driver distintos; comportamiento de refresco/VRR diferente.

Solución: Construye escenas de repro deterministas que incluyan streaming y recorrido; rastrea tiempos de frame p99/p99.9; prueba ejecuciones con cache fría.

Listas de comprobación / plan paso a paso

Paso a paso: elegir los valores por defecto adecuados para FSR

1. Fija un objetivo: 60 estable, 90 estable, 120+ competitivo. No finjas que un único valor por defecto satisface todo.
2. Mide el cuello de botella base: GPU-bound vs CPU-bound a nativo y a resolución reducida.
3. Selecciona el modo más suave que alcance el objetivo: prefiere Quality/Balanced sobre Performance cuando sea posible.
4. Establece nitidez conservadora: comienza más baja de lo que crees; deja que los usuarios la suban si disfrutan el dolor.
5. Valida en trampas de artefactos: follaje, cercas, partículas, paneos rápidos, HUD brillante sobre escenas oscuras.
6. Valida el comportamiento en inicio en frío: compilación de shaders y streaming en la primera ejecución.
7. Revisa la composición de la UI: asegura que la UI sea a resolución de salida y estable.
8. Documenta limitaciones conocidas: líneas finas, ciertas transparencias, resoluciones de entrada extremadamente bajas.

Checklist de integración: upscaling temporal tipo FSR 2

• Vectores de movimiento incluyen: meshes skinneados, cuerpos rígidos, movimiento de cámara y movimiento UV/material animado cuando aplique.
• El buffer de profundidad coincide con la convención esperada (Z invertida, rango, linearización según se requiera).
• El jitter se aplica consistentemente en color, profundidad y generación de vectores de movimiento.
• La exposición es estable entre frames; cambios abruptos de exposición resetean el historial o reducen el peso del historial.
• Existen máscaras reactivas para: partículas, agua, cristal transparente, señalización emisiva, follaje con alpha test animado.
• Cortes de cámara y teletransportes desencadenan reseteo de historial (o lógica equivalente).
• La UI se renderiza después del upscaling (preferido) o se excluye de la reutilización de historial.
• Los valores por defecto de nitidez son conservadores y probados bajo movimiento, no solo en imágenes estáticas.

Checklist de operaciones: enviar sin prender fuego al equipo

• Despliegue canario para cambios que vienen activados por defecto; rastrea la tasa de quejas por vendor/modelo de GPU y rama de driver.
• Harness de regresión con escenas deterministas; captura distribuciones de tiempo de frame y capturas de artefactos.
• Script claro para soporte: qué ajustes solicitar (modo, nitidez, generación de frames, VRR, VSync).
• Matriz driver/OS para QA que refleje la realidad, no solo tus rigs de desarrollo.
• Plan de fallback: permitir desactivar/intercambiar el upscaler sin romper saves o el escalado de UI.

Datos interesantes y contexto histórico

El upscaling no apareció de la nada. Aquí hay puntos concretos de contexto que explican por qué FSR aterrizó como lo hizo:

1. FSR 1 se lanzó en 2021, posicionado como una alternativa espacial rápida que podía adoptarse ampliamente en GPUs.
2. La postura cross-vendor de FSR importó: pudo ejecutarse en hardware competidor, lo que redujo la fricción de adopción para estudios en PC.
3. El upscaling temporal precedió a FSR en muchos motores como reconstrucción basada en TAA; FSR 2 formalizó una vía de alta calidad proporcionada por el vendor.
4. FSR 2 cambió la conversación de “trucos de nitidez” a “dame vectores de movimiento correctos”, poniendo el foco en la corrección del motor.
5. El upscaling se vinculó a la adopción de ray tracing: los costes de RT empujaron más títulos hacia técnicas de reconstrucción para mantener tasas jugables.
6. FSR 3 trajo generación de frames al ecosistema de AMD, expandiendo las discusiones de upscaling hacia latencia y pacing más que al rendimiento bruto.
7. Enfoques abiertos basados en shaders permitieron a desarrolladores inspeccionar y adaptar detalles de integración más fácilmente que soluciones caja negra.
8. Las expectativas consola→PC empujaron el pensamiento de “modo rendimiento” a los menús de PC, normalizando el escalado de resolución interna.
9. La madurez de drivers y compiladores influye fuertemente en los resultados: dos sistemas con “la misma GPU” pueden producir perfiles de stutter distintos entre ramas de driver.

FAQ

1) ¿FSR es “verdadero 4K”?

No. FSR renderiza a una resolución interna más baja y reconstruye a la resolución de salida. El objetivo es “se parece lo suficiente a cierta distancia de visualización”,
no equivalencia píxel a píxel.

2) ¿Por qué FSR a veces se ve borroso?

Normalmente porque la resolución de entrada es demasiado baja para la complejidad de la escena, la nitidez está baja, o la cadena de postprocesado del juego no es
amigable con la reconstrucción (grano de película, DOF agresivo, motion blur).

3) ¿Por qué FSR a veces se ve demasiado nítido o ruidoso?

La sobre-nitidez amplifica el aliasing y la inestabilidad temporal. Reduce la nitidez primero. Si los reflejos especulares se arrastran, quizá también necesites mejor
anti-aliasing especular en contenido/shaders.

4) ¿Cuál es la diferencia práctica entre FSR 1 y FSR 2?

FSR 1 es espacial: rápido y simple, con menos necesidades de integración y reconstrucción de detalle más débil. FSR 2 es temporal: potencial de mayor calidad,
pero depende de vectores de movimiento correctos, profundidad, jitter y manejo de historial.

5) ¿FSR ayuda si estoy limitado por CPU?

No mucho. Bajar la resolución interna reduce el trabajo GPU, pero si la CPU limita el frame, las ganancias pueden ser pequeñas.
Diagnostica CPU vs GPU antes de esperar milagros.

6) ¿Por qué la generación de frames a veces se siente lenta?

Porque generar frames adicionales mostrados no reduce automáticamente la latencia de entrada. Si la tasa base de frames es baja o inestable,
puedes obtener movimiento más suave con respuesta de entrada igual o peor.

7) ¿Cuál es el mejor modo por defecto de FSR?

Para la mayoría de títulos: comienza con Quality (o Balanced a resoluciones más altas) y una nitidez conservadora. “Performance” es para cuando realmente lo necesitas,
y has probado cuidadosamente geometría delgada y follaje.

8) ¿Por qué las partículas y efectos transparentes se ven peor con upscaling temporal?

Las transparencias no se comportan como geometría sólida en términos de movimiento/profundidad. Sin máscaras reactivas o manejo especial, el upscaler reutiliza historial
incorrectamente y ves smearing o ghosting.

9) ¿Activar FSR reduce el uso de VRAM?

Puede reducir algunos tamaños de render target, pero las texturas, buffers de geometría y estructuras de ray tracing a menudo dominan la VRAM.
Si estás cerca del límite de VRAM, reduce ajustes de texturas y tamaños de caché de sombras antes de esperar que el upscaling arregle el hitching.

Conclusión: pasos prácticos siguientes

FSR no solo hizo popular el upscaling. Lo normalizó operativamente: una opción que los jugadores esperan, que los revisores prueban
y de la que los estudios dependen para alcanzar objetivos de rendimiento sin sacrificar visuales.
Esa es la buena noticia. La mala noticia es que la reconstrucción temporal castiga entradas descuidadas del motor.

Si vas a enviar o dar soporte a FSR en el mundo real, haz lo siguiente:

1. Deja de usar FPS promedio como tu estrella del norte. Rastrea tiempos de frame p95/p99 y consistencia de pacing.
2. Construye un repro pack determinista con escenas que estresen intencionalmente la reconstrucción temporal.
3. Valida vectores de movimiento y máscaras antes de tocar los valores por defecto de nitidez.
4. Separa ganancias bound por GPU de problemas de CPU/IO. El upscaling no arreglará compilación de shaders ni streaming lento.
5. Envía valores por defecto sensatos y toggles claros. Permite a los usuarios optar por salir sin problemas cuando su configuración sea la extraña.

El upscaling ahora forma parte del contrato base entre tu renderer y tus jugadores. Trátalo como cualquier otra dependencia de producción:
mídelo, pruébalo y no confíes en él hasta que lo haya demostrado.