Acontece que eu gosto de codificação heroica

Acompanho Michael Abrash há mais de 10 anos; ele é um dos meus heróis da programação. Por isso, fiquei fascinado ao descobrir que o Sr. Abrash escreveu um artigo exaltando as virtudes do Larrabee da Intel, que será lançado em breve.. O que é o Larrabee? É uma besta estranha e inédita que fica em algum lugar na vaga terra de ninguém entre a CPU e a GPU:

[Larrabee] NÃO é, antes de tudo, uma GPU. É uma CPU. Uma CPU de vários núcleos otimizada para processamento paralelo de dados. Qual é a diferença? Bem, há muito pouco hardware de função fixa, e o hardware é direcionado para executar códigos de uso geral com a maior facilidade possível. O resultado final é que a Intel pode fazer com que essa CPU de vários núcleos muito ampla se pareça com uma GPU implementando bibliotecas de software para lidar com DirectX e OpenGL.

Sabemos que as GPUs geralmente oferecem uma ou duas ordens de magnitude a mais de desempenho do que as CPUs de uso geral nas coisas em que são boas. Isso é o que eu esperaria de um hardware dedicado a uma tarefa específica e altamente paralizável.

Michael Abrash já tentou fazer o que a maioria das pessoas dizia ser impossível: construir um software completo de renderização 3D que executa jogos modernos com taxas de quadros razoáveis. Em outras palavras, fazer com que uma CPU de uso geral concorra em uma luta completamente injusta contra uma GPU altamente especializada. Ele conseguiu isso de fato, e sua empresa o vende como um produto chamado Pixomatic:

Neste artigo em três partesdiscuto o processo de otimização de Pixomatic, um rasterizador de software 3D x86 para Windows e Linux escrito por Mike Sartain e por mim. O Pixomatic foi talvez o maior desafio de desempenho que já encontrei, certamente ao lado do Quake. Quando começamos a trabalhar no Pixomatic, não tínhamos certeza de que conseguiríamos obter recursos e desempenho do DirectX 6, o mínimo para um rasterizador viável. Tenho o prazer de informar que conseguimos. Em um Pentium 4 de 3 GHz, o Pixomatic pode executar o Unreal Tournament 2004 a 640Å 480, com a filtragem bilinear ativada. Em processadores mais lentos, o desempenho é obviamente menor, mas renderizando em 320′-240 e estendendo até 640′-480, o Unreal Tournament 2004 funciona adequadamente bem, mesmo em um Pentium III de 733 MHz.

O Pixomatic está documentado em uma excelente série de artigos do Dr. Dobbs. É uma leitura fascinante; embora eu não saiba nada sobre linguagem assembly, a linguagem preferida de Michael, ele é um escritor fantástico. Aquele velho ditado de que o assunto não importa quando o senhor tem um ótimo professor nunca foi tão verdadeiro.

Lembro-me de que o senhor experimentando o Pixomatic há apenas quatro anos. Essas CPUs de que ele está falando parecem terrivelmente antiquadas agora, e isso me deixou curioso: qual é a velocidade do renderizador de software Pixomatic no de hoje. CPUs? Minha caixa atual é um Core 2 Duo (wolfdale) rodando a 3,8 GHz. Então, fiz o download do demo do Unreal Tournament 2004 (ainda divertida, por sinal!) e segui as instruções breves e fáceis fornecidas para ativar o renderizador de software Pixomatic. Não é complicado:

ut2004.exe -software

Uma palavra de advertência. Certifique-se de que o senhor tenha uma resolução adequada definida antes de fazer isso! Inicialmente, eu estava jogando em 1920×1200, e foi essa a resolução padrão do renderizador do software. E aqui está o choque: era realmente jogável! Eu não conseguia acreditar. Não estava muito bom, o senhor sabe, mas não era uma apresentação de slides. Ajustei a resolução para algo que considerei realista: 1024×768. Ativei a exibição da taxa de quadros pressionando …

~
stat fps

… de dentro do jogo. Essa versão do jogo renderizada pelo software Pixomatic proporcionou uma experiência sólida de 40-60 fps no modo capture the flag. Na verdade, ele funcionou tão bem que decidi aumentar os detalhes – habilitei a cor de 32 bits e a filtragem bilinear editando o arquivo ut2004.ini :

[PixoDrv.PixoRenderDevice]
FogEnabled=True
Zoom2X=False
SimpleMaterials=True
LimitTextureSize=True
LowQualityTerrain=False
TerrainLOD=10
SkyboxHack=True
FilterQuality3D=3
FilterQualityHUD=1
HighDetailActors=False
SuperHighDetailActors=False
ReduceMouseLag=True
DesiredRefreshRate=0
DetailTexMipBias=0.000000
Use16bitTextures=False
Use16bit=False
UseStencil=False
UseCompressedLightmaps=False
DetailTextures=False
UsePrecaching=True

Depois de fazer isso, o jogo ficou totalmente respeitável. Na verdade, o visual e o desempenho lembram muito os clássicos e antigos cartões Voodoo e Voodoo 2.

ut2004 em execução com renderização de software Pixomatic, 32bpp e filtragem bilinear

(Se o senhor acha que isso parece ruim, dê uma olhada no Doom 3 em execução em uma configuração antiga do Voodoo 2. É certamente melhor do que isso!)

A taxa de quadros sofreu um grande impacto, caindo para 30 fps, mas descobri que era um estável 30 fps. O único calcanhar de aquiles do renderizador de software Pixomatic são os locais com muita mistura alfa, como quando o usuário dispara um rifle sniper, obscurecendo toda a tela com uma baforada de fumaça do cano, ou se estiver perto de um portal de teletransporte.

É incrível, não é? Pois é!

E totalmente sem sentido.

Meu placa de vídeo atual renderiza o Unreal Tournament 2004 na resolução mais alta possível, com todas as opções de qualidade possíveis definidas no máximo, em algo entre 200 e 300 quadros por segundo. Apesar da montagem milagrosamente eficiente que Abrash e Sartain criaram para tornar isso possível, o em tudoé, na melhor das hipóteses, uma esquisitice de carnaval; até mesmo o laptop 3D integrado mais ruim (supondo que seja um laptop recente) poderia superar o Pixomatic sem nem mesmo suar a camisa.

Sabemos que o jogo é muito mais agradável de jogar com uma GPU real, em uma placa de vídeo real. E estamos trabalhando com GPUs reais em todas as plataformas; até mesmo a iPhone tem uma. Talvez a Pixomatic tenha feito algum sentido comercial em 2003, mas não foi preciso ser um analista genial para ver que não faria sentido comercial na época. todos os hoje. Ao mesmo tempo, não posso deixar de admirar o esforço de engenharia que foi feito para criar um renderizador de software 3D viável, algo que parecia praticamente impossível que beira a insensatez.

Em resumo, será possível obter grandes aumentos de velocidade com o [Larrabee] sem programação heróica, e isso certamente é uma coisa boa. É claro que nada é tão fácil assim; como acontece com qualquer nova tecnologia, só o tempo dirá exatamente como a vetorização automática funcionará e, no mínimo, levará algum tempo para que as ferramentas fiquem totalmente prontas. Independentemente disso, é igualmente certo que será possível obter aumentos de velocidade ainda maiores sujando as mãos com intrínsecos e linguagem assembly; além disso, Acontece que eu gosto de codificação heróica.

Idem.

Teremos que esperar para ver se os esforços da Intel para incluir a funcionalidade de GPU em sua arquitetura x86 tornarão essa codificação heróica mais relevante no futuro. De qualquer forma, continua sendo impressionante.