Após diálogo com alguns programadores em foruns e blogs, o consenso geral é que o problema existe e não tem uma solução standard. Mas pode ser minimizado!
Desde que publiquei o artigo sobre a memória da Xbox que a dúvida me ficou no ar. O gargalo parece evidente, mas será que ele se revelará um problema? Será que ele prejudica assim tanto a Xbox, ou a situação será mínima ao ponto de ele não ser um problema?
Bem, foi isso que tentei saber, e foi isso que soube. O problema existe, está lá, ocorrerá como descrito, e vai pesar sempre, mas dependendo da forma como se aborda o mesmo, a penalização poderá ser maior ou menor.
Qual a melhor forma então de se minimizar isto?
Bem, basicamente a coisa está ainda em ponderação, mas uma das formas mais simples foi a resposta preponderante: Basicamente os dados deverão ser tratados segundo ordens de prioridade, sendo que os de menor prioridade deverão ser guardados na RAM lenta.
Mesmo aí, quando necessários, eles não devem ser processador na memória lenta. Basicamente dever-se-à mover os dados para a memória rápida o mais rápido possível, e processa-los aí. A ideia é minimizar ao máximo os acessos à memória lenta, de forma a se evitar ao máximo a penalização causada pelo seu acesso.
Ora se na situação analisada no nosso artigo, o que prevíamos era um acesso intercalado e assíncrono a ambas as memórias, o que resultaria na divisão da largura de banda entre as duas pools, sendo o mais esperado 392 GB/s na memória rápida e 168 GB/s na memória lenta, neste caso o acesso às memórias partilhada deixaria de ser simultâneo e passaríamos a fazê-lo de forma dedicada para obter a maior velocidade e fazer a transferência o mais rápido possível.
Basicamente se no caso anterior a ideia era somar as larguras de banda de ambas as pools, aqui a ideia é fugir ao máximo à segundo pool, usando-a apenas para armazenar dados e transferi-los para a pool mais rápida, em acessos de muito curta duração.
O problema da divisão da largura de banda não deixaria de ocorrer, isso é uma inevitabilidade, mas ao se minimizar o acesso aos 6 GB, a largura de banda acaba por ser optimizada.
Basicamente estaríamos o máximo de tempo possível na Pool de 560 GB/s, podendo usufruir dela sem qualquer divisão!
Agora o preço a pagar existe. Quando fosse preciso aceder aos 6 GB, essa largura de banda era cortada para 244 GB/s ou 392 GB/s dependendo do tipo de acesso. Seriam situações pontuais, mas que mesmo assim poderão ter efeito nas performances, até porque o corte é muito grande.
No entanto com a devida preparação e antecipação das necessidades dos acessos, será possível minimizar este impacto de forma a não ser sentido.
Por outras palavras, basicamente não poderemos ainda responder à questão sobre se esta situação se tornará um gargalo ou não, mas ficamos a saber que há já técnicas previstas para se superar o problema. A real qualidade dessa implementação, iremos vê-la apenas no futuro. No entanto, dado que os jogos iniciais terão como base o denominador comum Xbox One, esta situação dará muito tempo aos programadores para experimentarem técnicas de mitigação antes de explorarem a consola a 100%, e nesse aspecto prevê-se que quando isso acontecer o problema possa estar minimizado ao máximo.
Basicamente, tal como como quando expusemos o problema da eSRAM da Xbox One, referimos que a situação poderia ser minimizada e até ultrapassada, explicando como. Claro que isso teria sempre custos, pois são realidades físicas, mas como se viu a correcção existiu e a situação melhorou e muito.
Nesse sentido, achamos de relevo expor aqui igualmente a solução que se prevê usar para esta situação da memória da XsX. A coisa terá sempre um custo nas performances, mas o que se prevê é que hajam soluções que não impedirão a solução de funcionar de forma eficiente.
A memória lenta poderá ser para o Software da Xbox SX e o restante para o som e coisas mais leves.
O segredo do uso está no trocar o conteúdo da memória lenta com a rápida antes de processar. Processar na RAM é algo que se mantem no tempo, pelo que fazê-lo aí corta a largura de banda da outra memória.
Trocar o conteúdo só obriga a mover 2.5 GB no máximo, o que é feito muito rápidamente
É, isso confirma o que o engenheiro da cryteck falou e também a maioria dos desenvolvedores.
Para ver só como funciona o FUD mantido pela galerinha do discord/xbox.
Quando esse assunto aparece no resetera/neogaf sempre é um fã do xbox afirmando que tem gargalo na RAM do PS5.
PS: Lockhart com 10GB de ram?
Se isso for verdade, está explicado o gargalo!
A Microsoft acredita que se safa só com 10 GB dado o SSD e o Sampler Feedback Streaming. Daí que optou por aquela solução!
Basicamente ao trabalhares com texturas de menor resolução os 10 GB chegarão… a questão é que isso é muito limitativo. São só mais 2 GB que a geração anterior.
Eu continuo achando estranho essa solução de RAM do SX… Se fosse 20GB GDDR6 ai seria um pool único de memória com 560GB/s de banda?
Sim, seria
talvez o sx deveria ter 20GB 560GB/s unificados com SSD mais lento originalmente.
Viram que os desenvolvedores estava empolgados com o PS5, e nos multis o xbox iria ser prejudicado, talvez até jogos third saindo somente no PS5, igual saiam somente no ps1 por causa do CD, resolveram cortar na RAM e aumentar o SSD pq o BOM já estava em ~*550USD.
* e não, não vejo como o SX pode ter o mesmo BOM do xoneX para sair por 500USD… Resta ver como o PS5 é para ter uma ideia se a diferença de preço vai ser 10~100 USD de BOM.
ou o lockhart é 10GB 560GB/s.
lembro dos boatos que a MS estava com os devkits atrasados e uma semana depois o Phill Spencer começou a falar no twitter que ele já estava com o sx em casa jogando. Se não fosse verdade, não precisava de controle de danos igual o “acabou o cheque em branco do xbox” que o zhuge falou, dois dias depois o phill spencer correu “desmentir” no twitter.
jornalista “que cobre somente Microsoft” correu no twitter dizer que não era devkit atrasado pq a MS estava correndo atras do que a Sony tinha definido, e sim “master plan” para surpreender a Sony.
Já que tivemos tanto esforço de fãs da marca para espalhar FUD de “PS5 bomba, feito no oba oba para correr atras da pioneira absoluta MS”, se eu tivesse um produto com gargalos que foi feito como reação a concorrência, e conhecido por fazer FUD, primeira coisa que eu iria fazer é acusar a concorrencia de ser isso
Vamos lá ver uma coisa. A X tem um gargalo na largura de banda devido à configuração de memória.
Que solução há para isso?
Trabalhar com 10 GB, usando o resto basicamente para armazenar dados de pouco acesso.
Este tipo de solução requer a criação de níveis de prioridade na ram, uma solução que não pode ser implementada se tiveres outra consola com uma configuração de memória diferente.
Daí que a existir uma lockhart ela terá 10 GB, pois esse é o pool rápido. Não precisa de ser 10 chips de 1 GB, num bus de 320 bits (560 GB/s) mas tem de ser 10 GB.
Se não for 10 GB não sei como se supera esta limitação de memória. (Eventualmente posso não a estar a ver agora).
Mario, da uma olhada nesse post:
https://www.neogaf.com/threads/next-gen-ps5-xsx-ot-speculation-analysis-leaks-thread.1480978/page-1744#post-257820795
Especulações… a única info real nesse vídeo são dois pontos ainda a confirmar:
– O controlador da PS5 é feito pela Marvel
– A diferença real entre as duas consolas é 8%.
Estava ontem a jogar the witcher 3 novamente e a imaginar como a nova geração vai conseguir fazer com que esse jogo pareça ultrapassado.
Fico a imaginar esse mundo ainda mais vivo, com npcs mais independentes e sem loadings!
Como eu tenho dito sempre, as duas consolas vão permitir uma infinidade de melhorias.
Os grandes desenvolvedores vão conseguir fazer magia!
O the witcher 3 é de 2015. E ainda é impressionante o que a CD project Red conseguiu nesse jogo.
Acredito que teremos jogos fascinantes num futuro bem próximo!
Eu tô jogando ele no One Fat, e sinceramente a mim já parece datado perante os últimos openworlds que pude jogar como RDR2, Assassins Oddyssey e Days Gone. Foi um jogo espetacular pra 2015/2016, mas hj perdeu muito do seu brilho no aspecto técnico, ao menos pra mim
Eu respeito a sua opinião e concordo que os jogos que vc citou são bons exemplos de open world.
Mas o the witcher 3 para mim é excepcional pelo conjunto.
Roteiro, jogabilidade, mundo, gráficos.
É um dos meus preferidos.
Pelo conjunto eu concordo que ele está entre os melhores jogos de todos os tempos
Que o 4 venha pra quebrar tudo igual fez o 3
Graficamente está mais que ultrapassado. Em termos de mecânicas também.
Mas continua a ser um jogo muito equilibrado em termos de mundo aberto.
Olá Felipe Leite, pode me tirar só uma dúvida: eu começei semana passada a jogar The Wicther 3 pela primeira vez na minha vida, O jogo é absurdamente doentio no nível dos detalhes, em que nível vc fechou a campanha? quanto tempo leva para terminar este jogo? Grato.
Oi David, me permita responder também =D eu demorei para terminar bem umas 80h fazendo tudo que tem no jogo sem contar as DLc’s, mas não lembro o nível que terminei, agora um aviso que para mim é o maior erro de The Witcher cuidado ao fazer quest’s, side quest’s e contratos pois the witcher só deixa você ganhar a experiência completa se você estiver no máximo 5 níveis acima do level da missão, caso contrário você vai receber bem menos experiência quando completar.
Olá Daniel Torres, muito obrigado, estou seguindo a sugestão do jogo de fazer as quests no nível recomendado, eu passo mais tempo estudando os tutoriais, bestiário, documentos, tentando descobrir como melhorar e construir itens do que propriamente jogando, minha primeira experiencia com um RPG e, meu Deus, haja perseverância, que jogo complexo!
Ao custo de 6GB?
Ficaria o XSX neste cenário com menos memória que o One X, mais rápida, mas mesmo assim menos. E frente ao PS5 a situação seria ainda pior visto que este terá ao menos 13GB só pros jogos, de toda forma, a mim parece estranho os “erros” da Microsoft quanto a RAM e SSD quando comparado ao concorrente, lógico, eles tem acertos na APU, mas isso mostra que o projeto do XSX não é tão perfeito com muitos apontavam, “A 8 maravilha do mundo”. E com isso a balança é novamente reequilibrada
Quais erros???? a internet é aquele lugar onde até os burros são doutorados em astrofisica…a XBOX series X foi PROJECTADA assim para diminuir os custos, não foi um tumor que apareceu na memória e que a fez ficar lenta não…os projectistas da MIcrosoft colocaram deliberadamente memória a duas velocidades e testaram essa e outras soluções até que escolheram esta que tu vês e que eles acharam que era o melhor compromisso entre valor e desempenho…o fato de ter muita genta na NET a dizer que é um defeito não significa que seja verdade…deixa a consola sair e depois de os especialistas analizar é que podes deizer se foi erro ou não….
E em streaming de videojogos… nao te esquecas dos burros doutorados em streaming de videojogos, que afirmam aos 4 ventos que o streaming vai revolucionar a maneira como se jogam jogos multijogador online.
Geforce 650 TI… Mesma configuração!
Quanto aos resultados procura por ti mesmo!
PS: Perdeste a postagem livre a partir do momento que acusas-te o site noutro post!
Se não estás bem aqui, se não gostas do que se posta aqui… muda-te!
Eu como leigo, creio que esses caras não iriam cometer erros assim. Deve ter alguma tecnologia que nós ainda desconhecemos deles, pois esses consoles hj são projetados com opiniões de programadores de seus estúdios primários e de terceiros e caso o xbox seja assim, os programadores concordaram com isso de alguma forma, dando aval a empresa nisso. Eu não creio que terão essa falha, mas como disse, sou leigo!
Edson você não deixa de ter uma certa razão. Mas o que falta você considerar no seu raciocínio é o fator custo. As empresas buscam soluções para atingir o melhor desempenho dentro de determinado custo. E essas soluções podem funcionar “melhor ou pior”. Não fosse assim bastava colocar 16GB de memória rápida!
Na realidade ninguem entende muito bem o que levou a Microsoft a optar por esta configuração. Os 448 GB/s num bus de 256 bits eram menos problemáticos. Esta solução permite, com a devida gestão aumentar a largura de banda, mas a realidade é que ela nunca será 560 GB efectivos, e pode até ser problemática e revelar-se pior que os 448 GB/s.
Daí que a ideia geral é que das duas uma:
1 – A Microsoft ponderou 20 GB na X e esta solução com 16 GB era para a Lockhart, sendo que depois por isso ser caro cortaria para 16 na x e 10 na lockhart
2 – A Microsoft pensou em 10 GB para a Lockhart e 16 para a X. Daí que o processamento base se vai fazer nos 10 GB, e os 6 GB adicionais seriam apenas para armazenamento.
Em qualquer dos casos, a Lockhart aparece com 10… daí que quando o Detto falou em 10 GB na Lockhart não me surpreendeu pois isso já se falava como explicação a isto!
Mas o HBCC não ajuda a passar estes problemas?
Lembro-me que chegamos a falar de 8 GB de memória ultrarapida mais DDR4 mais o SSD como scratchpad.
Não… não passa!
O que o HBCC faz é permitir ver duas pools como uma só.
Mas aqui problema não é esse!
Aqui o problema é que o assincronismo obriga a que toda a memória seja absolutamente igual, pelo que tens de aceder a 10 GB + 6 GB!
E é por esse motivo que a Microsoft os refere. Se o HBCC resolvesse isso, eles nem os referiam.
E não resolve porque aqui os controladores para os 10 GB e para os 6 GB são os mesmos pois a memória é a mesma. Ao contrário do caso de 8 GGDR + 4 DDR4, oned cada memória tinha os seus próprios controladores.
E isso tem como implicação que se ocupas um canal a aceder à parte superior da memória, ele deixa de estar acessível para aceder à parte inferior da memória (e vice-versa).
Imagina a coisa assim.
Tens copos de água, todos iguais e duas palhetas a aceder a cada um. Mas depois tens alguns copos onde a capacidade é o dobro.
Para a coisa funcionar, esses copos do dobro são na realidade 1+1 copo, ou seja um copo sobre outro igual.
A questão é que as palhetas são na mesma duas. Se acedes com as duas ao copo de baixo tiras a largura de banda toda, mas se uma delas tiver de se deslocar para o copo de cima, vais dividir o fluxo. No global ele é o mesmo, ou seja a agua que puxas sai sempre a mesma, mas o que puxas de cada parte é diferente.
E esse é o problema. é que para teres a agua toda ao máximo metes as 20 palhas nos copos de baixo. O que dá 560 litros. Se quiseres puxar dos copos de cima, moves 6 palhetas para os de cima, o que dá 392 litros a virem de baixo e 168 a virem dos de cima. Ou se quiseres o máximo dos de cima, metes 12 palhetas em cima, o que dá 244 litros vindos de baixo e 366 litros vindos de cima.
Ou seja, tens sempre 560 litros, o que não tens é um acesso garantido a um conjunto de copos que te forneça 560 litros.
Eu sei que isto pode ser confuso, mas em vez de água pensa em M&Ms… Tu queres sacar 550 M&M vermelhos, e 10 amarelos, mas os vermelhos estão todos no copo de baixo e os amarelos nos de cima.
Ora tu podes puxar os 550 do copo de baixo se meteres lá as palhetas todas, mas não puxas os 10 amarelos de cima. Ou podes puxar os 10 amarelos de cima se meteres lá as 6 palhetas, mas aí só puxas 392 dos vermelhos.
A quantidade global é teóricamente a mesma, mas como o exemplo te mostra, na prática a coisa não é bem assim, e há um corte nas larguras de banda. Mesmo minimizada ao máximo, ela nunca vai ser 560 GB/s constantes. E isso quer dizer que os programadores não podem contar com ela, sob pena de terem abrandamentos de performance.
https://www.pcmanias.com/segredos-da-ps5-desvendados-parte-3/
Eram apenas rumores iniciais, mas aqui discutiu-se muito sobre o HBCC e as vantagens que traria, podendo mesmo dispensar uma grande quantidade de memoria rapida.
Tinha nocao que o HBCC era uma evolucao dos move engines da ONE e permitia fazer a gestao dos dados entre memorias, com base na prioridade. Parece aplicar-se esta situacao, permitindo a gestao em background sem muito impacto.
Outra coisa que tem sido tocada, tem a haver com o lag do CPU e em possiveis vantagens da mais lenta ao permitir menos lag.
Eu nao entendo muito bem o conceito de memoria assincrona, mas um hipotetico cenario seria os 6 GB serem acedidos pelo CPU e SO alternadamente com o acesso aos 10 GB pelo GPU. Se a MS incluiu um sistema que permite gerir isto automaticamente, teras as duas a serem geridas sem muito problema.
O acesso alternado pode liberar os canais e tens a maxima bandwith em cada cesso ou nao?
A questão do sincrona ou assincrona só tem a ver com timmings de resposta. Aqui o relevante é perceberes como isto funciona.
Imagina um HDD a debitar 50 MB/s.
Lês um ficheiro gravando sequencialmente com 50 MB. Quanto tempo demoram os dados a chegar? 1 Segundo.
Agora colocas um segundo disco. Pedes um ficheiro de 50 MB a um e outro de 50 MB a outro. Quanto tempo demoram a chegar. 1 segundo!
Mas apesar de o tempo se ter mantido e teres demorado o mesmo a obter a informação, cada ficheiro demorou por sí tambem 1 segundo.
Ou seja, transferiste 100 MB em 1 segundo, mas transferiste 50 MB em 1 segundo.
Será que podes dizer que a velocidade de leitura é 100 MB/s?
Não! É 50+50!
Em que casos é que é 100 MB?
Se fizesses um raid 0 aos discos. Dois discos exactamente iguais, com a mesma capacidade, com a mesma velocidade. 100% iguais!
Metes metade dos primeiros 50 MB em cada um (25 MB em cada), e metade dos segundos 50 MB em cada (25 MB em cada).
Agora quando leres, vais receber os 100 MB em 1 segundo, mas os 50 MB em meio segundo (porque cada disco só leu 25).
Agora sim, tens 100 MB/s.
E este principio é que te permite somar as velocidades, ou larguras de banda.
Neste caso a Xbox usa 10 chips com 1 GB cada um (na realidade 6 deles são de 2 GB, mas o GB superior é ignorado). E grava a informação distribuida por todos. Assim quando lê, o que tens são 56 GB/s de cada módulo x 10 módulos. Os 560 GB/s.
O mesmo se passa quando acedes aos GB superiores. São 6, cada um a debitar 56 GB, o que dá 336 GB/s.
Nota que cada módulo tem dois canais de 16 bits, cada um ligado a metade da capacidade do módulo. Mas isso não impede que o canal ligado ao GB superior aceda aos dados do GB inferior, e vice versa. Se isso acontecesse, nunca terias 320 bits nos 10 GB inferiores.
Agora o que acontece é que cada módulo debita 56 GB, e cada um dos canais vai levar 28 desses GB.
O que quer dizer que se há um acesso à memória superior, vais ter pelo menos 6 canais de 16 bits a activar essa ram, o que vai roubar 168 GB/s à outra.
Isto não há como se escapar. A Microsoft não inventou a pólvora aqui. Estás configurações sempre foram possíveis, mas não se revelam vantajosas, e por isso não são usadas.
Se a Microsoft as usou é porque acredita que os 6 GB superiores podem ser usadas para situações pouco relevantes. E ela nunca imporia está limitação face a uma PS5 que não a tem, a não ser que haja outro produto que lhes forre as costas. A Lockhart com 10 GB de RAM?
E limitando o uso de RAM da nova geração a 10 GB para se suportar esta consola, os 6 GB seguintes são um extra secundário.
Por isso é que refiro que sempre acreditei que a Lockhart tivesse 10 GB. Mas ela pode até ter mais, mas se o tiver, será numa configuração deste mesmo género, com por exemplo apenas 2 módulos de 2 GB.
[OFF-TOPIC]
Já alguém viu está consola portátil da Alienware?
Só pelo design dava uma excey Xbox One portátil.
Acho que a MS devia fazer uma parceria com eles. Está consola com o SO da Xbox One e o catalogo da consola… Seria fantástica.
https://youtu.be/7AqS0OCansY
Eu vi, Bruno! Muito interessante!!!
Não existe gargalo porque todos os chips tem a mesma mclk e o mesmo tipo de memória, o que muda é que parte dos chips tem mais camada de memória.
Veja o chip ele possui 8 controles de memória.
?itok=ZJIF5oK7
Mas possui 10 chips
10x2x16= 320bits em Navi 10 tem 8x2x16= 256bits, 4 canais 16 bits foram adicionados no XSX
Esses canais está diretamente relacionado a Renoir que originalmente suporta LPDDR4, eles simplesmente estão usando GDDR6 no lugar.
Então o que veríamos se tivesse LPDDR4x + GDDR6?
LPDDR4 2 chips x 2 canais 2GB chip total 4GB
GDDR6 8 chips x 2 canais 2GB total 16GB
Então a Microsoft dar um jeito de cortar LPDDR4 ao mesmo tempo que pode usar chips de 1GB mais baratos onde o todo completa 16GB.
2 * 2GB chips x 2 canais total 4GB
8 * 1GB chips x 2 canais total 8GB
Mas ficaria 12GB e não 16GB certo? Por isso eles separam um terceiro e quarto chip que é da partição da GPU e coloca um chip de 2GB, isso da a eles 16GB.
2*2GB chip x 2 canais = 4GB
2*2GB chip x 2 canais = 4GB
8*1GB chip x 2 canais = 8GB
Na hora de preencher a GPU vai enxergar todos os chips pois o faz pela mesma Northbridge e pelos mesmos memory controller mas o north bridge diz pra GPU que ela só vai preencher 1GB de cada memória no endereço 0. Portanto no endereço 0 a GPU acessa até 560GB/s de largura de banda.
Já o CPU ele enxerga o espaço Renoir com 4GB e se extende aos 2 chips adicionais mas ele está limitado ao número de canais que a GPU está deixando livre.
Por isso a Microsoft estipula 10GB pra GPU e 6GB para CPU e outros mas o que ocorre mesmo é que a CPU acessa nativamente até 4GB mas fica com nos 2GB, os outros 4GB são uma parte combinada entre todos os clientes com coerência, enquanto a GPU sem coerência se extende até 10GB mas nativamente é 8GB.
Então não tem gargalo mas realmente tem prioridades, a CPU deve ter a maior prioridade na hierarquia a GPU a menor prioridade. Então o sistema começa a preencher na CPU, carrega todos os dados para o banco coerente e este vai copiando framebuffers para o banco de VRAM.
No PS5 o banco de VRAM também é o banco coerente ou seja, os 8 chips podem ser acessados a todos os clientes. 20GB/s é acessado pelo Tempest e pelo menos 56GB/s é para a CPU então podemos entender que o PS5 age como uma RX5600XT que mantém os 36*64 ULAs mas tem apenas 192Bits de acesso de memória.
No PS5
2*2GB chip x 2 Canais = 4GB (CPU, Tempest, Kraken outros)
6*2GB chips x 2 Canais = 12GB (GPU)
Ou seja quem está mais gargalado é o PS5 que está limitado a 336GB/s, o acesso a 12GB apenas por uma partição facilita a vida dos Devs mas não esconde a baixa largura de banda, o XSX vai ter pelo menos 448GB/s mas pode ir a até 504GB/s com acesso de 10GB, se for necessário a Microsoft pode simplesmente direcionar ainda mais 2 GB pra GPU comprimido seu espaço coerente fornecendo 12GB. Se não o fará é por que não é necessário. Até porque ambos usam a VRAM como framebuffer e cache, dificilmente vão precisar de mais de 8GB.
Shin…
Desculpa, mas… que raio de conclusões são essas?
Claro que todos os chips tem a mesma velocidade de relógio. Não era possível ser de outra forma a não ser que tivesses pools físicas separadas.
A memória assincrona obriga a chips com a mesma capacidade e velocidade. E é por isso que aqui, apesar de fisicamente serem os mesmo módulos, tens uma pool de memória rápida e uma de memória lenta. Porque a velocidade e e a capacidade tem de ser sempre a mesma.
Daí que tens 10 chips com a mesma velocidade entre si aos quais acedes a 1 GB, e 6 chips com a mesma velocidade entre si aos quais acedes 1 GB superior.
E 8 controladores de memória? Os controladores são 64 bits cada, 8 daria um BUS de 512 bits… Estás louco?
Depois comparas pools separadas com módulos físicos diferentes com o que aqui temos, depois falas em 12 GB, depois os chips já são 8+2+2=12 quando olhando para a board eles são 10, mas nesse exemplo os canais que tens já são 6, ou 384 bits.
Pá… o que está ali escrito é uma salgalhada de um tamanho tal que nem tem ponta por onde se lhe pegue!
Oh Mário é o Windows Central… Se isto valer de fonte a FOLHA também vale #SQN
Não percebi? O que ele refere é de lá? Onde? Link.
E quem é a Folha?
O primeiro link que Shin colocou é do WindowsCentral.
Lembrando que o FUD e a PS5 superaquecer começaram lá…
https://www.google.com/amp/s/www.tweaktown.com/news/71606/playstation-5s-rumored-heat-issues-should-be-solved-in-final-console/amp.html
Folha de São Paulo é um jornal brasileiro tantas vezes desacreditado que chega ser insulto usar como fonte…
Ele cita a fonte do Shin pra imagem da Apu do XSX.
Folha de São Paulo é um jornal brasileiro acostumado a se meter em tretas, aliás, algumas tretas passam longe de jornalismo.
Bingo! Internamente o circuito provavelmente vai até 512bits mas externamente originalmente eles miravam em 384bits, lembra do rumor de 48GB? No fim das contas A MS se concentrou no custo e trouxe para 320bits, isso significa que ela pode criar versões 12 e 16 chips de memória no mesmo SoC. Eles escolheram tal organização pois não seria necessário mais para competir com o PS5.
Lol Shin… tens noção do custo que teria colocar um bus de 512 Bits, para depois caires numa situação onde nem sequer os 320 usas em condições? Para além do mais, cada módulo de ram GDDR6 tem duas ligações de 16 bits, cada uma acedendo a metade da capacidade da memória.
Com 10 módulos tens no máximo 20 conexões ou 320 bits.
Ligas os restantes onde? 🤪
Shin… desculpa mas os teus dois primeiros links, em que tu apontas o primeiro como revelando os controladores e o segundo como revelando os chips sao a mesmissima imagem. Nao sei o que uma revela que a outra nao revela. Podes elaborar como chegas aos 8 controladores?
Seja como for, que a XsX tem mais 4 canais de 16 bits, esta bem patente neste artigo, e foi considerado na analise. O problema nao e nem nunca foi esse, o problema e que a XsX tem 10 chips para os 16 Gb, 4 de 1 GB e 6 de 2 GB. Ao passo que a PS5 tem 8 Chips de 2GB. Logo a XsX tem 10 controladores de 32bits (cada sao 2 canais de 16 bits como bem dizes) ao passo que a PS5 tem 8 controladores de 32 bits (o mesmo).
Foste buscar o Renoir, e fizeste um cenario hipotetico em que terias LPDDR4 e GDDR6 para um total de 20GB. Podes elaborar mais porque? No fim nao tens isso, e nao invalida as conclusoes a que o artigo chega. Tu basicamente so explicas como as substituicoes foram feitas se, hipoteticamente, a MS tivesse partido da Renoir…. mas o que e que isso interessa a discussao e em que e que isso altera o que foi dito.
O grande problema, Shin e que os teus canais tem que ver o mesmo montante de memoria. E o problema esta nos chips de 2 GB. E que o sistema e obrigado somente a considerar metade da memoria devido aos Chips mais pequenos de 1 GB.
E dai teres ou os 10 GB a 560 ou os 6 GB a 360… porque no primeiro caso fazes o acesso aos 10 chips pelo bus contando com os 10 canais e no segundo fazes o acesso aos 6 GB extra, por 6 canais. O problema e que nao podes usar os dois no maximo, e se tiveres que usar os dois bancos de memoria, ou seja os 6 Gb extra, entao teras que cortar na bandwith da mais rapida e nunca chegas a esse valor.
O que se esta a revelar e que, e o que tu descreves, e que em processamento normal, durante o jogo, se pode minimizar o acesso aos mais lentos e rentabilizar os 10GB mais rapidos. Se ha gargalo ou nao, isso vai depender do desempenho do sistema em casos reais.
O cenario que colocas em cima da mesa e problematico porque usar 6 ou 4 nao para o CPU nao importa. Ao aceders a pool de 6 Gb prejudicas o acesso a pool de 10 GB, isto e nunca teras os 560 GB/s e teras sempre que sacrificar bandwith, com esta configuracao.
Devido a característica GDDR6 a AMD conta canais em 16 bits e não 32bits.
Cada chip tem 2 canais, 4 pools por canal
O datafabric, simplesmente abre para a CPU qualquer canal disponível no limite dos seus 2 canais direcionados. Veja que o dado não vai diretamente para o canal, ele fica no cache L3 seja da CPU ou GPU, então quando é necessário o data faz a varredura das portas disponíveis e então copia o dado para a memória.
Por isso são 2 pools independentes 560GB/s é o máximo para GPU ou
336GB/s para todos os demais. Veja que são máximas físicas, dentro delas tbm tem os endereços virtuais de cada recurso.
Isso nunca esteve em causa… O que está em causa é que não consegues ter os 560 GB/s se a outra pool estiver igualmente a puxar dados.
E mesmo que a outra pool puxe 1 byte, se mudas o acesso, a velocidade da pool rápida caí para 392 GB/s.
392GB/s? Não
Lembrando quem acessa RAM é o Datafabric Control e não a CPU ou GPU, a CPU não exerga RAM diretamente, ela simplesmente escreve para L3 e a medida que isso ocorre o Datafabric copia para RAM.
O Datafabric vai escolher copiar dados pelos 6GB 336GB/s ou dados pelo 10GB 560GB/s ele não precisa dividir, ele o faz sobredemanda.
Não é ele que divide Shin… é o controlador. Ele ou está a ler para um lado ou para o outro. Não pode ler para os dois. Se pudesse ler para os dois não haviam duas pools!
O controlador é o Infinite Fabric que se trata do norte bridge e ele não é serial nem o acesso a memória, como cada chip tem 2 canais 4 contendes são 4 pulsos 2 indo e 2 vindo.
em 16ms por exemplo digamos que 6ms o CPU passa lendo e escrevendo, no tempo restante GPU usará 10ms. Ambos irão acessar a mesma memória então a diferença fica entre aquelas memórias que possuem mais espaco bytes por contender, por isso a divisão de espacos 6 e 10GB.
Os acessos do CPU e do GPU são simultâneos… Se não o fossem nunca terias problemas de largura de banda acumulada entre CPU e GPU! E os tempos de acesso entre ambos são mais ou menos 50/50.
Sim, mas isso o artigo ja diz. E essa e a raiz do problema! Cada canal, independentemente da bandwith total tem que aceder o mesmo montante de memoria. Logo tens 4 canais de 32 bits a aceder a 1 Gb e 6 canais de 32 Bits a aceder a 2Gb. Como e que o sistema resolve isto?
Simples, dado que cada canal de 32 bits corresponde a 2 de 16 bits tens, para os chips de memoria de 2Gb, cada de 16 gb a aceder a 1GB. Esta e a causa do gargalo. Logo com e que isto funciona?
Ou tens os 10 GB (ignorando o 1 Gb adicional do chips de 2 GB) a memoria maxima, ou se usares os 6 GB extra, teras qu sacrificar a bandwith do acesso aos 10Gb.
Logo as pools nao sao independentes porque partilham canais. Melhor dizendo, sim podes ter duas pool independentes, mas nunca serao a de 560 Gb/s ou 336Gb/s. Quando tens as duas pools independentes sacrificas bandwith.
Sua explicação foi muito clara Mário, parabéns pelas ótimas matérias e artigos da pcmanias. Pelo o que eu pude entender até agora, a Série X tem uma memória unificada, 10 chips de memória são conectados da mesma forma ao mesmo controlador de memória, 6 têm 2GB, 4 1GB. Se os dados necessários estiverem disponíveis nos 10 chips, então o console tem largura de banda máxima, se os dados estiverem em 6 chips, 6/10 largura de banda máxima, em 1 chip, 1/10 largura de banda máxima. Eu imagino que o software e o hardware no novo Xbox devem estar preparados para fazer o melhor uso da largura de banda. Eu acho que os dados devem ser alocados em pequenos pedaços através de toda a memória, ou seja, o software vai reservar algumas seções da memória , os 1GB extras de 6 chips de memória, apenas para algumas coisas, talvez o sistema operacional, CPU, áudio. Então na pior das hipóteses, o desenvolvedor ou o motor do jogo terão que adicionar uma função que vai ditar onde os dados serão armazenados. De todo jeito, a CPU nunca será capaz de acessar uma largura de banda tão alta, então o Xbox pode fornecer a largura de banda menor para a CPU, assim, eu suponho que o desenvolvedor vai pode optar por carregar recursos da GPU para o pool mais rápido e recursos da CPU para o pool mais lento. Isso não é como a ESRAM do Xbox One, porque apesar da alta largura de banda que tinha, os 32 MB não tinha suficiente buffer de quadro e só poderia ser usado raramente. Uma coisa que é interessante é que a CPU tem alguns limites de processamento, alguns limites de armazenamento (cache), e a conexão com o controlador de memória é equilibrada a esses limites, então o design de largura de banda dividida é realmente interessante, porque permite maior largura de banda com a mesma velocidade de barramento do design uniforme, ou seja, você pode carregar informações confidenciais não enquadradas mais lentas, como arquivos de som, motor de jogo ferramentas na memória mais lenta, e, em seguida, reservar a memória rápida para ativos visuais. Os 2,5 GB devem ser para o sistema operacional, e ainda há 3.5 para o que eu acho a Microsoft imaginou ser dados de não textura, representação backend do jogo em vez do que é exibido. No caso da PS5 a largura de banda é realmente a mesma que a Radeon RX 5700, mas a 5700 tem um menor desempenho do que a PS5 especialmente quando se leva em conta a eficiência RDNA2 da GPU do PS5. Além disso, a largura de banda do PS5 é compartilhada com a CPU, som e outras tarefas, por isso a largura de banda real para GPU acaba sendo inferior em comparação com a Radeon RX 5700. A GPU da PS5 não deve precisar de tanta largura da memória para poder funcionar de maneira eficiente.
Sempre que acedes aos 6 GB a largura de banda dos 10 GB cai para pelo menos 392 GB/s. Seja para acessos do OS, seja do que for! E isso é inevitável.
Mas se os acessos forem pequenos, eventualmente as caches podem compensar a perda. Daí que o ideal é não fazer nada que obrigue a acessos constantes dessa memória, movendo-a para a rápida e processando lá. Basicamente a Microsoft tem experiência nestas trocas pelos Move Engines, pelo que eventualmente a X será pouco prejudicada.
Agora que isto é um gargalo e que se não for devidamente usado arrasa as performances da consola, isso é uma realidade.
E o mais curioso sao os supostos isentos que depois ficam assim ofendidos, nao e Vitor?
No meu entendimento, quem vai ter problemas com largura de banda é o Playstation 5, e ainda vai ter mais problemas de contenção de banda entre CPU e GPU do que o Xbox SX.
A largura de banda do PS5 aliado ao menor poder de computação provavelmente vai inviabilizar a maioria das implementações de Ray Tracing em tempo real e o console não vai conseguir parear nem com a RTX2060.
Por isso é quase muito claro que a Sony vai ter a necessidade de ter um PS5 Pro mais rápido do que a Microsoft vai ter um Xbox SX 2, e ai vai ser engraçado, por que tenho certeza que o poder vai voltar a discussão e vai ser importante de novo, quando a Sony tiver um playstation vai forte.
Me parece todo dia pela campanha em mostrar deficiências no Xbox SX que a Microsoft acertou de novo, igual com o 360, onde por aqui sempre foi forte a campanha pra mostrar que o PS3 era melhor, apesar de ineficiente e ter mostrado alguma coisa diferente só na programação dedicada de um first party que o 360 – excluindo a turn 10 que entrega 60fps perfeitos desde essa época – só veio a ter no Halo 4, no fim da geração, o que mostrou que o console ainda tinha potencial não explorado, ao contrario do PS3 que ja estava se matando pra rodar o The Last of Us.
E dessa vez parece que a Microsoft acertou tanto em poder quanto em design inteligente, e tenho a impressao de que quando os jogos chegarem, será um pouco chocante a diferença, o que vai fazer com que as pessoas, assim como na época do Cell do PS3, saiam pra dizer que os devs não sabem usar o SSD… e agora que a Microsoft tem os estudios dedicados com forte skill tecnológico, como a 343i, Playground, Turn 10 e Coalition, acho que vai ser chocante a diferença de capacidades.
Acho até que na primeira onda de jogos, os devs das thirds vao dar uma boicotada no Xbox SX para o PS5 acompanhar, pela força da marca e o panorama atual do mercado, onde o Playstation é lider por larga margem.
Medeiros, por favor lembra-te de colocar o teu sobrenome no comentario. Temos aqui outro Fernando, que se identifica so por Fernando, e estas a dar azo a confusoes com isso.
Eu nao sei onde foste buscar esse teu entendimento. Mas aqui ja factualmente se demonstrou que o teu entendimento… esta errado.
Por CU a PS5 possui maior largura de banda e mais memoria RAM que a XsX e isso e factual, e sem sequer olhar para o SSD, onde tb tens diferencas a favor da PS5.
Que a XsX tera um maior “bottleneck” que a PS5 isso nem se submite a discussao – e um facto. O ssd e mais lento e possui 10 GB a 560 GB/s para o GPU que possui mais unidades de computacao face a uma PS5 que oferece 16 GB a 448 Gb/s.
Agora o que nao se pode concluir e se isto equilibrara as performances entre as duas ou sequer se constituira problema para a Xbox. Porque e tudo demasiado novo, a Xbox por si ja e muito boa. A unica coisa que se tem dito e que o facto de a PS5 ser ainda melhor neste quesito ira diminuir em termos reais a diferenca do valor medido e teraflops brutos, em performance.
Sobre se a XsX constitui uma 360… pois… ai e que falta ver. A 360 nao se valeu por ser a mais poderosa… mas por ser aquela com menos bottlenecks e mais facil de programar. O que nao foi dificil dado que a PS3 foi desenhada para ser dificil de programar.
Sobre o resto… se a 360 tivesse chegado ao nivel grafico do que foi visto na PS3 ate concordaria contigo… mas nao chegou.
O que estamos a ver, com base em reaccoes iniciais de quem contactou com o hardware e que… a PS5 e a consola que torna mais facil a extraccao de performance e a XsX, comparativamente, menos.
Sobre campanhas, o unico FUD identificado foi a favor da Xbox. E relativamente a campanhas a favor do SSD a ultima veio da propria Microsoft… esses safados a fazer campanha a favor da concorrencia.
Cuidado com o nome. Usa dois nomes para te identificares para não seres confundido.
Para além do mais, mudando o nome arriscas-te a ser banido automáticamente ao seres confundido como spam.
Não dá para confundir, o conteúdo do post e o modo como escreve dá para identificar quem é. Pode até usar outro nome que a maioria vai perceber quem é.
Então Fernando, no alto desse teu entendimento, explica lá como é que 448 GB/s para alimentar 36 CU + 8 núcleos de CPU é inferior a 560 (que não serão 560) para 52 CU + 8 núcleos.
Porque há várias contas que posso fazer:
448 / (36+8) = 10,18 GB para cada
560 / (52+8) = 9,33 GB para cada
Equilibrio
448 / 10,28 Tflops = 43 GB por Tflop
560 / 12.15 Tflops = 46 GB ppr Tflop
Equilibrio
Diz-me lá então que conta fazes tu para teres um entendimento diferente.
Será que o teu entendimento é um mero… bitaite.
Oi Mário, no caso vem a seguinte dúvida, a forma como colocado os módulos e a separação deles de 1GB pode influenciar em como é usada a bandwidth? Sou leigo no assunto, dê uma olhada nessa imagem. Essa disposição diferente da memória dos módulos traz algum efeito diferente do que você comentou? Obrigado!
Boa tarde André!
Infelizmente a disposição dos chips é irrelevante. O problema não se prende com a sua posição, mas sim com o facto que cada chip está ligado a dois canais de 16 bits cada um, totalizando os 32 bits.
Ora os chips de 2 GB para a memória ser usada como assincrona só podem ser acedidos na mesma medida dos de 1 GB, o que quer dizer que só são acedidos em 1 GB.
O restante 1 GB tem de ser acedido à parte.
Ora é essa separação que vai criar o problema. Pois os canais ou estão dedicados a ler o 1º GB ou a ler o 2º GB. A melhor das situações aparece quando todos leem o primeiro GB (os 560 GB/s), mas basta que o segundo seja acedido que a coisa vai piorar. E aí a melhor das situações ocorre quando um lê o primeiro GB e o outro o 2º Gigabyte (392 GB/s do 1º GB e 168 GB/s do segundo).
Seja como for, se o segundo GB for lido, ele vai ter de usar um dos canais, deixando apenas o outro livre para o outro GB, o que vai diminuir a largura de banda.
Vê a coisa assim:
Imagina 10 jarros de água, em que 4 deles levam 1 litro e 6 deles são mais altos e levam o dobro da água (2 litros). Cada um deles é acedido por duas palhinhas que puxam 28 ml de água cada uma, ou 56 ml no total (os dois canais 16 bits).
Mas para a coisa funcionar, todos tem de ter a mesma água, o que quer dizer que tu vais ter de colocar um separador a meio dos jarros mais altos, dividindo em 1+1 litro (ou dois jarros iguais um sobre o outro).
Ora o problema aqui não está na posição dos jarros, mas no facto que se quiseres beber água de todos ao mesmo tempo com a capacidade máxima, tu metes as 20 palhinhas no primeiro litro (o de baixo), puxando 560 ml. Mas se quiseres beber a água de cima, tens de subir pelo menos uma das palhinhas dos jarros maiores para a parte de cima. O que quer dizer que a agua que puxas da parte de baixo vai ser menos (nota que neste caso terias de puxar a palhinha em todos os jarros de 2 litros, pois a coisa tem de ser sempre assincrona), e isto permite-te puxar 392 ml de baixo e 168 ml de cima. E se puxares as duas palhinhas dos jarros de 2 litros, ainda menos água podes puxar de baixo pois eles deixam pura e simplesmente de contar para o débito de baixo, caso onde puxas 244 ml em baixo e 336 ml de cima.
Basicamente é esta divisão na capacidade de puxar a água que causa o problema, e não a posição dos jarros (Isso foi dito no primeiro artigo, que a posição era irrelevante)).
Mas a pergunta é coerente, e mostra interesse. Obrigada por a fazeres!
Espero que tenha ajudado a perceberes.
Obrigado, entendi sim!
Sabendo dessa redução de bandwidth quase que inevitável, existe uma maneira da Microsoft contornar esse problema? Sendo por meio de uma tecnologia ou hardware que não foi apresentado? Ou pelo simples entendimento de como os módulos funcionam não há outra maneira de minimizar isso?
Vamos lá a ver. Acima de tudo temos de ter consciencia que isto é uma consola. É hardware proprietário e personalizado, pelo que o problema pode ter já sido abordado na concepção e contornado de qualquer forma.
O nosso artigo inicial tem como título “Terá a Xbox série X problemas de gargalo com a sua memória?”.
Repara no ponto de interrogação!
Basicamente não posso afirmar que o problema não tenha sido contornado (e daí a interrogação). O que afirmo é que esta configuração cria esse problema, e que nos casos em que ela foi usada, nas geforce 650 e 660, ela deu enorme barraca com quebras na largura de banda pelos motivos explicitados.
A norma de acesso, da JEDEC, não prevê estas configurações, por este mesmo motivo.
Ou seja, o problema é real… isso é inegável!
Agora a Microsoft pode ter encontrado forma de o contornar. Não eliminando-o, pois isso não é possível, mas minimizando-o ao ponto de o resultado final ser aceitável e compensador, e basicamente poder ser considerado como ultrapassado.
Como? Uma das possibilidades vou aborda-la dentro de dias. É uma forma de se superar o problema, mas traz uma gestão de memória complicada (que, quem sabe, a Microsoft não automatizou como fez na One com a gestão dos 32 MB), e que passa pelo uso eficiente das caches e acessos alternados à RAM.
Mas nota que, como direi nesse artigo, vou falar disso, teorizando, pois não sei se essa foi a solução da Microsoft,