Os dados sobre o Xbox Velocity Architecture sempre foram escassos, mas agora o canal XboxBR refere uma esquemática que, não sabendo se é realmente correcta, revela algo que mostra como este SSD funciona e como o Sampler Feedback Streaming pode operar, maximizando performances.
Quando falamos do SSD da PS5, falamos dos cache scrubbers, motores de coerência, canais DMA, e toda uma série de situações hardware que libertam o CPU a 100% e que nos levam a perceber que houve ali melhorias substanciais face ao que existe num sistema de I/O standard, e que permitem o uso de todo o disco como sendo memória virtual.
Já quando se fala do Xbox Velocity Engine, fala-se em 100 GB de memória virtual, um novo software chamado Direct Storage que melhora bastante a questão do uso do CPU, mas que mesmo assim ainda usa 1/10 de um núcleo, e o Sampler Feedback Streaming, uma tecnologia no GPU que permite definir que parte efectiva das texturas são precisas, evitando transferências desnecessárias, e maximinado assim as transferências do SSD e o uso da memória, num factor que a Microsoft anuncia ser de 2 a 3 vezes.
Ora aqui na PCManias nunca minimizamos este sistema, mas o certo é que o mesmo nunca teve a atenção que demos ao SSD da Sony, e o principal motivo era o não sabermos, e nem sequer saltar à vista por total falta de dados, pormenores sobre como todo ele funcionava.
Por exemplo, no sampler feedback streaming sempre nos questionamos como é que era possível extrair-se parte de uma textura se a textura estava comprimida. Numa analogia esta situação seria o mesmo que se ter uma máquina de contar moedas, com dinheiro armazenado em notas. Ora da mesma maneira que para contarmos moedas tínhamos de destrocar o dinheiro, aqui era necessário ler-se a textura toda, descomprimi-la e só então, extrair a parte necessária. E isto matava toda a questão do ganho na quantidade de dados transferidos referido pela Microsoft na parte do SSD pois este tinha de transferir a textura na mesma.
Mas recentemente o canal youtube XboxBR colocou uma esquemática que procura explicar como funciona este sistema. Foi a primeira esquemática que vimos sobre este assunto, e diga-se que a informação sobre a Xbox está longe de ser tão abundante como a da PS5, algo que qualquer website de tecnologia vos dirá.
O que ali foi mostrado e explicado estava confuso. O diagrama usado misturava blocos de software com blocos de hardware, colocava o Sampler feedback como algo fora do GPU, colocava o CPU a aceder ao Direct Storage que é um software que está na RAM, num bloco que estava fora da RAM… enfim… confuso!
Mas de qualquer maneira penso que conseguiram passar a imagem. E caso o que entendi esteja correcto, o Velocity Engine da Xbox não é exactamente algo de se desprezar. É algo bastante eficaz e uma excelente melhoria face ao que existe no PC.
Ora este artigo serve para que possa tentar passar aquilo que compreendi da explicação, mas usando agora um diagrama meu, que entendo como sendo mais correcto. Aqui vai ele:
Legenda:
A verde – Disco SSD dividido em duas partes – 900 GB armazenamento, 100 GB de memória virtual.
A verde escuro – Bloco compressor/descompressor
A amarelo – CPU
A Cinza escuro – 10/de 1 núcleo dedicado ao Direct Storage
A azul – Ram dedicada ao OS
A roxo – Memória RAM disponível
A azul esverdeado – GPU
A bordeaux – Samspler Feedback Streaming e ID Buffers
A laranja – Comunicação entre Bloco compressor/descompressor e RAM
A azul escuro – Comunicação do CPU com o Direct Streaming
A preto – Comunicação do CPU com a RAM e o OS
A rosa – Comunicação da memória vistual com o SFS para fornecimento das texturas descomprimidas.
Nota: Estes canais de comunicação não representam canais dedicados reais, mas apenas a existência de comunicação.
À nossa esquerda, a verde, temos o SSD NVME de 1 TB. Este SSD terá, aparentemente, 100 GB reservados, deixando assim livres 900 GB para os jogos. Esses 100 GB são parte do Velocity Engine, e serão sujeitos a leituras e escritas com dados dos jogos presentes no disco.
Essa situação é aliás a que nos deixa mais dúvidas sobre como funcionará a alocação desse espaço. Será que cada jogo tem acesso aos 100 GB e descomprime a cada vez que se executa dados para lá? Será que só tem acesso a parte, dependendo do número de jogos abertos, mas descomprime a cada vez que o jogo se executa dados para lá? Ou será que funciona de outra forma?
Ora o que nos faz acreditar que não estaremos perante nenhum dos casos de cima é o desgaste que escritas constantes a cada sessão de jogo poderiam criar no SSD. Mark Cerny analisou se 825 GB seriam suficientes analisando o desgaste do SSD com instalações diversas. E agora a Microsoft deixa apenas mais 75 GB que o disco da PS5, mas não se preocupa com o desgaste dando um uso de escrita regular aos 100 GB reservados, algo que não é exactamente saudável num SSD?
Antes de abordarmos essa resposta vamos explicar porque motivo esses 100 GB são sujeitos a escrita, explicando um pouco o diagrama de cima!
Bem, segundo a explicação, o Velocity Architecture lê os dados comprimidos dos 900 GB onde os jogos estão armazenados e comprimidos pelo Zlib e BCPack. Esses dados são pedidos pelo CPU, que tem 1/10 de um núcleo dedicado ao Direct Storage, ao OS, que inclui o novo API Direct Storage,s endo o pedido transmitido ao SSD para a entrega do necessário que é então tratado pelo bloco de compressão/descompressão por hardware, sendo remetido directamente à RAM, ou à memória virtual de 100 GB presentes no SSD.
Esta recepção de dados descomprimidos obriga a que o SSD escreva os dados. E essa é uma situação que é negativa no aspecto que sujeita essa parte do disco a um elevado desgaste. Como já referimos, Mark Cerny preocupava-se com as instalações, mas aqui a Microsoft não se preocupa com escritas a cada arranque de um jogo? É no mínimo estranho, não?
Olhando para trás, vimos este canal (ou pelo menos era o mesmo senhor), a explicar como funciona a memória da Xbox. Mas curiosamente, na sua explicação, este passou ao lado da situação que aqui abordamos e que poderá causar gargalos na largura de banda da consola. Será que foi lapso, conveniência, ou outro motivo? Não sabemos, mas o certo é que se quem tem acesso à informação não aborda as partes menos convenientes, o mesmo pode estar a acontecer aqui também. E esta poderá ser uma informação que não é conveniente dizer-se!
Mas não acreditando que a Microsoft tenha sequer pensado em sujeitar o disco a tal desgaste, acreditamos que os 100 GB de memória virtual terão uma alocação por jogo limitada e com escritas apenas a ocorrerem uma vez.
Vamos explicar:
Basicamente, por cada 9 GB de armazenamento que um jogo ocupe, este verá atribuído 1.1 GB de espaço nesses 100 GB onde poderá descomprimir dados para serem usados como memória virtual. Estes dados são seleccionados, e escrevem-se apenas uma vez, ou pelo menos um número limitado de vezes, ficando os dados ali, mesmo que a sessão de jogo termine, só sendo apagados se o jogo que lhes deu origem a esses dados for apagado do disco.
Basicamente, o que nos quer parecer é que, dependendo do tamanho do jogo no disco, são atribuidos uns GB extra nessa memória virtual onde se descomprimem algumas texturas, para cada jogo. Mas não nos parece coerente que este espaço tenha um uso à descrição, pois tal obrigaria a escritas e re-escritas constantes vindas dos vários jogos que não nos parece que aconteçam. Ou seja, quer-nos parecer que os 100 GB são um espaço a dividir por todos os jogos, não algo que cada um deles possa usar livremente!
Seja como for, esta memória virtual conteria texturas descomprimidas. E isso explica como pode então funcionar o Sampler Feedback Streaming.
As texturas estando no disco devidamente descomprimidas, já se compreende como é que o SFS pode pedir a parte correspondente sem a necessidade de se transferir a textura toda comprimida, descomprimir, e seleccionar a parte. Elas já estão descomprimidas, só não estão é na RAM, estão no SSD, na chamada memória virtual. E desta forma, esta memória virtual transfere os dados apenas relevantes da textura que o SFS identificou, para a RAM do GPU.
Esta situação liberta o SSD de transferências mais pesadas, podendo efectivamente aumentar a sua capacidade de transferência, e liberta a RAM que não tem de recepcionar a textura toda seleccionando apenas a parte relevante e descartando o resto.
No entanto, sendo esta uma transferência do SSD que pode assim ser optimizada, nas taxas de 2 e 3 vezes, conforme a Microsoft refere, e de acordo com a dimensão da parte da textura necessária, este ganho limitar-se-à às texturas ali colocadas, e sendo o espaço, muito certamente 1,1 GB por cada 9 GB usados, um jogo com 100 GB de ocupação de disco só terá 12,2 GB de disco atribuído para as texturas da totalidade do jogo, o que faz com que este ganho de performance, mesmo que existente, seja altamente limitado. A alternativa a isso não acontecer é realmente o uso deste espaço ser dinâmico e usado de acordo com as necessidades do jogo. Tal permitiria que esses ganhos fossem reais e constantes, mas como já referimos, cria aqui uma situação de durabilidade do SSD que faria escritas constantes durante o uso da consola.
Sinceramente, quando vemos uma empresa a preocupar-se com a durabilidade da sua consola pelo eventual número de instalações. Ver a outra a apresentar um espaço útil que será semelhante, e a promover o desgaste do disco, é um aparente claro e total contra senso. Sabendo que há jogadores que jogam horas sem fim, o que poderemos esperar da fiabilidade do SSD num período de 8 anos, quando este está constantemente a escrever?
Não é credível. E não o é por outro motivo, porque o SSD ao ter de escrever não debitaria a mesma coisa a ler. Porque estaria ocupado com as duas coisas. E assim sendo as vantagens trazidas pelo SFS perdiam-se pelo facto que o SSD teria de descer a sua velocidade útil de leitura.
Mas mudando de assunto, esta configuração levanta-nos uma outra questão. E esta poderá ser favorável à consola. É que teoricamente, e aqui não sabemos se isso acontece, uma vez que não há referência a motores de coerência na consola, os dados ao serem descomprimidos e colocados no disco, podem eventualmente ser já alterados de forma a evitar, pelo menos parte, do processo de check-in. Tal como acontece na PS5.
Recorde-se que o processo de check-in engloba duas fases.
- Fase 1 – Após a recepção dos dados na memória, eles são ligeiramente alterados para poderem ser usados na RAM.
- Fase 2- Os dados são movidos para o endereço final na RAM, onde ficarão e serão usados durante o jogo.
Basicamente, quer-nos parecer que, dado que a Microsoft chama a esses 100 GB uma memória virtual, teoricamente a Fase 1 do Check in pode ocorrer já aqui, sendo os dados guardados como se já estivessem na memória.
Note-se porém que esta parte já é especulação da nossa parte, sendo que, mesmo que o processo de check-in seja evitado na parte da alteração dos dados, não o é na parte de movimentação para o endereçamento final, sendo assim expectável que os dados a necessitem ainda de serem movidos uma vez na RAM para a posição final devidamente indexada.
Ou seja, apesar de tal não estar confirmado, a Microsoft pode ter aqui uma forma de passar à frente um pedaço do processo de check-in, apesar que não se liberta dele todo, e não liberta o CPU de ser ele a fazê-lo. No entanto, sobre esta possibilidade, estamos a teorizar pois não há elementos que nos permitam dizer isto com certeza. Mas o facto de os dados estarem descomprimidos numa parte do SSD que até é denominada como “memória virtual”, teóricamente aparente que poderia permitir a criação dessa situação. Mas se realmente tal é possível e se a Microsoft o faz ou não, é outra história.
Daí que, nesse campo, deixa-se a situação em aberto pois, como sempre dissemos, não se conhece ainda tudo sobre as consolas, e este diagrama que somente agora apareceu, é um bom exemplo disso.
Acima de tudo o que este diagrama nos mostra é que a Microsoft criou aqui um esquema que, apesar de relativamente simples, efectivamente pode melhorar as performances do seu SSD. No seu global a coisa ainda aparenta ficar a muita distância do que foi feito na PS5, e é certamente mais penalizador na durabilidade do SSD, mas o certo é que a Xbox mostra, pela primeira vez, como realmente funciona a Velocity Architecture, algo que até agora era uma incógnita e levava a questionar os reais ganhos do Sampler Feedback streaming, que agora se percebem como podem efectivamente existir.