Porque o sistema de I/O da PS5 é o sistema de I/O mais avançado até hoje criado

O conteúdo deste artigo foi escrito como resposta para ser colocado no Beyond3D, tendo a mesma sido removida, pois entende-se adequada para um artigo.

Nota: Recomenda-se que após este artigo, seja lido este outro.

Após a questão de Ratchet correr no PC com um HDD, alguns questionam a capacidade do sistema de I/O da PS5. Mas apesar que isto pode custar a muitos, efetivamente o sistema de Input/Output da PS5, que vulgarmente aqui nos referimos apenas como SSD, muito elogiado no inicio da geração, é efetivamente o sistema de I/O mais avançado criado até hoje.

Em 2020 o sistema era efetivamente revolucionário. Comparado com o que um PC conseguia fazer na altura, o sistema de I/O tinha como grande vantagem a sua capacidade de descompressão de dados do SSD com volumes de informação que podiam alcançar os 17.38 GB/s efetivos e 22 GB/s máximos teóricos.

Agora, em 2023, as diferenças para o que o PC pode fazer decresceram, e isso graças à introdução do Direct Storage, mas no entanto mesmo nas implementações mais avançadas, como o RTX I/O, a grande vantagem introduzimos no PC foi a libertação do CPU, sendo que, o sistema de I/O da PS5 é muito mais do que isso e há outras situações cobertas pelo seusistema de I/O que o PC não cobre.



A principal diferença entre o que existe de semelhante nos dois lados é o facto que a descompressão tem peso zero nos recursos e processamento da Playstation 5. Mas no Direct Storage isso não acontece, e ele usa RAM, recursos do GPU e VRAM. Como se pôde ver em sistemas PC mais capazes e que podem executar Ratchet and Clank desativando o Direct Storage, os ganhos e performance chegam aos 30%, o que significa que essa percentagem de performance perdida é o usado para se fazer o que a PS5 faz com 0% de perdas de performance.

Mas o maior impacto de um sistema destes aplicado ao PC acaba por ser na largura de banda. No PC, no Direct Storage base, os dados dão carregados para a RAM, mandados para a VRAM do GPU, descompactados pelo GPU, e na parte que é do CPU, devolvidos à RAM. E apesar de o principal volume de dados, sendo texturas, ficar logo na VRAM, há uma enorme taxa de transferências internas que tem impacto na largura de banda do sistema. E tudo isto controlado pelo CPU que dedica recursos ao controlo deste fluxo, havendo na RAM um processo de check in destinado a criar coerência entre os dados vindos de outro hardware, uma descompressão com duplicação de dados (comprimidos e descomprimido) e uma movimentação dos dados para os endereços de memória finais (ou seja, diversas movimentações que usam processamento, tempo, e largura de banda).

O diagrama que se segue, vindo da Microsoft, mostra as transferências necessárias para dados que se mantém no GPU. Ali seria necessário acrescentar a devolução de dados do CPU para a RAM principal, caso quiséssemos indicar a totalidade de transferências que podem existir.

Esta situação é bem diferente da que existe na PS5. Toda a gestão e movimentação de dados não é controlada pelo CPU, mas sim por dois co-processadores de I/O, os dados são descompactados usando um descompressor dedicado e numa SRAM de 4 GB e de alta velocidade, que consegue fazer esta descompressão em “tempo real”, sendo que os dados são enviados para a RAM já descompactados e prontos a serem usados graças ao uso de motores de coerência.

O que isto significa é que o SSD pode ser tratado como se fosse RAM efetiva, as transferências não usam qualquer CPU, e a largura de banda necessária para toda a transferência é apenas a necessária para a entrada dos dados na RAM, e nada mais.



Dado que a PS5 usa um sistema unificado de memória, não há transferências entre o CPU e o GPU. Os dados estão lá e os motores de coerência tratam de a tornar coerente para uso de qualquer um deles, sem que o CPU tenha de intervir a criar a mesma, gastando assim ciclos de processamento para tal.

Num exemplo que nos soa a algo bem equivalente ao que se passa, temos a descompressão de um ficheiro comprimido. Um ficheiro RAR ou ZIP.

Num PC de 2020, o CPU faria a leitura de todos os dados para a RAM onde eles eram descompactados, e movidos para a sua localização final. Um processo que demoraria o seu tempo e que usaria o CPU de uma forma intensiva.

Com o Direct Storage, o CPU enviaria os dados na RAM, moveria os mesmos para VRAM onde seriam descompactados pelo GPU, que moveria depois os dados para a sua localização. O CPU seria libertado, apesar que continuava a controlar tudo, mas a descompressão seria tremendamente mais rápida e o uso de recursos críticos bem menor.



Em qualquer dos casos os dados são lidos, colocados na RAM, descomprimidos para um novo pedaço de RAM, e uma vez o ficheiro completo, movidos para a sua posição final (que neste caso seria no disco e não na RAM).

Mas eis que nos chega a PS5… Onde comparativamente seria como se os dados pudessem ser usados diretamente do ficheiro comprimido… Sem o uso de qualquer recurso adicional.

Isto porque os dados estarem comprimidos ou não é basicamente irrelevante para o sistema, o facto de eles estarem no SSD ou na RAM é basicamente irrelevante para o sistema. A única diferença está no tempo de entrega dos dados que não é igual, apesar de tudo ser entregue em tempo útil para que o processamento possa ocorrer no chamado “tempo real”.

Este exemplo permite perceber a grande diferença entre o sistema de I/O da PS5 e o que existe no PC, inclusive atualmente. E tal como o Direct Storage nasceu na XBox e foi adaptado ao PC; não há grandes dúvidas que no futuro o PC terá de utilizar algo equivalente. Afinal por muita performance que exista nas máquinas mais caras, o uso desses recursos torna-se desnecessário pois um sistema de I/O baseado no da PS5 seria barato e libertaria recursos valiosos no sistema.

Será talvez de dizer que a intenção da Sony com o SSD da PS5 foi exactamente o de quebrar um pouco os limites impostos por 16GB de RAM, permitindo assim que a consola possa ir um pouco mais longe. E para tal, o SSD responder como se fosse RAM tornou-se relevante.



Notas finais

Como primeira nota há que se dizer que o uso do sistema de I/O da PS5 não acontece por milagre, e necessita de suporte. Tal como qualquer hardware há uma curva de aprendizagem com o seu uso, e será melhor usado no final da geração.

Como segunda nota há que se fazer uma ressalva relativa ao RTX I/O. O sistema da Nvidia tem um suporte hardware diferente que vai um bocado mais longe e se aproxima mais do existente na PS5. Segundo o diagrama da Nvidia, os dados não passam pela memória RAM, indo directamente para a VRAM. A situação permite diminuir o uso normal do CPU em 20x (uma comparação face ao sistema tradicional e não face ao Direct Storage). Este RTX I/O, compatível com o Direct Storage é, como já se referiu, mais próximo do que a PS5 faz, mas mesmo assim não é algo que traz uma movimentação de dados e descompressão “gratuita” como acontece na PS5.

NVIDIA

AMD

A AMD, não possui qualquer hardware adicional nos seus GPUs, pelo que, como se pode ver do esquema tirado da AMD, o seu funcionamento é o do Direct Storage tradicional.





22 Comentários
Antigos
Recentes
Inline Feedbacks
Ver todos os comentários
Júlio Esteves
Júlio Esteves
19 de Agosto de 2023 11:13

Ótimo artigo. Mário acreditas que AMD possa usar o sistema de I/O do PS5 em um futuro RDNA? ( dada sua parceria com a Sony).

Tiohildo
Tiohildo
19 de Agosto de 2023 11:56

OFF: Estou pesquisando e fazendo testes para implementar a minha ferramenta de análise com um interface gráfica, utilizando python mesmo.
Estou querendo fazer um ‘player’ de vídeo embutido para visualizar os resultados.
Porém as abordagens comuns de exibição de imagens em um canvas normal animado são bem lentas. Não é possível rodar
nem um vídeo Full HD em 60 FPS, pelo menos no meu computador.
Olhei várias outras formas de fazer isso com mais performance, a princípio, utilizando opencv.
Consegui os seguintes resultados na reprodução de vídeos:

Reprodução de 1 vídeo Full HD a 150 FPS
Reprodução de 1 vídeo 4K a 40 FPS.
Reprodução de 4 vídeos em Full HD em 40 FPS 
Reprodução de 4 vídeos em 4K a 13 FPS.

Depois de várias pesquisas e otimizações de: leitura e escrita da memória em python, utilização de multiprocessamento ( cada vídeo é lido por um processo diferente), outra lib para leitura mais rápida de vídeos, otimização de código, renderização dos frames na GPU com OpenGL, etc. Consegui os resultados abaixo:

Reprodução de 1 vídeo Full HD a 250 FPS
Reprodução de 1 vídeo 4K a 85 FPS
Reprodução de 4 vídeos em Full HD em 85 FPS
Reprodução de 4 vídeos em 4K a 35 FPS.
Reprodução de 6 vídeos em Full HD em 60 FPS

Aproveitando o gancho do artigo de hoje, essa questão de memória é muito relevante.
Nesse meu player, a maior parte das vezes está ‘Memory Bound’, pois já otimizei ao máximo a transferência dos frames da memória RAM para a GPU conseguir ler e renderizar ( antes de otimizar, eu ficava fazendo várias cópias dos frames para outra variáveis e perdia performance, agora o programa escreve na RAM uma única vez, mas não é simples, pois como estou fazendo multiprocessamento, a memória onde fica armazenado os frames tem que ser compartilhada com o processo que renderiza utilizando a GPU). Ainda tenho a opção de alocar a memória na própria GPU, a lib permite isso, mas eu tenho que ter uma placa da NVIDIA para usar CUDA, e onde eu estou desenvolvendo é um notebook com GPU intel onboard. E para usar essa feature da lib, tem que recompilar a lib em C++, coisa que já consegui fazer.

Foto do player:
comment image?o=1

Tiohildo
Tiohildo
Responder a  Mário Armão Ferreira
19 de Agosto de 2023 13:34

Obrigado, Mário. Se quiser posso fazer uma versão do player para você testar no seu super PC … rs

Tiohildo
Tiohildo
Responder a  Mário Armão Ferreira
19 de Agosto de 2023 22:29

Estou tentando fazer um executável para você não ter que instalar nada. Contudo, estava bugado e estava criando um milhar de processos ( um monte de mario.exe, parecendo um malware, LOL ). Consegui arrumar, vou só parametrizar as entradas pois estava tudo hardcoded …

Juca
Juca
Responder a  Tiohildo
19 de Agosto de 2023 12:21

Ótimo trabalho, Hildo… agora, aparentemente estás a “fazer milagres” com uma gpu intel onboard! Lol Cara, a melhoria pra compressão em tempo real e mesmo execução de vídeos com aplicativos com suporte a GPUs Nvidia é tão superior pelo que já testei, que penso que estás a tirar leite de pedra mas que terias muito menos trabalho e ainda um melhor resultado com uma GPU Nvidia, de qualquer forma, são otimizações, e o raciocínio dessas servirá pra qualquer computador com o qual for trabalhar. Estás sempre de parabéns. Continue sempre melhorando!

Tiohildo
Tiohildo
Responder a  Juca
19 de Agosto de 2023 13:33

O PC desktop onde faço as minhas capturas tem um placa da Nvidia, porém não tem o ambiente de desenvolvimento instalado e não tem NVME, para ler esse monte de vídeos, preciso de velocidade de leitura acima de 1 GB/s ( quando se carrega 4 vídeos 4K, chega a dar picos de 4 GB/s). Vou ver se o player consegue executar nesse PC com barramento SATA.

Tem outras coisas que eu implementei também, como limitador de FPS e a possibilidade de tocar o áudio de uns dos vídeos , o áudio é sincronizado com os frames, ou seja, se o FPS estiver lento, o áudio fica lento, se estiver rápido, o áudio fica rápido ( esse deu bastante trabalho).
Também é possível escolher a de saída e a resolução de entrada, ou seja, a resolução que irá ler do vídeo para não desperdiçar processamento ( se quiser exibir um vídeo em Full HD de uma fonte em 4K, ou o inverso também, já é feito o upscale automático).

Juca
Juca
Responder a  Tiohildo
19 de Agosto de 2023 16:09

Bacanas essas implementações, Hildo!

Tiohildo
Tiohildo
Responder a  Juca
19 de Agosto de 2023 13:40

Outra coisa que implementei também foi Double Buffering, mas estranhamente não tive nenhum ganho de performance com dois buffers. Ou seja, enquanto um buffer é desenhado pela GPU, o processo responsável por ler os frames já pode escreve no outro buffer. Ainda estou investigando o porque não deu diferença.
Veja na foto do player que tem um ‘0’ depois do FPS, esse 0 é o buffer onde está escrevendo no momento. Se tiver dois buffers, irá ficar, 0,1,0,1 toda hora.

Juca
Juca
19 de Agosto de 2023 12:09

Sempre pensei que a evolução dos PCs, do ponto de vistas de streaming, seria uma espécie de SSD de RAM (que eu pensei serem as evoluções naturais dos optane da intel ou mesmo como o tal UltraRAM já conjecturado há algum tempo mas que acabam de ventilar como possível), que é algo que de longa data se conjectura e vez por outra sai algum equipamento teórico que não se sabe se funciona. Ainda assim se usaria CPU para descomprimir, pois a compressão se faz necessária pra preservar espaço. De qualquer forma, vejo como lamentável cada um na indústria puxando a sardinha para o seu lado, o mais sensato seria que esses sistemas de coerência e descompressão viessem embutidos nas placas mãe, e assim permitindo o seu uso com qualquer CPU, ou GPU, mas como tudo se transforma em guerras comerciais, é algo compreensível, pelo menos se veem melhoras vindo de qualquer forma, mesmo que sem um consonância estratégica aprazível.

https://www.hardware.com.br/noticias/2023-08/pesquisadores-criam-a-ultraram-um-tipo-de-memoria-que-une-ram-e-ssd-no-mesmo-componente.html

marcio
marcio
19 de Agosto de 2023 12:34

A Sony criou uma solução bastante interessante para eliminar esse gargalo nos jogos e realmente aproveitar o potencial do SSD e torna-lo como uma ram e em nenhum outro sistema tens “825gb +16gb” de ram, mas ainda espero um jogo que mostre na pratica que essas features desta geração, não so para no sentido de loadings mais rapido como ja acontece mais na melhora do grafismo, o fim dos pop-ins, LoD infinito, mais draw distance e tudo que esses “841” gb de ram possibilitaria…

Juca
Juca
Responder a  marcio
19 de Agosto de 2023 13:08

Márcio, ao que parece, a maior parte da questão é que as engines não avançam rapidamente como o sistema da Sony o fez, e tendo-se em vista o compromisso com o PC, duvido que as coisas aconteçam rápido assim.

O Nanite é um bom passo na direção dos fins de pop-ins e LoD “infinito”, mas é algo que também exige bastante das máquinas ainda, a minha impressão é que tudo na humanidade é uma espécie de futuro que nunca chega, pois estão sempre a subir o sarrafo.

De qualquer forma, meus anseios são semelhantes aos seus.

marckos
marckos
Responder a  marcio
19 de Agosto de 2023 15:43

A Sony criou, ou evoluiu uma ideia que já existia no PC? Em 2016, lembro que a AMD lançou uma GPU com, se não me engano, um 1 TB de ssd e 16 gb de memória HBM (Radeon Pro SSG), porém não era usado para jogos, era voltado pra uso profissional… Me parece que o “esqueleto” do conceito já estava ali…

Deto
Deto
Responder a  marckos
19 de Agosto de 2023 16:57

dificilmente se faz algo do “zero” hoje…

os aceleradores que a Nvidia tanto fala hoje eram as SPUs do Cell…

Juca
Juca
Responder a  marckos
19 de Agosto de 2023 18:32

Marckos, assim, a princípio, nada se cria do nada, a questão é como a releitura de ideias postas pode ser aplicada em conjunto ou em partes para criar novas lógicas de funcionamento das coisas ou o novos usos.

No caso em questão, a “revolução” apregoada por parte da Sony não está em ter simplesmente um SSD/RAM veloz, mas sim de implementar de forma racional, e porque não dizer econômica, diversos artifícios para tirar gargalos de uma sistema PC like, e a Sony não inovou só pelo “SSD/RAM” dela e sim por criar um I/O para compressão e descompressão indepenente e uma maneira de disponibilizar os dados tanto pra CPU quanto pra GPU, algo que apesar de parecer óbvio depois de já existir, não era tão óbvio assim no mundo do PC, já que ninguém implementou o antes da Sony, muito menos com sucesso. Ou seja, juntar várias ideias e princípios em uma nova ideia que resulte avanços não é simplesmente copiar é criar e melhorar as coisas.

Fora que ter ideias gerais e conceituais, não é o mesmo de executar as mesmas ideias gerais de maneira inovadora e de modo economicamente viável.

Alex
Alex
22 de Agosto de 2023 22:53

Na prática o sistema vram unificado e igual na Microsoftz o que muda é como o sistema operacional reserva cada espaço se memória.

Em ambos consoles temos a mesma abordagem, pois ambos são SoC AMD com implementação específica de cada empresa.

O que muda no caso do Play é o número de pistas/lanes do barramento do PCIx para acesso a disco, que deve usar xfat

No caso da Microsoft, muito provavelmente utilize volume e compressão NTFS.

Vale ressaltar que temos duas abordagem de uso de vram como ram, numa delas foi implementação de GDDRX6 e GDDR6 com reserva de memória de Maia clock e menos clock para jogo e sistema operacional

A Sony uso vulkan open GL e sistema operacional Unix Live já a Microsoft utiliza um Windows embarcado com directx.

Essa e a diferença das duas abordagens de console vs PC. Que ainda está na Ram DDDR5 e PCI5 ainda não é o padrão oara o barramento de disco para todos desktops. A grande maioria ainda usa PCI4.

Ainda temos a questão do tempo de acesso da memória e o clock, mas aí já foge do escopo do artigo.

error: Conteúdo protegido