Conoces la escena: subes las texturas a Ultra porque el desplegable implica que estás comprando “más juego”, y de pronto el gráfico de tiempos de fotograma se convierte en arte moderno. La GPU no está al máximo, la CPU no está al máximo, y aun así girar la cámara se siente como arrastrar un sofá por la alfombra.
Esto normalmente no es “mala optimización” en abstracto. Es un tipo muy específico de mal día: presión de VRAM, residencia de texturas y la fea interacción entre lo que el motor quiere, lo que informa el controlador y lo que tu tarjeta puede realmente mantener residente sin paginación.
Ultra es una política, no una promesa
“Ultra” no es una unidad universal. No es “lo mejor”. No es “correcto”. Es un paquete de decisiones tomadas por un estudio bajo presión de tiempo, con conocimiento incompleto de tu máquina, tus aplicaciones en segundo plano, la versión del controlador y tu tolerancia al tartamudeo.
La calidad de texturas es el lugar más sencillo donde “Ultra” puede volverse absurdo, porque es la opción que en silencio puede exigir más VRAM mientras ofrece la mejora visible más pequeña. Muchos motores asignarán memoria hasta el límite y luego gastarán tu presupuesto de tiempo de fotograma haciendo triage de memoria.
Aquí está el modelo mental que uso en sistemas de producción y en juegos: cuando estás cerca de un límite de capacidad, todo se convierte en un problema de planificación. No se trata solo de “¿me quedé sin VRAM?” Se trata de “¿con qué frecuencia fuerzo desalojos, cargas y descompresión en los peores momentos posibles?”
Qué deberías hacer, por defecto
- Empieza con texturas en Alta, no en Ultra, incluso en una GPU potente. Luego mide. Si no distingues la diferencia mientras te mueves, no la pagues con tartamudeos.
- Mantén un margen de seguridad de VRAM. Si tu superposición dice que estás al 95–100% de VRAM en una escena cargada, no estás “usándola toda eficientemente”. Estás coqueteando con la paginación.
- Prioriza tiempos de fotograma estables sobre FPS pico. Los picos son lo que siente tu mano.
Una cita que merece estar en una nota pegada junto a cada conmutador “Ultra”: La esperanza no es una estrategia.
— Gene Kranz
Texturas, VRAM y por qué se vuelve raro
Las texturas son grandes, numerosas y no todas iguales. Un control deslizante de “calidad de texturas” normalmente cambia alguna mezcla de:
- Resolución máxima de textura (p. ej., 2K → 4K)
- Bias de mip y reglas de residencia (qué tan agresivamente se usan/retienen los mips inferiores)
- Valores predeterminados de filtrado anisotrópico (a veces separado, a veces agrupado)
- Tamaño del pool de streaming (cuánta memoria reserva el motor para streaming)
- Elecciones de formato de compresión para ciertas clases de activos (varía ampliamente)
La VRAM no es un único “cubo”. Es una jerarquía: memoria de video local, más memoria compartida/sistema, más lo que el SO/controlador pueda paginar dentro/fuera. Las APIs modernas (DX12/Vulkan) exponen presupuestos de memoria y residencia de forma más explícita, pero la experiencia aún depende de que el controlador y el motor se comporten como adultos.
Matemáticas de texturas que hacen que “Ultra” parezca caro
Una sorpresa común: una sola textura 4K no son “unos pocos megabytes”. Depende del formato y de los mipmaps. Aproximadamente:
- RGBA8 sin comprimir 4K: 4096×4096×4 bytes ≈ 64 MiB para el mip superior, más ~33% para la cadena de mips → ~85 MiB.
- 4K comprimida en BC7: ~16 MiB mip superior, más cadena de mips → ~21 MiB.
Ahora multiplica por: albedo + normal + rugosidad/metalness/AO + emisiva + máscaras. Luego multiplicas por el número de materiales únicos en pantalla, más los activos “por si acaso” que el motor mantiene porque tiene que predecir hacia dónde girarás. La cuenta llega rápido.
Broma corta #1: Las texturas Ultra son como llevar un frigorífico de tamaño completo a un picnic. Técnicamente impresionante; socialmente cuestionable.
La resolución no es el mismo control
La resolución de pantalla afecta principalmente a los render targets (color, profundidad, buffers de postprocesado) y al coste de sombreado. La calidad de texturas afecta sobre todo a la residencia de activos. Puedes jugar en 4K con texturas en Alta y tener una buena experiencia, y puedes jugar en 1080p con texturas en Ultra y sufrir un desastre con tartamudeos. Son puntos de presión diferentes.
Hechos y contexto que puedes usar en una reunión (o un postmortem)
- El mipmapping es más antiguo que la mayoría de GPUs que has tenido. Se describió a principios de los años 80 para reducir aliasing y mejorar el comportamiento de caché, y sigue siendo una herramienta clave para la estabilidad.
- Las consolas normalizaron presupuestos de memoria fijos. La era del “8 GB de memoria unificada” obligó a los estudios a ser disciplinados sobre residencia y streaming, aunque los puertos a PC a veces olvidan esa lección.
- DX11 ocultaba mucho dolor de residencia. La memoria gestionada por el controlador facilitó la vida, hasta que dejó de hacerlo; DX12/Vulkan lo hizo explícito, lo cual es genial para el rendimiento y terrible para presupuestos descuidados.
- La compresión de texturas es una estrategia de ancho de banda, no solo un truco de almacenamiento. Los formatos de compresión por bloques (BCn/ASTC) reducen la huella en VRAM y el tráfico de memoria; son una característica de rendimiento.
- Los mapas normales a menudo dominan más que los albedos. La gente piensa en “texturas de color”, pero las normales de alta frecuencia están por todas partes y rara vez son baratas.
- El texturizado virtual (“mega textures”) no es nuevo. Variantes existieron durante años, pero los SSD modernos y mejores tablas de páginas GPU lo hicieron práctico a escala.
- El reporte de VRAM no está estandarizado entre herramientas. “Asignado”, “comprometido”, “residente” y “en uso” son estados diferentes; las superposiciones a menudo los mezclan.
- Resizable BAR puede cambiar la sensación de sobresuscripción. No aumenta la VRAM, pero puede influir en el comportamiento de transferencia y reducir algunos bloqueos en el peor caso.
- El ancho de banda de PCIe no es ancho de banda de VRAM. Cuando paginas texturas desde la memoria del sistema, abandonas una autopista de cientos de GB/s por una carretera mucho más estrecha con semáforos.
Qué ocurre realmente cuando te “quedas sin VRAM”
La mayoría de las veces, no ocurre nada dramático. No hay crash. No hay error. Solo tiempos de fotograma inconsistentes.
Bajo presión de VRAM, el sistema hace malabares con:
- Desalojos: sacar recursos de la VRAM local para hacer espacio.
- Cargas: traer texturas de vuelta cuando son necesarias.
- Agitación de estado: cambiar qué mips son residentes, a veces varias veces por segundo.
- Sincronización: esperar a que transfes, fences o colas de copia terminen.
El modo de fallo no es “bajo FPS promedio”. Es tartamudeo al rotar la cámara, saltos al entrar en un área nueva o picos periódicos cada pocos segundos. Estos se correlacionan con eventos de streaming, compilación de shaders o recolección de basura también —pero la presión de VRAM amplifica todo porque todo compite por el mismo pool de residencia limitado.
Sobresuscripción de VRAM: el impuesto oculto
Cuando el “presupuesto” del motor excede la VRAM local, aún puede ejecutarse apoyándose en la memoria del sistema (o peor, el archivo de paginación). Esa es la sobresuscripción. Piénsalo como ejecutar una base de datos con una caché de búfer más grande que la RAM: técnicamente arranca y luego pasa la vida thrashing.
Si solo tomas un punto accionable de este artículo: mantén tu conjunto de trabajo cómodamente dentro de la VRAM. “Cómodamente” significa dejar espacio para picos, sobrecarga del controlador y lo que el motor no te dijo que está haciendo.
Broma corta #2: Poner las texturas en Ultra en una tarjeta con VRAM ajustada es una excelente forma de experimentar “pantallas de carga inmersivas” en tiempo real.
Guía rápida de diagnóstico
Este es el orden que encuentra el cuello de botella rápidamente sin convertir tu tarde en una danza interpretativa de conmutadores.
Primero: demuestra si es presión de VRAM
- Activa una superposición de VRAM (superposición del controlador o en el juego si es confiable) y reproduce el tartamudeo en la escena exacta que se siente mal.
- Observa si la VRAM se llena (95–100%) y si hay picos en el tiempo de fotograma que coincidan con movimiento de cámara o transiciones con muchos activos.
- Baja la calidad de texturas un nivel (Ultra → Alta). No cambies nada más todavía. Si los picos se reducen materialmente, encontraste tu palanca.
Segundo: separa la VRAM del tartamudeo por “todo lo demás”
- Comprueba la saturación por núcleo de CPU. Un único núcleo al máximo puede causar stalls de streaming y draw-calls que parecen problemas de VRAM.
- Comprueba síntomas de compilación de shaders: picos que ocurren la primera vez que ves un efecto y luego desaparecen.
- Comprueba I/O de almacenamiento: si tu disco está al 100% de actividad durante el streaming, tus texturas llegan tarde independientemente de la VRAM.
Tercero: optimiza para consistencia
- Configura texturas al nivel más alto que se mantenga dentro del presupuesto en las escenas de peor caso.
- Limita los FPS para reducir picos de carga transitorios y estabilizar el ritmo.
- Ajusta la configuración de streaming si está expuesta (tamaño del pool, distancia de prefetch). Más grande no siempre es mejor; más grande puede significar “hacer thrash más lento pero más tiempo”.
Tareas prácticas con comandos (qué significa, qué decides)
Estas son intencionalmente aburridas. Lo aburrido es bueno; lo aburrido es repetible. Los comandos asumen Linux con herramientas comunes porque ahí los hábitos de SRE son más fáciles de demostrar, pero la lógica aplica en todas partes.
1) Identifica tu GPU y controlador
cr0x@server:~$ lspci -nn | grep -Ei 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2782] (rev a1)
Qué significa la salida: Confirma qué GPU está presente y qué dispositivo PCI estamos mirando. Útil cuando tienes gráficos híbridos o sesiones remotas.
Decisión: Si la GPU no es la que crees que estás usando, detente y arregla eso antes de sintonizar nada.
2) Comprueba uso de VRAM de NVIDIA y consumidores por proceso (si aplica)
cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version,memory.total,memory.used,memory.free --format=csv
name, driver_version, memory.total [MiB], memory.used [MiB], memory.free [MiB]
NVIDIA GeForce RTX 4070, 550.54.14, 12282 MiB, 10321 MiB, 1961 MiB
Qué significa la salida: VRAM total vs usada vs libre. Si lo usado es alto mientras hay tartamudeo, probablemente estás cerca del límite de residencia.
Decisión: Si “libre” está consistentemente por debajo de ~10–15% en la escena problemática, trata a las texturas Ultra como culpables hasta demostrar lo contrario.
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec fb command
0 28144 G 62 48 0 0 9920 game.bin
0 2331 G 2 1 0 0 180 Xorg
Qué significa la salida: Vista rápida de qué procesos están consumiendo memoria de framebuffer (fb). “mem” aquí es % de utilización, no MiB.
Decisión: Si procesos en segundo plano retienen cientos de MiB (grabadores, navegadores con aceleración GPU), mátalos o aíslos antes de culpar al juego.
3) Comprueba información de memoria GPU AMD (si aplica)
cr0x@server:~$ cat /sys/class/drm/card0/device/mem_info_vram_total
17179869184
cr0x@server:~$ cat /sys/class/drm/card0/device/mem_info_vram_used
12884901888
Qué significa la salida: Bytes brutos de VRAM total y usada según reporta el controlador del kernel.
Decisión: Convierte a GiB mentalmente (divide por 1024^3). Si lo usado está cerca del total durante el tartamudeo, baja texturas o reduce otras características que consuman mucha VRAM (RT, sombras de alta resolución, caches grandes).
4) Verifica que el enlace PCIe no esté degradado
cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16
Qué significa la salida: Capacidad del enlace vs enlace negociado real. Si estás en x4 o a menor velocidad, los costes de paginación duelen más.
Decisión: Si el enlace está degradado inesperadamente, vuelve a asentar la tarjeta, revisa ajustes de BIOS y no persigas las texturas aún.
5) Comprueba saturación por núcleo de CPU al reproducir el tartamudeo
cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (server) 01/21/2026 _x86_64_ (16 CPU)
12:04:10 PM CPU %usr %sys %iowait %idle
12:04:11 PM all 22.11 6.18 1.02 70.69
12:04:11 PM 7 92.00 5.00 0.00 3.00
Qué significa la salida: Un núcleo (CPU 7) está al máximo. Eso puede ser hilo de render, hilo de streaming o trabajo del controlador.
Decisión: Si un solo núcleo está atascado cuando ocurre el tartamudeo, bajar texturas puede ayudar indirectamente (menos trabajo de streaming), pero también deberías probar a reducir ajustes que carguen draw-calls (distancia de visión, densidad de multitud) y revisar procesos en segundo plano que consuman CPU.
6) Comprueba latencia y saturación de almacenamiento durante el streaming
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
21.2 0.0 6.1 1.0 0.0 71.7
Device r/s rkB/s await %util
nvme0n1 210.0 82000.0 3.20 62.0
Qué significa la salida: “await” es el tiempo medio por E/S. %util muestra saturación del dispositivo. Si await se dispara alto durante los tirones, el almacenamiento está en el bucle.
Decisión: Si %util está cerca del 100% y await es alto cuando tienes tirones, mover el juego a un SSD más rápido o reducir la demanda de streaming (texturas, distancia de visión) ayudará.
7) Verifica que el sistema no esté paginando intensamente a nivel de SO
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 0 8123456 221000 9021000 0 0 120 340 900 2100 22 6 71 1
Qué significa la salida: “si/so” son swap-in/out. Si estos son distintos de cero durante los tartamudeos, no solo te quedaste sin VRAM; también te quedaste sin margen de memoria del sistema.
Decisión: Si ocurre paginación: cierra apps en segundo plano, añade RAM, reduce la calidad de texturas y asegúrate de que el archivo de paginación/swap esté en SSD (y dimensionado adecuadamente).
8) Observa la utilización de motores de GPU (chequeo de coherencia)
cr0x@server:~$ sudo intel_gpu_top -s 200 -o -
requesting drm device 0, main kdev 0, minor 0
Render/3D 12.32% Blitter 0.00% Video 0.00%
Qué significa la salida: En sistemas con iGPU Intel, muestra si la GPU está realmente ocupada. Baja utilización con malos tiempos de fotograma a menudo apunta a stalls de CPU o de memoria.
Decisión: Si la utilización es baja durante el tartamudeo, no persigas “más GPU”. Persigue la fuente del bloqueo (paginación de VRAM, hilo de CPU, I/O, compilación de shaders).
9) Comprueba el compositor / modo de pantalla (VRR y comportamiento a pantalla completa)
cr0x@server:~$ xrandr --verbose | grep -E 'connected|vrr_capable|vrr_enabled'
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis)
vrr_capable: 1
vrr_enabled: 1
Qué significa la salida: El soporte de refresco variable está habilitado. VRR puede ocultar pequeñas variaciones de tiempo de fotograma pero no te salvará de tartamudeos de 200 ms.
Decisión: Si VRR está desactivado, actívalo para comodidad. Si VRR está activado y aún tienes tirones, estás lidiando con picos grandes (streaming/paginación).
10) Confirma qué sistema de archivos y espacio libre tienes (el streaming odia discos llenos)
cr0x@server:~$ df -hT /mnt/games
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p2 ext4 930G 870G 13G 99% /mnt/games
Qué significa la salida: 99% lleno es una señal de olor a rendimiento. La fragmentación y el comportamiento de recolección de basura pueden aumentar la latencia.
Decisión: Libera espacio. Apunta a al menos 10–15% de margen. Luego prueba de nuevo el tartamudeo antes de tocar más ajustes.
11) Observa picos de latencia I/O en tiempo real con iotop
cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 75.21 M/s | Total DISK WRITE: 2.11 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
28144 be/4 cr0x 62.10 M/s 0.00 B/s 0.00 % 9.21% game.bin
Qué significa la salida: El juego está leyendo muchos datos. Eso es normal durante el streaming, pero si coincide con tirones y tu unidad es lenta/saturada, encontraste un contribuyente.
Decisión: Si las tasas de lectura son altas y tu disco está al límite, reduce la demanda de streaming (texturas/distancia de visión) o mueve la instalación a almacenamiento más rápido.
12) Valida el margen de memoria del sistema
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 26Gi 1.2Gi 1.1Gi 4.8Gi 3.9Gi
Swap: 8Gi 0.0Gi 8Gi
Qué significa la salida: “available” es lo que importa. Si está baja, el SO luchará contra ti.
Decisión: Si la memoria disponible está por debajo de ~3–4 GiB mientras juegas, espera más paginación y peor tartamudeo cuando la VRAM esté apretada. Cierra cosas o añade RAM.
13) Comprueba tamaño y ubicación de la caché de shaders (sana práctica)
cr0x@server:~$ du -sh ~/.cache/* 2>/dev/null | sort -h | tail -n 5
1.2G /home/cr0x/.cache/mesa_shader_cache
2.8G /home/cr0x/.cache/game-shader-cache
Qué significa la salida: Cachés grandes de shaders son normales. Si tu home está en un disco lento o casi lleno, la compilación de shaders y las escrituras de caché pueden causar tartamudeos.
Decisión: Asegura que las cachés vivan en SSD y haya margen libre. No “optimices” borrando cachés rutinariamente a menos que estés solucionando corrupción.
14) Mide el pacing de fotogramas vía estadísticas de present (enfoque básico)
cr0x@server:~$ mangohud --dlsym ./game.bin
MangoHud: HUD initialized
Qué significa la salida: Estás ejecutando con una superposición de tiempo de fotograma. Te importa más el gráfico de tiempos de fotograma que el número de FPS.
Decisión: Si el gráfico muestra picos periódicos que desaparecen al bajar la calidad de texturas, estás viendo estrés por streaming/residencia de VRAM, no por el throughput bruto de GPU.
Tres mini-historias corporativas desde el frente
1) Incidente causado por una suposición errónea: “La VRAM es como RAM, simplemente cacheará mejor”
Un estudio con el que trabajé (llamémoslo Compañía A) lanzó un parche para PC que “mejoraba los visuales” subiendo la calidad de texturas por defecto en GPUs de gama alta. El cambio se justificó con una línea familiar: la mayoría de las tarjetas ya tenían suficiente VRAM, y la VRAM no usada es desperdiciada.
Probaron en un puñado de máquinas en el laboratorio. Las tasas de fotogramas parecían bien. Sin crashes. El parche salió un martes, porque por supuesto así fue.
En cuestión de horas, los canales de soporte se llenaron de reportes: “microtartamudeos tras 20 minutos”, “saltos al girar”, “bien al principio, luego terrible”. Lo peor: muchos reportes venían de tarjetas de 8–10 GB que deberían haber sido “seguros”. La suposición falló porque la VRAM no es una caché pasiva. Es una restricción de residencia, y los motores pueden apostar mal sobre movimientos futuros de cámara. Un jugador con FOV amplio, giros rápidos y una montura de alta velocidad era efectivamente un benchmark de streaming de peor caso.
El postmortem mostró que el cambio de textura por defecto empujó el uso típico de VRAM de “cómodo” a “al filo”, y la política de desalojo del motor empezó a oscilar. La oscilación es el enemigo en todo sistema: una vez que estás thrashing, el trabajo que haces crea más trabajo. Bucle de realimentación positiva clásico.
La solución no fue heroica. Revirtieron el valor por defecto, añadieron una etiqueta de advertencia que mapeaba los presets de texturas al margen de VRAM y ajustaron el pool de streaming para comportarse más conservadoramente bajo presión. La lección más grande no era sobre texturas; era sobre asumir que la capacidad se comporta de forma lineal. No lo hace.
2) Optimización que salió mal: “Reducimos memoria de texturas con drops agresivos de mip”
La Compañía B tenía un problema legítimo: en GPUs de gama media, el uso de VRAM era demasiado alto en ciudades densas. Alguien propuso una idea ingeniosa: eliminar mips dinámicamente de forma más agresiva siempre que la VRAM se acercara al presupuesto. En teoría, esto mantendría el juego dentro de su carril y evitaría saltos.
La primera prueba interna fue prometedora. El uso de VRAM se aplanó. Menos stalls duros. Todos asintieron. Luego QA empezó a hacer lo que hace QA: quedarse quietos y girar lentamente la cámara, repetidamente, en el mismo punto.
La ciudad se volvió un desastre titilante. Las texturas poppeaban constantemente. Peor aún, el motor empezó a “hacer yo-yo” con los mips: bajar mips para reducir VRAM, aparece espacio libre, el motor vuelve a subir mips, la VRAM sube, vuelve a bajar. El resultado fue VRAM estable pero visuales inestables y trabajo continuo en segundo plano. Cambiaron un tipo de tartamudeo por otro: en lugar de saltos grandes y raros, obtuvieron sacudidas constantes de baja intensidad.
En términos de sistemas, implementaron un controlador sin amortiguación y con umbrales demasiado agresivos. Era un termostato que enciende la calefacción a 19.9°C y la apaga a 20.0°C. Felicidades, inventaste la oscilación.
La solución final fue añadir histéresis (no volver a subir mips inmediatamente después de una caída), limitar la velocidad con la que los mips pueden cambiar por segundo y preferir reducir solicitudes de streaming futuras sobre desalojar activos actualmente visibles. La “optimización” no estaba mal; estaba incompleta. En trabajo de rendimiento, lo incompleto es cómo despliegas nuevos problemas a tiempo.
3) Práctica aburrida pero correcta que salvó el día: “Presupuestos, instrumentación y un firme ‘no’ a defaults silenciosos”
La Compañía C no tenía el motor más glamuroso, pero tenía una disciplina que se sentía casi anticuada: una tabla de presupuesto de VRAM por plataforma y por nivel de calidad, revisada como un SLO. No “aproximadamente”. Una tabla real.
Cada build recopilaba telemetría de playtests internos: texturas residentes pico, profundidad media de la cola de streaming, número de desalojos por minuto, percentil de peor tiempo de fotograma. Si cambiabas presets de texturas, tenías que mostrar las métricas. Si añadías una nueva librería de materiales, tenías que mostrar el impacto en el presupuesto. Si no lo hacías, tu cambio no entraba.
Cuando contenido de última etapa empujó el mapa de la ciudad cerca del presupuesto, no se pusieron frenéticos. Ya sabían qué grupos de activos eran los mayores ofensores. Bajaron algunas resoluciones de mapas normales, ajustaron unas instancias de materiales y reemplazaron un puñado de props “hero” que no merecían texturas de héroe.
El lanzamiento aún tuvo bugs, porque el software siempre los tiene. Pero no tuvieron el fiasco característico de “Ultra hace que el juego tartamudee en hardware perfectamente normal”. La práctica aburrida—presupuestos, instrumentación y negarse a cambios silenciosos—hizo lo que las prácticas aburridas hacen: evitó fallos emocionantes.
Errores comunes: síntoma → causa raíz → solución
1) “Los FPS son altos, pero se siente terrible cuando giro”
Causa raíz: Stalls de streaming de texturas o sobresuscripción de VRAM causando desalojos/cargas durante el movimiento de cámara.
Solución: Baja la calidad de texturas un nivel; reduce la distancia de visión; asegúrate de que el juego esté en SSD; mantén uso de VRAM por debajo de ~85–90% en las peores escenas.
2) “Bajar resolución no arregló el tartamudeo”
Causa raíz: Reduciste la carga de render-target, pero tu cuello de botella es la residencia de activos y el streaming, no el sombreado de píxeles.
Solución: Baja texturas y/o ajustes de streaming; reduce sombras de alta resolución; desactiva paquetes de texturas de alta resolución que excedan tu VRAM.
3) “Funciona bien 10 minutos, luego empeora”
Causa raíz: El conjunto de trabajo crece a medida que avanzas; las cachés se llenan; aplicaciones en segundo plano se acumulan; la VRAM se fragmenta o el presupuesto se reduce por otras asignaciones.
Solución: Cierra apps GPU-intensivas en segundo plano; reinicia el juego entre sesiones largas como solución temporal; ajusta texturas para las áreas de peor caso, no para la zona tutorial.
4) “Las texturas Ultra se ven igual que en Alta, pero el rendimiento cae”
Causa raíz: Estás limitado por huella/bandwidth de memoria, no por percepción de detalle. Muchas escenas están limitadas por mips en movimiento de todos modos.
Solución: Mantén Alta. Gasta presupuesto en filtrado anisotrópico (usualmente barato) o en mejores ajustes de iluminación que realmente cambian la escena.
5) “El pop-in de texturas es terrible en Medio”
Causa raíz: Pool de streaming demasiado pequeño o bias de mip demasiado agresivo, causando transiciones de mip visibles.
Solución: Aumenta la calidad de texturas un nivel, o incrementa el pool de streaming si el motor lo expone—pero solo si tienes margen de VRAM.
6) “La superposición de VRAM dice que uso 11 GB en una tarjeta de 12 GB, así que estoy bien”
Causa raíz: Estar “casi lleno” no es estar bien. Ocurren picos. Ocurre sobrecarga del controlador. El motor puede alocar en ráfagas durante transiciones.
Solución: Apunta a un buffer. Trata el 90% como “amarillo”, no como “verde”, en las escenas donde el juego sufre.
7) “Tras activar ray tracing, las texturas empezaron a tartamudear”
Causa raíz: RT suele asignar buffers grandes (BVHs, historial de denoiser, render targets extra), reduciendo la VRAM disponible para texturas.
Solución: Si quieres RT, baja texturas o sombras. Si quieres texturas nítidas, baja RT. Elige un lujo a la vez a menos que tengas mucha VRAM.
8) “Instalé un paquete de texturas de alta resolución y ahora todo pega”
Causa raíz: El paquete aumentó el conjunto de trabajo más allá de la VRAM; ahora la paginación por PCIe es parte de tu bucle de fotograma.
Solución: Desinstala el paquete o acepta texturas más bajas en otras áreas. Los packs de alta resolución no son “actualizaciones gratuitas”. Son decisiones de capacidad.
Listas de control / plan paso a paso
Lista A: elige el nivel de texturas correcto en 15 minutos
- Encuentra una escena de peor caso: ciudad densa, muchos materiales únicos, travesía rápida.
- Activa una superposición de tiempo de fotograma (no solo FPS).
- Configura texturas en Ultra; juega 2 minutos; anota pico de VRAM y peores picos de tiempo de fotograma.
- Configura texturas en Alta; repite el mismo recorrido; compara picos y pico de VRAM.
- Si Alta elimina picos importantes y Ultra no se ve significativamente mejor en movimiento, mantén Alta.
- Si Ultra es fluido y aún tienes 10–20% de VRAM libre en el peor caso, felicidades: Ultra es para ti.
Lista B: estabilizar un sistema que tartamudea bajo carga de VRAM
- Cierra apps GPU-intensivas en segundo plano (navegadores con muchas pestañas, grabadores, superposiciones que no necesitas).
- Asegura que el juego esté instalado en SSD con >15% de espacio libre en ese volumen.
- Baja texturas un nivel; vuelve a probar.
- Si aún es malo: reduce RT/ resolución de sombras; vuelve a probar.
- Reduce ligeramente los FPS por debajo de tu promedio típico (p. ej., 120 → 90, 60 → 50). Esto reduce ráfagas.
- Sólo entonces considera la escala de resolución.
Lista C: reglas “Ultra sin arrepentimiento”
- Las texturas Ultra están justificadas cuando tienes margen de VRAM en las peores escenas y juegas lo suficientemente despacio como para notar detalle fino.
- Las texturas Ultra no están justificadas cuando llevan la VRAM al límite, especialmente en juegos de mundo abierto.
- Si transmites contenido (captura/encode) mientras juegas, asume que necesitas más margen que en un escenario de “solo juego”.
- Si el juego tiene un “paquete de texturas de alta resolución”, trátalo como un requisito de hardware, no como un añadido cosmético.
Preguntas frecuentes
1) ¿Se supone que el uso de VRAM debe estar cercano al 100%?
No. Un sistema sano usa VRAM pero mantiene margen. 95–100% en escenas demandantes es donde empiezan la paginación y las tormentas de desalojos.
2) ¿Por qué las texturas causan más tartamudeo que otros ajustes?
Porque las texturas son grandes y numerosas, y la penalización por faltar una textura necesaria suele ser una espera síncrona: desalojar, subir, descomprimir y luego dibujar.
3) Si mi GPU tiene mucho cálculo, ¿por qué no puede “sobresalir”?
El cálculo no ayuda si los datos no son residentes. Una GPU rápida esperando una carga de textura sigue esperando. Esto no es una competición de fuerza; es una falla logística.
4) ¿Bajar resolución reduce el uso de VRAM?
Reduce la memoria de render-target y algunas cachés, pero puede no reducir materialmente la residencia de texturas. Por eso las caídas de resolución a menudo no arreglan el tartamudeo causado por texturas.
5) ¿Las texturas “Alta” y “Ultra” son visiblemente diferentes?
A veces en imágenes estáticas. A menudo no en movimiento, especialmente con TAA, profundidad de campo y distancias de cámara típicas. Si no lo notas durante el juego, no pagues el impuesto de VRAM.
6) ¿Cuál es la diferencia entre VRAM “asignada” y VRAM “usada”?
Asignada puede significar espacio de direcciones reservado o recursos comprometidos. Usada/residente significa que ocupa realmente VRAM local. Las herramientas varían; no asumas que una superposición es la autoridad definitiva.
7) ¿Un SSD puede arreglar problemas de VRAM?
Un SSD ayuda el streaming, no la residencia. Puede reducir la severidad de los tirones haciendo que los datos lleguen más rápido, pero no puede reemplazar el ancho de banda y la latencia de la VRAM local.
8) ¿Debo desactivar el streaming de texturas?
Sólo si el juego lo soporta bien y tienes VRAM masiva. Desactivar el streaming suele aumentar las cargas iniciales y puede incrementar la demanda total de VRAM. Prueba, no adivines.
9) ¿Por qué el trazado de rayos afecta la suavidad de las texturas?
Las características RT consumen VRAM para estructuras de aceleración e historiales. Eso reduce el presupuesto de memoria disponible para la residencia de texturas y los pools de streaming.
10) ¿Qué ajuste único da mejor relación coste/beneficio si bajo las texturas?
El filtrado anisotrópico suele ser barato y mejora la claridad de las texturas en ángulos. Mantenlo alto mientras ajustas a la baja la resolución de texturas.
Siguientes pasos que realmente puedes hacer
Si tu enfoque actual es “poner todo en Ultra y esperar”, reemplázalo por un proceso:
- Elige una escena de peor caso y mide VRAM y picos de tiempo de fotograma.
- Baja texturas un nivel y repite el mismo recorrido. Si los picos disminuyen, mantiene ese ajuste y sigue con tu vida.
- Protege margen: apunta a picos de VRAM que dejen 10–20% libres en las escenas que importan.
- Gasta tu presupuesto donde lo notes: pacing estable, sombras sensatas y AF antes que derechos de fanfarronear.
- Cuando cambies algo, cambia una sola cosa. Afinar es depurar, no un ritual.
Ultra no es una insignia de honor. Es una política de recursos. Haz que sea una política que puedas permitirte.