O SSD da Sony não seria muito mais do que um disco mais rápido não fossem um conjunto estruturante de alterações radicais ao funcionamento de muitas caracteristicas do sistema. Aqui abordamos a parte relativa ao novo sistema de Input/Output da PS5.
Esta é a segunda e última parte da transcrição da palestra de Mark Cerny sobre o SSD e o sistema de E/S da PS5. Das partes mais revolucionárias da consola, e algo que certamente veremos a ser implementado em breve em outros sistemas. Há mesmo quem já diga que no futuro os GPUs AMD virão equipados com um SSD e com estas modificações incluidas.
A realidade, porém, é que o SSD é apenas uma peça do quebra-cabeças. Há muitos sítios onde podem ocorrer gargalos entre o SSD e o código do jogo que usa os dados recebidos.
Isso vê-se facilmente no PlayStation 4. Se eu usar um SSD com 10 vezes a velocidade de um disco rígido padrão, provavelmente vejo apenas o dobro da velocidade de carga.
Para o PlayStation 5, o nosso objetivo não era apenas que o SSD fosse cem vezes mais rápido, mas também que a carga e o streaming do jogo fossem cem vezes mais rápidos, de modo que todos os possíveis gargalos que pudessem potencialmente aparecer precisavam de ser resolvidos.
E há um monte deles.
Vejamos o check-in e o que acontece quando a sobrecarga trazida por um disco 100x mais rápido fica cem vezes maior. Conceptualmente, o check-in é um processo bastante simples: os dados são carregado na memória do sistema, vindos do disco rígido ou SSD . Eles são examinados, alguns valores são ajustados para fazer o check-in e depois o bloco de dados é movido para o local final na memória.
Nas velocidades deste SSD, falando sobre a última parte, mover os dados, ou seja, copiá-los de um local para outro requer aproximadamente um núcleo de CPU de última geração.
E isso é apenas a ponta do iceberg se todas as sobrecargas aumentarem cem vezes, tal vai afectar os fotogramas assim que o jogador se mover e esse fluxo maciço de dados começar a sair do SSD.
Num sistema standard, o SSD ao meter os dados tão rapidamente na memória, não só cria um grande impacto no CPU que tem de tratar estes dados rapidamente, mas igualmente na largura de banda da RAM, que tem de escrever os dados quando são recebidos, quando são alterados, e novamente para serem movidos para o destino final. São as tais sobrecargas adicionais de que Cerny fala, e às quais a Sony se propôs resolver com a PS5.
Então, para resolver isso tudo, construímos uma enorme quantidade de hardware personalizado, ou seja, um controlador flash personalizado e várias unidades personalizadas no nosso chip principal.
O controlador flash no SSD foi projectado para permitir operações suaves e sem gargalos, mas também tendo jogos em mente. Por exemplo, existem seis níveis de prioridade de dados ao ler os mesmos a partir do SSD.
A prioridade é muito importante: Podemos imaginar o jogador a ir para um novo local no mundo e o jogo a solicitar alguns gigabytes de texturas. Mas enquanto essas texturas estão a ser carregadas, um inimigo é atingido e precisa dizer algumas palavras antes de morrer.
Tendo vários níveis de prioridade, vamos conseguir carregar o áudio dessas palavras moribundas imediatamente.
De um dos seus lados, o controlador flash conecta-se aos chips flash reais que fornecem o armazenamento. Para alcançarmos a meta de largura de banda de 5 gigabytes por segundo, acabamos com uma interface de 12 canais. 8 canais não seriam suficientes.
A largura de banda resultante que alcançamos é na verdade cinco gigabytes e meio por segundo. Com uma interface de 12 canais, o tamanho mais natural que surge para um SSD é de 825 gigabytes.
É relevante perceber-se aqui que não só a Sony conseguiu superar a sua meta de 5 GB ao usar este controlador proprietário, como na realidade, comparativamente a um SSD normal de PC, com dois níveis de prioridade, este disco teria um débito bastante superior a 5.5 GB/s.
5.5 GB/s é o obtido com os seis níveis de prioridade activos. Um SSD standard apenas possui 2 níveis de prioridade.
É esse o motivo pelo qual os SSDs PC a serem usados como expansão na consola terão de ser mais rápidos que os da PS5, pois ao se lhes acrescentar níveis de prioridade, a sua velocidade irá cair.
A principal questão para nós foi que é tentador adicionar mais espaço, mas a memória flash não sai barata e temos a responsabilidade para com o nosso público alvo de sermos eficientes na relação custo/benefício face ao que colocamos na consola.
Por fim, resolvemos essa questão observando os padrões de jogo de uma ampla variedade de jogadores.
Examinamos os jogos específicos que eles jogavam ao longo de um fim de semana, semana ou mês e se esse conjunto de jogos se encaixava correctamente na dimensão do SSD.
Conseguimos estabelecer que o desgaste causado pelos downloads e reinstalações seria bastante baixo e, portanto, mantivemos o tamanho de 825 gigabytes enquanto preparávamos várias estratégias para que aqueles que desejam mais armazenamento possam adicioná-lo. Analisarei os detalhes daqui a um momento
Voltando ao controlador flash, pelo seu outro lado ele conecta-se ao nosso chip personalizado principal por meio de 4 pistas PCIe de 4ª Geração e, dentro do chip personalizado principal, há uma unidade bastante robusta dedicada à E / S (Entrada / Saida ou Input / Output).
Antes de abordarmos o que tudo isso faz, vamos falar um pouco sobre compressão de dados.
O PlayStation 4 usou o “Zlib” como formato de compactação e decidimos usá-lo novamente no PlayStation 5, mas nas minhas viagens entre os criadores, em 2017 eu ouvi falar de um novo formato chamado “Kraken” da Rad Game Tools.
Ele é como um primo mais inteligente do Zlib, um tipo de algoritmo simples e similar, mas com uma compressão 10% melhor, o que é bastante pois significa 10% de mais dados de jogo no disco Blu-ray UHD ou no SSD.
O Kraken tinha sido lançado há apenas um ano que já se estava a tornar um padrão no sector. Metade das equipes com as quais conversei ou que o estavam a usar ou preparavam-se para o avaliar.
Por isso, criamos um descompactador personalizado na unidade de E / S, capaz de lidar com mais de 5 gigabytes dados de entrada nesse formato por segundo.
Após a descompressão, esses dados tornam-se por norma em 8 ou 9 gigabytes, mas a unidade é capaz de debitar até 22 gigabytes por segundo se os dados compactarem particularmente bem.
A propósito, em termos de desempenho, este descompressor personalizado equivale-se a nove de nossos núcleos Zen2, pois isso seria o necessário para descomprimir o fluxo Kraken com um CPU convencional.
Aqui dá-se a entender que todo o fluxo de compressão/descompressão é retirado a 100% do CPU, que neste caso nem teria núcleos suficientes para descomprimir estes dados em tempo real. Ou seja, este sistema de E /S (ou I/O como gosto mais de lhe chamar) é 100% autónomo e automatizado. Podemos ver esse descompressor representado na Imagem que se segue, e dentro do complexo destinado ao Input/output de dados.
Há muito mais na unidade de E / S personalizada, incluindo um controlador DMA dedicado que permite que o jogo possa direcionar directamente e exatamente para o local final onde se deseja colocar os dados que saem do SSD.
Este processo. a nível de equivalência de desempenho de cópia, equivale-se a mais um ou dois núcleos Zen2.
O seu principal objetivo é remover o check-in como um gargalo.
Este chip, acima representado como DMAC, torna-se extremamente relevante. Ele permite poupar CPU, e mais do que isso, ciclos de processamento, bem como imensa largura de banda. Basicamente o SSD lê directamente para a memória, o que quer dizer que, com um pedaço de RAM dedicado a receber estes dados, o SSD funciona como RAM, neste caso, pela sua velocidade de 5.5 GB/s, uma RAM DDR2 667 a 33 Mhz. Esta é uma alteração significativa!
E desta forma, o processo de escrita, alteração e re-escrita dos dados na RAM passa a ser apenas o de escrita, poupando-se mais de metade da largura de banda usada neste processo.
Há dois co-processadores de E / S dedicados, uma grande pool de RAM. Estes não são núcleos Zen 2, e existem principalmente para direccionar a variedade de hardware personalizado que existe ao seu redor
Um dos coprocessadores é dedicado à E / S de dados do SSD, o que nos permite ignorar o sistema de E / S tradicional e seus gargalos igualmente tradicionais que surgem ao se ler dados a partir do SSD.
O outro é responsável pelo mapeamento de memória, que eu sei que não parece nada relacionado ao SSD, mas o certo é que muitos criadores mapeiam e re-mapeiam a memória como parte do sistema de ficheiros de E / S, e isso também se pode tornar um gargalo.
Existem ainda motores de coerência para assistir os co-processadores. A questão da coerência surge em muitos lugares, e provavelmente o maior problema de coerência são os dados parados nos caches da GPU.
Limpar todos os caches da GPU sempre que o SSD é lido é uma opção pouco atraente, pois pode prejudicar o desempenho da GPU.
Portanto, implementamos uma maneira mais meiga de fazer as coisas, em que os mecanismos de coerência informam a GPU dos intervalos de endereços a serem reescritos Cache Scrubbers em várias dezenas de caches do GPU realizam despejos apenas desses intervalos de endereços.
O melhor é que, como criador de jogos, quando você lê o SSD, não precisa de saber nada disto. Nem precisa sequer saber que seus dados estão compactados.
Basta apenas indicar quais dados que se deseja ler do seu arquivo não compactado original e onde se deseja colocá-lo, e todo o processo de carga acontece de forma invisível e em velocidade muito alta.
Esta parte da apresentação mostra como a Sony revolucionou o sistema de I / O da PS5. É um novo paradigma no qual os gargalos de um sistema clássico basicamente desaparecem. E tudo se processa de forma automático 100% no hardware, sem intervenção de software, de APIs, ou sequer do conhecimento do programador. É tudo 100% automatizado e optimizado por hardware.
Como podemos ver, há uma RAM dedicada para estes processos, e adicional à RAM da consola. É nela que se dão os processos internos que estes Chips efectuam, não penalizado assim as largura de banda da memória principal.
Os motores de coerencia tratam dos acertos de coerência entre todos os chips e a integração dos dados nas caches do GPU e os cache scrubbers permitem escrever directamente nessas caches nos endereços definidos. Esta situação optimiza o desempenho do GPU, das memórias e das larguras de banda.
É um processo realmente revolucionário.