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.
Ó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).
O sistema de I/O da Sony não pode ser implementado ao nível do GPU. Teria de ser feito na Motherboard.
Mas isso é complexo pois existe ali uma série de standard que não existem no PC, e a AMD não aparecia muito as tecnologias proprietárias. Aliás esse é o motivo porque não acompanha a NVidia, pois a AMD discorda da forma como eles só criam tecnologias proprietárias para uso exclusivo.
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:
?o=1
Homem… Os meus parabéns sinceros para dedicação.
Obrigado, Mário. Se quiser posso fazer uma versão do player para você testar no seu super PC … rs
Depois podemos ver isso se quiseres, só para perceberes as diferenças.
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 …
Lol… Viroses não… E nem nada parecido, hehehehe
Ó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!
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).
Bacanas essas implementações, Hildo!
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.
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
Lol… Tenho este artigo nos favoritos para ler e ver se faço um artigo… Mas isto tem estado complicado a nível de tempo.
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…
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.
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…
dificilmente se faz algo do “zero” hoje…
os aceleradores que a Nvidia tanto fala hoje eram as SPUs do Cell…
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.
A ideia do PC, presente nesse GPU da AMD era o GPU usar um SSD, que estava incorporado no GPU.
A Sony expandiu o conceito para ser usado por todo o sistema, acrescentando ainda tudo o resto para que o uso tivesse custo zero
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.
OMG… Parem lá com a comparação com os PCs. A PS5 tem diferenças a mais para isso.
O sistema VRAM unificado é igual em ambas as consolas. Mas isso não diz tudo. E a tua explicação sobre ele é demasiadamente simplista.
Os sistemas atuais possuem memória unificada. Mas memória unificada não é tudo. A Xbox 360 tinha memória unificada, mas o CPU não acedia aos dados do GPU e nem o contrário acontecia. Era apenas uma pool de ram comum a ambos os sistemas.
Para isso precisares de uma memória virtual unificada com coerência obtida por hardware. Isso é o que a AMD chama de hUMA.
Ambas as consolas possuem isso, mas apenas no que toca aos dados na RAM. No entanto, ainda há diferenças.
Tanto uma consola como a outra possuem caches no CPU e GPU, sendo que é aí, nessa memória ultra rápida que se dá o real processamento.
Quando a Xbox tem dados na cache de um dos processadores que requer uso pelo outro, tem de colocar esses dados na RAM para criar a coerência para eles serem entendidos pelo CPU. A PS5 não faz isso pois os seus motores de coerência permitem a transferência direta entre as caches ao criarem a coerência para o uso direto.
Só isto cria uma diferença enorme no uso da RAM unificada que não referes em cima.
Quanto ao PCIE, não te chamas Alex Bataglia, certo? 😉
A PS5 usa PCIe 4.0 no seu disco externo. Mas não usa qualquer PCIe no seu interno. O disco interno está inserido num sistema de I/O totalmente proprietário, pelo que o uso do termo PCIe deixa de ser válido, mesmo que se use o mesmo como válido.
O disco externo usa ex-fat, o interno usa um sistema de ficheiros proprietário da Sony e muito mais rápido. Para compensar estas diferenças, bem como os 6 cá aos de prioridade, o disco externo tem de ser mais rápido que o interno para garantir a paridade.
As Xbox series usam PCIe 4.
Quanto à questão da memória da X, a ressaltar a abordagem no uso da RAM terá de ser pela negativa.
Primeiro porque não existem duas memórias diferentes. É GDDR6 em tudo (não há cá GDDR6X), e não são duas pools de RAM fisicamente distintas. É a mesma RAM acedida por canais diferentes nos módulos de 1 GB e de 2 GB, o que permite aceder ao 1º GB em 1 modulos, e ao 2ª em 6 (são 19 modulos, 4 de 1 GB e 6 de 2 GB), criando o que cria tremendos problemas de performance por quebras de largura de banda quando acedidas em simultâneo.
A Xbox tem ainda check in nos processos de leitura, o que lhe rouba largura de banda. A PS5 não tem!
Depois a Sony não usa vulkan e nem Open GL. Usa um API proprietário de muito baixo nível desenvolvido pela ICE team e chamado AGN. O sistema operativo é o Orbis OS, baseado em FreeBSD, um sistema comparável ao UNIX, com as mesmas bases do UNIX.
Daí que na prática… Os sistemas são completamente diferentes. Possuem é semelhanças na forma como ambos abordaram os problemas, mas com soluções bem distintas e bem mais completas do lado da PS5.