The road to PS5 – Em português e comentado – Parte 2 – As mudanças de paradigma com o novo sistema de I/O

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.

 

 



20 Comentários
Antigos
Recentes
Inline Feedbacks
Ver todos os comentários
AlexandreR
AlexandreR
7 meses atrás

Com esta explicação adicional, da para perceber o quão inovar será a ps5! E que para os distraídos, a Ps5 será uma proeza de engenharia, tal como a ps4.
A ps5 consegui-o remover os gargalos, segundo a Sony. Será que com a Xbox SX, poderemos dizer o mesmo? Ou tem hardware dedicado, que faça equivalente? Ou sobrecarrega o cpu, para remover alguns gargalos?

AlexandreR
AlexandreR
Responder a  Mário Armão Ferreira
7 meses atrás

Sim, no caso da Ps5. Na Xbox SX é uma incógnita, certo?

nETTo
nETTo
7 meses atrás

Duas coisas muito interessantes

Descompressor Kraken: 825GB foi o que se conseguiu levando-se em consideração o custo benefício e a questão do preço ao consumidor, um valor estranho levando em consideração que 1TB tem 1024GB, uma diferença de tamanho de 25% em relação ao valor arredondado, mas com o descompressor Kraken e com a sua eficiência de 10% em relação ao Zlib, logo essa diferença cai pra 15%, um cenário bem melhor do que o esperado.

Otimização: Muito foi dito depois dessa apresentação que somente os jogos first party se beneficiariam de toda estás beneces do SSD, agora podendo analisar em detalhes se percebe que tudo foi criado pra ser automatizado, ou seja, nas palavras do Cerny é só escrever o código e correr pro abraço, até a DF disse que esse sistema precisaria de otimização pra poder alcançar tais velocidades, ao que nesta altura não parece.

Pra terminar, a Sony revoluciona não por colocar um SSD no PS5, longe disso, ela o fazz porque pensou realmente em todos os gargalos que os devs tem vindo a ter ao longo das décadas, e no fim trouxe um sistema de e/s dados como nunca antes foi visto.

PS: E já prevendo algumas reações que eu vi na primeira parte do artigo, aqui pelo menos pra mim ninguém está dizendo que 12.1<<10.3 tá, logo, segure esse hate ai.

AlexandreR
AlexandreR
Responder a  Mário Armão Ferreira
7 meses atrás

Estou super curioso para ver os 2 sistemas a funcionarem!

Carlos Eduardo
Carlos Eduardo
7 meses atrás

Perfeito Mário. Isso vai de encontro com o que a Digital Foundry disse no artigo “PlayStation 5 uncovered: the Mark Cerny tech deep dive”, ou seja: “Developers simply need to specify the ID, the start location and end location and a few milliseconds later, the data is delivered.”

A grande vantagem que vejo nesse aspecto é exatamente pelo fato do SeriesX também ter projetado sua consola para que o SSD funcione como RAM virtual. Com isso, a tendência é que em jogos multiplataforma, o Playstation 5 possua mais folga, com menos chance de stuttering. Se o jogo for exigir atualizações na RAM que usem o limite do SeriesX, este poderá ter quedas de FPS, e o PS5 estará na folga.

Carlos Eduardo
Carlos Eduardo
Responder a  Mário Armão Ferreira
7 meses atrás

Sim. Quis evidenciar o fator folga, porque como sabemos no PC, todo componente que é exigido 100% impacta negativamente em quedas de FPS, stuttering.

Agora o curioso é que para a GPU, a situação não necessariamente se inverte. Se um jogo distribuir instruções em paralelo para todas as 36 unidades computacionais do Playstation 5, embora esta consola esteja no seu limite e o SeriesX tenha 16 unidades computacionais de sobra (totalizando 52), como o clock do PS5 é maior, as operações sequenciais como raster funcionarão mais rapidamente no PS5, logo o SeriesX poderá ter problemas.

Carlos Eduardo
Carlos Eduardo
Responder a  Mário Armão Ferreira
7 meses atrás

Entendi. Então você está dizendo que se o SeriesX usar 36UCs em um jogo, terá 36UCs de RT, ou seja, as 16 UCs sobrando ficarão ociosas?

Daniel Cardoso
Daniel Cardoso
7 meses atrás

Mais do que nunca, o conteúdo exclusivo é o que vai ser o maior diferencial da nova gen. Vendo esta matéria é o que da a etender.

AlexandreR
AlexandreR
6 meses atrás

Offtopic: falam do tempest

https://gamingbolt.com/ps5s-tempest-engine-is-hardware-accelerated-will-be-a-huge-boost-to-cpu-hellpoint-dev

Pelo que percebi, sendo o áudio tratado a parte, é uma mais valia para o cpu. Pois, não tem que processar o áudio.

Cucapalooza
Cucapalooza
6 meses atrás

Olá Mario, queria parabenizar pelo trabalho e pela forma como conduz aos assuntos mais técnicos, mesmo sendo leigo, consigo absorve bastante.

Um abraço de um companheiro que acompanha o site desde 2012!
Continue com o bom trabalho.

Andrio
Andrio
6 meses atrás

Parei para ler melhor os 2 artigos e realmente o cerny trabalhor duro durante todos esses anos para trazer essas mudanças(tecnologicas) para o ps5. da pra ver que foi tudo minuciosamente pensado, detalhe por detalhe e não somente um aumento de força bruta. Espero que as devs usem bem as ferramentas do ps5.

error: Conteúdo protegido