Quake em um FPGA (CPU MRISC32) [vídeo]

Quake foi portado para rodar em um softcore MRISC32 customizado implementado em um FPGA, impressionando muitos com o desempenho suave de um jogo 3D dos anos 1990 em hardware, toolchain e ISA totalmente caseiros. Os comentadores usam isso como ponto de partida para explorar sonhos de hardware “específico para Quake”, os limites dos FPGAs para computação de uso geral e o papel de ferramentas de código aberto como Yosys e F4PGA em tornar esses projetos mais acessíveis. A discussão também mergulha fundo em microarquitetura de CPU — de designs vector-first a pipelines modernos de x86 e ARM — para examinar como conjuntos de instruções, predição de desvios e densidade de código afetam o desempenho em projetos como este.

Visão Geral do Projeto e Esclarecimentos

  • A demonstração é o renderizador de software original de Quake executado em um softcore customizado de 32 bits MRISC32 em um FPGA, não uma implementação pura de Quake “em lógica total”.
  • O autor usa Quake como um benchmark realista para ajustar cache, preditor de desvio e o design geral da CPU.
  • Em uma placa Cyclone V, ele roda a cerca de 40 FPS em 320×180, escalado para 1080p, com uma FPU adequada e clock de ~110 MHz (as margens de timing estão “overclockadas” além do fechamento formal).

Implementações em Hardware vs. Software de Jogos Clássicos

  • Vários comentadores fantasiam sobre hardware específico para Quake implementado inteiramente em lógica de FPGA, rodando em taxas de quadros extremas.
  • Outros observam que implementações completas em hardware de jogos grandes e de uso geral são irrealistas; softcores com aceleradores ou instruções customizadas são mais plausíveis.
  • Contexto histórico: jogos de arcade antigos e alguns consoles usavam majoritariamente hardware discreto ou analógico; arquiteturas totalmente digitais no estilo GPU se tornaram dominantes muito mais tarde.

Ferramentas e Ecossistema de FPGA

  • As ferramentas são amplamente criticadas (por exemplo, IDEs dos fornecedores); isso é visto como uma barreira importante para o uso mais amplo de FPGAs.
  • Iniciativas de código aberto mencionadas: Yosys, F4PGA/SymbiFlow, Verilator. Elas são promissoras, mas consideradas menos maduras do que as stacks de compiladores convencionais.

GPUs Customizadas e Projetos Relacionados

  • Vários projetos gráficos relacionados em FPGA são citados:
    • Um visualizador de níveis de Quake e um pequeno renderizador de Quake em FPGAs muito pequenos.
    • Uma GPU customizada em FPGA no estilo de meados dos anos 90 que executa Quake via uma API semelhante à Vulkan.
    • Um “chip do Doom” e outros experimentos de GPU minúsculos.
  • Há interesse em combinar CPUs e GPUs customizadas no mesmo FPGA ou via PCIe, embora sejam mencionadas a complexidade do hardware e do projeto da placa.

ISA MRISC32, Vectors e Microarquitetura

  • MRISC32 é uma ISA estilo RISC “vector-first”, com vetores de hardware simples que funcionam bem para loops de rasterização de Quake/Doom.
  • O uso atual de vetores é em assembly escrito manualmente; o suporte a auto-vetorização pelo compilador ainda está ausente.
  • A discussão aprofunda-se em design de pipeline, estratégias de predição de desvios e como branch delay slots se comparam aos preditores modernos.

RISC vs. CISC e o Debate GBOoO

  • Longas subthreads debatem:
    • Como os núcleos x86 modernos traduzem internamente instruções complexas em micro-operações.
    • Se eles devem ser vistos como “RISC load/store por baixo dos panos” ou como uma classe separada (“great big out-of-order” designs).
    • Compensações em densidade de código, tamanho do cache de uops, complexidade de decodificação de instruções e eficiência energética entre x86, AArch64 e RISC-V.
  • Consenso: a complexidade da front-end e os caches de uops são um grande “imposto x86”, mas todos os núcleos de alto desempenho, independentemente da ISA, convergem agora para microarquiteturas grandes out-of-order semelhantes.

Display, Resolução e Estética Retrô

  • Alguns preferem Quake em baixa resolução em CRTs, argumentando que o suavizamento analógico e o “preenchimento” do cérebro faziam os jogos parecerem melhores do que o escalonamento nítido de LCDs hoje.
  • A demo renderiza em baixa resolução e depois escala com vizinho mais próximo para 1080p, produzindo pixels muito nítidos; as opiniões divergem sobre se um suavizamento adicional seria desejável.

Conselhos Práticos para Começar

  • Para iniciantes em FPGA, o conselho é:
    • Comprar uma placa de desenvolvimento FPGA barata e começar a experimentar.
    • Usar Verilator para simulação quando os projetos crescerem.
    • Explorar recursos da comunidade (por exemplo, fóruns/subreddits focados em FPGA) para recomendações de placas e tutoriais.

Diversos

  • Há também uma discussão paralela sobre como bloquear pop-ups intrusivos de “Sign in with Google”; relata-se que o uBlock Origin com filtros de “annoyances” ajuda.