Shaders programables: cuando los «gráficos» se convirtieron en software

El punto de inflexión: de fixed-function a programable

Las GPUs de función fija eran electrodomésticos. Les dabas vértices y texturas; aplicaban una secuencia conocida de transformaciones, iluminación y mezcla.
Podías elegir opciones (niebla on/off, un par de etapas de texturas, un modelo de iluminación), pero no podías reescribir la tubería. Esa era una época de
cierta estabilidad: si renderizaba mal, probablemente era por tus matemáticas o tus activos, no por tu “programa”.

Los shaders programables convirtieron la tubería en un entorno de ejecución. En lugar de seleccionar en un menú, escribes programas—primero para vértices,
luego para fragmentos/píxeles, después geometry, tessellation, compute, mesh shaders y varias variantes modernas. La GPU se volvió una máquina masivamente paralela
que ejecuta tu código con restricciones que se sienten como una mezcla entre sistemas embebidos y computación distribuida: distintos proveedores, distintos
compiladores, comportamiento sutil indefinido y acantilados de rendimiento que pueden aparecer o desaparecer con una actualización de driver.

El cambio cultural importa tanto como el técnico. Una vez que los shaders se convirtieron en código, “gráficos” dejó de ser un problema puramente artístico
de pipeline y pasó a ser un problema de operaciones de ingeniería. Ahora tienes:

• Sistemas de build que compilan shaders (a menudo varias veces, para múltiples objetivos).
• Cachés que almacenan variantes compiladas y que pueden quedar obsoletos, corromperse o explotar en tamaño.
• Rutas de compilación en tiempo de ejecución que causan tirones, stutters o timeouts.
• Comportamiento específico del proveedor y bugs de drivers que debes mitigar sin reescribir el mundo.
• Presupuestos de rendimiento que se comportan como SLOs: un objetivo de tiempo de fotograma fallido es tiempo de inactividad visible para el usuario.

Aquí está la verdad operacional: si no puedes explicar a dónde va tu tiempo de fotograma, no controlas tu producto. Los shaders programables te dan las
perillas para controlarlo—pero también suficiente cuerda para hacer un macramé y luego caerte.

El pipeline de shaders, visto como un SRE

Piensa en cada etapa de shader como un servicio con un presupuesto de latencia

En sistemas de producción, asignas presupuestos: tiempo de CPU, E/S, memoria, profundidad de colas. En renderizado, tu “request” es un fotograma, y tu SLO es
un tiempo de fotograma estable (por ejemplo 16.6ms para 60Hz, 8.3ms para 120Hz). Cada etapa del pipeline consume presupuesto: procesamiento de vértices,
rasterización, shading de fragmentos, blending, post-procesado, presentación. Cuando añades etapas programables, añades servicios con código que puedes cambiar
con frecuencia—y cada cambio es una regresión potencial.

El tiempo de fotograma no es un número único; es una ruta crítica. Tu cola de GPU puede bloquearse por un shader de larga duración, overdraw excesivo, un pase
que consume ancho de banda, o puntos de sincronización (barriers, readbacks, espera de fences). “GPU bound” es una respuesta como “la base de datos está lenta”:
técnicamente cierta, operacionalmente inútil.

Los shaders son artefactos compilados con riesgo en el despliegue

Los shaders no se ejecutan como tu código fuente de alto nivel. Se compilan a representaciones intermedias y luego a código máquina. Dependiendo de la API y
la plataforma, la compilación puede ser:

• Offline (ahead-of-time), empaquetada en el build.
• Online (JIT), compilada en tiempo de instalación o en el primer uso.
• Híbrida, donde envías un intermedio (como SPIR-V) pero los drivers aún optimizan y bajan a código nativo.

Cada uno de estos modelos tiene un coste operativo. La compilación offline desplaza fallos a CI y reduce los tirones en tiempo de ejecución, pero aumenta la
complejidad del build y la proliferación de artefactos. JIT reduce el tamaño del build y puede usar el mejor compilador del driver, pero introduce
stutter en el primer uso y hace que los fallos ocurran en la máquina del cliente, donde tienes menos observabilidad.

Permutaciones de shaders: el problema de sistemas distribuidos que no pediste

Un único “shader” raramente es un solo programa. Los motores reales generan permutaciones basadas en:

• Características del material (normal map, clear coat, subsurface, emissive, etc.).
• Rutas de iluminación (forward vs deferred, calidad de sombras, número de luces).
• Capacidades de la plataforma (precision, wave ops, formatos de textura).
• Conmutadores del pipeline de render (MSAA, HDR, VR, variantes de temporal AA).

Multiplica eso y obtienes miles de variantes. Si no gestionas activamente las permutaciones, tus tiempos de compilación se disparan, tus cachés thrashan y
lanzarás una build que “está bien en máquinas de desarrollo” pero se queda en stutter para los jugadores porque la cache de shaders está fría. Esto es el
equivalente gráfico de desplegar una arquitectura de microservicios porque querías un botón nuevo en la página principal.

Una cita para tener en una nota adhesiva

La esperanza no es una estrategia. — General Gordon R. Sullivan

Los shaders recompensan la ingeniería basada en la esperanza: “El compilador lo optimizará”, “El driver lo cacheará”, “Probablemente esté bien”. Eso funciona
hasta que no, y entonces tu canal de incidentes se llena de capturas de pantalla de iluminación derretida y gráficas de tiempo de fotograma con forma de montaña.

Hechos interesantes y contexto histórico (la versión corta y concreta)

1. La función fija duró más de lo que la gente recuerda. Las primeras GPUs de consumo ofrecían una tubería que podías configurar pero no reescribir; la creatividad venía de trabajar con las limitaciones.
2. Los vertex shaders programables llegaron antes que los píxeles programables. Transformación e iluminación fueron la primera gran victoria “programable” porque coincidían con las fortalezas del hardware.
3. Los primeros pixel shaders estaban muy restringidos. El conteo de instrucciones y la presión de registros eran límites duros; aprendías a contar ops como los ingenieros de almacenamiento cuentan IOPS.
4. Los lenguajes de shader no eran sólo por conveniencia. Eran para portabilidad y herramientas—alejarse del ensamblador específico del proveedor y entrar en algo que los compiladores pudieran razonar.
5. Las arquitecturas de «shader unificado» cambiaron la planificación. Cuando las GPUs pasaron de unidades separadas de vértices/píxeles a núcleos unificados, el rendimiento dejó de ser una simple historia de “vertex vs pixel bound”.
6. Los compute shaders difuminaron la línea entre gráficos y GPGPU. Una vez que tienes una etapa de cómputo general, empiezas a hacer culling, trabajo parecido a física y efectos de post como cargas de cómputo.
7. La compilación de shaders se trasladó a la pila del driver. Eso convirtió las actualizaciones en una variable de rendimiento, que es una forma educada de decir: tu build puede volverse más lenta sin que cambies código.
8. Las representaciones intermedias se convirtieron en estrategia. Enviar algo como SPIR-V busca estandarizar entradas, pero los drivers aún tienen la última palabra sobre el código máquina final.
9. Los pipelines modernos añaden nuevas etapas programables. Tessellation, mesh shaders, ray tracing shaders—cada uno añade potencia y nuevos modos de fallo.

Qué se rompe en la vida real: modos de fallo que puedes predecir

1) Tirones de compilación que se hacen pasar por “lag de red”

Un clásico: un jugador gira una esquina, ve un nuevo efecto y el juego se queda corto. La gráfica de red recibe la culpa. Los servidores reciben la culpa. Alguien abre un ticket
contra matchmaking. Mientras tanto, el problema real es que una variante de shader se compiló en el primer uso en el cliente. Si no precalientas cachés o no envías
artefactos compilados, estás subcontratando la latencia al peor momento posible: cuando el usuario está interactuando activamente.

2) Explosiones de permutación que silenciosamente DoSean tu build y caché

Las características de shader son adictivas. Una define más, una rama más, un toggle de calidad más. “Solo lo añado” hasta que tienes decenas de miles de variantes.
Entonces tus tiempos de CI se duplican, los artistas dejan de iterar porque los builds son lentos y tu caché en tiempo de ejecución se convierte en un vertedero. Las permutaciones
no son gratis; son un problema de planificación de capacidad.

3) Bugs de precisión: “funciona en mi GPU” con matemáticas en ese límite

GPUs y drivers diferentes difieren en comportamiento de punto flotante, manejo de denormales, operaciones fusionadas y valores por defecto de precisión. Si tu shader depende
de un comportamiento numérico al límite—especialmente en half precision—puedes obtener banding, parpadeo, NaNs o frames completamente negros en un subconjunto de hardware.

4) Overdraw y ancho de banda: los asesinos silenciosos

El ALU del shader recibe toda la atención porque parece “código”. Pero muchos cuellos de botella reales son de ancho de banda (lecturas de textura, escrituras a render target) y overdraw
(shading de píxeles que serán sobrescritos). Puedes escribir el BRDF más mono del mundo y aun así perder frente a un pase a pantalla completa que lee cuatro texturas a 4K y escribe
dos targets HDR. Tu GPU no es un filósofo; es una carretilla.

5) Errores de sincronización: burbujas de GPU que creaste tú mismo

Barreras, transiciones de recursos y readbacks pueden serializar trabajo. El resultado es una GPU que está “ocupada” pero no productiva. Es el equivalente en renderizado de
una carga de almacenamiento que pasa la mitad del tiempo esperando flushes porque alguien puso fsync en un bucle caliente.

6) Regresiones del compilador del driver: tu código estable, su backend cambiante

Los drivers cambian. Los compiladores de shader cambian. Exactamente el mismo shader de alto nivel puede compilarse en diferente código máquina tras una actualización. A veces es más rápido.
A veces es más lento. A veces se compila mal. Por eso el despliegue de shaders necesita observabilidad y guardrails, no vibras.

Broma #1: Un compilador de shaders es como un gato—si le gusta tu código, igual tirará algo de la mesa sólo para verte reaccionar.

Guía rápida de diagnóstico (qué comprobar primero/segundo/tercero)

Primero: determina si estás ligado a CPU, GPU o sincronización

• Comprueba la utilización y las frecuencias de la GPU. Uso alto de GPU con relojes estables sugiere GPU-bound; uso bajo con stutters sugiere sincronización o agotamiento de CPU.
• Comprueba el desglose del tiempo de fotograma. Si el tiempo de fotograma de CPU es bajo pero el de GPU es alto, estás GPU-bound. Si ambos se disparan, busca stalls y sincronizaciones.
• Busca picos periódicos. Picos regulares (cada pocos segundos) suelen indicar compilación de shaders, streaming de activos o recolección de basura.

Segundo: clasifica el cuello de botella de GPU

• ALU-bound: matemáticas pesadas, iluminación compleja, demasiadas instrucciones, ramas divergentes.
• Texture/bandwidth-bound: muchas lecturas de textura, fallos de caché, render targets grandes, pases de alta resolución.
• Overdraw-bound: muchas capas transparentes, partículas, efectos a pantalla completa, sombreado de píxeles repetido.
• Cuello de función fija: rasterización, blending, resoluciones MSAA, complejidad de profundidad, saturación de ROP.

Tercero: aisla el pase o material culpable

• Captura un frame de GPU y ordena los draws por coste (tiempo o muestras).
• Deshabilita pases sistemáticamente: sombras, SSAO, bloom, reflections, volumétricos.
• Forza un material “plano” para ver si es impulsado por contenido (materiales) o por la tubería (post, iluminación, resolves).

Cuarto: confirma el comportamiento de compilación y caché

• Comprueba tasas de acierto de cache de shaders (logs del motor, directorios de cache del driver, estadísticas de pipeline cache).
• Busca eventos de compilación en tiempo de ejecución en el primer uso.
• Verifica que tu pipeline cache esté versionado correctamente y no se invalide en cada build.

Quinto: regresiones y seguridad en el despliegue

• Biseca cambios de shader por commit o por feature flag.
• Valida en múltiples vendors y múltiples versiones de driver.
• Despliega con guardrails: toggles, modos seguros y telemetría.

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

Estos son los tipos de comandos que ejecutas cuando depuras rendimiento y estabilidad relacionados con shaders en estaciones Linux o rigs de prueba.
El objetivo no es hacer cosplay de ingeniero de drivers. El objetivo es tomar una decisión rápida: CPU vs GPU, compilación vs tiempo de ejecución, salud de la caché y dónde instrumentar a continuación.

Task 1: Identify the GPU and driver in use

cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484] (rev a1)

Qué significa: Sabes el vendor/device. Esta es tu primera clave de partición para “sólo en algunas máquinas”.

Decisión: Reproduce en al menos otro vendor si es posible; no confíes en una sola familia de GPU para representar “PC”.

Task 2: Confirm the loaded kernel driver module

cr0x@server:~$ lsmod | grep -E "amdgpu|i915|nvidia"
nvidia_drm             73728  4
nvidia_modeset       1236992  8 nvidia_drm
nvidia              59387904  457 nvidia_modeset

Qué significa: La pila de driver está activa; útil para confirmar que no estás ejecutando por accidente en un fallback.

Decisión: Si esperas un driver (p. ej. amdgpu) y ves otro o ninguno, para: tus datos de prueba son basura.

Task 3: Check OpenGL renderer and version (easy sanity check)

cr0x@server:~$ glxinfo -B | sed -n '1,20p'
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: NVIDIA Corporation (0x10de)
    Device: NVIDIA GeForce RTX 3070/PCIe/SSE2 (0x2484)
    Version: 535.154.05
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 3070/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 535.154.05

Qué significa: Confirma rendering directo y la versión del driver en espacio de usuario. Si esto está mal, todo lo demás es ruido.

Decisión: Registra esto en tu plantilla de informe de bugs. Si no puedes reproducir con la misma cadena de renderer, trátalo como un incidente distinto.

Task 4: Check Vulkan device and driver (if your engine uses Vulkan)

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

Devices:
========
GPU0:
    apiVersion         = 1.3.280
    driverVersion      = 535.154.5
    vendorID           = 0x10de
    deviceID           = 0x2484
    deviceType         = DISCRETE_GPU
    deviceName         = NVIDIA GeForce RTX 3070

Qué significa: Confirma la ruta Vulkan y la versión del driver; crucial para el comportamiento del pipeline cache y las toolchains SPIR-V.

Decisión: Si una regresión se correlaciona con cambios en driverVersion, reproduce en un driver más antiguo/nuevo antes de reescribir shaders.

Task 5: Watch GPU utilization live (is it actually busy?)

cr0x@server:~$ nvidia-smi dmon -s u -d 1
# gpu   sm   mem   enc   dec   mclk   pclk
# Idx    %     %     %     %    MHz    MHz
    0   97    61     0     0   7001   1905
    0   98    62     0     0   7001   1905

Qué significa: SM% alto sugiere shader/compute intensivo. mem% alto sugiere presión de ancho de banda.

Decisión: Si SM% es bajo pero el tiempo de fotograma es alto, sospecha stalls por sincronización, cuellos de botella de CPU o esperas a nivel de driver.

Task 6: Identify which process is using the GPU

cr0x@server:~$ nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory --format=csv
pid, process_name, used_gpu_memory [MiB]
23144, game-client, 6123

Qué significa: Confirma el binario correcto está siendo medido; ayuda a detectar errores de “ups, estoy midiendo el launcher”.

Decisión: Si múltiples procesos compiten, aisla: los números de rendimiento no son comparables bajo contención.

Task 7: Inspect shader cache directories (size and churn)

cr0x@server:~$ du -sh ~/.cache/*shader* 2>/dev/null | sort -h
128M	/home/cr0x/.cache/nvidia/GLCache
1.9G	/home/cr0x/.cache/mesa_shader_cache

Qué significa: Cachés grandes pueden ser normales, pero un crecimiento repentino tras un parche sugiere bloat de permutaciones o invalidación.

Decisión: Si la caché crece drásticamente por build, versiona correctamente tu pipeline cache y reduce permutaciones.

Task 8: Check whether your app is recompiling shaders at runtime (log grep)

cr0x@server:~$ grep -E "Compiling shader|Pipeline cache miss|PSO compile" -n /var/log/game-client.log | tail -n 8
18422 Compiling shader variant: Material=Water, Perm=HDR+SSR+Foam
18423 PSO compile: vkCreateGraphicsPipelines took 47 ms
18424 Pipeline cache miss: key=0x6f2a...

Qué significa: Evidencia de compilación en tiempo de ejecución y creación de pipelines costosa. Esos 47ms son un tirón que se nota.

Decisión: Añade pasos de precompile/prewarm para permutaciones calientes conocidas; evita crear pipelines en el render thread durante gameplay.

Task 9: Monitor CPU frequency and throttling (stutters that look like GPU issues)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 1 | head -n 5
Avg_MHz	Busy%	Bzy_MHz	TSC_MHz	IRQ
4120	38.5	4710	2800	21430
1180	12.1	2870	2800	9050

Qué significa: Si Avg_MHz colapsa durante los stutters, tu “regresión de GPU” podría ser gestión de energía de CPU o límites térmicos.

Decisión: Reprueba con el governor de rendimiento, verifica la refrigeración y elimina la estrangulación de CPU del experimento.

Task 10: Check present mode / compositor interference (frame pacing problems)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Qué significa: Las diferencias Wayland/X11 pueden cambiar el pacing de frames y el comportamiento de las herramientas de captura.

Decisión: Si el pacing es inconsistente sólo bajo un compositor, prueba en una sesión de pantalla completa dedicada o en otro tipo de sesión.

Task 11: Track GPU memory pressure (evictions cause spikes)

cr0x@server:~$ nvidia-smi --query-gpu=memory.total,memory.used,memory.free --format=csv
memory.total [MiB], memory.used [MiB], memory.free [MiB]
8192 MiB, 7940 MiB, 252 MiB

Qué significa: Estás cerca del precipicio. Cuando la VRAM está ajustada, el driver puede paginar o expulsar recursos, produciendo stutters y costes impredecibles.

Decisión: Reduce tamaños de render target, recorta la residencia de texturas, corta pipelines cargadas por permutación o implementa límites de streaming.

Task 12: Confirm the engine is using the expected shader backend (config check)

cr0x@server:~$ grep -E "rhi=|renderer=|shader_backend=" -n /etc/game-client.conf
12 renderer=vulkan
13 shader_backend=spirv

Qué significa: Un backend desajustado (fallback OpenGL, ruta de compilador distinta) cambia rendimiento y corrección.

Decisión: Si un bug sólo ocurre en un backend, has aislado el radio de impacto y puedes enviar una mitigación dirigida.

Task 13: Measure per-process CPU time and context switches (sync-bound clue)

cr0x@server:~$ pidstat -w -p $(pgrep -n game-client) 1 3
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(16 CPU)

12:14:01      UID       PID   cswch/s nvcswch/s  Command
12:14:02     1000     23144   1250.00    210.00  game-client
12:14:03     1000     23144   1180.00    190.00  game-client

Qué significa: Altos context switches involuntarios pueden indicar contendencia, bloqueos o sincronización con el driver.

Decisión: Si nvcswch/s se dispara durante hitchs de frame, inspecciona puntos de sincronización y hilos de compilación en background.

Task 14: Detect shader-related crashes via kernel logs (GPU reset / hang)

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Mon Jan 13 12:22:09 2026] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: Shader Program Error
[Mon Jan 13 12:22:09 2026] NVRM: Xid (PCI:0000:01:00): 31, Ch 0000007b, engmask 00000101, intr 10000000

Qué significa: La GPU reportó una falla consistente con un problema de shader/programa o un problema de driver. No es “solo un crash”.

Decisión: Reproduce con capas de validación / builds debug y reduce la complejidad del shader; también prueba versiones alternativas de driver.

Task 15: Compare shader artifact counts between builds (permutation control)

cr0x@server:~$ find /opt/game/shaders/ -type f -name "*.spv" | wc -l
18422

Qué significa: Un salto en el conteo entre builds es un fuerte indicador de explosión de permutaciones.

Decisión: Bloquea merges que aumenten el conteo de artefactos de shader por encima de un umbral; requiere justificación y una prueba de rendimiento.

Tres microhistorias corporativas del terreno de “funcionó en mi GPU”

Microhistoria 1: El incidente causado por una suposición equivocada

Un equipo de producto mediano lanzó un nuevo pase de iluminación “premium”. Estaba controlado por un toggle simple: High/Ultra lo habilitaba, Medium lo deshabilitaba.
QA firmó el toggle. El rendimiento parecía aceptable. Todo siguió su curso.

El incidente empezó un lunes después de que una actualización rutinaria de drivers se propagara por las máquinas corporativas. De repente, los canales de soporte se llenaron de
informes: “Pantallas negras aleatorias tras alt-tab”, “UI parpadea”, “solo en portátiles”, “solo a veces”. Ingeniería hizo el baile usual—reinstalar, limpiar caches,
culpar a Windows, culpar al compositor, culpar la fase de la luna.

La suposición equivocada: creyeron que “si compila, se ejecuta”. En realidad, el nuevo pase incluía una variante de shader que compilaba con éxito pero activaba un comportamiento
indefinido en una combinación específica driver/compilador cuando se activaba una define rara (sólo ocurría cuando la superposición de UI estaba activa y el HDR estaba habilitado).
No probaron esa permutación porque no formaba parte de sus “escenas estándar” de prueba.

La solución no fue glamorosa. Crearon una matriz de permutaciones para la cobertura de pruebas, añadieron cheques de validación en tiempo de ejecución (guards contra NaN en debug),
y construyeron una pequeña suite de escenas “raras pero reales” que activaban overlays, escalas de resolución extrañas y combinaciones HDR. También añadieron una válvula de seguridad:
si el pase falla validación o provoca errores repetidos de GPU, se desactiva automáticamente y registra una huella.

La lección: compilar es la admisión al edificio, no la prueba de que no incendiarás la cocina.

Microhistoria 2: La optimización que salió mal

Otro equipo persiguió un pico de costes GPU en una escena con mucha vegetación. El perfil mostró que el shading de fragmentos era costoso, y un ingeniero senior propuso una
optimización: empaquetar múltiples parámetros de material en menos texturas y usar half precision. Menos ancho de banda, menos registros, shading más rápido. En papel, era un cambio
para presumir en una revisión de rendimiento.

El cambio se lanzó detrás de una bandera y se veía genial en las GPUs insignia de desarrollo. El tiempo de fotograma mejoró modestamente. Luego llegó a un conjunto más amplio de máquinas
y comenzó la rareza: reflejos chispeantes, TAA inestable, píxeles negros ocasionales en movimiento. El rendimiento también empeoró en algunas GPUs AMD.

El revés fue doble. Primero, la half precision redujo la estabilidad numérica en su ruta de reconstrucción normal. Valores que eran “suficientemente cercanos” pasaron a ser “suficientemente
para romper la historia de TAA”. Segundo, el esquema de empaquetamiento incrementó la divergencia en el muestreo de texturas: más lecturas dependientes, patrones de acceso menos amigables
con caché y mayor latencia en arquitecturas específicas. El shader se volvió “más pequeño” pero menos coherente.

Lo revertieron, luego lo reintrodujeron con guardrails: mantener precisión completa en las partes que alimentan la reproyección temporal; usar half precision sólo en lóbulos menos sensibles;
y verificar rendimiento por vendor. También añadieron una prueba de corrección visual que comparaba frames a lo largo de una ruta de cámara determinista, porque “parece bien” no es una prueba.

Lección: optimizar shaders es como ajustar un índice de base de datos—puedes ganar mucho, pero también optimizar para el benchmark y castigar la realidad.

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

Un equipo de plataforma tenía una política que parecía dolorosamente conservadora: cada cambio de shader tenía que incluir un pequeño archivo de metadatos describiendo el impacto esperado
en el conteo de permutaciones, y cada build producía un manifiesto diffable de artefactos de shader. La gente se quejaba. Parecía burocracia.

Un ciclo de lanzamiento, una característica aparentemente inocua añadió una nueva keyword de material. Los artistas la empezaron a usar por todas partes, porque mejoraba la apariencia.
La keyword interactuaba con tres toggles más, y el conteo de permutaciones se multiplicó en silencio. Los tiempos de build empezaron a crecer. Los reportes de stutter en tiempo de ejecución
aumentaron, pero lo hicieron lo suficientemente despacio como para que nadie tuviera un único momento de “rompió”.

La práctica aburrida entró en acción: el diff del manifiesto de shaders mostró un aumento significativo en variantes compiladas ligado a esa keyword. Al estar rastreado como artefacto de primera
clase, el equipo de plataforma pudo señalarlo sin discutir sensaciones. Pausaron el rollout, refactorizaron la keyword en una rama en tiempo de ejecución donde era segura, e introdujeron una
política de niveles de característica: si una keyword crea demasiadas variantes, debe restringirse a materiales específicos o colocarse tras un nivel de calidad.

Eso previno un incidente mayor: una escena de marketing de última hora habría forzado la compilación en frío de miles de variantes en el primer inicio. En su lugar,
la build se envió con permutaciones controladas y entradas de caché pre-calentadas para la ruta de demo conocida. Nadie fuera de ingeniería notó nada—eso significa que fue un éxito.

Broma #2: El shader más fiable es el que no existe, que también es mi enfoque para las reuniones.

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

Stutter al primer encuentro con un efecto

Síntoma: Picos de tiempo de fotograma cuando aparece un nuevo material/efecto; luego suaviza.

Causa raíz: Compilación de shader o pipeline en tiempo de ejecución (cache fría), a menudo en el render thread.

Solución: Precompilar permutaciones conocidas; pre-calentar cachés durante la carga; mover la creación de pipelines a compilación asíncrona con un fallback; enviar caches de pipeline versionados.

Regresión de rendimiento sólo en un vendor de GPU

Síntoma: NVIDIA está bien, AMD se desploma (o viceversa) tras un cambio de shader.

Causa raíz: Sensibilidad específica de la arquitectura: ramas divergentes, presión de registros, patrones de acceso a texturas o regresión del compilador del driver.

Solución: Perfilar por vendor; reducir divergencia; simplificar lecturas dependientes de textura; probar formas de código alternativas; mantener rutas de workaround específicas por vendor sólo cuando se midan.

Parpadeo aleatorio o píxeles brillantes en movimiento

Síntoma: Inestabilidad temporal, “fireflies” o parpadeo que empeora durante el movimiento de cámara.

Causa raíz: Problemas de precisión (half floats), NaNs/Infs, normales inestables o matemática no determinista que alimenta filtros temporales.

Solución: Añadir clamps contra NaN en debug; mantener rutas críticas en precisión completa; estabilizar entradas (normalizar con seguridad); auditar divisiones y raíces cuadradas; añadir epsilon donde sea necesario.

Banding en gradientes o iluminación

Síntoma: Gradientes suaves se vuelven escalones, especialmente en niebla, cielo o zonas de poca luz.

Causa raíz: Almacenamiento o matemática de baja precisión (buffers de 8-bit, half precision), o falta de dithering.

Solución: Usar formatos de mayor precisión donde haga falta; aplicar dithering; evitar cuantizar iluminación intermedia demasiado pronto.

Utilización de GPU baja pero tiempo de fotograma alto

Síntoma: La GPU parece infrautilizada, pero los fotogramas son lentos o inconsistentes.

Causa raíz: Stalls de sincronización: esperando fences GPU/CPU, readbacks, serialización por barriers o la CPU que no alimenta la GPU.

Solución: Eliminar readbacks de rutas calientes; usar doble/triple buffering; mover trabajo fuera del hilo principal; reducir barriers innecesarias; medir tiempos de submission y espera de colas.

Partículas transparentes aplastan el rendimiento inesperadamente

Síntoma: Picos de tiempo de fotograma con humo, UI o escenas con muchas partículas.

Causa raíz: Overdraw y shaders de fragmento costosos; el blending impide optimizaciones early-z.

Solución: Reducir número de capas de partículas; ordenar y agrupar; usar shaders más baratos para partículas lejanas; añadir pre-pass de profundidad o profundidad aproximada; considerar masked en lugar de blended cuando sea aceptable.

Los tiempos de build explotan tras “solo una característica más”

Síntoma: La compilación de shaders en CI pasa de minutos a “ve a comer”.

Causa raíz: Explosión de permutaciones por combinaciones de features y keywords de material.

Solución: Rastrear conteos de permutación; limitar keywords; consolidar features; mover toggles a ramas en tiempo de ejecución; precomputar código compartido; requerir justificación de perf/compilación para nuevos defines.

Crash o reset de GPU en escenas específicas

Síntoma: Reset de driver, device lost o entradas de kernel log referenciando errores de shader.

Causa raíz: Acceso a recursos inválidos, comportamiento indefinido, shaders demasiado largos que activan watchdogs o bugs de driver impactados por patrones de código específicos.

Solución: Usar capas de validación; simplificar el shader; evitar indexado fuera de rango; reducir complejidad de bucles; añadir cheques de límites robustos; probar drivers alternativos y desactivar la característica como mitigación.

Listas de verificación / plan paso a paso para una entrega fiable de shaders

1) Trata los shaders como código con puertas en CI

1. Compila en CI para todos los objetivos que envías. Falla builds por warnings que entiendas, no por warnings que ignores.
2. Exporta un manifiesto de artefactos de shader. Cuenta variantes, tamaños y hashes; haz diff por commit.
3. Haz seguimiento del tiempo de compilación como métrica. Si tiende a subir, es deuda técnica con interés.
4. Ejecuta una pequeña prueba de render determinista. Ruta de cámara fija, seed fijo, captura frames; compara contra baselines para detectar desviaciones grandes.

2) Controla las permutaciones intencionalmente

1. Que cada define se justifique. Si una feature crea muchas variantes, muévela a una rama en tiempo de ejecución o restrínjela por niveles.
2. Separa “comodidad del artista” de la “realidad en tiempo de ejecución”. Flexibilidad en authoring es genial; enviar 20k variantes no lo es.
3. Versiona correctamente las keys de cache. Cambios en la generación de shaders, opciones de compilador o estado de render deberían invalidar caches antiguos de forma limpia—no aleatoria.

3) Precalienta lo que importa, no todo

1. Identifica las rutas calientes. Pantalla de título, primera partida, efectos de armas comunes, cadena de post común.
2. Precompila o precrea pipelines para esas rutas. Hazlo durante la carga o como trabajo en background con indicador de progreso.
3. No bloquees el render thread por compilación. Si debes hacerlo, usa un shader fallback barato y cambia cuando esté listo.

4) Observabilidad: haz los problemas de shader medibles

1. Loggea eventos de compilación de pipeline con duraciones. Trata >5ms como sospechoso, >20ms como incident-grade en escenas interactivas.
2. Registra la huella del GPU/driver. Vendor, device ID, versión de driver, backend API y toggles clave.
3. Captura histogramas de tiempo de fotograma, no solo promedios. Los usuarios sienten p99 spikes, no tu FPS medio.
4. Mantén feature flags para pases riesgosos. Si aparece una regresión de driver, necesitas un kill switch que no requiera rebuild.

5) Disciplina operativa para el caos de drivers

1. Mantén una matriz de compatibilidad pequeña. Mínimo dos vendors, al menos un driver antiguo y uno último.
2. Documenta versiones de driver conocidas como malas. No como folklore—vínculalo a telemetría y escenas reproducibles.
3. Prefiere formas de código estables frente a trucos ingeniosos. El compilador GPU es poderoso, pero no es tu compañero de equipo.

Preguntas frecuentes

1) ¿Qué es exactamente un shader programable?

Un pequeño programa que se ejecuta en la GPU como parte del renderizado (o compute). En lugar de iluminación y texturizado de función fija, defines cómo se transforman los vértices
y cómo se sombrea cada píxel, a menudo con acceso a texturas y buffers.

2) ¿Por qué los shaders programables cambiaron la ingeniería de producción?

Porque introdujeron compilación, caché y comportamiento específico de plataforma en la ruta de render. Ahora despliegas código que pasa por toolchains de proveedores que no controlas,
con riesgos de latencia y corrección que aparecen en tiempo de ejecución.

3) Shader de vértices vs de fragmentos: ¿cuál es la diferencia operacional?

Los vertex shaders escalan con el conteo de vértices; los fragment shaders escalan con el conteo de píxeles (y el overdraw). Si el problema aparece a alta resolución o con mucha transparencia,
sospecha coste en fragment. Si aparece con geometría densa independiente de la resolución, sospecha coste de vértices o procesamiento de geometría.

4) ¿Por qué los shaders provocan stutter la primera vez que veo un efecto?

Porque algo se compiló o se creó un pipeline state object bajo demanda. El primer encuentro dispara compilación y pagas ese coste en la ruta crítica. La solución es prewarming, caching
o mover la compilación fuera del render thread con fallbacks.

5) ¿Enviar SPIR-V (u otro intermedio) es lo mismo que enviar “shaders compilados”?

No exactamente. Un intermedio puede reducir variabilidad y mejorar herramientas, pero los drivers suelen seguir compilando/optimizando a código máquina final. Aún necesitas gestionar costes
de creación de pipeline y comportamiento de caché.

6) ¿Cómo sé si estoy limitado por ancho de banda o por ALU?

Usa perfiles y contadores GPU cuando estén disponibles, pero también puedes hacer experimentos baratos: reduce resolución (los costes de bandwidth/fragment deberían bajar),
reduce lecturas de textura o simplifica las matemáticas. Si escalar la resolución cambia poco el rendimiento, puedes estar ligado a vértices/CPU/sincronización.

7) ¿Los shaders “sin ramas” siempre corren más rápido?

No. Eliminar ramas puede incrementar el conteo de instrucciones y la presión de registros, lo que reduce la occupancy y perjudica el rendimiento. La elección correcta depende de la arquitectura y debe medirse
en GPUs representativas.

8) ¿Deberíamos usar half precision siempre para velocidad?

Sólo donde sea seguro. Half precision puede ser excelente para algunos valores intermedios, pero también puede introducir inestabilidad en iluminación y sistemas temporales.
Úsala quirúrgicamente, no como regla general, y prueba tanto rendimiento como corrección.

9) ¿Cuál es el error más común de despliegue de shaders en las empresas?

Tratar cambios de shader como “actualizaciones de contenido” en lugar de despliegues de código: sin puertas CI, sin diffs de manifiesto, sin versionado de cache y sin telemetría
de eventos de compilación en tiempo de ejecución.

10) Si los drivers pueden cambiar el rendimiento, ¿optimizar es inútil?

La optimización sigue importando, pero debe basarse en medición y estar protegida por pruebas de regresión. Además, formas de código estables y patrones de acceso predecibles suelen
sobrevivir mejor a la variabilidad de drivers que los trucos ingeniosos.

Siguientes pasos prácticos

Si eres responsable de una pila de render en producción—juego, visualización, UI, cualquier cosa con GPU—trata los shaders como el código crítico que son.
No porque sea intelectualmente satisfactorio, sino porque reduce incidentes.

1. Añade un manifiesto de artefactos de shader a tu build. Cuenta variantes y haz diff por cambio. Detecta explosiones de permutaciones temprano.
2. Instrumenta la compilación en tiempo de ejecución y la creación de pipelines. Registra duración, etapa y clave de shader; alerta en picos de p95/p99 de tiempo de fotograma tras releases.
3. Establece un plan de prewarm de rutas calientes. Identifica los primeros 5 minutos de comportamiento típico del usuario y asegura que los shaders/pipelines relevantes estén listos.
4. Construye una matriz mínima de compatibilidad. Múltiples vendors, múltiples versiones de driver y una escena de prueba determinista difícil de “engañar”.
5. Crea kill switches para pases riesgosos. Si aparece una regresión de driver, quieres una mitigación hoy, no tras rebuild y re-certificación.

Los shaders programables son una de las mejores cosas que le pasaron a los gráficos. También son un recordatorio de que “gráficos” no es un dominio especial.
Es cómputo, compilación, caching y presupuestos de latencia—solo con capturas más bonitas cuando lo haces bien.