3dfx Voodoo: la tarjeta que popularizó el 3D

Antes de Voodoo: por qué el 3D era un desastre

En 1995, “3D en PC” significaba una lotería de chipsets, drivers y APIs a medio hacer. Podías comprar una CPU rápida, una tarjeta 2D decente,
y aun así acabar con una presentación de diapositivas en cuanto el juego intentaba mapear texturas. La mayoría de los sistemas renderizaban 3D por software en la CPU.
Funcionaba, más o menos, y solo si eras generoso con lo que “funcionaba” significaba.

El problema central no era que nadie supiera cómo hacer 3D. Los fabricantes de silicio lo sabían. Las placas arcade lo sabían. Las workstations lo sabían.
El problema en PC era la economía y la fragmentación: cada vendedor tenía un enfoque distinto, compensaciones distintas y calidad de drivers distinta.
Los desarrolladores de juegos se enfrentaban a una elección que todo ingeniero de plataforma reconoce:
o apuntar al común denominador y dejar rendimiento sobre la mesa, o optimizar para un entorno y alienar al resto.

En ese desorden, 3dfx lanzó un producto estrecho, diseñado para un propósito y bordeando la rudeza: “Esto es solo para 3D.
Conéctalo junto a tu tarjeta 2D y disfruta de no escribir un rasterizador por software.”
No era elegante. Era efectivo. Los sistemas de producción suelen serlo.

Qué era (y qué no era) la tarjeta Voodoo

El éxito original de consumo se recuerda típicamente como “Voodoo Graphics” (a menudo llamado Voodoo1 en retrospectiva).
Era un acelerador 3D dedicado, no una tarjeta gráfica completa en el sentido moderno. Aún necesitabas una tarjeta 2D separada para Windows.
El Voodoo se sentaba en el bus PCI, esperando a que un juego lo invocara, y entonces tomaba el control de la señal de vídeo mediante un cable de passthrough externo.

Ese cable externo suena a truco porque lo era. Pero fue un truco escogido estratégicamente: permitió a 3dfx salir al mercado
sin pelear contra el ecosistema de escritorio 2D y sin necesitar ser la única tarjeta que debía funcionar en todos los modos de Windows.
Si alguna vez has aislado un subsistema arriesgado detrás de un feature flag o un proxy, has visto el mismo instinto arquitectónico.

También significaba que el Voodoo podía centrarse en lo que importaba para los juegos: mapeo de texturas, Z-buffering, filtrado y blending,
afinado para las resoluciones habituales de la época. No tenía que ser un generalista. Tenía que ser rápido donde la gente realmente vivía.

La era de dos tarjetas y por qué fue un compromiso razonable

La configuración “dos tarjetas + cable” parece ridícula ahora, pero fue una separación limpia de responsabilidades:
salida 2D estable del escritorio por un lado y una tubería 3D especializada por el otro.
Esto redujo el radio de explosión cuando algo fallaba. Si un juego se bloqueaba, no perdías todo el escritorio.
En una época en que los drivers podían tumbar el sistema operativo con ellos, eso importaba.

Broma #1: El cable de passthrough fue el service mesh original—excepto que no tenía observabilidad, y podía quedarse atrás de tu mesa para siempre.

Cómo funcionaba: pipelines, passthrough y por qué importaba

El enfoque Voodoo fue contundente: acelerar las partes que son caras en software. La CPU podía encargarse de la lógica del juego, la física (tal como era),
y de alimentar triángulos. La tarjeta manejaba rasterización y texturizado a una velocidad que una CPU de mediados de los 90 no podía alcanzar.
Esta división de labores suena obvia hoy. En aquel entonces no lo era en el mercado de consumo, especialmente a precios que la gente común pagaría.

Un detalle práctico clave: la tubería Voodoo estaba diseñada alrededor de hardware de función fija. Los desarrolladores no escribían shaders.
Seleccionaban modos. Gestionaban texturas. Vivían dentro de restricciones.
Es muy parecido a operar un datastore distribuido con un modelo de consulta fijo: el rendimiento es asombroso siempre que respetes la forma del sistema.
Lucha contra él y perderás.

Cambio por passthrough: “simplemente funciona” hasta que no

El cable de passthrough externo del Voodoo llevaba señales VGA analógicas desde la tarjeta 2D hacia el Voodoo y luego hacia el monitor.
Cuando un juego entraba en modo 3D, el Voodoo conmutaba la salida hacia sí mismo. Era simple y sorprendentemente robusto, pero añadió nuevos modos de fallo:
degradación suave de la calidad de imagen, ghosting, cables defectuosos y problemas de “¿por qué mi monitor está en negro?” que no eran depurables por software.

Aquí es donde el cerebro del periodista y el del SRE se dan la mano. La característica es brillante. El modo de fallo es hostil para el usuario.
Puedes tener razón y aun así recibir páginas.

Por qué se sintió como una revolución

Voodoo no hizo que existiera el 3D. Hizo que el 3D se sintiera consistente. Podías comprar un juego que decía “acelerado por 3dfx”
y esperar razonablemente que fuese fluido y vistoso en una amplia gama de sistemas.
Esto redujo la incertidumbre para clientes y desarrolladores, y la incertidumbre es el impuesto que mata mercados.

Glide: el carril rápido con peaje

Glide era la API propietaria de 3dfx. Era esbelta, enfocada en juegos y cercana al hardware.
A los desarrolladores les encantaba porque producía buenos resultados con menos dolor que las alternativas de propósito general de la época.
A los usuarios les encantaba porque los juegos funcionaban mejor.

Pero el peaje era real. Glide ataba a los juegos al hardware 3dfx. Si no estabas en un Voodoo, estabas en el carril lento.
Ese tipo de optimización vertical es embriagadora cuando estás ganando—y asfixiante cuando la plataforma cambia.
Si alguna vez tu equipo ha construido herramientas internas que “solo funcionan en nuestro stack”, has visto la misma historia desarrollarse,
solo con menos polígonos.

Direct3D y OpenGL: desordenados, pero inevitables

La industria convergió hacia APIs que no estaban controladas por un único vendedor. Fueron más difíciles al principio, a veces más lentas
y con frecuencia menos predecibles. Pero eran portables, y la portabilidad es una inversión que se acumula.
Puedes lanzar una interfaz propietaria increíble, pero también te comprometes a mantener todo el ecosistema para siempre.
Los ecosistemas son caros. Pregúntale a cualquiera que esté en una rotación on-call.

Lo que cambió de la noche a la mañana: expectativas de usuario y gravedad de la industria

Una vez que la aceleración al nivel Voodoo se volvió visible, ya no hubo vuelta atrás. Efectos de iluminación, filtrado de texturas,
tasas de frames más altas—eso dejó de ser “algo agradable” y se convirtió en la base de cómo debía verse el juego en PC.
La tarjeta no solo se vendía a sí misma; vendía la idea de que el hardware 3D era un requisito.

Este es el cambio cultural sutil: cuando una capacidad se vuelve dominante, deja de ser una característica y se vuelve una dependencia.
Las dependencias crean obligaciones: compatibilidad, drivers, soporte, rendimiento predecible. La era Voodoo obligó al ecosistema PC
a tomarse en serio el 3D de consumo, y arrastró a sistemas operativos, modelos de driver y herramientas de desarrollo con ella.

También cambió la cultura de los benchmarks. La gente empezó a preocuparse por la tasa de frames, no solo por “si se muestra”.
Y una vez que te importa el rendimiento, inevitablemente empiezas a preocuparte por la medición.
Bien. La medición es el antídoto contra la superstición.

Datos interesantes y contexto que puedes usar en una barra (o en un postmortem)

• Voodoo Graphics era un acelerador solo para 3D: necesitabas una tarjeta 2D separada y un cable VGA de passthrough hacia el monitor.
• Glide se convirtió en un objetivo de facto: muchos juegos de PC incluían renderizadores explícitos 3dfx/Glide porque la mejora de rendimiento era obvia.
• Voodoo2 introdujo el intercalado por líneas (SLI): dos tarjetas podían repartir la carga de renderizado alternando líneas de exploración para mayor rendimiento.
• “SLI” originalmente significó scan-line interleave: el rebranding posterior en GPUs modernas está relacionado en espíritu pero no idéntico en implementación.
• El mercado pivotó hacia soluciones integradas 2D+3D en una sola tarjeta: los consumidores no querían dos tarjetas y un cable para siempre; ganó la integración.
• La calidad del driver se volvió un arma competitiva: la velocidad importaba, pero “¿se cuelga?” y “¿funciona en este juego?” importaban más que el marketing.
• La integridad de la señal analógica era real: cables baratos de passthrough y placas ruidosas podían degradar visiblemente la calidad de imagen 2D en CRTs.
• Las APIs se consolidaron con el tiempo: las rutas rápidas propietarias dieron paso a APIs ampliamente soportadas conforme el coste para desarrolladores y la compatibilidad dominaron.

Lecciones SRE de una tarjeta gráfica de 1996

1) Alcance estrecho vence a alcance perfecto

Voodoo tuvo éxito al no intentar ser todo. No necesitaba ejecutar el escritorio. Necesitaba hacer que los juegos se vieran bien y funcionaran rápido.
En sistemas de producción, el equivalente es un servicio con un límite claro y un SLO definido—y luego optimizar implacablemente dentro de ese límite.
El alcance amplio es cómo terminas haciéndote cargo de los casos límite de todos los demás.

2) La compatibilidad es una característica, no un impuesto

El ecosistema Voodoo funcionó porque suficientes juegos lo apuntaban y suficientes sistemas podían instalarlo sin sacrificios rituales.
Eso no es magia; es ingeniería operativa: drivers, rutas de instalación, valores por defecto sensatos y un modelo de soporte que no culpa al usuario.
La fiabilidad es un atributo del producto.

3) Mide el tiempo de fotograma, no sensaciones

La gente discutía sobre FPS entonces como discute sobre percentiles de latencia ahora. El instinto es correcto: la experiencia del usuario está moldeada por la consistencia,
no por los promedios. Un 45 FPS estable a menudo se siente mejor que 90 FPS con picos. Lo mismo con servicios:
un p95 estable es mejor que un p50 heroico. No optimices el número que te hace sentir bien.

4) “Ruta rápida” es un compromiso

Glide fue una ruta rápida. Las rutas rápidas son atractivas porque hacen que tu mejor caso sea espectacular.
Son peligrosas porque crean dos mundos: el mundo donde las cosas son rápidas y el mundo donde las cosas están rotas.
Si construyes una ruta rápida, también construyes una carga de pruebas, una historia de fallback y un plan de migración. O construyes un fallo futuro.

5) Los pequeños detalles físicos pueden convertirse en tu mayor problema de fiabilidad

Un cable VGA de passthrough endeble puede arruinar la experiencia aunque el silicio sea impecable. En el centro de datos esto es el transceptor flojo,
la fibra mal etiquetada, la alimentación con una mala puesta a tierra, el cable de parche “temporal” que sobrevive a tu organigrama.

6) Una cita que merece estar en tu pared

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

La era Voodoo recompensó a los equipos que probaron juegos reales en máquinas reales, no a los equipos que esperaban que el driver se comportara.
Igual hoy. La esperanza no te manda páginas; la realidad sí.

Tareas prácticas: verificar, medir y decidir (con comandos)

Estas tareas asumen que estás operando una estación de trabajo Linux, un host de construcción retro-gaming o una máquina de laboratorio usada para benchmarking/emulación.
El punto no es que puedas ejecutar un Voodoo en Linux moderno; el punto es desarrollar la memoria muscular:
inventariar el hardware, confirmar drivers, validar la ruta de renderizado y luego encontrar el cuello de botella con evidencia.

Task 1: Identify the GPU(s) and kernel driver bindings

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,+4p'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] [10de:1c03] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:11c3]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Qué significa: Ves el dispositivo y qué driver lo controla.
Decisión: Si falta “Kernel driver in use” o está equivocado, arregla el enlace del driver antes de perseguir el rendimiento.

Task 2: Check whether OpenGL is software-rendered (a classic “why is it slow” trap)

cr0x@server:~$ glxinfo -B | egrep 'OpenGL vendor|OpenGL renderer|OpenGL version'
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2
OpenGL version string: 4.6.0 NVIDIA 550.54.14

Qué significa: Estás usando un driver GPU real, no Mesa llvmpipe.
Decisión: Si el renderer muestra “llvmpipe” o “Software Rasterizer”, para—arregla el driver/pila GL primero.

Task 3: Verify Vulkan path (useful for modern wrappers/emulators)

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

Instance Extensions: count = 20
==============================
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
...

Devices:
========
GPU0:
	apiVersion         = 1.3.275
	driverVersion      = 550.54.14
	vendorID           = 0x10de
	deviceID           = 0x1c03
	deviceName         = NVIDIA GeForce GTX 1060 6GB

Qué significa: La pila Vulkan ve la GPU y el driver.
Decisión: Si no aparecen dispositivos, no tienes una pila Vulkan usable—evita las capas de traducción basadas en Vulkan hasta arreglarlo.

Task 4: Measure CPU frequency scaling (performance “mystery” number one)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|MHz'
CPU(s):                               16
Model name:                           AMD Ryzen 7 5800X 8-Core Processor
CPU MHz:                              3699.906

Qué significa: MHz de CPU reportado y topología.
Decisión: Si MHz está atascado muy bajo bajo carga, arregla el governor de energía/throttling térmico antes de culpar a la GPU.

Task 5: Confirm GPU clocks and throttling state

cr0x@server:~$ nvidia-smi --query-gpu=clocks.gr,clocks.mem,pstate,temperature.gpu,utilization.gpu --format=csv
clocks.gr [MHz], clocks.mem [MHz], pstate, temperature.gpu, utilization.gpu [%]
1770, 4006, P2, 67, 35

Qué significa: Puedes ver si la GPU está haciendo boost y si la utilización es significativa.
Decisión: Utilización baja con FPS bajos apunta a overhead de CPU/driver, stalls de sincronización o una ruta de renderizado equivocada.

Task 6: Validate PCIe link width and speed (bus bottlenecks still exist)

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta'
LnkCap:	Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us
LnkSta:	Speed 8GT/s (ok), Width x16 (ok)

Qué significa: La GPU está funcionando a la anchura/velocidad de enlace esperada.
Decisión: Si ves x1 o velocidad degradada, vuelve a asentar el hardware, revisa ajustes de BIOS e inspecciona risers/cables.

Task 7: Check system I/O wait and context switches during a benchmark

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 st
 1  0      0 312456  66240 845320    0    0    12    24  684 1250 12  3 85  0  0
 2  0      0 309812  66240 845988    0    0     0     0  722 1890 28  6 66  0  0
 3  0      0 307220  66240 846112    0    0     0     0  740 2055 35  7 58  0  0
 1  0      0 306900  66240 846220    0    0     0     0  701 1622 25  4 71  0  0
 1  0      0 306500  66240 846330    0    0     0     0  690 1501 18  3 79  0  0

Qué significa: Si wa es alto, estás esperando disco; si cs explota, podrías estar limitado por el scheduler.
Decisión: Iowait alto significa que tu “problema de GPU” probablemente sea streaming de assets o swap; arregla almacenamiento/presión de memoria.

Task 8: See which processes are actually eating CPU while you “benchmark”

cr0x@server:~$ pidstat -u 1 3
Linux 6.6.12 (server) 	01/13/2026 	_x86_64_	(16 CPU)

12:10:01     UID       PID    %usr %system  %guest   %CPU   CPU  Command
12:10:02    1000     18421   92.00    6.00    0.00  98.00     7  retroarch
12:10:02       0      1542    1.00    2.00    0.00   3.00     1  Xorg
12:10:02    1000      2310    0.00    1.00    0.00   1.00     3  pulseaudio

Qué significa: El emulador/juego está limitado por CPU (un core al máximo).
Decisión: Optimiza afinidad de cores, ajustes del emulador o overhead de traducción; las mejoras de GPU no ayudarán mucho.

Task 9: Confirm whether the system is swapping (latency poison)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        21Gi       1.2Gi       1.1Gi       9.0Gi        8.7Gi
Swap:          2.0Gi       1.6Gi       400Mi

Qué significa: Swap está en uso; si crece durante las pruebas, el rendimiento variará.
Decisión: Añade RAM, reduce procesos en segundo plano o ajusta swappiness; no persigas “stutter de GPU” hasta eliminar swap.

Task 10: Check dmesg for GPU resets and PCIe errors

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|amdgpu|i915|pcie|AER|reset' | tail -n 12
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:1c.0
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0:   device [1022:1453] error status/mask=00000001/00002000
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0:    [ 0] RxErr

Qué significa: Errores PCIe corregidos. No son fatales, pero no son reconfortantes.
Decisión: Si esto se correlaciona con stutters/caídas, inspecciona slot, riser, estabilidad PSU; no pierdas tiempo afinando software primero.

Task 11: Measure storage latency (asset streaming stutter is real)

cr0x@server:~$ iostat -x 1 3
Linux 6.6.12 (server) 	01/13/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.12    0.00    4.92    0.21    0.00   76.75

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         72.00   9140.00     0.00   0.00    0.35   126.94   15.00   1920.00    0.62   0.03   3.10

Qué significa: r_await/w_await son bajos; %util es bajo: el almacenamiento no es tu cuello de botella.
Decisión: Pasa a sincronización CPU/GPU y ruta de renderizado; no “optimices disco” por aburrimiento.

Task 12: Check file descriptor limits (yes, games and launchers can trip this)

cr0x@server:~$ ulimit -n
1024

Qué significa: 1024 archivos abiertos máximo para el shell/proceso.
Decisión: Si un launcher o emulador carga muchos assets/plugins, sube los límites; evita perseguir “crashes aleatorios” que son solo agotamiento de FD.

Task 13: Validate that you’re not running in a remote session with forced software rendering

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Qué significa: Tipo de sesión local. El reenvío X11 por SSH y algunas configuraciones anidadas pueden perjudicar la aceleración.
Decisión: Si corres por SSH X11 forwarding o en una VM limitada, haz el benchmark localmente o con passthrough GPU adecuado.

Task 14: Sanity-check thermal throttling (the silent performance killer)

cr0x@server:~$ sensors | sed -n '1,35p'
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +83.9°C
Tdie:         +83.9°C

nvme-pci-0100
Adapter: PCI adapter
Composite:    +44.9°C

Qué significa: La temperatura de la CPU es alta; puedes estar cerca del throttling según la plataforma.
Decisión: Arregla la refrigeración antes de optimizar caminos de código; el throttling hace que cada medición sea una mentira.

Broma #2: Si tus resultados de benchmark cambian después de abrir la caja, felicidades—has inventado el autoscaling basado en flujo de aire.

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

El objetivo no es ser listo. El objetivo es ser rápido, reproducible y lo suficientemente correcto para elegir la siguiente acción.
Haz esto en orden. Desvíate solo si tienes una razón sólida y puedes explicarla a otra persona.

Primero: verifica la ruta de renderizado y la realidad del driver

• Confirma que el driver de la GPU está enlazado (lspci -nnk).
• Confirma que OpenGL/Vulkan es hardware, no software (glxinfo -B, vulkaninfo --summary).
• Revisa logs por resets y ruido PCIe/AER (dmesg -T con filtros).

Puerta de decisión: Si estás con renderizado por software, para. Arregla eso. Todo lo demás es ruido descendente.

Segundo: decide si es CPU-bound o GPU-bound con una pasada de mediciones

• Observa la saturación de cores CPU (pidstat -u).
• Observa utilización y clocks GPU (nvidia-smi u equivalente del fabricante).
• Revisa swap y presión de memoria (free -h).

Puerta de decisión: Si un core está al máximo y la GPU está ociosa, estás limitado por CPU/overhead de driver.
Si la GPU está al máximo y la CPU tiene margen, estás limitado por GPU. Si ambos están bajos, estás estancado en sincronización, I/O o configuración.

Tercero: elimina los cuellos de botella “no obvios”

• Latencia de almacenamiento (iostat -x) si hay streaming/stutter.
• Ancho/velocidad PCIe (lspci -vv) si el rendimiento está extrañamente capado.
• Térmicas (sensors, temperaturas GPU) para evitar perseguir resultados con throttling.

Puerta de decisión: Si las térmicas o el enlace PCIe están mal, arregla hardware o firmware antes de afinar software.

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

Pantalla negra cuando el juego cambia a 3D

Síntoma: La pantalla se apaga al entrar en modo acelerado; el escritorio vuelve al salir, a veces.

Causa raíz: En la era Voodoo: cable de passthrough malo, frecuencia de refresco no soportada o problemas de sincronía del monitor.
En configuraciones modernas: modo fullscreen equivocado, conflicto con el compositor o reset de GPU.

Solución: Fuerza una resolución/frecuencia segura; cambia cables; evita adaptadores exóticos; revisa logs por resets de GPU; prueba fullscreen exclusivo vs borderless.

Buen promedio de FPS, pero el juego “se siente” mal

Síntoma: El benchmark reporta FPS altos, pero el movimiento es irregular y la entrada se siente con lag.

Causa raíz: Problemas de frame pacing: tiempos de fotograma desiguales por picos de CPU, compilación de shaders en caliente o problemas de sincronización (vsync/profundidad de cola).

Solución: Captura tiempos de fotograma (no solo FPS) con tus herramientas; reduce carga en segundo plano; precompila shaders cuando sea posible; prueba vsync y limitadores de frames.

El rendimiento está limitado a un techo extrañamente bajo

Síntoma: No importa lo que cambies, no puedes superar un FPS bajo (por ejemplo, 30/60/75) o la GPU se niega a boostear.

Causa raíz: Cap de Vsync, desajuste de refresco, estado de gestión energética o enlace PCIe negociado bajo (x1/x4).

Solución: Valida la tasa de refresco, desactiva vsync para probar, verifica anchura/velocidad PCIe y revisa pstate y ajustes del governor de la GPU.

Crashes que solo ocurren en una máquina

Síntoma: Mismo build, mismo juego, distinta estabilidad por máquina.

Causa raíz: Versiones de driver, overclocks inestables, PSU marginal, errores PCIe corregidos que escalan bajo carga o RAM defectuosa.

Solución: Fija versiones de driver; elimina overclocks; ejecuta tests de memoria; revisa dmesg por AER; trata los “errores corregidos” como advertencia temprana.

“Iba bien ayer” después de una actualización rutinaria

Síntoma: Regresiones súbitas sin cambios en el código del juego/emulador.

Causa raíz: Cambios en la pila GL/Vulkan, actualización de Mesa/NVIDIA, actualización del compositor o regresiones del kernel.

Solución: Revertir y bisecar; mantener paquetes de drivers conocidos como buenos; capturar métricas base (clocks GPU, FPS, tiempos de fotograma) como parte de la validación rutinaria.

La imagen se ve suave o ruidosa (específico retro pero instructivo)

Síntoma: El texto del escritorio o la salida 2D se ve peor después de añadir una tarjeta 3D (queja clásica del passthrough Voodoo).

Causa raíz: Degradación de señal analógica a través del cable de passthrough y conectores.

Solución: Usa un cable corto y de alta calidad; evita adaptadores baratos; mantén las tiradas de cable cortas; acepta que lo analógico es una capa física con opiniones.

Tres mini-historias corporativas de las minas de compatibilidad

Mini-historia #1: El incidente causado por una asunción equivocada

Teníamos una herramienta interna de visualización gráfica intensiva usada para revisiones de incidentes—irónico, sí. Se ejecutaba localmente en máquinas de ingenieros y también en un modo CI-render
que producía clips cortos para documentación. Llegó un cambio para “estandarizar” el backend de renderizado: si OpenGL estaba disponible, lo usábamos;
de lo contrario, caíamos al render por software.

La asunción equivocada fue sutil: “OpenGL disponible” se trató como “aceleración por hardware disponible”. En un subconjunto de portátiles, la pila de drivers
proporcionaba silenciosamente OpenGL mediante un rasterizador por software. Era técnicamente correcto y operativamente desastroso.
Los jobs de CI empezaron a caducar; los portátiles empezaron a sonar como pequeñas aeronaves; la herramienta ganó reputación de inestable.

Los primeros intentos de depuración fueron en las direcciones poco productivas habituales: culpar al nuevo algoritmo, perseguir fugas de memoria y discutir sobre modelos de portátiles.
El avance vino de una persona que hizo la pregunta aburrida: “¿Qué dice glxinfo -B en las máquinas que fallan?”
Decía “llvmpipe.” Caso cerrado.

Lo arreglamos mejorando la lógica de detección. No preguntamos “¿está OpenGL presente?”, preguntamos “¿es hardware?”.
Si no, forzábamos el renderizador más simple con advertencias explícitas. También añadimos un auto-test de arranque que imprimía la cadena del renderer en los logs.
Nada heroico. Solo un predicado correcto.

Esta es la lección Voodoo con ropa moderna: no puedes asumir que la ruta rápida está activa. Verifícala.
El sistema te mentirá educadamente hasta que exijas evidencia.

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

Otro equipo lanzó una “optimización” para reducir la latencia end-to-end en un entorno de escritorio remoto usado para un laboratorio.
Aumentaron el tope de FPS y desactivaron un paso de sincronización para mantener los frames fluyendo. La demo lucía suave en el mejor de los casos.
Lo propagaron ampliamente porque a nadie le gusta ser la persona que dice “no” a una ganancia de rendimiento.

Lo que omitieron fue el frame pacing bajo carga. Desactivar el paso de sincronización provocó que los frames se encolaran de forma impredecible.
Los usuarios vieron micro-stutters y ocasional “rubber banding” en la entrada, pese a un FPS medio mayor.
Llegaron las quejas, y el equipo tuvo el clásico problema de “pero las métricas están mejor”.

El postmortem giró en torno a medir lo correcto. El FPS medio subió, pero el p95 de tiempo de fotograma empeoró.
Más importante, el comportamiento de cola se correlacionó con pausas de GC en un componente separado y con jitter de red.
La optimización no eliminó un cuello de botella; eliminó un estabilizador.

El rollback lo arregló. La corrección posterior fue más aburrida: capear el FPS a un valor estable, reintroducir la sincronización
y añadir lógica de buffering que prefiriera un pacing consistente sobre el rendimiento pico. Los usuarios dejaron de notar el sistema,
que es el mayor cumplido que puede recibir una plataforma.

El paralelo Voodoo: la aceleración por hardware hizo las cosas rápidas, pero la experiencia ganadora fue predecible.
La gente recuerda “suave”, no “pico”. Optimiza la sensación, no el número para presumir.

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

Un pequeño grupo de infraestructura mantenía un laboratorio de máquinas heterogéneas para QA: distintas GPUs, ramas de drivers distintas
e imágenes de SO diferentes. Era caro de mantener y no ganaba premios. También evitó una falla costosa.

Un nuevo build de una aplicación tipo CAD se veía bien en las estaciones principales de desarrollo. Se programó el lanzamiento.
El laboratorio ejecutó la suite de regresión en las máquinas de “esquina rara”—drivers antiguos, GPUs alternativas y un par de sistemas con pantallas atípicas.
Aparecieron dos fallos: uno fue un crash de driver en una rama específica; el otro fue una corrupción de renderizado cuando cierta extensión estaba presente.

El equipo no se lanzó a “arreglar drivers”. Hicieron lo que hacen los equipos de ops maduros: redujeron el alcance y controlaron variables.
Fijaron una versión de driver conocida como buena para el lanzamiento y añadieron detección de características en tiempo de ejecución para evitar la ruta de extensión defectuosa.
La app se lanzó sin una tormenta de soporte.

Nadie fuera del equipo lo notó. Ese es el punto.
La práctica—mantener un laboratorio de compatibilidad poco glamoroso y fijar dependencias—se pagó evitando un incidente público.
Fue el equivalente corporativo de guardar un cable de passthrough de repuesto en el cajón y etiquetarlo como si fuera en serio.

Listas de comprobación / plan paso a paso

Paso a paso: evaluar un “problema de aceleración 3D” sin desperdiciar la tarde

1. Inventario de hardware y drivers.
   Usa lspci -nnk. Confirma que el driver del kernel correcto está enlazado.
   Si no, arregla eso primero.
2. Verifica que la aceleración por hardware sea real.
   Usa glxinfo -B (y vulkaninfo si procede).
   Si ves renderizadores por software, para y repara la pila gráfica.
3. Establece una ejecución base.
   Elige una escena/benchmark reproducible y ejecútalo dos veces. Si los resultados difieren mucho, tu entorno no es lo bastante estable para afinar.
4. Clasifica la dirección del cuello de botella.
   Observa saturación de cores CPU (pidstat) y utilización/clocks GPU (nvidia-smi).
5. Elimina la presión de memoria.
   Revisa free -h. Si el swap se mueve, arregla memoria primero.
6. Elimina stalls de I/O.
   Usa iostat -x durante una ejecución. Si los await suben y %util se dispara, estás ligado al almacenamiento.
7. Revisa la capa física/firmware.
   Confirma anchura/velocidad PCIe. Revisa dmesg por errores AER. Revisa térmicas.
8. Solo entonces ajusta ajustes.
   Cuando afines, cambia una variable a la vez y toma notas. Trata esto como un experimento, no como una sesión de sensaciones.

Lista de comprobación: hacer segura una característica de ruta rápida (la lección de Glide)

• Tener un mecanismo explícito de detección para si la ruta rápida está activa.
• Registrar la ruta detectada en un lugar recuperable después del hecho.
• Mantener una ruta de fallback más lenta pero correcta.
• Probar ambas rutas rutinariamente; de lo contrario el fallback se convierte en mitología.
• Fijar dependencias para releases; no “flotar” versiones de driver/toolchain a menos que te gusten las sorpresas.

Lista de comprobación: esenciales del laboratorio de compatibilidad (seguro barato)

• Al menos una máquina por cada principal proveedor de GPU/rama de driver que afirmen soportar.
• Una caja “denominador común más bajo” que represente la base de usuarios mínima.
• Smoke tests automatizados que validen la selección del backend de renderizado y registren cadenas de renderer.
• Imágenes de SO reproducibles o gestión de configuración para resetear máquinas rápidamente.
• El hábito de ejecutar la suite del laboratorio antes de releases, no después de incidentes.

Preguntas frecuentes

¿El Voodoo original era una “GPU” como la entendemos hoy?

Funcionalmente aceleraba el renderizado 3D, así que sí en espíritu. Arquitectónicamente era una tarjeta add-in solo para 3D que dependía de una tarjeta 2D separada y passthrough analógico.
Las GPUs modernas suelen manejar 2D/escritorio y 3D con drivers unificados y salidas digitales.

¿Por qué 3dfx usó un cable de passthrough en lugar de ser la única tarjeta de vídeo?

Redujo el alcance y el riesgo de compatibilidad: 3dfx no necesitaba asumir todos los modos de escritorio y las esquinas de aceleración 2D.
Podían centrarse en rendimiento 3D y salir rápido al mercado. La contrapartida fue cableado extra y problemas de calidad de señal analógica.

¿Qué hizo a Glide tan atractivo para los desarrolladores?

Era más sencillo, más cercano al hardware y optimizado para las necesidades comunes de los juegos de la época.
Reducía el dolor a los desarrolladores y ofrecía mejor rendimiento en hardware Voodoo comparado con alternativas tempranas e inconsistentes.

¿Glide fue “malo” por ser propietario?

Ser propietario no es automáticamente malo; es un intercambio. Glide generó valor real para el usuario rápidamente.
El coste fue el lock-in del ecosistema y fragilidad a largo plazo cuando el mercado se movió hacia APIs ampliamente soportadas y tarjetas integradas.

¿Qué era Voodoo2 SLI y cómo funcionaba?

Voodoo2 podía emparejarse con una segunda tarjeta usando scan-line interleave: una tarjeta renderizaba líneas horizontales alternas.
Mejoraba rendimiento y soportaba resoluciones más altas para la época, pero añadía coste, complejidad y consideraciones de compatibilidad.

¿Por qué la industria se alejó de los “aceleradores 3D especializados”?

La integración ganó en coste, simplicidad y experiencia de usuario. Una tarjeta, un conjunto de drivers, menos cables, menos modos de fallo.
Una vez que las tarjetas integradas 2D+3D fueron lo suficientemente buenas, el enfoque de dos tarjetas se volvió una complicación innecesaria.

¿Cuál es la lección más relevante para SRE de la era Voodoo?

Verifica la ruta rápida. No la supongas. Instruméntala.
Muchos incidentes de rendimiento son solo “pensamos que la aceleración/caché/replicación estaba activa, pero no lo estaba.”

Si estoy solucionando stutter hoy, ¿cuál es el equivalente moderno de “problemas de cable passthrough”?

La capa física sigue mordiéndote: risers PCIe defectuosos, alimentación marginal, throttling térmico o rarezas de cables/adaptadores de pantalla.
También: compositores, overlays y herramientas de captura que se inyectan en rutas de renderizado.

¿El Voodoo cambió cómo la gente compraba PCs?

Sí. Ayudó a normalizar la idea de que un PC necesitaba hardware 3D dedicado para juegos serios.
También convirtió la “marca de tarjeta gráfica y calidad del driver” en un factor de compra mainstream, no solo una obsesión de nicho.

¿Cuál es la práctica aburrida que mejor mapea a la historia Voodoo?

Fijar y probar drivers/toolchains. Mantener una matriz de compatibilidad.
El mercado castigó sistemas que eran rápidos en el laboratorio pero inestables en producción, y lo mismo ocurre con stacks modernos.

Conclusión: pasos prácticos siguientes

El 3dfx Voodoo popularizó el 3D cumpliendo tres cosas bien: reducir alcance, ofrecer una ruta rápida amigable para desarrolladores y dar una experiencia consistente.
Además demostró el coste a largo plazo de la aceleración propietaria y la realidad operativa de que pequeños detalles físicos pueden dominar la calidad percibida.

Si construyes u operas cualquier cosa sensible al rendimiento—renderizado, vídeo, procesamiento de datos, “IA”, elige tu buzzword—toma estos pasos siguientes:

1. Añade un “rendering path” que se auto-reporta (o indicador equivalente de ruta rápida) en logs e informes de fallos. Hazlo inconfundible.
2. Establece la base en tiempo de fotograma y latencia de cola, no solo promedios. Elige una métrica que puedas defender en un postmortem.
3. Crea un pequeño laboratorio de compatibilidad si soportas clientes heterogéneos. Una caja rara hoy previene diez tickets mañana.
4. Fija dependencias para releases—drivers, toolchains, runtimes—y prueba actualizaciones de forma intencionada, no accidental.
5. Mantén tus “cables de passthrough” bajo control: etiqueta la capa física, audítala y trata errores corregidos como advertencias tempranas.

El legado de Voodoo no es nostalgia. Es un recordatorio de que lo mainstream ocurre cuando el rendimiento se vuelve confiable—y lo confiable rara vez es glamuroso.