Arquitetura do PlayStation 3

Bem-vindo à parte mais conhecida e inovadora deste console.

Introdução

A CPU do PS3 é extremamente complexa, mas também é um trabalho de engenharia muito fascinante que cruza necessidades complexas e soluções incomuns, proeminentes em uma era de mudanças e experimentações. Então, antes de mergulharmos nos detalhes da CPU do PS3, escrevi os próximos parágrafos para trazer um contexto histórico. Dessa forma, conseguiremos decompor o chip de cima a baixo de uma maneira que não só permitirá que você entenda como este chip funciona, mas também compreenda a lógica por trás das principais decisões de projeto.

O estado do progresso

A CPU do PS1 (1994). Desenvolvido pela LSI e a Sony, usando a tecnologia MIPS.

O Emotion Engine do PS2 (2001). Desenvolvido pela Toshiba, novamente com tecnologia MIPS.

Quase dez anos após a introdução do PlayStation original com processador MIPS, no início dos anos 2000, as coisas não pareciam boas para a CGI/MIPS. A Nintendo tinha recentemente abandonado os processadores MIPS em favor de um núcleo PowerPC de baixo custo com a IBM como novo fornecedor, enquanto a Microsoft, a novata deste mercado, escolheu a Intel e seu império x86.

A Sony tinha um histórico de pegar projetos existentes de baixo custo (núcleos MIPS baratos) e moldá-los para alcançar um desempenho 3D aceitável com custo reduzido, um processo que envolveu outras empresas, como a LSI (para a CPU do PS1) e a Toshiba (para o Emotion Engine do PS2). Esse método continuou até 2004 com o lançamento do PlayStation Portable. Então, qual seria a nova combinação de MIPS que eles iriam construir para o PlayStation 3?

Bem, acontece que o desenvolvimento do PlayStation 3 precede o do PlayStation Portable . Em 2000, meses após o lançamento do PS2, a Sony formou uma aliança com a IBM e a Toshiba chamada "STI" com o único objetivo de entregar o próximo chip que poderia alimentar a próxima geração de supercomputadores . Se isso já não parecesse extravagante o suficiente, o próximo chip também seria usado no sucessor do PS2. No final, em 2004, a IBM apresentou o Cell Broadband Engine (também conhecido como "Cell BE" ou simplesmente "Cell") .

Novas filosofias de projeto

O chip Cell Broadband Engine. Infelizmente muito brilhante para minha câmera.

Para entender a proposta radical, devemos primeiro considerar dos problemas que afetavam aquela época (final dos anos 90 e início dos anos 2000).

A cada ano, os consumidores pediam mais velocidade. Isso sempre foi assim. No entanto, a última abordagem utilizada para resolver isso (construir um pipeline no caminho de dados e aumentar a frequência do clock) estava falhando em escalar. O NetBurst da Intel não pôde evoluir mais e seu prometido sucessor não existia. Da mesma forma, o PowerPC 970/G5 da IBM não pôde cumprir sua promessa de "3 GHz" nem de sua CPU ser de baixo consumo de energia (daí a Apple não conseguir lançar nenhum laptop com sua CPU da última geração) . Resumindo, parecia que os engenheiros tinham uma nova crise de escalabilidade em mãos.

Então, o foco se voltou para a computação distribuída . Em outras palavras, por que se preocupar em aumentar o desempenho de uma única máquina quando você poderia ter várias máquinas menores distribuindo sua carga de trabalho? Por outro lado, essa abordagem não era nova, considerando que todos os consoles analisados neste site contêm mais de um processador. No entanto, foi o desenvolvimento de um "único processador com múltiplos núcleos" que abriu novas oportunidades para o projeto de CPU (que não estavam necessariamente limitadas ao mercado de consoles).

Consequentemente, o Cell fez parte dessa nova onda de pesquisa e desenvolvimento. Essa nova CPU combinou um projeto multi-núcleo com um foco especial no processamento de vetores. Lembre que o processamento de vetores é ótimo para simulações (física, iluminação, etc.) e foi anteriormente materializado na forma do Geometry Transformation Engine e do Vector Units, em seguida você verá por que o projeto do Cell foi um grande avanço em relação aos dois anteriores.

A nova era dos multinúcleos

Exemplo de projeto heterogêneo.
Este está sendo a arquitetura predominante de muitos consoles poderosos até os dias atuais.

Exemplo de projeto homogêneo.
Cada núcleo pode realizar as mesmas tarefas como antes, mas não necessariamente está restrito a essa tarefa.

Se você parar para pensar, tanto o processador do PS1 quanto o Emotion Engine já eram processadores multinúcleos. Então, por que houve tanta empolgação em relação ao Cell? Bem, os dois processadores anteriores eram compostos por um núcleo de propósito geral e vários núcleos de aplicação específica (ou seja, processador de áudio, descompressão de imagem, etc.), misturando diferentes arquiteturas, em que o núcleo de propósito geral é responsável por comandar os outros.

Esse tipo de projeto de CPU é chamado de computação heterogênea e era a escolha padrão para construir máquinas especializadas para um conjunto específico de aplicações (jogos, neste caso). Sua contraparte, a computação homogênea, é mais predominante no mercado de PC, onde as CPUs são exigidas a realizar uma ampla gama de tarefas (e todas elas têm a mesma prioridade). Portanto, o último tipo pode ter vários núcleos, mas do mesmo tipo.

Voltando ao assunto, o Cell combina ambos os modelos: há dois tipos de núcleos nesta CPU, um "líder" de propósito geral e oito "assistentes" vetoriais. Esses núcleos vetoriais podem desempenhar vários papéis e, ao fazê-lo, eles cumprem tarefas anteriores que foram originalmente resolvidas por projetos heterogêneos, mas como os vetores do Cell não estão limitados a um único tipo de tarefa, seus núcleos fornecem a flexibilidade dos computadores homogêneos. Resumindo, esse projeto não era perfeito e apresentava algumas limitações, mas ao longo deste texto, você verá os diferentes problemas que o Cell tentou resolver e como ele conseguiu fazê-lo.

Um olhar sobre o Cell

Após ter explicado toda essa história e teoria, acredito que estamos prontos para apresentar o protagonista desta seção. Este é Cell ...

O Cell Broadband Engine (variante PS3).
Projetado pela IBM para supercomputação e simulação científica. O "SPE" riscado significa que está desabilitado (inutilizado). O outro "SPE" à esquerda é reservado para o sistema operacional.

... e ao final desta seção, você saberá o que cada componente faz.

Estrutura

O Cell funciona a uma impressionante velocidade de 3,2 GHz e é composto por uma infinidade de componentes. Portanto, para fins de análise, essa CPU pode ser dividida em três áreas principais :

• O líder: esta é a parte do Cell que controla os outros do circuitos. Aqui encontramos um componente chamado PowerPC Processing Element (PPE).
• Os assistentes: esses são tão cruciais quanto o PPE, mas suas capacidades se limitam a um papel de assistente/acelerador. Esse grupo é composto por oito Synergistic Processing Elements (SPEs).
• As interfaces: à medida que a necessidade de largura de banda aumenta exponencialmente, novas interfaces são implementadas para transferir os dados sem produzir gargalos. No grupo de interfaces, encontramos um punhado de protocolos: o Element Interconnect Bus (EIB), o Broadband Engine Interface Unit (BEI), o Memory Interface Controller (MIC) e o Flex I/O buses.

Essas informações serão revisitadas ao longo deste texto com mais detalhes, para que você não precise memorizar esses nomes. O objetivo principal desta seção é permitir que o leitor tenha uma imagem mental da natureza do Cell e se familiarize com todos os componentes que discutiremos no devido tempo.

Como este estudo está organizado

Considerando a estrutura anterior, precisei organizar esta parte do texto para que você não fique sobrecarregado com muitas informações. Assim, começamos a analisar o Cell pelo estudo de cada componente nesta ordem:

1. O barramento que conecta todos os componentes, o Element Interconnect Bus (EIB).
2. O PowerPC Processing Element (PPE) e seu elemento principal, a PowerPC Processing Unit (PPU).
3. Qual é a memória de propósito geral disponibilizada no console.
4. Os Synergistic Processing Elements (SPE) e seu elemento principal, a Synergistic Processing Unit (SPU).
5. O modelo de programação desenvolvido para programar o Cell de maneira eficiente.

Dito isso, vamos começar a análise real.

Dentro do Cell: o coração

Desde o seu anúncio, o Cell tem sido referido como uma Network-on-Chip (NoC) em vez da definição tradicional do System-on-Chip (SoC), isso se deve ao barramento de dados incomum do Cell, o Element Interconnect Bus (EIB). Já vimos até agora o quão exigentes os componentes da CPU podem ser, além de quão suscetível um sistema é a gargalos. Bem, para enfrentar isso pela décima primeira vez, a IBM criou um novo projeto... e o documentou usando termos análogos à condução de veículos.

Diagrama simplificado do Element Interconnect Bus (EIB).
Cada seta entre as "Ramps" (nós) representa dois barramentos unidirecionais, assim, cada nó está conectado ao próximo usando quatro canais.

O EIB é composto por doze nós chamados de Ramps, cada um conectando um componente do Cell. Os Ramps são interconectados usando quatro barramentos, dois deles seguem no sentido horário e os outros dois no sentido anti-horário. Cada barramento (ou canal) possui uma largura de banda de 128 bits. Em vez de usar topologias de barramento único (como o Emotion Engine e seu antecessor fazia), os Ramps são interconectados seguindo a topologia em anel (token ring), onde os pacotes de dados devem passar por todos os vizinhos até chegar ao destino (não há caminho direto). Considerando que o EIB fornece quatro canais, existem quatro rotas possíveis (anéis).

Agora, você pode se perguntar, qual o motivo do uso da topologia em anel se os dados podem acabar viajando por caminhos mais longos (em comparação com um barramento único direto)? Bem, um barramento único é altamente suscetível a congestionamento. Portanto, os engenheiros do EIB decidiram por essa topologia para lidar com grandes quantidades de tráfego concorrente (continue lendo se quiser saber como a topologia em anel ajudou).

Os dados são transferidos na forma de pacotes de 128 bits . Cada anel pode transportar até três transferências simultâneas, desde que os pacotes não se sobreponham. O EIB opera com o uso de créditos de comando, ou seja, sempre que um componente precisa iniciar uma transferência, ele envia uma solicitação ao Data Arbiter (árbitro de dados, em tradução livre) do EIB, que gerencia o tráfego nos anéis. No momento em que a solicitação é aprovada, os pacotes entram no anel e recebem um "token", que o Data Arbiter usa como metadados para supervisionar a transferência. Além disso, alguns componentes têm prioridade preferencial sobre outros, como o componente Memory Interface Controller (MIC), onde a RAM principal está localizada. Finalmente, o Data Arbiter nunca colocará pacotes em anéis cujo caminho é maior que a metade do anel.

Cada Ramp desempenha um papel na transferência, eles leem o endereço de destino do pacote para saber se devem enviar dados para seu respectivo componente ou encaminhá-lo para o próximo Ramp. Durante cada ciclo de clock, os Ramps podem receber e enviar pacotes de 128 bits (16 bytes) simultaneamente. Portanto, considerando que existem quatro canais e o EIB opera a 1,6 GHz (metade da velocidade do Cell), a taxa máxima teórica de transferência é de 16 bytes x 2 transferências/clock x 4 anéis x 1,6 GHz = 204,8 GB/s, esse valor é, claro, muito otimista e há vários fatores externos (por exemplo, caminho de origem/destino, estado do barramento, etc.) que condicionam o desempenho. De qualquer maneira, muitos trabalhos de pesquisa feitos pela IBM e outros autores compilaram velocidades mais realistas usando experimentos práticos .

Agora que você viu como cada componente do Cell está interconectado, é hora de conferir o primeiro componente deste chip...

Dentro do Cell: o líder

Aqui vamos dar uma olhada na "parte principal" do Cell. Essa é a parte do silício encarregada de comandar o resto. O nome do componente é PowerPC Processing Element (PPE) e você pode pensar nele como o MIPS R5900 do Emotion Engine.

Composição do PPE

Lembra como eu dividi o Cell em diferentes áreas? Bem, o mesmo pode ser feito com o PPE. A IBM usa o termo "elemento" para descrever a máquina independente , mas uma vez dentro dele, usa o termo "unidade" para separar a parte do circuito principal das interfaces que se comunicam com o resto do Cell.

Diagrama simplificado do PowerPC Processing Element (PPE).

Dito isso, o elemento PowerPC Processor é surpreendentemente composto por duas partes:

• PowerPC Processing Unit (PPU): essa é a parte lógica do PPE (o "núcleo"). Não esqueça que este não é o PPU da Nintendo! (mesmo que compartilhem as mesmas letras do alfabeto latino... na mesma ordem...).
• PowerPC Processor Storage Subsystem (PPSS): a grande interface que conecta a PPU ao mundo externo. Além disso, ela fornece incríveis 512 KB de cache L2.

Como você pode ver, o projeto do PPE (e do restante do Cell) é bastante modular, o que segue os ensinamentos do projeto RISC. Logo você verá que a modularidade é aplicada até mesmo dentro da PPU.

A PowerPC Processing Unit

Vamos dar uma olhada no interior da PPU agora. Para recapitular, mergulhamos no Cell, depois no PPE e, finalmente, na PPU. Vamos analisar a PPU como qualquer outro núcleo de CPU.

Uma arquitetura familiar

Para começar, a PPU não é construída do zero, mas reutiliza a tecnologia PowerPC existente. No entanto, ao contrário de iterações anteriores em que a IBM pegou um processador existente e o atualizou pela metade para atender novos requisitos, o PPE não sucede nenhum projeto anterior de CPU. Em vez disso, a IBM construiu uma nova CPU que segue a versão 2.02 da especificação PowerPC (que acontece de ser a última especificação PowerPC antes de ser renomeada para "Power ISA"). Resumindo, você não encontrará o mesmo projeto da PPU em nenhum chip existente daquela época, no entanto, ele é programado usando o mesmo código de máquina que em outros chips PowerPC.

Dito isto, por que a IBM escolheu a tecnologia PowerPC para desenvolver um chip de alto desempenho? Simples, o PowerPC é uma plataforma madura que desfrutou de cerca de 10 anos de testes e revisões por parte dos usuários do Macintosh testando e revisando, atende a todas as necessidades da Sony e, se surgir a necessidade, pode ser adaptado a diferentes ambientes. Por último, mas não menos importante, o uso de uma arquitetura conhecida é uma boa notícia para compiladores e conjuntos de códigos existentes, o que, para um novo console, é uma grande vantagem inicial.

Vale ressaltar que a IBM foi uma das autoras dos primeiros chips PowerPC, juntamente com a Motorola e a Apple (lembre da aliança AIM). Seja como for, no início dos anos 2000, os chamados membros da aliança já estavam trabalhando separadamente, onde a Motorola/Freescale desenvolveu uma série diferente de PowerPC da IBM.

Recursos distintos

A PPU compartilha parte da história com o PowerPC 970 (chamado de G5 pela Apple), ambos são descendentes do POWER4, um antecessor do PowerPC usado principalmente em estações de trabalho e supercomputadores. Isso fica mais evidente quando eu lhe mostrar as unidades de execução modularizadas. Esta foi uma mudança radical comparado com a CPU da linha 750 do GameCube, que teve uma considerável contribuição da Motorola, mas foi ligeiramente modificada pela IBM.

Voltando ao assunto, a PPU é um processador completo de 64 bits. Isso significa:

• O tamanho de uma palavra é de 64 bits.
• Existem registradores de propósito geral de 64 bits (para ser exato, 32).
• O barramento de dados tem pelo menos 64 bits de largura de banda: nas próximas seções do artigo, você verá que é muito mais amplo do que isso, mas por enquanto, tenha em mente que transferir palavras de 64 bits não penaliza o desempenho.
• O barramento de endereço tem 64 bits de largura: na teoria, a CPU pode acessar até 16 exabytes de memória. Agora, na prática, isso é muito caro se a máquina não abrigar toda essa memória. Então, as CPUs modernas delegam o endereçamento à unidade de gerência de memória (MMU, do inglês * Memory Management Unit*) para fornecer mais usos ao barramento de endereço.

Finalmente, a PPU implementa a ISA PowerPC versão 2.02, incluindo instruções opcionais para raíz quadrada de ponto flutuante . Também foi estendido com um grupo de instruções SIMD chamadas de Vector/SIMD Multimedia Extension (VMX). Por outro lado, alguns elementos estão faltando na especificação original, como o modo little-endian (na verdade, o Cell opera apenas em big-endian) além de algumas poucas instruções.

Os blocos de construção da PPU

Ao aplicarmos uma visão "microscópica" à PPU, podemos observar que esta unidade é composta por diferentes blocos ou sub-unidades que realizam operações independentes (carregar valores da memória, realizar operações aritméticas, etc). As capacidades da PPU são definidas pelo que cada bloco pode fazer e como:

Instruções

Diagrama simplificado da Instruction Unit (IU).

O primeiro bloco é chamado de Instruction Unit (IU) e, como o nome sugere, ele retira as instruções da cache L2 e sinaliza outras unidades para executar a operação solicitada. Assim como seus contemporâneos i686, parte do conjunto de instruções é interpretada com o uso de microcódigo (a IU incorpora uma pequena ROM para esse fim). Por fim, a IU também possui 32 KB de cache L1 para instruções.

A emissão de instruções é realizada com um pipeline de 12 estágios, embora, na prática o número total de estágios varie muito dependendo do tipo de instrução. Por exemplo, o bloco de previsão de desvio (branch prediction) pode ignorar boa parte do pipeline. Se combinarmos a IU com as unidades vizinhas, o número final de estágios geralmente fica próximo de 24 (sim, é um número grande, mas lembre-se que o Cell funciona a 3,2 GHz).

Agora para as partes interessantes, a IU é de dupla emissão: em alguns casos, a IU emitirá até duas instruções ao mesmo tempo, aumentando assim consideravelmente a taxa de transferência. Na prática, no entanto, existem muitas condições para que isso funcione, portanto, os programadores/compiladores são responsáveis por otimizar suas rotinas para que sua sequência de instruções possa aproveitar essa funcionalidade. A propósito, a emissão dupla também foi implementada por outras CPUs, e o termo varia entre os fornecedores, então aqui usei a definição da IBM.

Além disso, para completar, a IU também é multi-threaded, onde a unidade pode executar duas sequências diferentes de instruções (chamadas de "threads") simultaneamente. Nos bastidores, a IU simplesmente alterna entre os dois threads a cada ciclo, dando a aparência de multi-threading. Essa técnica é historicamente conhecida como Simultaneous Multi-Threading (SMT) ou hyper-threading, como a Intel posteriormente chamou. No entanto, o multi-threading da IBM mitiga efeitos indesejados como bloqueios de pipeline, uma vez que a CPU não ficará mais bloqueada se uma instrução travar o fluxo. Para realizar o multi-threading, os engenheiros da IBM duplicaram os recursos internos da IU, que incluem registradores de propósito geral (anteriormente eu disse que existem 32 registradores disponíveis, isso é por thread. De fato, existem 64 no total!), no entanto, recursos que não pertencem à especificação do PowerPC (como cache L1 e L2; e as interfaces) ainda são compartilhados. Assim, o último grupo é de thread único.

Resumindo, combinando o threading duplo com a emissão dupla, a PPU pode executar até quatro instruções por ciclo. Mesmo que este seja um "cenário ideal", ele ainda oferece oportunidades de otimização que os usuários eventualmente perceberão na taxa de quadros do jogo!

Gerência de memória

Diagrama simplificado da Load-Store Unit (LSU) e sua vizinhança.

Os blocos seguintes concedem à PPU a capacidade de executar instruções de carga-armazenamento e de realizar gerenciamento de memória.

Para começar, a Load and Store Unit (LSU) executa instruções de "carga" e "armazenamento" com suporte de 32 KB de cache de dados L1. Como consequência, essa unidade tem acesso direto à memória e aos registradores.

Além disso, a LSU é acoplada à Memory Management Unit (MMU — Unidade de Gerência de Memória, em tradução livre), o que é uma ocorrência comum no hardware atual. Resumindo, a MMU lida com o endereçamento de memória usando um mapa de endereços virtuais combinados com proteção de memória. Para melhorar este último aspecto, esta MMU em particular apresenta uma unidade de segmentação, que agrupa endereços de memória usando faixas de endereço chamadas "segmentos". Agora, para evitar degradação de desempenho no processo, um Translation Lookaside Buffer (TLB) (caches de endereços traduzidos) e um Segment Lookaside Buffer (SLB) (caches de segmentos) estão incluídos.

Aritmética

Diagrama simplificado das unidades que realizam as operações aritméticas.

Restam apenas duas unidades do PPU para explicar, aquelas que calculam a matemática que qualquer jogo precisa.

A primeira é uma Fixed-Point Integer Unit (FXU — Unidade de Ponto Fixo, em tradução livre) tradicional. Ela realiza aritmética de inteiros, como divisão, multiplicação, rotação de bits (similar ao deslocamento de bits, mas os bits descartados são retornados para a outra extremidade) e contagem de zeros à esquerda (útil para normalizar coordenadas de vértices, por exemplo). Seu pipeline possui 11 estágios.

Se você olhar o diagrama, verá que a FXU, LSU e MMU são agrupados em uma única unidade chamada de Execution Unit (XU), isso porque eles compartilham o mesmo arquivo de registro.

A segunda unidade é muito mais interessante, a Vector/Scalar Unit (VSU) realiza operações com números de ponto flutuante e vetores. Ela é composta por uma FPU de 64 bits (segue o padrão IEEE 754) e uma Vector/SIMD Multimedia Extension Unit (VXU), que executa um conjunto de instruções SIMD chamado VMX. Este último opera com vetores de 128 bits, compostos por dezesseis valores de 8 bits até quatro de 32 bits . Você pode ter ouvido falar dessa extensão antes, já que "VMX" é o nome da IBM para "AltiVec" da Motorola ou "Velocity Engine" da Apple (viva as marcas registradas). Por outro lado, as capacidades competitivas SIMD do Cell são encontradas em outro processador, então não relaxe ainda!

Concluindo o PPE

Você acabou de ver como o PPE funciona e do que ele é feito, mas o que isso significa para um desenvolvedor?

Afinal, o PowerPC Processing Element é apenas um processador de propósito geral, mas aqui está a questão: ele não é destinado a trabalhar sozinho. Lembre-se do amplo barramento principal (o EIB)? A IBM projetou o PPE para que os engenheiros pudessem combiná-lo com outros processadores para acelerar aplicativos específicos (ou seja, HPC, gráficos 3D, segurança, simulações científicas, rede, processamento de vídeo, etc.) e, como este texto é sobre o PlayStation 3, o restante do Cell é tratado tendo em mente gráficos de computador e física, então este texto reflete esse propósito.

Fora do Cell: a memória principal

Vamos sair um pouco do Cell, pois não importa quão bom seja o PPE se não tivermos um espaço de trabalho adequado (memória) para colocá-lo em funcionamento.

Por isso, a Sony equipou a placa-mãe com 256 MB de XDR DRAM... Mas, novamente, o que isso significa? Para responder a essa pergunta, precisamos dar uma olhada em como funcionam os blocos de memória e como eles se conectam ao Cell.

O Cell próximo a quatro chips de 64 MB XDR DRAM.

Primeiramente, o tipo de memória utilizada é chamado de Extreme Data Rate (XDR). Você pode reconhecer a XDR DRAM como sucessora da problemática RDRAM encontrada no Nintendo 64 e no PlayStation 2. Mas não tire conclusões precipitadas ainda!

A Rambus, como qualquer outra empresa, melhora suas invenções. Sua terceira revisão (XDR) opera em taxa óctupla (octa-rate — quatro vezes a taxa de sua adversária, a DDR DRAM) . A latência não é mais um problema, se olharmos para a ficha técnica de seus fabricantes, a latência do XDR é relatada entre 28 ns e 36 ns , quase 10 vezes mais rápido do que os chips RDRAM de primeira geração.

A primeira revisão da placa-mãe do PlayStation 3 contém quatro chips de 64 MB, operandos em pares. O XDR é conectado ao Cell usando dois barramentos de 32 bits, um para cada par. Então, sempre que a PPU escreve uma palavra (dados de 64 bits), ela é dividida entre dois chips XDR. Estes últimos são sincronizados em 400 MHz .

Diagrama da arquitetura de memória do Cell.

O Cell se conecta aos chips XDR usando o Memory Interface Controller (MIC), outro componente dentro do Cell (como o PPE). Além disso, o MIC armazena em buffer as transferências de memória para melhorar a largura de banda, mas possui uma grande limitação: o alinhamento de bytes. Em essência, o tamanho mínimo de dados do MIC para transferência é de 128 bytes, o que funciona bem para leituras ou gravações sequenciais. Mas se os dados forem menores que 128 B ou se for exigido a alternância entre gravação e leitura, as penalidades de desempenho aparecem.

Dito isso, o MIC é um gargalo ou um acelerador? Bem, você tem que colocar isso em perspectiva, a otimização de largura de banda é crítica em sistemas que exigem muitos dados. No passado, vimos soluções como write-gather pipe ou o write back buffer, então o MIC é simplesmente uma nova proposta para um problema recorrente. Vale ressaltar que a Sony afirma que a taxa de transferência é de 25,6 GB/s, no entanto, existem muitos fatores que, na prática, condicionam a taxa final (você viu o quão complicado é mover dados de um lugar para outro dentro do Cell).

Isso é tudo para a RAM principal, mas há mais memória em outros lugares: o disco rígido. O PS3 também permite que os jogos usem 2 GB do seu disco rígido interno como uma área de trabalho (similar ao que o Xbox original oferecia) .

Dentro do Cell: os assistentes

Já vimos antes como a Sony sempre fornece um processador de propósito geral (o PPE, neste caso), acompanhado de aceleradores para alcançar um desempenho de jogo aceitável (os VPUs e IPU no caso do PS2; e o GTE e MDEC com o PS1). Esta é uma prática comum no hardware de consoles de videogame, já que os processadores de propósito geral podem realizar uma ampla gama de tarefas, mas não são especializados em nada. Consoles de jogos exigem apenas um subconjunto de habilidades (física, gráficos e áudio, por exemplo) então os coprocessadores são usados para fornecer a capacidade de processamento necessária para essas tarefas.

[O PPE] é uma versão simplificada para reduzir o consumo de energia. Então, ele não tem a potência que você vê, por exemplo, em um Pentium 4(...) Se você pegar o código que roda hoje no seu processador Intel ou AMD, qualquer que seja sua potência, e recompilá-lo para o Cell, ele vai rodar — talvez você tenha que mudar uma ou duas bibliotecas, mas vai rodar, sem problemas. Mas ele será cerca de 50% a 60% mais lento e então as pessoas dirão "Oh meu Deus! Esse processador Cell é terrível!" Mas isso ocorre porque você está usando apenas uma componente .

- Dr. Michael Perrone, gerente do IBM TJ Watson Research Center's Cell Solutions Department

Os aceleradores incluídos dentro do Cell do PS3 são os Synergistic Processor Element (SPE). O Cell possui oito deles, embora um seja desativado durante a inicialização do console. Isso ocorre porque a fabricação do chip requer uma quantidade excepcional de precisão (o Cell inicialmente usou o processo de fabricação de 90nm) e a máquina não é perfeita. Então, em vez de descartar os circuitos que apresentam defeito (<10%), o Cell inclui um SPE sobressalente. Assim, se um deles apresentar defeito, o chip inteiro não é descartado. Agora, esse SPE sobressalente sempre estará desativado, independentemente de estar funcionando corretamente ou não (a Sony não pode ter dois PS3s diferentes no mercado).

Composição do SPE

Seguindo em frente, o Synergistic Processor Element (SPE) é um pequeno computador independente dentro do Cell e comandado pelo PPE. Lembra do que eu expliquei antes sobre a adoção de elementos de computação homogênea? Bem, esses coprocessadores são um tanto quanto de propósito geral e não restritos a uma única aplicação, então eles serão capazes de auxiliar em uma ampla gama de tarefas, isto é, desde que os desenvolvedores possam programá-los adequadamente.

Diagrama simplificado do Synergistic Processor Element (SPE), existem oito dentro do Cell (um fica desativado).

Assim como fizemos com o PPE, vamos dar uma olhada no SPE. É um tópico mais curto, então se no final você quiser aprender mais sobre os SPEs, confira a seção "Fontes" no final do texto. Dito isso, vamos começar...

O SPE é um processador que segue uma estrutura semelhante à do PPE, sendo composto por duas partes:

O Memory Flow Controller

O Memory Flow Controller (MFC) é um bloco que interconecta o núcleo com o restante do Cell, sendo equivalente ao PowerPC Processor Storage Subsystem (PPSS) no PPE. O trabalho principal do MFC é mover dados entre a memória local da SPU e a memória principal do Cell e manter o SPU em sincronia com seus vizinhos.

Para realizar suas funções, o MFC incorpora um controlador de DMA para lidar com a comunicação entre o barramento EIB e a memória local do SPU. Além disso, o MFC abriga outro componente chamado Synergistic Bus Interface (SBI) que fica entre o barramento EIB e o controlador DMA. É um circuito muito complexo para resumir, mas basicamente interpreta comandos e dados recebidos de fora e envia sinais para as unidades internas do SPE. Como porta de entrada para o Cell, o SBI opera em dois modos: mestre de barramento (onde o SPE é adaptado para solicitar dados de fora) ou escravo de barramento (onde o SPE é configurado para receber ordem de fora).

Como curiosidade, considerando o limite dos pacotes EIB (comprimento de até 128 bits), o bloco de DMA do MFC só pode mover até 16 KB de dados por ciclo, caso contrário, o EIB gera uma exceção de "erro de barramento" durante a execução .

A Synergistic Processor Unit

A Synergistic Processor Unit (SPU) é a parte do SPE onde o processador principal reside, equivalente ao "PPU" quando falamos do PPE.

Ao contrário da PPU, a SPU é isolada do restante do Cell. Portanto, não há memória compartilhada entre a PPU ou outras SPUs. Em vez disso, a SPU contém memória local usada como espaço de trabalho. No entanto, o conteúdo da memória local pode ser movido de um lado para outro usando o MFC.

Em termos de funcionalidade, a SPU é muito mais limitada do que a PPU. Por exemplo, a SPU não inclui funções de gerenciamento de memória (tradução de endereços e proteção de memória) ou mesmo funções de última geração (ou seja, previsão dinâmica de desvio). No entanto, ele funciona excepcionalmente bem no processamento vetorial.

Para programar essa unidade, os desenvolvedores usam a PPU para invocar rotinas fornecidas pelo Sistema Operacional do PlayStation 3, que fazem o upload do executável especificamente escrito para a SPU escolhida e a sinaliza para iniciar a execução. Depois, a PPU mantém uma referência à thread da SPU para fins de sincronização .

Arquitetura da SPU

Como qualquer CPU, a Synergistic Processor Unit (SPU) é programada usando uma arquitetura de conjunto de instruções (ISA, do inglês Instruction Set Architecture). Tanto a SPU quanto a PPU seguem a metodologia RISC, no entanto, ao contrário da PPU (que implementa uma ISA PowerPC), a ISA da SPU é proprietária e principalmente composta por um conjunto de instruções do tipo SIMD. Como resultado, a SPU apresenta 128 registradores de propósito geral de 128 bits que abrigam vetores feitos de valores de ponto fixo ou de ponto flutuante de 32/16 bits. Por outro lado, para preservar a memória, as instruções da SPU são muito menores, com apenas 32 bits de comprimento. A primeira parte contém o código de operação e o restante pode fazer referência a até três operandos a serem calculados em paralelo.

Isso é muito semelhante antiga Vector Floating Point Unit apresentada no PS2, entretanto muita coisa mudou desde então. Por exemplo, a SPU não exige que os desenvolvedores aprendam uma nova linguagem de montagem proprietária - a IBM e a Sony forneceram kits de desenvolvimento para programar as SPUs usando C++, C ou assembly.

Em termos de projeto, este processador não executa todas as instruções usando a mesma unidade. A execução é dividida em dois blocos ou "pipelines de execução", uma é chamada de pipeline ímpar e a outra é chamada de pipeline par. Esses dois pipelines executam tipos diferentes de instruções, permitindo que a SPU emita duas instruções por ciclo sempre que possível. Por outro lado, a SPU nunca emitirá duas instruções simultâneas que dependam uma da outra, mitigando assim os riscos de dados (data hazards) que possam surgir.

Vamos dar uma olhada nos dois pipelines :

Pipeline ímpar

Diagrama simplificado do pipeline ímpar.

O pipeline ímpar executa a maioria das instruções, exceto as aritméticas.

Em primeiro lugar, você encontrará a SPU Load/Store unit (SLS), que faz três coisas essenciais:

• Contém 256 KB de memória local para armazenar instruções e dados. O tipo de memória utilizada é de porta única (considerando que esta é uma área crítica, é um pouco decepcionante que eles não tenham usado chips de porta dupla...). Além disso, o barramento de endereço tem 32 bits de comprimento.
• Executa instruções de carga e armazenamento.
• Encaminha instruções para outro bloco para emissão.

Observe que apenas 256 KB estão disponíveis para armazenar o programa. Considerando que os programas da SPU podem ser compilados usando C/C++, não é fácil prever o tamanho que o arquivo binário terá. Por isso, é recomendando que os desenvolvedores considerem haver apenas metade da memória disponível (128 KB) , o que deixa espaço suficiente para o código compilado ocupar o espaço que precisar, embora isso resulte em custo de armazenamento e eficiência.

Finalmente, também há uma SPU Channel and DMA Transport Unit (SSC), que o Memory Flow Controller usa para preencher e/ou buscar memória local, e uma unidade de ponto fixo insignificante que apenas faz embaralhamento e rotação de vetores.

Pipeline par

Diagrama simplificado do pipeline par.

O * pipeline* par é notável por suas capacidades aritméticas.

Aqui encontramos uma verdadeira Fixed-point Unit (FXU) que realiza aritmética básica, operações lógicas (AND, OR, etc.) e deslocamento de palavras.

Por último, mas não menos importante, temos uma Floating-point Unit (FPU) que realiza operações de precisão simples (float de 32 bits), dupla precisão (double de 64 bits) e inteiro (int de 32 bits). Segue o padrão IEEE com algumas divergências (os pontos flutuantes se comportam de maneira semelhante ao PS2).

Dentro do Cell: estilos de programação

Como chegamos no final do Cell, você pode se perguntar como os desenvolvedores devem programar esse monstro? Bem, de forma semelhante aos modelos de programação anteriores criados para o Emotion Engine, a IBM propôs as seguintes metodologias :

Abordagens centradas no PPE

Representação do padrão de vários estágios, em que o PPE atribui uma tarefa passada por cada SPE e, eventualmente, retornada com os dados processados.

Representação do padrão paralelo, em que o PPE atribui uma sub-tarefa para cada SPE e, por sua vez, cada SPE retorna os dados processados, que o PPE mescla.

Representação do padrão de serviços, em que o PPE aloca uma tarefa diferente para cada SPE, e cada um trabalha individualmente para cumprí-la.

As abordagens centradas no PPE são um conjunto de padrões de programação que colocam as principais responsabilidades no PPE e deixam o SPE para a descarga de trabalho. Existem três possíveis padrões:

• Modelo de pipeline multiestágios: o PPE é encarregado de enviar trabalho para um único SPE, que por sua vez realiza os cálculos necessários e passa os resultados para o próximo SPE. Isso continua até que o último SPE na cadeia envie os dados processados de volta ao PPE.
  • Por razões óbvias, a IBM não sugere este projeto para tarefas principais, pois requer uma quantidade considerável de largura de banda e tende a ser difícil de manter.
• Modelo de estágios paralelos: o PPE divide sua tarefa principal em subtarefas independentes e envia cada uma para um SPE diferente. Cada SPE retorna os dados processados ao PPE depois de concluídos, e o PPE os combina para produzir o resultado final.
• Modelo de serviços: cada SPE recebe a atribuíção de uma tarefa única (por exemplo, decodificação MPEG, streaming de áudio, projeção de perspectiva, iluminação de vértice, etc.) e o PPE é responsável por enviar dados brutos para o SPE designado. Enquanto espera, o PPE realiza outras funções.
  • Embora isso implique que cada SPE terá um único trabalho, sua designação de trabalho não é destinada a durar para sempre. O PPE deve realocar diferentes trabalhos dinamicamente à medida que as necessidades do programa mudam.

Abordagens centradas no SPE

Representação do padrão centrado em SPE, em que cada SPE é responsável por sua funcionalidade e interage apenas com o PPE para obter um recurso.

Em vez de usar os SPEs para servir o PPE, é o contrário. Usando a unidade interna de DMA, os SPEs buscam e executam tarefas armazenadas na memória principal, enquanto o PPE é limitado ao gerenciamento de recursos.

Este modelo é muito mais radical do que o restante, no sentido de que os padrões anteriores estão mais próximos do paradigma "processador geral de propósito com coprocessadores". Assim, as bases de código que implementam algoritmos centrados no SPE podem ser mais difíceis de portar para outras plataformas.

Conclusão

Como você pode imaginar, embora o projeto multi-núcleos do Cell acelere técnicas emergentes, como geração procedural, nenhum desses projetos é particularmente simples de implementar, especialmente considerando que os estúdios de jogos preferem bases de código que possam ser compartilhadas em diferentes plataformas.

Para dar um exemplo, os desenvolvedores do Unreal Engine 3 (Epic Games) demonstraram as limitações dos SPUs ao tentar implementar seu sistema de detecção de colisão . Seu projeto depende do Binary Space Partitioning (BSP — partição binária do espaço, em tradução livre), um algoritmo fortemente dependente de comparações (branching). Como as SPUs não fornecem previsão dinâmica de desvios como a PPU, sua implementação decepcionou os usuários do PlayStation 3 quando comparada lado a lado com outras plataformas (ou seja, Xbox 360 ou PCs i686, ambas fornecendo técnicas consistentes de previsão em todos os seus núcleos). Assim, a Epic Games teve que recorrer a mais otimizações compatíveis apenas com o Cell.

Suponho que seja apenas uma questão de tempo, paciência e muito aprendizado para que os engenheiros de software aproveitem todo o potencial do Cell. No entanto, a história demonstrou que isso não é viável para todos os estúdios, o que me faz pensar se esse é o motivo pelo qual o hardware do console atual (a partir de 2021) se tornou tão homogêneo.