Quake en un FPGA (CPU MRISC32) [video]

Artículo original ↗ Discusión en Hacker News ↗

Quake ha sido portado para ejecutarse sobre un softcore MRISC32 personalizado implementado en un FPGA, impresionando a muchos por lo fluido que puede funcionar un juego 3D de los años 90 en hardware, cadena de herramientas e ISA totalmente caseros. Los comentaristas lo usan como punto de partida para explorar sueños de hardware “específico para Quake”, los límites de los FPGA para la computación de propósito general y el papel de herramientas de código abierto como Yosys y F4PGA para hacer estos proyectos más accesibles. El hilo también profundiza en la microarquitectura de CPU —desde diseños vector-first hasta pipelines modernos de x86 y ARM— para examinar cómo los conjuntos de instrucciones, la predicción de saltos y la densidad de código afectan al rendimiento en proyectos como este.

Resumen del proyecto y aclaraciones

  • La demo ejecuta el renderer de software original de Quake sobre un softcore MRISC32 personalizado de 32 bits en un FPGA, no una implementación pura de Quake “todo en lógica”.
  • El autor usa Quake como un benchmark realista para ajustar la caché, el predictor de saltos y el diseño general de la CPU.
  • En una placa Cyclone V funciona alrededor de 40 FPS a 320×180 reescalado a 1080p, con una FPU adecuada y un reloj de ~110 MHz (los márgenes de temporización están “overclockeados” más allá del cierre formal).

Implementaciones en hardware vs. software de juegos clásicos

  • Varios comentaristas fantasean con un hardware específico para Quake implementado enteramente en lógica de FPGA, funcionando a tasas de fotogramas extremas.
  • Otros señalan que las implementaciones completas en hardware de juegos grandes y de propósito general son poco realistas; los softcores junto con aceleradores o instrucciones personalizadas son una opción más plausible.
  • Contexto histórico: los primeros juegos arcade y algunas consolas usaban en su mayoría hardware discreto o analógico; las arquitecturas totalmente digitales al estilo GPU se volvieron dominantes mucho más tarde.

Herramientas y ecosistema de FPGA

  • Las herramientas son ampliamente criticadas (por ejemplo, los IDEs de los fabricantes); se las ve como una barrera clave para un uso más extendido de FPGA.
  • Se mencionan esfuerzos de código abierto: Yosys, F4PGA/SymbiFlow, Verilator. Son prometedores, pero se consideran menos maduros que las cadenas de compilación convencionales.

GPUs personalizadas y proyectos relacionados

  • Se citan varios proyectos gráficos relacionados en FPGA:
    • Un visor de niveles de Quake y un pequeño renderer de Quake en FPGAs muy pequeñas.
    • Una GPU personalizada para FPGA con estética de mediados de los 90 que ejecuta Quake mediante una API similar a Vulkan.
    • Un “chip Doom” y otros experimentos de GPU diminuta.
  • Hay interés en combinar CPUs y GPUs personalizadas en el mismo FPGA o mediante PCIe, aunque se señala la complejidad del hardware y del diseño de placas.

ISA MRISC32, vectores y microarquitectura

  • MRISC32 es una ISA RISC “vector-first” con vectores de hardware simples que funcionan bien para bucles de rasterización de Quake/Doom.
  • El uso actual de vectores es en ensamblador escrito a mano; aún falta soporte de auto-vectorización del compilador.
  • La discusión profundiza en el diseño de pipeline, las estrategias de predicción de saltos y en cómo los delay slots de salto se comparan con los predictores modernos.

RISC vs. CISC y el debate GBOoO

  • Largos subhilos debaten:
    • Cómo los núcleos x86 modernos traducen internamente instrucciones complejas en microoperaciones.
    • Si deberían verse como “RISC load/store por debajo” o como una clase aparte (“great big out-of-order”).
    • Compromisos entre densidad de código, tamaño de la caché de uops, complejidad de decodificación de instrucciones y eficiencia energética en x86, AArch64 y RISC-V.
  • Consenso: la complejidad del front-end y las cachés de uops son un gran “impuesto x86”, pero todos los núcleos de alto rendimiento, sin importar la ISA, convergen ahora en microarquitecturas grandes y fuera de orden similares.

Pantalla, resolución y estética retro

  • Algunos prefieren Quake a baja resolución en CRTs, argumentando que el suavizado analógico y el “relleno” mental hacían que los juegos se sintieran mejor que el escalado nítido de los LCD actuales.
  • La demo renderiza a baja resolución y luego escala con vecino más cercano a 1080p, produciendo píxeles muy nítidos; las opiniones difieren sobre si sería deseable un suavizado adicional.

Consejos prácticos para empezar

  • Para quienes se inician en FPGA, el consejo es:
    • Comprar una placa de desarrollo FPGA barata y empezar a experimentar.
    • Usar Verilator para simulación cuando los diseños crezcan.
    • Consultar recursos comunitarios (por ejemplo, foros/subreddits centrados en FPGA) para recomendaciones de placas y tutoriales.

Miscelánea

  • También hay una discusión lateral sobre bloquear ventanas emergentes intrusivas de “Iniciar sesión con Google”; se informa que uBlock Origin con filtros de “annoyances” ayuda.