DOOM3 no XBOXOG foi o jogo que me fez ter certeza que dali em diante eu não precisaria ter um console e um PC ao mesmo tempo.
Dada as diferenças óbvias, era o mesmo jogo. Não devia em nada a experiência do PC.
XBOX foi definitivamente o console mais poderoso de todos os tempos. Em segundo eu colocaria o Neo Geo, que não tinha nada de tecnologia nova (ou nenhuma inovação), mas tudo nele era overclockeado, além de como o hardware funcionava para processar os gráficos. Eram lidos diretamente da ROM (sem precisar copiar tiles pra V-RAM), só apontava o registrador da VDP pra ROM e trocava instantaneamente qualquer tile, sem precisar de nenhum tipo de transferência.
XBOX tinha um processador monstro, além de uma GPU, que também era outro monstro ainda maior, acima de qualquer outra GPU da época no mercado (incluindo os PCs). Nvidia NV2 que era baseada na Nvidia 3, mas com mais recursos e maior capacidade computacional.
Era definitivamente um monstro. 21.8 milhões de polígonos por segundo, com iluminação e mapeados com texturas de 512x512 pixels (de 32 bits) e shaders programáveis avançados (23 operações diferentes de shaders), 4 camadas de texturas por passada, compressão de texturas de 6:1 (S3TC), fog, blending, z-buffer (com compressão de pixels pra maior bandwidth), vindos de um fillrate de 700 megapixels por segundo (ou 233MHz x 4 pipelines das TMUs = 932 megapixels brutos) e normal mappinp (mais pesado e avançado que bump mapping, por ser 24 bits contra 8), 5 filtradas deflicker (contra 3 dos outros consoles), cores em 32 bits (True Color com transparência), sendo o único console da época com essa profundidade de cores, imagina em 720p… coisa só absurda.
Sabe por quê alguns jogos só rodam em 720p com o mod de 128MB? Porque o frame-buffer fica GIGANTE.
O frame-buffer em 720p com 32 bits de cores ocupa 7.37 MB de RAM. 1280x720 (pixels) x 2 (Z-buffer) x 4 bytes (32 bits de cor) = 7.373.800 bytes.
Voltando a GPU. Na verdade o conceito de GPU mudou. Pois a GPU tinha uma FPU incluindo parte da lógica do que antes era feito pela ALU da CPU, ou seja, GPGPU.
O site do Rodrigo Copetti tem uma explicação didática sobre isso:
>>> Graças aos programas de vértice, a GPU agora pode acelerar as transformações do modelos, cálculos de iluminação e geração de coordenadas de textura (T&L). Este último é essencial para compor superfícies de ordem superior (qualquer superfície geométrica, renderização de cenários, partículas, objetos e curvas geométricas). Com isso, a CPU pode se concentrar em fornecer melhor física, IA e gerenciamento de cena.
No caso de sombreadores de pixel, os programadores podem manipular e misturar texturas de várias maneiras para obter efeitos diferentes, como multitexturização, mapeamento especular, mapeamento de relevo, mapeamento de ambiente e assim por diante.
Um novo conceito de programação que surge graças a essa abordagem é a GPU de uso geral ou ‘GPGPU’, que consiste em atribuir tarefas à GPU que seriam realizadas exclusivamente pela CPU. Portanto, não apenas a GPU assumiu a maior parte do pipeline gráfico, mas agora pode atuar como um coprocessador eficiente para cálculos especializados (ou seja, cálculos físicos). Esta é uma nova área que evoluirá à medida que as GPUs se tornarem mais poderosas e flexíveis. No entanto, o NV2A já conseguiu isso graças a uma combinação de recursos de hardware (vertex & pixel shaders) e APIs especializadas desenvolvidas ('programas de estado' do OpenGL).
Tenho a sensação de que os shaders serão revisitados regularmente em artigos futuros. Lembre-se que neste artigo, no entanto, eles podem ser considerados um pouco ‘primitivos’ e algumas pessoas podem argumentar que os pixel shaders nem são ‘shaders’ (comparado ao que as GPUs oferecem hoje em dia). <<<
Em teoria o GameCube levaria vantagem em 2 coisas… no número de camadas de texturas por passada e na resolução das texturas. Onde o GameCube tinha 8 camadas de texturas por passada (8 camadas processadas por 4 TMUs) contra 4 do XBOX (4 camadas processadas por 4 TMUs) e texturas de 1024x1024 contra 512x512 do XBOX. Porém, a GPU tinha uma capacidade aritmética muito alta, sendo capaz de fazer o mesmo número de camadas (ou mais) com 2 ciclos de FPU, sem comprometer o desempenho. Também tinha RAM suficiente (e S3TC) pra usar 4 texturas de 512x512 a fim de formar uma de 1024x1024. Vide o Fur-Shading de Conker, como as camadas de pelos eram volumétricas, (além do normal mapping), e in-game. Star Fox Adventures também fazia de forma volumétrica, mas nas cut-scenes.
Fur Shading:
Geometria:
64MB de DDR SDRAM unificada (UMA) em 200 MHz (dual-channel), efetivando 400 MHz (5.34 GB/s de bandwidth) destinado a GPU, mais 1.06 GB/s do FSB (barramento frontal destinado a CPU). Nem mesmo os 64MB de GDDR3 que colocaram no Wii pra substituir os 16MB de A-RAM são mais rápidos que a RAM do XBOX. Os 64MB do Wii tem 2.7 GB/s de bandwidth, enquanto no XBOX é 6.4 GB/s, totalizados.
O que na verdade seriam 128MB (a Microsoft retirou o segundo socket de 64MB na placa mãe de última hora). Mas essa RAM poderia ser estendida usando parte do HD para armazenar os dados e melhorar o tempo de leitura no DVD. Como no vídeo de DooM rodando em 720p, o frame-buffer não caberia em apenas 64MB, pois não foi programado pra isso, existem códigos, texturas, geometria e parte sonora armazenada lá, assim esse frame-buffer maior é jogado nos 64MB de RAM adicionais. Com optimizações rodaria muito melhor, no código original não se tem como tirar proveito de 128MB.
Sobre o HD, também aumentava a RAM do sistema. O XBOX copiava os dados usados de cada jogo para na unidade como um cache, simplesmente porque é mais rápido que o DVD. Por esse motivo que quando se inicia um jogo diferente do último que você jogou leva mais tempo, um segundo buffer (ou vários) ficam alocados ali e portanto, qualquer troca de telas poderiam ser feitas de forma “instantânea”. GameCube fazia isso em Metroid Prime, com seus 16MB de A-RAM (que também era usada como cache), imagina o XBOX com 750MB reservados pra isso.
XBOX tem o HD separado em 3 partições, uma para músicas e jogos salvos, outra para Dashboard e três com 750 MB para cachê.
Como são as unidades no HD do XBOX:
Alguns HD tinham 8 GB, outros 10 GB. As unidades de 10 GB não permitem que você use mais armazenamento.
Cada HD foi formatado em várias partições. Havia a partição utilizável pelo usuário que sempre foi de aproximadamente 4,7 GB. Essa era a única partição que continha todos os seus jogos salvos, DLC e faixas de música.
Havia também a partição do sistema e três partições de cache separadas.
C: partição do sistema ~300 MB
D: unidade de disco
E: partição do usuário. ~4.700 MB
X: Cache1 ~750 MB
Y: Cache2 ~750 MB
Z: Cache3 ~750 MB
Todas as unidades foram formatadas de maneira semelhante a esta, com os mesmos tamanhos de partição de unidade para as unidades de 8 e 10 GB.
Não importa qual unidade você tenha em seu Xbox original (não modificado), ele tinha apenas 4,7 GB de espaço utilizável pelo usuário.
Dependendo de como o jogo acessa o restante dos arquivos, pode resultar em mais cache cabendo no cache interno do disco rígido, o que pode melhorar os tempos de carregamento.
Mas quem disse que o HD poderia ser usado somente pra buffer do disco? Na verdade você poderia usar a partição reservada para o cachê como RAM virtual, e armazenar tudo nela, podendo ter mais do que 64 MB de RAM. Contanto com 3 partições de 750 MB de cachê no HD, poderiam ser usados como RAM virtual.
Normalmente o dobro da RAM principal seria o suficiente, pois o que vai pra RAM virtual é o que está na RAM principal como arquivos de paginação, depois podem ser resgatados pra RAM principal quando solicitado. Então seriam 64 MB de RAM principal e 64 MB de RAM virtual, totalizando 128 MB. Teoricamente seria viável usar para armazenamento de qualquer tipo de dado, só seria mais lento, cabendo ao dev mover os dados mais leves (como código de animações por exemplo) pra liberar espaço na RAM e usar quando necessário. Fator 5 fez isso na época, em Star Wars do GameCube, enfiando código até encher tudo (numa RAM super lenta pra variar).
Falando da CPU. Bem, a CPU do XBOX é baseada no Pentium III, chamada de Pentium III Copermine em 733 MHz. É do tipo CISC (gasta mais ciclos por instruções), mas tem um chipset de instruções aceleradas que deixam ela extremamente rápida, usando a microarquitetura P6, que contém uma série de melhorias em performance, como:
1) Pipeline de 14 estágios (14 instruções podem ser executadas simultaneamente).
2) Instrução fora de ordem (a CPU reordena a sequência de instruções para aumentar a eficiência e o desempenho).
3) Sempre que houver uma condição que precise ser avaliada (que decidiria se a CPU deve seguir o caminho 'A' ou o caminho 'B'), a CPU seguirá um dos caminhos com base nas execuções anteriores e, em seguida, avaliará a condição. Se a previsão estiver correta, a CPU terá economizado algum tempo, caso contrário, ela reverterá e seguirá o caminho correto.
Segue o benchmark comparando com outros Pentium de clocks maiores:
