Los gigantes 2D perdidos: Matrox, S3, Tseng—y por qué importaron

Qué significaba realmente la “aceleración 2D” (y lo que te compraba)

Antes de que cada interfaz de usuario fuera un grafo de escena compuesto, el “escritorio” era mayormente rectángulos. Rectángulos llenos de píxeles. Rectángulos copiados de un sitio a otro. Rectángulos con glifos de texto estampados.
Si podías hacer esas operaciones rápido—y de forma consistente—ganabas. Eso era la aceleración 2D: descargar los primitivos aburridos de la CPU a hardware dedicado que podía mover píxeles
sin negociar con cachés, predictores de ramas, o lo que sea que la CPU ya estuviera lamentando.

Los primitivos clave no eran glamorosos:

• BitBLT (transferencia de bloques de bits): copiar un rectángulo de píxeles desde origen a destino, a menudo con operaciones raster (ROPs).
• Rellenos sólidos y por patrón: pintar rectángulos rápidamente (fondos de ventanas, resaltados de selección, elementos de la interfaz).
• Dibujo de líneas y contornos de rectángulos: la estructura de los primeros widgets de la interfaz.
• Cursor por hardware: una pequeña capa de superposición para que el puntero siga suave incluso cuando el resto de la pantalla está ocupado.
• Rutas aceleradas de texto: glifos en caché y expansión mono-a-color para fuentes.

En lenguaje de operaciones: estos primitivos eran la “ruta caliente”. Si los hacías bien, todo parecía ágil: mover ventanas, desplazar, teclear, sesiones de administración remota y
“abrí una hoja de cálculo y no hizo que mi portátil sonara como si fuera a despegar”.

Hoy, incluso si tu UI se compone a través de una GPU, las mismas restricciones básicas siguen aplicando: ancho de banda de memoria, atascos de canalización y comportamiento del controlador bajo cargas raras. Simplemente renombramos los modos de fallo.

Una idea parafraseada que mantengo en mi tablero mental es de Werner Vogels: todo falla, así que diseña para la falla en vez de fingir que no ocurrirá (idea parafraseada).
Los gigantes 2D interiorizaron eso. Construyeron tarjetas y controladores que toleraban escritorios reales y desordenados.

Por qué Matrox, S3 y Tseng se convirtieron en la opción por defecto 2D

Matrox: salida nítida, ingeniería disciplinada y reputación de “simplemente funciona”

Matrox se ganó el cariño de quienes valoraban la calidad de imagen y la estabilidad: usuarios CAD, maquetadores, operadores con múltiples pantallas y los equipos de TI que tenían que hacer que todo se comportara.
Sus motores 2D no solo eran rápidos; eran predecibles. Cuando despliegas cientos o miles de escritorios, la previsibilidad es rendimiento.

Matrox también trató la integridad de la señal como algo importante. Porque lo era. VGA analógica no era “buena” por defecto; era buena cuando el diseño de la placa, la calidad del DAC y el filtrado no eran una ocurrencia tardía.
Por eso la gente recuerda a Matrox como “nítido”. No lo están imaginando.

S3: el imperio silencioso dentro de cada caja beige

S3 no siempre fue cosa de entusiastas. S3 fue el mejor amigo del OEM: 2D competente, amplia compatibilidad, bajo costo y controladores que—la mayoría de las veces—no generaban tickets de soporte.
Si usaste un PC de los 90 en una oficina, hay una buena probabilidad de que S3 estuviera empujando tus píxeles.

Su éxito no fue accidental. Optimizaron para economía de volumen y compatibilidad amplia de software. Eso no es glamoroso, pero escala.

Tseng Labs: el demonio de la velocidad en DOS y los primeros Windows

Tseng es el nombre que dibuja sonrisas en veteranos porque la serie ET4000 tenía reputación: era rápida. Especialmente en escenarios DOS VGA/SVGA donde el rendimiento bruto y rutas de código compactas importaban.
La fuerza de Tseng fue exprimir rendimiento del bus y del subsistema de memoria de una forma que se notaba inmediatamente en cargas reales.

Tseng también subraya una lección recurrente: ser el mejor en el cuello de botella de una era no garantiza que sobrevivas el cambio de plataforma de la siguiente era. Más sobre eso después.

Chiste corto #1: El ET4000 era tan rápido en DOS que algunos juegos probablemente intentaron presentar una queja a RR. HH.

Hechos históricos concretos que explican el hype

La nostalgia alrededor de estos vendedores no es solo “el hardware antiguo era mejor”. Está anclada en realidades técnicas y de mercado específicas. Aquí hay puntos concretos que realmente importan:

1. Windows 3.x y los primeros Windows 95 se apoyaban mucho en la aceleración 2D mediante controladores que descargaban operaciones GDI como blits y rellenos a la tarjeta.
2. Las VESA BIOS Extensions (VBE) estandarizaron SVGA de mayor resolución para software de la era DOS, pero la calidad de implementación aún variaba entre tarjetas.
3. La línea ET4000 de Tseng se hizo famosa por su alto rendimiento SVGA en una era donde la eficiencia del bus y el timing de memoria a menudo importaban más que “características”.
4. La familia Trio de S3 integró RAMDAC y otras funciones para reducir costos y complejidad de placa—perfecto para despliegues OEM masivos.
5. Las tarjetas Matrox de la era Millennium fueron ampliamente elogiadas por la calidad de salida analógica cuando los CRT hacían visible el ruido de señal (parpadeo del texto, sangrado de color, bordes borrosos).
6. Los motores 2D solían soportar un amplio conjunto de operaciones raster (ROPs) porque los marcos de UI dependían de ellas para efectos tipo composición antes de que existiera la composición real.
7. Los cursores por hardware importaban más de lo que se admite: mantener el movimiento del puntero suave enmascaraba mucha lentitud de UI y reducía la latencia percibida.
8. Las transiciones PCI vs ISA/VLB cambiaron a ganadores y perdedores porque el cuello de botella se movió del núcleo GPU a la arbitraje del bus y al comportamiento del ancho de banda de memoria.
9. Las configuraciones multi-monitor tempranas eran nicho y frágiles; los vendedores que podían hacerlo de forma fiable (o al menos con controladores sensatos) ganaban la lealtad de usuarios de alto valor.

Fíjate en lo que falta: trazado de rayos. A nadie le importaba. Querían que Excel se desplazara sin parecer un libro animado.

La ingeniería no glamorosa: ancho de banda, blits, cursores y fuentes

El 2D es mayormente ancho de banda de memoria y comportamiento del bus

Una operación 2D típica es un problema de movimiento de memoria. Copia este rectángulo. Rellena ese rectángulo. Expande glifos monocromos en píxeles coloreados.
El factor limitante suele ser qué tan rápido puedes leer y escribir la memoria del framebuffer y qué tan eficientemente puedes hacerlo sobre el bus del sistema.

Por eso un CPU “más rápido” no siempre arreglaba un escritorio lento: la carga no era cómputo de CPU. Era churn de píxeles. Si la GPU podía hacerlo internamente y evitar viajes al bus del sistema, ganabas.
Si tenía que rebotar por la memoria del sistema o bloquearse en la arbitraje de bus, perdías.

Los controladores eran la mitad del producto

En la era 2D, un controlador era básicamente una promesa: “Cuando el SO pide un BitBLT con este ROP, no voy a emborronar la pantalla, filtrar handles o bloquear el hilo de la UI.”
Algunos vendedores simplemente eran mejores cumpliendo esa promesa ante comportamientos de aplicaciones extraños y tiempos de actividad largos.

Hoy decimos “el controlador se cayó”. Entonces obtuviste sabores distintos de dolor: regiones de redraw corruptas, rectángulos fantasma, fuentes renderizadas como jeroglíficos y un usuario insistiendo
que su monitor está embrujado. La causa raíz seguía siendo corrección de software bajo carga.

Cursor por hardware: característica pequeña, gran rendimiento operacional

Un cursor por hardware es una pequeña imagen de superposición que la tarjeta puede dibujar independientemente del framebuffer. El cursor se mantiene responsivo incluso si el motor principal de dibujo está ocupado.
Cuando falta—o el controlador cae a cursor por software—todo el sistema “se siente lento” porque el movimiento del puntero es tu bucle primario de retroalimentación.

Renderizado de fuentes: una característica de rendimiento

Las oficinas no miden triángulos. Renderizan fuentes. Muchas de ellas. Cachear glifos y acelerar la expansión mono-a-color hizo que las primeras GUIs se sintieran ágiles.
Y aquí es donde “salida estable” importaba: un solo bug en la caché de glifos podía volver ilegible una aplicación y generar una semana de tickets.

Chiste corto #2: Los cursores por software son como reuniones ininterrumpibles: todo lo demás se pausa para que puedas ver algo pequeño desplazarse por la pantalla.

Por qué se desvanecieron (y por qué eso no es lo mismo que “fracasaron”)

Los gigantes 2D no desaparecieron porque olvidaran cómo dibujar rectángulos. Se desvanecieron porque el mercado cambió su definición de “suficiente” y desplazó el pozo de beneficios.
Una vez que el 3D se convirtió en la característica que vendía PCs—y una vez que la gráfica integrada fue “suficiente” en 2D—la ventaja competitiva se movió.

Algunas fuerzas hicieron el trabajo pesado:

• APIs 3D y demanda de gaming: los consumidores compraban fotogramas por segundo, no salida VGA limpia.
• Consolidación de OEM: los acuerdos de volumen favorecieron a proveedores con chipsets integrados y relaciones de plataforma estrechas.
• La complejidad de los controladores explotó: composición, decodificación de vídeo, gestión de energía y hotplug de múltiples pantallas multiplicaron los modos de fallo.
• El 2D “suficientemente bueno” se volvió invisible: cuando todo está compuesto, dejas de notar la excelencia 2D hasta que desaparece.

Matrox pivotó hacia nichos (multi-monitor, embebido, industrial). La marca S3 vivió en distintas formas. Tseng no sobrevivió la carrera armamentista 3D de finales de los 90.
Eso no es fracaso moral; es la física brutal de las transiciones de plataforma.

La lección real para ingenieros modernos: las fortalezas de tu producto deben coincidir con el próximo cuello de botella del mercado, no con el actual.
Los “reyes 2D” resolvieron el cuello de botella de su tiempo con disciplina. Esa disciplina sigue valiendo la pena copiar.

Tres micro-historias corporativas desde las trincheras

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

Una empresa mediana renovó una flota de estaciones de trabajo de escritorio usadas para operaciones administrativas: pantallas ERP, sesiones RDP y una aplicación Java interna que redibujaba agresivamente.
Compras estandarizaron en una plataforma GPU integrada moderna. En papel, era un éxito seguro: cómputo de sobra, codecs modernos y “obviamente” mejor que una tarjeta discreta de hace una década.

En una semana, la cola de tickets se llenó con una queja extraña: “El ratón se siente pegajoso.” No lento. Pegajoso. Los operadores decían que no podían hacer clic con fiabilidad en elementos de UI pequeños.
Mientras tanto, el uso de CPU era bajo y la RAM abundante. TI inicialmente culpó a la aplicación Java, porque eso es lo que se hace cuando quieres que el problema desaparezca.

La suposición equivocada fue que la GPU integrada siempre ejecutaría con las rutas de aceleración adecuadas habilitadas. En realidad, la imagen se desplegó con un paquete de controladores conservador.
Bajo ciertos EDID de monitor y estaciones de acoplamiento, la pila cayó a un modo de compatibilidad que deshabilitó el cursor por hardware y forzó renderizado por software en partes de la UI.

La solución no fue heroica: validar que el controlador correcto estaba instalado, confirmar que DRI y modesetting estaban activos y estandarizar el firmware de la estación de acoplamiento.
La parte importante fue cultural: actualizaron la lista de verificación de despliegue para incluir combinaciones de periféricos (dock + monitor) como casos de prueba de primera clase.

La lección operacional: no asumas que “GPU más nueva” equivale a “mejor experiencia 2D”. En producción, la pila es el producto: firmware, controlador, compositor, protocolo remoto y monitores.

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

Otra organización gestionaba un entorno VDI donde clientes ligeros mostraban escritorios Windows sobre un protocolo remoto. Alguien notó que habilitar una determinada configuración de “efectos visuales” en la plantilla VDI
reducía la carga media de CPU en el host. Las gráficas se veían bien. Cambio aprobado.

Dos semanas después, el helpdesk empezó a recibir quejas sobre “texto aleatoriamente borroso” y “el desplazamiento se vuelve puré.”
El problema no era constante; aparecía en horas punta y mayormente en usuarios con múltiples monitores. Las gráficas de CPU seguían viéndose bien, lo que hacía el problema más irritante.

La optimización estaba empujando más trabajo a una ruta gráfica que usaba caché agresiva de bitmaps y compresión con pérdida bajo congestión. Cuando el ancho de banda se apretaba,
el protocolo se adaptaba degradando la calidad. Los usuarios lo experimentaban como “texto roto”. El monitoreo lo veía como “CPU estable”.

Revertir la configuración restauró la legibilidad consistente a costa de mayor CPU en el host. Luego hicieron el movimiento adulto:
crearon un pool dedicado para usuarios con múltiples monitores con ajustes de protocolo y garantías QoS diferentes.

La lección: optimizaciones que mejoran una métrica pueden destruir el trabajo real del usuario. Si tus “victorias” requieren que los usuarios dejen de leer texto, no ganaste.

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

Un equipo financiero gestionaba escritorios de trading con múltiples pantallas por usuario. Ya habían sido quemados por “actualizaciones rápidas de controladores”, así que su equipo de endpoints mantenía una política conservadora:
versiones de controladores gráficas fijadas, pruebas previas con sus modelos exactos de monitor y despliegues en anillos con scripts de reversión listos.

Una mañana, un proveedor liberó una actualización de SO rutinaria que también actualizó un componente gráfico. Algunas máquinas piloto la instalaron durante la noche.
A las 9:05 a.m., los pilotos reportaron un problema sutil pero mortal: las ventanas se repintaban ocasionalmente en negro por una fracción de segundo durante cambios rápidos entre ventanas.
No era un crash. Suficiente para que los operadores desconfiasen de lo que veían.

Debido a que el equipo tenía despliegue en anillos, detuvieron el despliegue antes de que alcanzara todo el piso. Debido a que tenían fijación de versión, la reversión fue determinística.
Porque tenían una captura base de comportamiento conocido-bueno, pudieron demostrar la regresión rápidamente sin discutir sobre “se siente diferente”.

No ocurrió nada heroico. Ese es el punto. La práctica aburrida previno un evento con impacto en el negocio sin crear un incidente mayor por experimentación frenética.

Guía de diagnóstico rápido: qué comprobar primero/segundo/tercero

Cuando alguien dice “el escritorio está lento”, necesitas un enfoque disciplinado. No persigas sensaciones. Encuentra el cuello de botella.

Primero: ¿Es renderizado local, renderizado remoto o estilo DisplayLink USB?

• Si es remoto (RDP/VDI), tu cuello de botella puede ser ancho de banda, codificación, composición en servidor o decodificación en cliente.
• Si es gráficos USB/docks, puedes estar limitado por CPU en compresión y transporte.
• Si es local, procede a comprobaciones de GPU/controlador/compositor.

Segundo: ¿Realmente estamos usando aceleración por hardware?

• Confirma el controlador del kernel en uso (modesetting/i915/amdgpu/nouveau/nvidia, etc.).
• Confirma que DRI está activo y que el renderer no es “llvmpipe” (software).
• Revisa si el cursor por hardware está habilitado; el stutter del cursor es una pista clara.

Tercero: ¿El sistema está hambriento (CPU, memoria, I/O), o es específico de la ruta gráfica?

• CPU alto durante un scroll suele significar renderizado por software o sobrecarga de codificación remota.
• Faltas de página grandes o actividad de swap harán que cualquier UI se sienta rota.
• Frecuencia GPU bloqueada baja (perfil de energía) puede imitar “GPU mala”.

Cuarto: Multi-monitor y alta DPI cambian el juego

• Más píxeles significa más ancho de banda y regiones de daño mayores para repintar.
• Frecuencias de actualización desparejadas pueden causar jitter y ritmo extraño.
• Docks + adaptadores agregan modos de fallo (EDID, límites de ancho de banda, peculiaridades de formato de color).

Quinto: Valida con un micro-test reproducible

• Prueba de mover/redimensionar ventanas, desplazar texto y seguimiento del cursor son básicos pero reveladores.
• Captura registros inmediatamente después de reproducir; no esperes al “más tarde”.

Tareas prácticas: comandos, salidas, qué significan y qué decisión tomar

Estas tareas asumen Linux en una estación de trabajo o cliente VDI. El punto no es la nostalgia; es claridad operacional.
Ejecuta estas en orden hasta saber si tratas con caída de controlador, problemas del compositor, presión de memoria o cuellos de botella remotos.

Tarea 1: Identificar la GPU y qué controlador está enlazado

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
01:00.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 [102b:0534]
	Subsystem: Super Micro Computer Inc Device [15d9:0834]
	Kernel driver in use: mgag200
	Kernel modules: mgag200

Significado: Tienes un dispositivo Matrox G200-class enlazado a mgag200. Esa es una ruta de servidor enfocada en 2D.

Decisión: Si falta el controlador o “Kernel driver in use” está en blanco, arregla el enlace del controlador antes de culpar a las aplicaciones.

Tarea 2: Comprobar si por accidente estás ejecutando renderizado por software (Mesa llvmpipe)

cr0x@server:~$ glxinfo -B | egrep "OpenGL renderer|OpenGL vendor|OpenGL version"
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)
OpenGL version string: 4.5 (Compatibility Profile) Mesa 23.0.4

Significado: El renderizado está en CPU vía llvmpipe. Tu “problema de GPU” ahora es un problema de CPU.

Decisión: Para. Arregla DRI/controlador/compositor para que el renderer use hardware, o acepta CPU alta y ajusta en consecuencia.

Tarea 3: Confirmar que Xorg está usando el controlador y método de aceleración esperados

cr0x@server:~$ grep -E "Driver|Acceleration|glamor|DRI" /var/log/Xorg.0.log | tail -n 20
[    18.224] (II) modeset(0): using drv /dev/dri/card0
[    18.224] (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) UHD Graphics 630
[    18.226] (II) modeset(0): glamor initialized
[    18.241] (II) modeset(0): [DRI2] Setup complete

Significado: Xorg está usando modesetting con aceleración glamor y DRI2 habilitado.

Decisión: Si ves “falling back to shadowfb” o “glamor failed”, espera mal rendimiento 2D e investiga paquetes faltantes o controladores incompatibles.

Tarea 4: Comprobar compositor y tipo de sesión (Wayland vs X11)

cr0x@server:~$ echo "$XDG_SESSION_TYPE"
wayland

Significado: Estás en Wayland. El debug pasa al compositor (GNOME Shell, KDE KWin, etc.) y a DRM/KMS.

Decisión: Si necesitas comportamiento legacy de aceleración X11 (herramientas remotas específicas, apps antiguas), prueba una sesión X11 para comparar.

Tarea 5: Inspeccionar mensajes DRM del kernel por modesetting y problemas de enlace

cr0x@server:~$ dmesg -T | egrep -i "drm|i915|amdgpu|nouveau|edid|hdmi|dp" | tail -n 30
[Tue Jan 13 08:41:02 2026] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[Tue Jan 13 08:41:03 2026] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[Tue Jan 13 08:41:05 2026] [drm:intel_dp_start_link_train] *ERROR* failed to train DP, aborting

Significado: El controlador GPU está bien, pero el entrenamiento de enlace DisplayPort falla—dolor clásico de negociación dock/cable/monitor.

Decisión: Cambia cable/puerto del dock, reduce la frecuencia de actualización, actualiza el firmware del dock. No pierdas tiempo afinando renderizado hasta que el enlace sea estable.

Tarea 6: Validar tasas de refresco y modos por monitor

cr0x@server:~$ xrandr --verbose | egrep -A2 " connected|^\s+([0-9]{3,4}x[0-9]{3,4})"
DP-1 connected primary 3840x2160+0+0 (0x4b) normal (normal left inverted right x axis y axis) 597mm x 336mm
  3840x2160 (0x4b) 533.250MHz +HSync -VSync *current +preferred
HDMI-1 connected 1920x1080+3840+0 (0x5c) normal (normal left inverted right x axis y axis) 509mm x 286mm
  1920x1080 (0x5c) 148.500MHz +HSync +VSync *current +preferred

Significado: Resoluciones mixtas. Eso incrementa el coste de composición y puede exponer bugs de escalado.

Decisión: Si los usuarios se quejan de stutter, prueba igualar tasas de refresco y configuraciones de escalado; DPI mixto es un disparador frecuente de jank.

Tarea 7: Comprobar saturación de CPU durante acciones “2D”

cr0x@server:~$ pidstat -u -p ALL 1 5
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(8 CPU)

08:52:10      UID       PID    %usr %system  %CPU  Command
08:52:11     1000      2123   85.00    8.00 93.00  gnome-shell
08:52:11     1000      2788   12.00    2.00 14.00  Xwayland

Significado: gnome-shell está consumiendo CPU. Eso a menudo significa fallback por software, efectos pesados o una interacción controlador/compositor.

Decisión: Reduce animaciones/efectos, prueba diferentes ajustes del compositor y verifica aceleración por hardware (Tarea 2/3).

Tarea 8: Verificar presión de memoria y swapping

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
 2  0      0 512000  82000 890000    0    0    12    20  410  900 12  4 84  0  0
 3  1  65536  48000  61000 210000    0  800   100   220 1200 2400 20  8 60 12  0

Significado: Swap-out (so) está activo; espera de CPU (wa) sube. El jank de UI puede ser simple presión de memoria.

Decisión: Añade RAM, reduce la carga o arregla fuga de memoria. No culpes a la GPU por lo que hizo el paginador.

Tarea 9: Comprobar utilización y frecuencia GPU (ejemplo Intel)

cr0x@server:~$ sudo intel_gpu_top -s 1000 -o - | head -n 12
freq  350 MHz  GPU  12%  RC6  75%  RCS  10%  BCS  2%  VCS  0%  VECS  0%
IMC reads:  820 MiB/s  IMC writes:  210 MiB/s

Significado: GPU está ligeramente usada y la frecuencia es baja; no necesariamente es un problema a menos que nunca se eleve cuando la carga aumenta.

Decisión: Si la frecuencia se queda fija baja bajo carga, revisa perfiles de energía, ajustes BIOS y parámetros del kernel.

Tarea 10: Verificar el perfil de energía activo (portátiles y algunos escritorios)

cr0x@server:~$ powerprofilesctl get
power-saver

Significado: Estás en modo ahorro de energía. Eso puede limitar GPU/CPU y producir lentitud “misteriosa”.

Decisión: Cambia a balanced/performance para roles afectados (traders, diseñadores), o acepta el intercambio explícitamente.

Tarea 11: Comprobación de sesión remota (RDP y restricciones de red)

cr0x@server:~$ ss -ti dst :3389 | head -n 12
ESTAB 0 0 10.10.8.21:52144 10.10.20.15:3389
	 cubic wscale:7,7 rto:204 rtt:42.1/8.2 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:22 bytes_sent:1849021 bytes_acked:1849010
	 retrans:12/45 lost:0 sacked:0

Significado: Hay retransmisiones presentes. Eso a menudo se traduce en artefactos visuales, latencia e interacción “pegajosa” en escritorios remotos.

Decisión: Arregla la red (Wi‑Fi, congestión, QoS). No afines efectos de UI antes de dejar de perder paquetes.

Tarea 12: Medir errores básicos del pipeline de pantalla y comportamiento de page flip (DRM)

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/i915_display_info | head -n 20
CRTC info
  CRTC 0: active=yes (pipe A)
    output types: DP
    plane 0: enabled, fb=197, visible=3840x2160
    flip_pending=no

Significado: El pipeline de pantalla está activo y los flips no están pendientes atascados. Si vieras repetidos flip_pending o errores, sospecharías de compositor o problemas de enlace/driver.

Decisión: Si esto luce malsano, correlaciona con dmesg y logs del compositor; prioriza la estabilidad del enlace sobre ajustes de aplicación.

Tarea 13: Comprobar problemas de ruta de renderizado X11 vía logs stderr (Xwayland / Xorg)

cr0x@server:~$ journalctl --user -b | egrep -i "xwayland|glamor|failed|dri" | tail -n 30
Jan 13 08:51:44 server Xwayland[2788]: glamor: Failed to initialize EGL.
Jan 13 08:51:44 server Xwayland[2788]: AIGLX: reverting to software rendering

Significado: Xwayland cayó a renderizado por software. Las apps X11 legacy arrastrarán la sesión.

Decisión: Arregla la pila EGL/controlador o ejecuta una sesión X11 si tu carga es X11-heavy.

Tarea 14: Buscar adaptadores de pantalla USB (DisplayLink) que trasladan el cuello de botella a la CPU

cr0x@server:~$ lsusb | egrep -i "displaylink|graphics|dl-|evdi"
Bus 002 Device 004: ID 17e9:6006 DisplayLink USB Graphics Device

Significado: Estás usando renderizado estilo DisplayLink. Puede funcionar, pero no es “GPU gratis”.

Decisión: Si las quejas de rendimiento coinciden con gráficos USB, prueba salidas GPU nativas primero; si debes usarlo, presupuestar CPU y afinar ajustes de compresión.

Tarea 15: Comprobación rápida del ancho de enlace PCIe (sí, puede importar)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L1
LnkSta: Speed 2.5GT/s, Width x4

Significado: El dispositivo puede x16 a 8GT/s pero actualmente funciona a x4 2.5GT/s. Es una caída importante de rendimiento.

Decisión: Reasienta la tarjeta, revisa ajustes BIOS y verifica cableado del slot. No optimices software sobre un bus cojo.

Tarea 16: Capturar una “línea base conocida-buena” para comparación (la herramienta aburrida que gana)

cr0x@server:~$ sudo inxi -Gxxx --filter
Graphics:
  Device-1: Intel UHD Graphics 630 driver: i915 v: kernel
  Display: wayland server: Xwayland v: 23.2.2 compositor: gnome-shell
  resolution: 3840x2160~60Hz, 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 23.0.4

Significado: Una instantánea compacta de GPU, controlador, servidor de display y renderer GL.

Decisión: Almacena esta salida para cada “golden image”. Cuando llegue una regresión, compara antes de debatir opiniones.

Errores comunes: síntoma → causa raíz → arreglo

1) El cursor se engancha pero la CPU parece bien

Síntoma: El puntero del ratón se siente lento o deja estelas; los usuarios dicen que está “pegajoso”, especialmente al mover ventanas.

Causa raíz: Cursor por hardware deshabilitado o no funcional; ruta de cursor por software ligada al tiempo de repintado/compositor.

Arreglo: Verifica soporte del controlador y compositor, revisa problemas de dock/EDID, prueba distinto tipo de sesión (X11 vs Wayland) y confirma que no hay fallback a renderizado por software.

2) El texto al desplazar se rasga o “se emborrona”

Síntoma: El desplazamiento en terminal/navegador muestra tearing o repintado parcial.

Causa raíz: Compositor que no usa vsync correctamente, frecuencias de refresco mixtas o ruta de aceleración dañada (glamor/EGL fallando).

Arreglo: Igualar tasas de refresco cuando sea posible, actualizar firmware GPU/dock y confirmar ajustes del compositor; revisa logs para glamor/EGL fallback.

3) CPU alta al mover ventanas

Síntoma: Mover ventanas dispara la CPU; los ventiladores aumentan; métricas GPU parecen inactivas.

Causa raíz: Renderizado por software (llvmpipe) o ruta gráfica remota/USB que codifica en CPU.

Arreglo: Arregla DRI y paquetes de controladores; para sesiones remotas, afina protocolo y ancho de banda; para DisplayLink, presupuestar CPU o usa salidas nativas.

4) Todo va bien hasta que conectas un segundo monitor

Síntoma: Añadir un monitor causa jank, flashes negros o desconexiones intermitentes.

Causa raíz: Límites de ancho de banda (modo DP/HDMI), entrenamiento de enlace inestable, bugs de firmware del dock o escalado mismatched.

Arreglo: Reducir tasa de refresco, cambiar cable/puerto, actualizar firmware del dock y probar conexión directa (sin dock) para aislar.

5) El escritorio remoto se ve “borroso” bajo carga

Síntoma: El texto se vuelve suave o pixelado durante horas punta.

Causa raíz: Compresión/adaptación de calidad en el protocolo remoto por pérdida de ancho de banda o retransmisiones.

Arreglo: Arregla pérdida de red, aplica QoS, separa usuarios pesados en políticas distintas y afina el protocolo remoto para fidelidad de texto.

6) Rectángulos negros aleatorios durante redraw de apps

Síntoma: Breves flashes negros o regiones faltantes durante cambios rápidos de ventana.

Causa raíz: Regresión del controlador o bug del compositor en seguimiento de daño/page flipping.

Arreglo: Revertir a controlador conocido-bueno, deshabilitar flags problemáticos del compositor y usar despliegues en anillos para evitar rollouts masivos.

Listas de verificación / plan paso a paso

Paso a paso: Diagnosticar “escritorio lento” sin agitar el entorno

1. Clasifica el entorno: GPU local vs VDI/RDP vs gráficos USB. Documenta en el ticket.
2. Captura identidad base: inxi -Gxxx, lspci -nnk, tipo de sesión, diseño de monitores.
3. Busca renderizado por software: glxinfo -B renderer. Si llvmpipe, para y arregla eso primero.
4. Revisa logs del kernel y display: dmesg para entrenamiento de enlace y errores DRM.
5. Valida modos de monitor: xrandr --verbose para refrescos y desajustes de escalado.
6. Mide presión del sistema: CPU (pidstat), memoria (vmstat) y para sesiones remotas, retransmisiones (ss -ti).
7. Reproduce con una prueba mínima: desplazamiento de texto, mover ventana, seguimiento del puntero, arrastrar entre múltiples monitores.
8. Haz un cambio a la vez: versión de controlador, tipo de sesión, toggles del compositor o tasa de refresco. Registra el resultado.
9. Estabiliza y estandariza: fija versiones y documenta combinaciones conocidas-buenas (GPU + controlador + dock + monitor).

Lista de despliegue: no repitas los errores de 1997 con hardware de 2026

• Mantén un conjunto probado de controladores GPU fijados por clase de hardware.
• Prueba con los periféricos reales: docks, adaptadores y los monitores que la gente tiene realmente.
• Rastrea los defaults de tipo de sesión (Wayland/X11) y sabe qué aplicaciones fallan dónde.
• Tener un plan de reversión que no requiera un login heroico remoto cuando la UI está rota.
• Establece criterios de aceptación de “fidelidad de texto” para escritorios remotos, no solo FPS.
• Documenta la política de perfil de energía; no dejes portátiles en ahorro permanente para roles de alta interacción.

Qué copiar del pensamiento Matrox/S3/Tseng (incluso si nunca tocas hardware antiguo)

• Prioriza la corrección aburrida: una ruta estable y determinista vence a una ruta rápida con corrupción rara.
• Optimiza el bucle de percepción: cursor por hardware y repintado predecible importan más que el rendimiento pico.
• Respeta las capas de señal y negociación: EDID, entrenamiento de enlace y cableado son parte del “rendimiento gráfico”.
• Construye pensando en la flota: tu mejor máquina no es la métrica; tu peor 5% sí lo es.

Preguntas frecuentes

1) ¿Eran Matrox, S3 y Tseng “mejores” que las GPUs modernas?

En capacidad bruta, no. En comportamiento 2D predecible bajo las pilas de software de su tiempo, muchas veces sí.
Fueron optimizados para las cargas dominantes: primitivas GDI/X11, cursores estables y salida consistente.

2) ¿Por qué la gente recuerda la salida de Matrox como más nítida?

La calidad VGA analógica dependía del diseño de placa, calidad del RAMDAC, filtrado y diseño eléctrico. Algunos vendedores lo trataron como una característica de primera clase.
En CRTs, la diferencia era obvia: menos parpadeo, bordes de texto más limpios.

3) ¿Qué convirtió a S3 en un gran negocio en oficinas?

Amigabilidad OEM: bajo costo, funciones integradas, compatibilidad amplia y controladores que funcionaban con un gran volumen de software empresarial.
Eso gana batallas de compras y reduce tickets de soporte.

4) ¿Cuál es el equivalente moderno de “aceleración 2D”?

Rendimiento del compositor, seguimiento de daño, swaps eficientes de buffers y controladores GPU/display fiables. Los primitivos cambiaron de forma, pero el trabajo sigue siendo:
mover píxeles de forma predecible con baja latencia.

5) Si mi sistema usa Wayland, ¿sigo preocupándome por problemas 2D?

Sí. Wayland cambia dónde aparecen los problemas (compositor/DRM en lugar de Xorg), pero aún puedes topar con fallback por software, estados de energía malos, inestabilidad de enlace y problemas de tiempo en multi-monitor.

6) ¿Por qué importa tanto un cursor por hardware?

Porque desacopla la retroalimentación del puntero del resto de la canalización de renderizado. Los humanos juzgan la capacidad de respuesta por el puntero.
Un cursor suave puede hacer que un escritorio lento resulte tolerable; un cursor lento hace que todo parezca roto.

7) ¿Cómo digo rápidamente si “gráficos lentos” son en realidad presión de memoria?

Ejecuta vmstat 1 5. Si ves actividad de swap-in/swap-out y aumento de espera I/O, tu UI está compitiendo con el paginador.
Arregla la RAM o la carga antes de afinar la pila GPU.

8) ¿Cuál es la causa moderna más común de “2D se siente mal” en hardware decente?

Fallback a renderizado por software (llvmpipe), seguido de cerca por problemas de negociación dock/monitor que causan enlaces inestables o comportamientos extraños de refresco/escalado.
Ambos son detectables rápido con las tareas anteriores.

9) ¿Debería forzar X11 porque “es más rápido”?

No lo conviertas en religión. Prueba. Algunos flujos de trabajo y controladores se comportan mejor en X11; otros son más suaves en Wayland.
Elige el tipo de sesión que te dé comportamiento consistente para la mezcla de aplicaciones y la flota de hardware.

10) ¿Qué nos enseñaron los gigantes 2D sobre fiabilidad?

Que enviar menos sorpresas vence a enviar más características. Trataron la ruta “aburrida”—blits, cursores, texto—como el producto.
Las pilas modernas deberían tratar a compositores, docks y despliegues de controladores de la misma manera.

Próximos pasos

Si gestionas flotas—escritorios, VDI, clientes ligeros, plantas de trading, laboratorios—toma la lección de Matrox/S3/Tseng y aplícala donde duela ahora:
el bucle de interacción base.

1. Construye una línea base gráfica conocida-buena por clase de hardware (GPU + controlador + dock + monitor).
2. Automatiza la captura de inxi -Gxxx, lspci -nnk, tipo de sesión y modos de monitor durante el aprovisionamiento.
3. Despliega cambios gráficos en anillos (controladores, actualizaciones de compositor, firmware de docks). Mantén la reversión determinística.
4. Usa la guía de diagnóstico rápido cuando lleguen tickets. Clasifica primero, luego mide, luego cambia una cosa a la vez.
5. Define SLOs visibles para usuarios: suavidad del cursor, fidelidad de texto en sesiones remotas y estabilidad multi-monitor. No solo “uso de GPU”.

Los gigantes 2D importaban porque trataban “dibujar una ventana” como algo crítico. Tú deberías también. No es retro. Es operaciones.