Declarações recentes dão a entender que a configuração de memória da série X poderá ser bastante problemática com a manutenção da largura de banda. Daí que resolvemos analisar.
NOTA: Artigo alterado a 09/04/2020 e 10/04/2020 dada a presença de novos dados.
Honestamente quando ouvi que a Xbox tinha 10 GB de RAM a 560 GB/s e 5 GB a 336 GB/s, numa mistura de chips de 2 e de 1 GB não fiz qualquer conta para verificar como seria a configuração desta memória. Mas agora que a situação está a ser referido como potencialmente problemática debrucei-me um bocado sobre a mesma e que vi mostra que realmente poderemos estar aqui com uma situação que pode ser um gargalo às larguras de banda, e consequentemente às performances do GPU.
Ora quando pensei em 10 GB a 560 GB/s e 6 GB a 336 GB/s, o que imediatamente me veio à cabeça foi que a consola teria os seus chips de 2 GB, e os seus chips de 1 GB montados em canais com largura diferente. Mas a questão é que sendo a combinação chips de 2 GB e de 1 GB, para se conseguir essa combinação de memória só havia duas hipóteses:
5 chips de 2 GB + 6 chips de 1 GB – Totalizando 16 GB (10+6)
10 chips de 1 GB + 3 chips de 2 GB – Totalizando 16 GB (10+6).
O problema é que nenhuma destas configurações é possível! Porque tanto uma como outra estavam a usar um número ímpar de chips.
Olhando para mais dados, foi possível saber-se que a Xbox série X usa um total de 5 controladores de 64 bits cada um para gerir a memória. E assim sendo, a configuração fica um bocado estranha e acima de tudo limitativa.
5 controladores de 64 bits, permitem no máximo ligar 10 módulos de memória. Fui então pesquisar fotos da consola, para confirmar isso:
Como vemos a consola possui 3 módulos de cada lado e 4 módulos no topo. Um total de 10.
Dado que tanto o número de chips de 2 GB, como os de 1 GB tem de ser par, e o número de chips é apenas 10, a única solução que nos permite 10 GB + 6 GB usando módulos de 2 GB e de 1 GB implica o uso de 6 chips de 2 GB mais 4 chips de 1 GB.
Estranho, não é? Mais estranho vão achar quando virem o tipo de ligações a que isto obriga com 5 canais de 64 bits (320 bits). Note-se que a posição dos chips não é forçosamente esta, mas tal é irrelevante, sendo que por uma questão de organização até se acredita que seja.
E então como é que isto funciona? De uma forma extremamente incomum.
Para se conseguir os 560 GB/s, os chips de 2 GB são acedidos apenas pela metade. Ou seja, o primeiro 1 GB. Sendo no total 10 chips, ficamos com 10 GB, acedidos todos a 32 bits, ou seja, 10 GB num bus de 320 Bits (32+32+32+32+32+32+32+32+32), ou 560 GB/s (56 GB/s fornecido por cada módulo de memória GDDR 6 14 mbps).
E os restantes 6 GB? Acedendo ao GB adicional dos módulos de 2 GB.
Estamos então com um bus de 192 Bits (32+32+32+32+32+32), o que nos dá os referidos 336 GB/s. (56 GB/s*6 modulos)
Mas e então qual é o problema que existe aqui?
Se olharmos para os quatro módulos de 1 GB presentes no topo do Chip, vemos que eles estão apenas dedicados à pool de 10 GB (o termo pool não é o mais correcto para aqui, uma vez que não há separação física da memória, mas como simplifica muito a escrita irei usa-lo). Com estes 4 chips a debitar 56 GB/s cada um, eles sozinhos debitam uma largura de banda de 224 GB/s. Tomem nota deste valor.
Ora os módulos de 2 GB também debitam 56 GB/s cada um (e o serem de 2 GB não altera isso pois a largura de banda é por módulo, independentemente da capacidade, e esse é o motivo porque se usam mais módulos e não módulos maiores quando se quer largura de banda). O problema é que nos dois casos de cima temo-los a usar os canal de 32 bits na sua totalidade e a debitar os 56 GB/s para ambas as pools. E isso nunca acontecerá! Na realidade a largura de banda do módulo (56 GB/s) e os canais 32 bits que vemos nas imagem de cima são os mesmos para as duas pools. E assim sendo, na realidade o que ali está são valores teóricos máximo de cada uma delas. mas não os valores reais. Na pratica tanto os canais como a largura de banda serão divididos entre a pool de 10 GB e a pool de 6 GB.
Qual a largura de banda que temos então? Bem, estes 10 chips, ao debitarem 56 GB/s cada um, garantem ao sistema um total de 560 GB/s. E isso será o valor que teremos a qualquer altura. Mas a questão é que isso não acontecerá em cada uma das duas pools, mas sim na soma das duas.
Explicado de outra forma, ao dividirmos a largura de banda dos modulos de 2 GB pelas duas pools o que temos é que estamos a dividir 56 GB/s que cada um debita pelas duas partes da memória. Isto porque o canal é o mesmo.
Resumidamente a largura de banda de cada uma das pools é variável, consoante a utilização, sendo que quando se acede à memória lenta a largura de banda da memória rápida diminui.
Os casos extremos ocorrem então quando nem sequer se usam os 6 GB. Nesse caso a largura de banda disponível na pool dos 10 GB será 560 GB/s pois os chips de 2 GB debitarão a totalidade dos seus 56 GB/s para ela.
Mas com o uso dos 6 GB adicionais a largura de banda da pool de 10 GB diminui, pois os chips passarão a dividir a largura de banda pelas duas pools.
Esta é uma relação que pode chegar ao extremo onde se usam os 366 GB/s na pool de 6 GB, caso onde a pool de 10 GB ficará restrita a 244 GB/s.
Porque este valor de 244 GB/s? Bem, para além de ser a diferença para 560GB da largura de banda dos 6 GB, este é o valor debitado pelos quatro módulos de 1 GB que apenas trabalham na pool de 10 GB e que vos pedimos para tomarem nota em cima.
Resumidamente, o total das duas pools mantêm-se sempre inalterado e em 560 GB/s, mas a largura de banda de cada uma das pools altera conforme se usa ou não a outra.
Basicamente o que isto altera face a uma situação normal presente nos GPUs. Por exemplo, a PS5, apresenta 448 GB/s sem esta divisão, ou seja um valor constante em todos os 16 GB de RAM?
Mas aqui, como viram a largura de banda de cada pool e variável. E isso quer dizer que para manterem os 560 GB/s ou não podem usar os 6 GB adicionais de RAM, ou se os usarem tem de ler dados das duas pools em simultâneo usando a sua largura de banda ao máximo, de forma a que a soma das duas seja 560 GB/s.
E isto é extremamente complexo dado que o uso da RAM pelo CPU e GPU não é constante criando assim igualmente variações constantes na largura de banda de cada uma das duas pools.
Ora isto torna-se difícil de gerir dado que para se manter uma largura de banda elevada há que se ler dados das duas pools em simultâneo. Mas sendo o débito de cada uma variável, torna-se difícil fixar as velocidades de transferência.
Por outras palavras, manter os 560 GB/s estáveis é um problema!
Para que se perceba como a situação varia nos casos intermédios, vamos acrescentar alguns dados novos.
Na realidade, a GDDR6 fornece dados a 16 bits, tendo dois canais de ligação com esta capacidade. Isso quer dizer que os canais acima referenciados como 32 bits são na realidade 2 canais de 16 bits. Uma situação que nada altera a questão dos módulos de 1 GB, mas altera a questão dos módulos de 2 GB, ao permitir aceder aos 10 GB em simultâneo com os 6 GB.
Assim a esquemática passará a ser a seguinte:
Estes dois canais de 16 bits ora acederão os dois ao 1 GB inicial, fornecendo este esquema já referido:
Ora acederão os dois aos 6 GB, fornecendo o restante esquema já referido:
Mas numa situação normal, com acesso a ambas as memórias, o esquema será então o de baixo:
Aqui os 4 módulos de 1 GB de cima debitarão sempre 224 GB/s fixos para a pool de 10 GB, mas os módulos de 2 GB debitariam a sua largura de banda de forma dividida para ambas as pools, ou seja 28 GB/s máximo para cada uma.
Consequências disto? Bem, a realidade é que ao existir acesso à memória superior, independentemente da largura de banda que se puxe, há 6 canais de 16 bits que são desviados para lá, e que vão roubar largura de banda à memória rápida. Sendo que os 6 GB vão alojar o sistema operativo, os acessos, mesmo que baixos vão existir, pelo que garantidamente o que os programadores podem contar como fixo são 392 GB na pool de 10 GB, e 168 GB/s na de 6 GB. Ou seja, os 560 GB/s são apenas o valor teórico na pool rápida, sendo na realidade o valor total das duas pools.
No fundo, não é uma solução ideal a nível de largura de banda, pois essa só existe se não se usarem os 6 GB, mas pelo menos com estes valores sabe-se com o que se contar a cada momento. Diga-se que o outro caso intermédio aconteceria se as solicitações aos 6 GB ultrapassassem os 168 GB/s, o que obrigaria a que a totalidade dos canais 16 bits fossem desviados para aí, deixando os 10 GB com apenas 244 GB/s. Mas dado que esta memória é usada pelo sistema operativo que tem poucas exigências, só deixando 2.5 GB a uso para os jogos, é praticamente impensável que se passe alguma vez os 168 GB/s, pelo que o caso de cima com 392 GB/s e 168 GB/s deverá ser mesmo o mais comum.
Seja como for, nesta fase é muito cedo para se perceber se isto poderá se revelar como um gargalo na memória ou não (daí o título ser uma interrogação), mas há muitos indícios que apontam que sim.
O mais forte de todos eles é que que esta solução da Microsoft não é novidade! A Nvidia já a usou nas sua Geforce 650 Ti e 660 Ti, e os resultados quando a memória mais lenta entrava a uso (que na altura era uma percentagem bem menor da total) eram extremamente penalizadores na performance. A largura de banda caia tremendamente e a placa sofria, tal como aqui é referido.
Ora aqui nesta caso estamos perante a mesma situação, mas com duas diferenças. É que a memória afectada é significativa face à memória total, pelo que dificilmente ela não será usada. e dado que o sistema operativo vai ficar nos 6 GB, mesmo que os acessos a esta ram aconteçam pontualmente, quando acontecerem a largura de banda dos 10 GB cai para 392 GB/s, e como tal, para que não hajam engasgos súbitos nos jogos, esse será o valor garantido com que se pode contar.
Nesse sentido prevê-se aqui um problema, um gargalo nas performances. Mas não se querendo ser bitaiteiro, e reconhecendo-se que não se conhece ainda tudo sobre as consolas, não vamos afirmar que ele existe. Quem sabe a Microsoft não implementou algum tipo de gestão que resolve este problema?
Daí que a questão fica como uma interrogação e serve o artigo para introdução ao tema. Se um dia esta situação se revelar relevante, retomaremos esta conversa.