Filosofia de Engenharia: John Carmack, performance como ofício moral

Principais lições

• Carmack trata performance como uma questão moral, não como uma etapa de otimização. A distância entre o seu código e o limite físico do hardware é desperdício, e desperdício é uma escolha.
• O método dele é subtrativo: entender o problema até a sua base, reduzi-lo ao núcleo rápido e simples e recusar todo recurso que torne esse núcleo mais lento.
• Quando o problema subjacente muda, ele reescreve do zero. O Quake jogou fora o motor que tornou a id famosa porque 3D de verdade era um problema diferente de simular 3D.
• Ele trabalhava abertamente – primeiro com registros diários em .plan, depois abrindo o código dos motores – movido por uma única convicção: código que você vai publicar é código que você escreve com mais honestidade.

O princípio

“A velocidade da luz é uma droga.” – John Carmack¹

É uma piada, e é a filosofia inteira. Carmack disse isso sobre latência de rede – o piso físico inflexível de quão rápido um pacote consegue atravessar um continente – mas o sentimento percorre cada linha que ele escreveu. A máquina é governada pela física, e o trabalho do engenheiro é chegar tão perto do limite físico quanto o problema permitir. Não perto o bastante. Tão perto quanto a física permite. Tudo o que existe entre o usuário e a velocidade da luz é desperdício, e desperdício é uma escolha que você fez.

Carmack trata performance como uma questão moral, e não como uma etapa de otimização. A maioria dos softwares acumula lentidão do jeito que uma casa acumula bagunça – uma decisão razoável de cada vez, cada uma defensável, a soma indefensável. A disciplina de Carmack é recusar esse acúmulo: entender o problema até a sua base, reduzi-lo ao núcleo rápido e simples e entregar isso. A mesma convicção sustenta o argumento de que performance não é um recurso que você adiciona, mas uma propriedade que você deixa de perder – você não otimiza um sistema lento até torná-lo rápido; você constrói um sistema rápido e o defende.

E ele mostrava o seu trabalho. Por mais de uma década, Carmack publicou seu registro diário de engenharia – o arquivo .plan – na internet aberta, legível por qualquer pessoa com um cliente finger.² Os problemas mais difíceis de renderização 3D dos anos 1990 foram resolvidos em público, quase em tempo real. Trabalhar abertamente não era marketing. Era o mesmo instinto que regia o próprio código: nenhum estado oculto, nada que você não possa inspecionar.

Contexto

John D. Carmack nasceu em 21 de agosto de 1970, em Shawnee Mission, Kansas.³ Cursou dois semestres na University of Missouri–Kansas City e depois saiu para escrever software para viver. Não houve aprendizado formal nem diploma. Aprendeu programação gráfica do jeito que a demoscene aprendia – lendo manuais de hardware, medindo o que o chip de fato fazia e escrevendo assembly até os números saírem certos.

Foi parar na Softdisk, uma empresa de software e revistas-em-disquete em Shreveport, Louisiana, trabalhando numa assinatura de jogos chamada Gamer’s Edge. Lá conheceu John Romero, Tom Hall e Adrian Carmack (sem parentesco). Em setembro de 1990, Carmack construiu uma demonstração que não deveria ser possível em um PC: rolagem lateral suave, com qualidade de console, em hardware EGA. O IBM PC de 1990 redesenhava a tela inteira a cada quadro – lento demais para um jogo de rolagem. A técnica de Carmack, o adaptive tile refresh, usava recursos obscuros do hardware EGA para deslizar a tela já desenhada e repintar apenas as bordas recém-expostas.⁴ A equipe reconstruiu a primeira fase de Super Mario Bros. 3, da Nintendo, como uma demo de PC para provar a ideia. A Nintendo recusou. A equipe ficou com o motor.

Em fevereiro de 1991, eles deixaram a Softdisk para fundar a id Software. O padrão já estava definido: achar o problema que ninguém tinha resolvido, resolvê-lo no nível do hardware e construir o produto sobre a solução. Carmack faria isso de novo com 3D mapeado por texturas, depois de novo com 3D poligonal de verdade, depois de novo com realidade virtual. O meio ao seu redor – o Graphics Programming Black Book, de Michael Abrash, a cultura de contagem de ciclos da demoscene – tratava o processador como algo a ser compreendido com exatidão, não aproximado. Carmack tornou essa cultura famosa.

O trabalho

Commander Keen e Doom: o núcleo rápido (1990–1993)

Commander Keen in Invasion of the Vorticons (dezembro de 1990) foi o primeiro jogo comercial construído sobre o adaptive tile refresh. Importava menos como jogo do que como prova: a de que uma leitura cuidadosa do hardware podia fechar a distância entre um PC de propósito geral e um console dedicado. A rolagem suave não era um truque gráfico aplicado por cima. Ela era o motor.

Doom (1993) é o exemplo canônico do método de Carmack. Para renderizar seus ambientes rápido o suficiente em um PC de 1993, ele adotou o binary space partitioning – árvores BSP, formalizadas em um artigo acadêmico de 1980 que Carmack rastreou e adaptou – para pré-calcular a ordem em que as paredes precisavam ser desenhadas, de modo que o motor nunca sobrescrevesse um pixel que mais tarde seria coberto.⁵ Doom não é 3D de verdade; é um mapa 2D renderizado com astúcia suficiente para parecer volumétrico. Essa distinção é o ponto central. Carmack não construiu o sistema mais geral. Construiu o sistema que rodava rápido no hardware que existia e recusou todo recurso que tornaria mais lento o laço principal. O núcleo rápido e simples, entregue.

Quake: 3D de verdade em software (1996)

Quake (1996) foi a reconstrução do zero. Onde Doom simulava profundidade, Quake renderizava mundos poligonais genuinamente tridimensionais – superfícies inclinadas, olhar para cima e para baixo, geometria de verdade – em software, antes que os aceleradores 3D de consumo fossem comuns.⁶ O motor combinava visibilidade BSP pré-calculada com lightmaps gerados offline e assembly ajustado à mão para fazer o que a sabedoria convencional dizia que uma CPU daquela época não conseguia. Mais tarde, a id lançou o GLQuake, um renderizador OpenGL, que ajudou a legitimar a placa de vídeo 3D de consumo.

Quake é o trabalho em que toda a postura de Carmack fica visível de uma só vez: ele jogou fora o motor que tinha tornado a empresa famosa, entendeu o novo problema (3D de verdade) até a sua base e reconstruiu. Nada de reaproveitar por reaproveitar. A solução anterior não era sagrada; o problema era.

Os motores abertos da id e os arquivos .plan (1997–2011)

Carmack fez duas coisas incomuns com o código que o deixou rico. Publicou seu registro diário de trabalho – os arquivos .plan – para que a engenharia fosse legível à medida que acontecia.² E depois deu os motores de graça. A id abriu o código do motor de Doom em 1997, do Quake em 1999, e continuou liberando o código-fonte de cada geração da id Tech à medida que a seguinte era lançada, passando por Doom 3 e além.⁷ O argumento dele era simples: liberar código antigo permite que desenvolvedores mais jovens aprendam como a coisa foi de fato construída, e “software livre que as pessoas valorizam acrescenta riqueza ao mundo.”⁸

Essa disposição é a parte que a maioria dos engenheiros obcecados por performance nunca alcança. O ofício de Carmack era disciplina privada tornada pública. A disposição de ser lido – de deixar qualquer um inspecionar o registro diário e, por fim, o código-fonte – é, ela mesma, um pacto de qualidade. Código que você vai publicar é código que você escreve com mais honestidade.

Oculus VR: o piso da latência (2013–2019)

Na Oculus, o inimigo de toda a vida de Carmack – a latência – virou o problema inteiro. Ele escreveu que “a latência entre o movimento físico da cabeça de um usuário e os fótons atualizados de um head mounted display chegando aos olhos dele é um dos fatores mais críticos para proporcionar uma experiência de alta qualidade”, e que a latência perceptível no rastreamento da cabeça “é também uma das principais causas do enjoo de simulador.”⁹ Ele definiu um orçamento – a meta era da ordem de 20 milissegundos do movimento ao fóton – e tratou cada etapa do pipeline como um lugar para recuperar microssegundos. Sua técnica de timewarp reprojeta um quadro já renderizado no último instante antes da exibição, para absorver o movimento da cabeça que ocorreu durante a renderização.⁹ É o adaptive tile refresh de novo, vinte e três anos depois: não redesenhe o que pode reaproveitar e meça o resultado contra o limite físico.

O método

O método é consistente ao longo de trinta anos e quatro domínios de problema.

Entender o problema até a sua base. Carmack lê o manual do hardware, mede o comportamento real e trabalha a partir de princípios fundamentais, não de convenções. Árvores BSP, lightmaps e timewarp não estavam em nenhum manual de receitas; foram derivados do que o problema de fato exigia.

Reduzir ao núcleo rápido e simples. Doom não é 3D porque 3D não era necessário para parecer 3D no hardware de 1993. A disciplina é subtrativa: identificar o laço interno, torná-lo rápido e recusar os recursos que o tornariam mais lento.

Reescrever do zero quando o problema muda. Quake não estendeu o motor de Doom. Carmack trata um sistema que funciona como descartável no momento em que o problema subjacente se desloca. Custo afundado não é argumento.

Foco profundo e ininterrupto. As maratonas de programação de Carmack nunca foram sobre resistência por si só. Manter um motor inteiro na memória de trabalho – o layout dos dados, o laço interno, os casos extremos, tudo ao mesmo tempo – leva horas para carregar e se estilhaça no instante em que você troca de contexto. Ele protegia esse estado do mesmo jeito que protegia ciclos no laço de renderização: como o recurso escasso sobre o qual o trabalho de fato rodava.

Mais tarde: estilo funcional em C. Na época de Doom 3 e depois, Carmack passou a preferir funções puras e a minimizar estado mutável mesmo em C e C++ – não por moda, mas porque código sem estado oculto é código cujo comportamento você consegue prever, o que significa menos bugs.¹⁰ É o mesmo instinto dos arquivos .plan: nada que você não possa inspecionar.

Cadeia de influência

Quem o moldou

Michael Abrash é o mais próximo de um mentor nessa linhagem. A escrita de Abrash sobre gráficos no x86 – mais tarde reunida no Graphics Programming Black Book – codificou a cultura de contar ciclos e medir tudo que Carmack praticava. Os dois mais tarde trabalharam juntos na id e, muito depois, na Oculus, onde Abrash se tornou cientista-chefe. (Influência direta)

A demoscene e a cultura de otimização em assembly do fim dos anos 1980 ensinaram a convicção fundamental: o processador é conhecível com exatidão, e a distância entre o seu código e o teto do hardware é responsabilidade sua. (Influência formadora)

John Romero, seu parceiro na id, era o complemento, não o professor. O design e o trabalho de fases de Romero davam aos motores de Carmack algo que valia a pena rodar. A parceria é o lembrete de que um núcleo rápido é necessário, mas não suficiente – o motor existe para ser jogado.

Quem ele moldou

A indústria inteira de motores de jogo. Visibilidade BSP, lightmaps e a abertura de código de motores maduros viraram prática básica. Uma geração de programadores de motores aprendeu renderização 3D lendo o código da id Tech que Carmack escolheu liberar.

Hardware de gráficos 3D de consumo. O caminho OpenGL de Quake foi um argumento comercial precoce em favor da placa aceleradora 3D, ajudando a puxar a GPU para o PC de uso comum.

A realidade virtual moderna. Timewarp e o implacável orçamento de latência são hoje vocabulário padrão em todo pipeline de VR. A meta de 20 milissegundos que Carmack perseguiu é a razão de os headsets de hoje não deixarem as pessoas enjoadas.

O fio condutor

Andrej Karpathy reconstrói redes neurais do zero porque a compreensão não é transferível – você tem que derivá-la por conta própria. Carmack deriva seus renderizadores do mesmo jeito: não a partir de um framework, mas a partir do hardware e do problema. E onde Linus Torvalds preza o “bom gosto” – o caso especial que se dissolve no caso geral – Carmack preza o laço interno que faz o mínimo de trabalho que a física permite. Ambos são a mesma convicção vestindo roupas diferentes: a estrutura certa não é enfeite por cima do problema; é o problema, visto corretamente. (Ponte da série)

O que eu tiro disso

A lição que guardo é que performance é honestidade. Um sistema lento costuma ser aquele cujo autor nunca entendeu o problema bem o bastante para achar o núcleo rápido dele – foram empilhando abstrações até funcionar, e “funcionou” foi onde pararam. Carmack para no limite físico, em vez disso. É o mesmo padrão de qualidade ser a única variável: a pergunta nunca é “isso está rápido o bastante para entregar?”, mas “eu realmente entendo por que isso está tão lento?”.

No mundo em que construo agora – agentes, laços de ferramentas, sistemas de IA – a tentação é o oposto da disciplina de Carmack: empilhar frameworks, encobrir latência com mais chamadas de modelo, nunca ler o que o sistema de fato faz. O movimento Carmack é traçar o perfil do laço, achar a parte que domina, entendê-la até a base e cortar o resto. Essa convicção – a de que gosto é um sistema técnico que você pode medir, não uma vibe que você afirma – é o fio que liga um truque de rolagem em EGA de 1990 a uma estrutura local de agentes de 2026.

Perguntas frequentes

Qual é a filosofia de engenharia de John Carmack?

Carmack trata performance como uma questão moral, e não como algo deixado para depois. A disciplina é entender um problema até a sua base, reduzi-lo ao núcleo rápido e simples, recusar os recursos que tornam esse núcleo mais lento e reescrever do zero quando o problema subjacente muda. Ele combina isso com o trabalho aberto – publicar seu registro diário de engenharia e abrir o código de motores maduros – movido pela convicção de que código que você pode inspecionar é código escrito com mais honestidade.²⁸

O que John Carmack construiu?

Carmack cofundou a id Software em 1991 e foi o programador-líder de Commander Keen (1990, adaptive tile refresh), Wolfenstein 3D (1992), Doom (1993, renderização baseada em BSP) e Quake (1996, renderização 3D de verdade em software). Abriu o código dos motores id Tech ao longo de duas décadas, atuou como CTO da Oculus VR, onde conduziu o trabalho sobre a latência do movimento ao fóton, e mais tarde fundou a empresa de IA Keen Technologies.⁵⁶⁷⁹

O que é adaptive tile refresh?

É a técnica que Carmack concebeu em 1990 para conseguir rolagem lateral suave no hardware EGA do IBM PC, que de outro modo era lento demais por redesenhar a tela inteira a cada quadro. O adaptive tile refresh desliza a tela já desenhada usando recursos do hardware EGA e repinta apenas os tiles recém-expostos nas bordas, cortando drasticamente o trabalho por quadro. Foi o que tornou Commander Keen possível e estabeleceu o movimento característico de Carmack: resolver o gargalo no nível do hardware.⁴

Por que Carmack publicava seus arquivos .plan e abria o código dos seus motores?

Os arquivos .plan eram um registro diário de engenharia, originalmente legível pelo protocolo finger, que documentava o desenvolvimento da id quase em tempo real.² Carmack mais tarde abriu o código de cada geração da id Tech assim que sua sucessora era lançada, argumentando que liberar código antigo ajuda os desenvolvedores mais novos a aprender como os jogos são de fato construídos e que software livre valioso “acrescenta riqueza ao mundo.”⁸ As duas práticas refletem o mesmo princípio do seu código: nenhum estado oculto, nada que você não possa inspecionar.

Fontes