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.
Bom dia! É um off topic, mas algo está estranho! Estão saindo pessoas grandes na The Coalition, Phil elogiou o trabalho que a The Coalition fez, ajudando a The initiative, com recursos técnicos, ensinamentos de tecnologia, no possível game do The Initiative, etc… O site do The Initiative não está atualizando há tempos e no linkedin, que eu sempre acompanhava o estúdio, onde eles estavam com umas 40 e poucas pessoas, o link da página saiu! Drew Murray, líder de design contratado pela MS para trabalhar no The Initiative, ex Insomniac e sempre ativo no Twitter, ainda está linkado no Linkedin. Onde quero chegar? Posso estar enganado, mas creio que as 40 pessoas do The Initiative estão se juntando ao The Coalition, e se bobear, Darrel Galagher, head do The initiative, assumirá o The Coalition, pela minha teoria.rs Eis o link do Drew Murray no linkedin e veja que o nome The Initiative está lá na página dele, mas agora sem link ou foto com a Logo. https://www.linkedin.com/mwlite/in/monsterdrew101
Eita
Esquisito pensar nisso, o estudio foi formado para entregar e segundo a Microsoft jogos “AAAA”, visto que a Microsoft tem vindo a público deturpar os conceitos já pré estabelecidos de “triplo A” chamando tanto State of Decay 2 e ORI 2 de AAA, títulos que passam longe de grandes orçamentos e grandes equipes, apesar que no caso de Ori 2 com muita qualidade. E eu também tendo visto que a equipe da THE INITIATIVE ficou ali com seus pouco mais de 40 colaboradores e vem vc me referi tal coisa.
SERIA UMA BOMBA NEGATIVA, visto que a antiga Black Tusk, atual The Coalition já tinha projetos próprios e os teve de cancelar pra passar a cuidar de GEARS, agora +1 studio que iria trabalhar em títulos inéditos sendo movido pra também cuidar de GEARS? tenso, tomará que sejam apenas boatos
Pelo head do estúdio, encontra o The initiative! Está tudo muito estranho!
Poderá ser a segunda equipa de The coalition. A Naughty dog tem 2 equipa…
A criação do estúdio, The Initiative, poderá não ter corrido como esperado.
Basicamente não é só criar um estúdio e começar a fazer jogos, creio eu.
Eitaaa! Faz sentido, The Iniative será fechada e as as pessoas remanejadas para The Coalition.
Ainda ontem o Phil Spencer falou na iGN sobre o jogo da the Initiative e a pouco tempo postou foto de visita ao estúdio e de que estava jogando o game deles. Mesmo que eles sejam fundidos a Coalition, isso não é uma bomba. Eles podem muito bem ter pego o IP da antiga Black Tusk para trabalhar nele, o projeto foi arquivado para dar preferência a Gears e nesse momento a The Coalition é a empresa com melhor conhecimento do Unreal Engine fora da Epic, aliás, esse estúdio é o maior colaborador da Epic no desenvolvimento do Unreal Engine. Eles trabalham tanto em Gears quanto no suporte a outras equipes que usam a Unreal dentro dos estúdios da Microsoft.
No final, seria interessante se eles virassem a Coalition Santa Monica.
Claro que não é uma bomba… bomba é terem saido 14 funcionários da Naughty Dog em três anos.
Sistema e data fabric
6GB 336GB/s
GPU
10GB 560GB/s
Como a GPU pode ter latência usa a parte 2 mais longa, os demais mais curta.
Isso significa que não tem coerência, então da mesma forma que dados de um sistema UMA precisam ser recopiados aqui funciona da mesma forma os dados são movidos da baixa largura para a alta largura. Por motivos de compatibilidade retroativa, os 336GB/s são coerentes através do do North Bridge funcionando de forma similar ao One X ou PS4pro. Então quando a GPU fareja o SSD ela usa os 6GB 336GB/s, quando roda framebuffer usa os 10GB 560GB/s.
Agora a real se olhar o SoC poderá notar que a GPU tem o mesmo cache de reserva que a RX5700XT. Portanto, a GPU está conectada a 256bits diretamente acessando 8chipsx56=448GB/s mas eles estão me dizendo que tem 10chips disponíveis, a razão é o infinite fabric que permite eles extender este acesso a todos chips.
Então a maior parte do tempo a GPI tem 448GB/s e quando ela precisa de um pouco mais, conta com 56GB/s, já o CPU ele não precisa de mais de 56GB/s pois acessa a 32bytes ciclo.
Eu não diria que é um gargalo, chip tem 7WGP por grupo de cache, sendo 2 ativados 6WGP total 52CU.
A idéia era ter o máximo de computação dentro do mínimo de espaço de memória.
Shin… Não sei se.percebeste, mas, não tens duas larguras de banda. Só tens uma. As memórias são as mesmas e com uma largura de banda total de 560 GB/s.
O que a configuração cria é que se tens 560 GB/a nos 10 GB não podes estar a usar os 6 GB. Se tens 336 GB/s nos 6 GB só tens 224 GB/a nos 10 GB. Basicamente é como se fossem duas pools de RAM, mas com largura de banda partilhada. O que usas numa, perdes na outra.
Isto pode não soar muito diferente a uma situação normal, onde se usas uma parte da largura de banda ela deixa de estar disponível, mas é pelo facto que os limites de velocidade são diferentes.
Por exemplo na PS5!
Tens 448 GB/s. O CPU usa 100 GB/s, e 4 GB de RAM, e o GPU quer usar a memória. Ele tem 348 GB/s para usar e 12 GB de RAM para o fazer
Já na Xbox se o CPU usar 100 GB/s de RAM e 4GB o GPU fica com 460. A questão é que para isso está limitado a 10 GB, deitando fora 2 GB.
Se usar esses 2 GB a que velocidade os acedes? Os 6 GB dão-te 336 GB/s pelo que podes ter aí uma largura de banda de 236 GB/s descontando o CPU. Mas aí ficas com apenas 224 GB/s nos outros 10 GB. Podes depois optar por qualquer combinação, mas basicamente todas elas têm uma consequência, vais ter 2 GB com uma velocidade de acesso diferente dos restantes 10 GB. Se dividires os acessos para não existir disparidade, a largura de banda vai para metade ou 280 GB/s. Se fores por uso mediano a média de largura de banda vai para os 392 GB/s. Etc.
Basicamente tu terás sempre 560 GB/s mas o que não tens é nenhuma parte da memória que efectivamente te dê dados a essas velocidades. Para isso ou não usas os 6 GB ou tens de ter um controlo perfeito do que está em cada pool para poderes ler das duas em simultâneo. Só que com as variações impostas a cada segundo nas larguras de banda.usadas, fazer isso será um problema.
Ha contudo uma outra hipotese. Os 3.5GB utilizados pelo SO serem dos 6GB mais lentos… e resevarem-se 4 chips para isso… e os restantes 10 GB serem acedidos a maior velocidade. E demasiado cedo para se perceber se efectivamente havera ali problema. Mas teria gostado que tivessem isolado mais as duas memorias.. nao percebi essa decisao da parte deles, quando ja nesta geracao foi possivel colocar chips de memorias em lados distintos do PCB.
Sinceramente, e cada dia uma desilusao com estas consolas (e incluo a PS5 nisto). A minha opiniao e esta: tiveram tanta pressa em lancar, vao perder o comboio devido a fraca adocao e acabaram com hardware nada impressionante.
Recordo apenas que neste caso, nao necessario ter a divisao 10+6 da forma descrita. Acho que isso e apenas o funcionamento maximo da forma que esta, mas depois pode selecionar-se a forma como corre. Acho tb, que num sistema optimizado, isto nao se revelara um gargalo e ate me parece que pode ser uma optimizacao extra que acabe por ser bem vinda.
Como dizes, e eu digo no artigo, é cedo para se saber se haverá um problema. Mas a situação não é nova e pode vir a acontecer, daí o artigo ficar no ar.
Quanto ao OS, ele irá para lá sim…. Deverá usar essa memória com pouco uso de largura de banda. Mas a questão é que sobram 2.5 GB. E se puxares por eles, vais dividir a largura de banda acima dos 225 GB/s.
Apesar de tudo, acredito que o problema não se vai por… E estou a ser muito sincero!
Estou convencido que se pode usar estes 2.5 GB adicionais com algo como audio ou outra situação que requeira baixa largura de banda.
A vantagem aqui face às Geforce é que isto é um sistema completo, não apenas um GPU, pelo que o GPU à partida não precisará de dividir a memória e há outras coisas com que se a usar.
Daí que repito… estou plenamente convencido que isto não será um problema, mas como website de tecnologia, e para que no futuro, se necessário esteja a base montada sobre este assunto, não podia deixar de abordar a coisa.
O os do series x não usa 3.5gb de RAM, usa apenas 2.5
Não, eu quis dizer existe 2 Pools físicos e não, pode ser usar mais de 10GB.
Como falei desconfio que a GPU está conectada diretamente a 448GB através de 8 chips devido os caches L2, porém existe 2 chips adicionais totalizando 10GB. Quando a GPU precisa de 2GB ela começa a contar novamente mas no segundo pool.
A maneira simples é olhar pra CPU ela sempre vai ocupar 56GB/s, outros clientes vai ocupar sempre a partição de 336GB/s 6GB, o que sobra pode ser direcionado para a GPU. Ou seja o acesso é simultâneo mas não são somados.
GPU requisita um dado do SSD 336GB/s
GPU faz framebuffer 560GB/s
Passou dos 10GB 336GB/s.
Então podemos enxergar 10+2, mas como os 2GB vem do mesmo conjunto de chips mudando apenas o canal, isso não torna as bandas somadas.
Outro ponto é que os 2 pools físicos não tem coerência virtual, determinado shader GPGPU da 336GB/s precisa repassar pelo data fabric para ser alocado nos 560GB/s.
Em outras palavras o datafabric ele é um filtro com multiplas entradas e duas saídas, uma saída é maior que a outra, mas leva pra o mesmo caminho.
A PS 5 sim, tem 8 chips de 2 GB cada! Isso perfaz 4 controladores de 64 bits, ou seja os anunciados 256 bits.
A Xbox série X não! 8 chips de 2 gigas seriam 16 GB, logo não poderias ter mais dois pois senão tinhas mais de 16 gigas, Se fossem de 1 GB terias 8 GB, e mais dois poderiam no máximo acrescentar 4 GB, o que totalizaria 12.
E é 10 + 6… a Microsoft já deu esse dado oficialmente! Daí que a única configuração possível é a do artigo!
10 chips… 10 + 6 com um canal de 320 bits no de 10 e 192 bits no de 6, com um máximo de 5 controladores de 64 bits. Não há mesmo outra combinação!
Eu não entendi muito bem, pelo que você explicou ambos sofrem a mesma penalização. Se no PS5 a CPU pedir 100/s dos 448/s, sobram 348/s para a GPU. No Xbox não acontece a mesma coisa? O problema é só que o Xbox está meio que limitado a 10GB para a GPU?
Isso que referes é universal. Quando um componente pede uma largura de banda, o outro só pode ficar com o que resta.
Se bem que 100 GB para o CPU é puxadinho. Maximo 50!
Mas vamos pelos 100. É irrelevante.
Na PS5 o CPU pede 100 e 6 GB. O GPU fica com 348 GB e 7,5 GB de RAM. (VAmos considerar sempre o Os a gastar 2.5 GB)
Na X:
Se só usares os 10 GB rápidos
O CPU pede 100 e 6 GB, o GPU fica com 460 e 4 GB RAM. O OS fica nos restantes 6 GB
Se usares os 16 GB e:
1 – Colocares o CPU a usar os 3.5 GB da memória lenta.
O CPU usa a memória lenta toda e como gastaria 100 GB com 6 GB de Ram, pela proporção aqui usaria aprox 58 GB.
Pelo uso desta memória e por não se passar os 168 GB/s, o GPU teria 392 GB/s.
Mas o CPU ainda ia usar 2.5 GB dessa ram e 42 GB/s.
Ou seja, o GPU teria 352 GB/s e 7.5 GB de RAM.
2 – O CPU trabalharia na memória rápida, e a memória lenta ficaria com coisas com pouco acesso do GPU.
O CPU gastaria 6 GB e gastaria 100 GB, o GPU ficaria com 7.5 GB de RAM. A sua largura de banda seria variavel de acordo com os acessos à memoria lenta.
Seja como for, neste caso ele teria sempre 460 GB/s, a questão é que quando acedesse à memória lenta onde estavam dados secundários, a largura de banda da memória principal cairia na melhor das hipoteses para 392 GB/s (quais quais tens de descontar os 100 do CPU – 292), ou na pior para 244 GB/s onde tambem tens de descontar os 100 (144 GB/s).
Como vês, isto é complexo, e demasiadamente variável. Há mais casos, mas todos eles implicam divisão da largura de banda se acederes aos 6 GB.
É complexo, e pode até não se revelar superior à situação da PS5, mas pode ter soluções, dependendo de como a Microsoft implementou a situação. O que te refiro é o acesso standard de acesso preconizado pela JEDEC para memória interleaved como esta.
Mário desculpe a ignorância, isso não seria uma redução de custo na séries X, digo na altura do lançamento da PS4 foram muitos os “especialistas” a dizer que a CPU sofreria com a latência da GDDR5 algo que se confirmou em alguns jogos que mais limitadores da CPU acabaram por ter performance melhor na Xbox One…
Penso que com GDDR6 é um caso mais grave, onde a latência seria maior para a CPU e esta segunda pool de 6 gb seria uma forma de mitigar essa latência… Bom na explicação da digital Foundry eu entendi assim…
Pois o SO da console estaria alocado nessa ram mais lenta.
Em termos de como a memória é alocada, os jogos recebem um total de 13,5 GB no total, que abrange todos os 10 GB de memória ideal da GPU e 3,5 GB de memória padrão. Isso deixa 2,5 GB de memória GDDR6 do pool mais lento para o sistema operacional e o shell front-end. Do ponto de vista da Microsoft, ainda é um sistema de memória unificada, mesmo que o desempenho possa variar. “Em conversas com desenvolvedores, normalmente é fácil para os jogos mais do que preencher sua cota de memória padrão com CPU, dados de áudio, dados de pilha e dados executáveis, dados de script e desenvolvedores como essa troca quando isso oferece mais potencial. largura de banda “, diz Goossen.
Parece uma situação um tanto complexa, especialmente quando a própria Microsoft já entregou uma interface de memória mais tradicional e mais ampla no Xbox One X – mas a noção de trabalhar com memória GDDR6 muito mais rápida apresentou alguns desafios. “Quando conversamos com a equipe do sistema, havia muitos problemas relacionados à complexidade da integridade do sinal e o que não”, explica Goossen.
“Como você sabe, com o Xbox One X, fomos com a interface de 384 [bits], mas a essas velocidades incríveis – 14 gbps com o GDDR6 – nos esforçamos o máximo possível e sentimos que 320 era um bom compromisso em termos de alcançar o mais alto desempenho possível, ao mesmo tempo em que construímos o sistema que realmente funcionaria e que poderíamos realmente enviar “.
O problema, By-mission, e que no fim tu nao tens uma ram separada mais lenta – tens chips que poem ou funcionar de forma mais rapida ou dividir-se e funcionar de forma mais lenta.
O que tu dizes esta certo… se efectivamente houvessem 6gb separados a 360. Mas nao ha… o que ha e 12 gb que ou funciona a velocidade maxima de transferencia ou se dividem em 6 lentos e 10 “rapidos” mas que na realidade nem sao rapidos.
Quero juntar isso que tem no artigo com o fato do BOM estimado pelo Zhuguex ser entre 460 e 520 USD para o SX e 460 para o PS5.
Se fosse BOM de até 480USD acho que a MS teria botado 20GB GDDR6 que daria um BUS unico de 560GB/s dando BOM de 500USD, a MS iria adorar fala que tem 20GB de RAM contra 16GB do PS5.
chuto ai BOM do SX em 500~520 USD para a MS vender por 550USD.
Foi claramente uma decisão para cortas custos….então sim o XSX também tem seus compromissos e não foi feito com o que há de melhor como pensam.
Senao queres compromissos vai para o pc e gastas o que a tua carteira deixar, eu tambem acho que foi uma decisao performance/custos como todas as consolas sempre foram.
E nao prevejo gargalos com este setup alias isto foi falado pela Microsoft, e o phill ja veio assumir a liderança em hardware.
Aqui a questão é quem cortou mais? Isso para mim é claro.
Estou neste momento a ter essa conversa em um forum… E a realidade é que não há, e nem se prevê que venha a haver tão cedo, hardware nos PCs capaz de acompanhar as consolas.
Nenhum PC consegue lidar com taxas de descompressão que usam vários núcleos de CPU (mais na PS5). Nenhum PC consegue lidar com as velocidades destes SSDs com as suas optimizações no sistema de I/O (mais na PS5).
Nenhum sistema de PC consegue comunicar entre o GPU e o CPU como nas consolas.
Estas situações vão obrigar a uma mudança radical do hardware dos PCs. Ou tens um CPU com 24 Núcleos para dedicares 11 à descompressão como na PS5, e 32 ou mais GB de RAM que onde os CPUs trabalharem, ou não consegues acompanhar.
Mas SSDs deste tipo não há… e vao demorar anos a aparecer. PCs que não tenham os gargalos que os actuais tem no seu sistema de I/O não existem ainda. Daí que neste momento dizer a alguém que não quer ir para as consolas qual o melhor hardware PC a comprar, é uma tarefa quase impossível. Ou o PC é estupidamente potente, ou ele não consegue acompanhar.
Estas consolas vão obrigar o panorama PC a upgrades… que neste momento ainda não podem ser feitos.
Quanto ao que o Phil referiu não aborda esta situação. Ele nunca se dirigiu a ela em particular. Nunca ninguém da Microsoft a abordou. Como já referi não acredito que ela venha a ser problemática, mas o certo é que o Phil nunca tocou nela, e se tocou naturalmente não ia reconhecer um problema…
Off Toppic:
Boa leitura a todos…
https://www.eurogamer.net/articles/digitalfoundry-2020-playstation-5-the-mark-cerny-tech-deep-dive
“Então, quando eu afirmei que a GPU passaria a maior parte do tempo na frequência mais próxima, ou seja, com a ‘corrida para o ocioso’ removida da equação – estávamos vendo os jogos do PlayStation 5 em situações em que todo o mesmo estava sendo usado produtivamente. O mesmo vale para a CPU, com base no exame de situações em que ela tem alta utilização em todo o quadro, concluímos que a CPU passará a maior parte do tempo na frequência de pico ”
Mark Cerny
Fim da discussão.
“Provavelmente há mais a descobrir sobre como o impulso influenciará o design do jogo. Vários desenvolvedores que conversaram com a Digital Foundry declararam que seu trabalho atual no PS5 os vê desacelerando a CPU para garantir um relógio de 2,23 GHz sustentado no núcleo gráfico. Faz todo o sentido, já que a maioria dos mecanismos de jogos agora é projetada com o Jaguar de baixo desempenho – mesmo uma duplicação da taxa de transferência (por exemplo, 60fps vs 30fps) dificilmente sobrecarregaria os núcleos Zen 2 do PS5. No entanto, isso não parece uma solução de impulso, mas perfis de desempenho semelhantes aos que vimos no Nintendo Switch. “Em relação aos perfis bloqueados, apoiamos os de nossos kits de desenvolvimento; pode ser útil não ter relógios variáveis ao otimizar. Os jogos PS5 lançados sempre recebem frequências aprimoradas para que possam tirar proveito da energia adicional”.
Segundo esse cara Aqui Daniel Rubino Exec editor
do WindowsCentral, o ps5 tem problemas de aquecimento.
Não sei se isso é verdade, mas quando o rumo é negativo, as fontes sempre são proximas da MS. @Mario, vc que ler bastante por ai em foruns, vc já viu algo isso ?
https://twitter.com/Daniel_Rubino/status/1245741486689398785
kkkkk
Mentiras? na Internet? Nunca vi! 😉
“Existe energia suficiente para a CPU e a GPU potencialmente executado em seus limites de 3,5 GHz e 2,23 GHz, não é o caso que o desenvolvedor tenha que optar por executar um deles mais lentamente. ”
E By-Mission… Leste aqui primeiro! Nos nossos artigos!
Quando a malta dizia que isso não ia acontecer, nós explicavamos isto!
Não temos os dados minucioso para ir ao pormenor como Cerny tem, mas sempre dissemos… Não há cá downclocks nenhuns! O CPU e o GPU vão correr na sua velocidade máximo sem problemas!
Nos bastidores, o bloco de compressão Kraken dedicado do SSD, o controlador DMA, os mecanismos de coerência e os coprocessadores de E / S garantem que os desenvolvedores possam acessar facilmente a velocidade do SSD sem exigir código personalizado para tirar o melhor proveito da solução de estado sólido . Um investimento significativo em silício no controlador flash garante um desempenho superior: o desenvolvedor simplesmente precisa usar a nova API. É um ótimo exemplo de uma peça de tecnologia que deve oferecer benefícios instantâneos e não exigirá uma extensa adesão dos desenvolvedores para utilizá-la.
e la se vai mais uma falácia dos caixistas
Engraçado como até se explica o problema que alguns devs estão a ter (e as queixas pelos vistos eram verdadeiras sobre terem de descer a velocidade do CPU para alcançarem a velocidade do GPU).
Como o sistema funciona com base em gestão de energias e frequências variáveis e os actuais motores estão preparados para o uso de CPUs jaguar de baixo consumo, e frequências fixas, daí que a consola activa um perfil de energia diferente uma vez que os jaguar no máximo nem conseguem tocaram no potencial dos Zen 2.
Não é um real limite da consola. São perfis de energia como os da Switch.
Sim é como tu mesmo disse aqui, se definido uma taxa de 60fps a PS5 calcula sempre 60fps ao contrário da séries X em que terá 60, 75 90fps pois o clock é fixo..
Uma análise constante ao que o CPU e GPU estão a fazer.
Mario, no final do artigo também e referido que o ps5 não possui variable rate shading. Isso pode gerar uma grande diferença a favor do Xbox?
Dividindo a resposta por partes:
– O VRS faz diferença? Sim, bastante! Chega a trazer ganhos de 30%
– A PS5 não possui? Vamos dividir a resposta por partes
1 – Duvido que não tenha. Primeiro porque a Nvidia tem à muito tempo, e como tal não acredito que a AMD não tenha isso como standard. O que pode não ter é a implementação da Microsoft que é mais avançada. Daí que acredito que há ali uma má informação da Eurogamer.
2 – Mas mesmo que não tenha esse VRS, não quer dizer que não tenha outro. O VRS é uma técnica. A microsoft tem uma patente sobre algo dele (como disse não será tudo pois a Nvidia usa-o), mas a Sony tem algumas patentes também sobre técnicas similares. Daí que não ter esse VRS é uma coisa, não ter algo semelhante é outra.
E sobre isso a Sony não se pronunciou. Sabe-se que tem algo chamado o Geometry Engine, que é um chip fora do GPU que trata da geometria. O que ele faz não se sabe ainda. Pode ter VRS aí ou notro sitio qualquer.
Resumindo, continuo sem concluir nada. E esta frase não altera nadinha de nada.
Existe um mito VRS depois que o GitHub validou o recurso para o Serie X e a Sony ficou calada, e esse mito é por causa da implementação.
O PS4 faz VRS quando ele usa Foveated Rendering
A AMD já está falando disso desde Polaris.
Antes VRS se chamava coarse pixel shading (CPS) que foi patenteado pela Intel.
https://patents.google.com/patent/US20160078672A1/en
O que a AMD fixou no RDNA 2 foi o método da Microsoft que inclusive faz parte do Shadel Model 6.5.
https://microsoft.github.io/DirectX-Specs/d3d/VariableRateShading.html
Não sabemos que método a Sony está usando e não ter a ID equivalente no Github pode indicar personalização.
Exactamente… Obrigada pela explicação detalhada…
A AMD tem o hardware para o VRS, apenas não tem o método da Microsoft para o novo Shader model!
Daí que na pior das hipóteses a Sony tem a versão antiga. Mas pessoalmente dadas as patentes da Sony sobre o assunto, acredito que ela tem uma solução proprietária incluída no Geometry Engine.
Digital foundry fez um vídeo hoje e nesse vídeo mostrou que não adianta os clocks altíssimos do ps5, porque quando aumenta o clock é não aumenta a largura de banda, temos aí um bottleneck e eles deram de exemplo a placa rx 5700 no jogo hitman 2,e os resultados foram esses:
Rx 5700 1700MHZ/7.83TF 43fps
Rx 5700 1900MHZ/8.87TF 46fps
Ex 5700 2100MHZ/9.67TF 47fps
Quem está achando que o clock alto do ps5 vai mitigar as diferenças com o Xbox, tá muito enganado, O clock vai mudar pouquíssimo o fps e Mário você fala de uma limitação que o series x vai ter mas eu lembro de você falando que o Xbox one x seria limitado pelo número de rops, e esse console foi o que rodou red dead 2 a 4k nativo, que é o dobro do ps4 pro
Ter 36 CU =/= ser RX5700
PS5 não tem uma RX5700
PS5 não é programado como a RX5700
PS5 não tem as mesmas limitações da RX5700.
PS5 nem tem GPU dedicada, é uma APU.
Sim o PS5 é mais fraco que o XSX mas não, seu desempenho não é equivalente ao PC referência. A Sony aumenta o clock base para obter uma vantagem das unidades de função fixa…
2230MHz * 4 geometry engines = 17,8 Bilhões de triângulos
1825MHz *4 = 14,6 bi.
O raster também tem sua diferença, clock mais alto tbm põe um pouco mais de velocidade na passagem L1.
Jogos de PC não irão aproveitar isso pois eles mantém o nível de raster baixo para compatibilizar com o máximo de plataformas.
Agora estás a dar-lhe 😉
E eu nem tinha percebido que a pergunta era essa… Estava um pouco confusa.
Mario, nem precisa aprovar, fica só para vc dar uma olhada… mas ao que parece um bando de fanboys do xbox que se organizavam para fazer bait e report em massa no resetera tinham o vazamento do github bem antes de todo mundo.
https://www.neogaf.com/threads/next-gen-ps5-xsx-ot-speculation-analysis-leaks-thread.1480978/page-1650#post-257649489
ao que parece, a fonte inicial do github saiu de lá.
como vc estava desconfiado, ai tem coisa sim. esse vazamento está estranho.
site da MS tem vazamento que cai no colo dos fanboys do xbox que já estão organizados em uma “SEITA” para fazer fazer flamme em foruns de video game? que coincidência.
bom, se vc atualizar o artigo do vazamento do github ou fizer outro eu comendo lá, se não fizer tb azar UHAUHAUHUHUH
Vou apenas dizer que estou parvo com o que tem vindo a público. Que a ser tudo verdade, a palavra seita não chega para definir.
E continuo a achar que isto do github vai dar muito que falar.
Man… estou a ficar chocado com o que leio.
A malta reunia no Discord, definia estratégias e espalhavam todos a mesma coisa, misturada com outros casos reais para dar credibilidade.
Na lista temos o Colbert, e o Dictator (o Alex battaglia da Digital Foundry), entre muitos outros. Todos eles que publicaram posts a negar ou contrariar situações alegadas para a PS5.
Quando o Dictator foi questionado se tinha noção que com isto estava a por em causa o seu posto de trabalho, ele refere que clickou no link um dia em que estava a ter dificuldades em dormir… Apesar de participar activamente e de as suas mensagens serem colocadas da parte da tarde.
Aquele gajo que refere o aquecimento da consola e do SSD é o pior… Está no grupo e tem um historial do caraças a denegrir a Playstation. O tipo até fechou o Twitter dele para ninguem poder ir lá ver, mas valeu-lhe de pouco pois estão a aparecer capturas de ecrã.
“Não é como se não tivéssemos visto isso antes. Esses mesmos fanboys se uniram à mídia para divulgar o FUD sobre o PS4, a ponto de banir grupos de astroturfistas toda semana que tentavam estufar o Xbox One. Até Albert Penello foi pego. Isso não é novidade. O que devemos nos interessar é por que esta rodada de FUD é muito mais detalhada que a da última geração? Eu realmente sinto que o PS5 está causando ondas na comunidade de desenvolvedores e tem MS e seus fãs assustados.”
“Mas o fato de um membro do DF estar lá e fornecer detalhes de que se eu fosse da Sony é um sinal claro de que pelo menos parte do DF não é imparcial. Confio no DF como uma análise, mas para ter um
membro que estivesse disposto a apoiar esse grupo porque ele não fala bem de você.
Isso não significa que a Microsoft os pague, mas se eles são incentivados a esse comportamento pelo que vemos, você já reparou no tipo de fanboy tóxico que o próprio Phil segue …
A Microsoft é conhecida por ter tido algumas práticas antiéticas no passado, talvez agora que isso não está acontecendo, mas não sabemos.”
Hora aqui o Dictador (ReE) a fazer artigos para o DF só derrubam o que se refere a, isenção do sítio, digo se este e pego e ainda assume como ficam os outros ao que parecem ainda são muitos.. E pior se a história do GitHub foi a luz por força deste, como fica o DF e pior como fica a credibilidade do site???
https://www.eurogamer.net/authors/1798
Parece que os astroturf da MS eram coisa do passado, mas pelos vistos ainda estão bem activos, uma pena. Este foi um dos motivos que comecei a desgostar da marca!
Do passado… recente! Em 2013 vários astroturfers estiveram bem activos.
É assim alguem me explique isto sff.
SX frequências locked.
PS5 continuos boost, ou seja a frequência não é locked ou seja nem sempre vamos ter o pico.
Se a ps5 efectivamente tivesse capacidade térmica e energética para todo o tipu de situações nao teria as suas frequências locked?
Mais, quando cerny diz na maioria do tempo, não é sempre, vai descer, é que as vezes parece que ou eu nao sei ler ou entao explicam mal.
E é verdade que o gpu no qual a ps5 é baseado não tem muitas vantagens com a acelaracao do mesmo mas la esta o gpu pc talvez o mesmo gpu na consola escale melhor.
Tivemos hoje mesmo o phill a assumir a liderança em hardware mas qual é a duvida? Se a sx nao fosse a melhor em hardware ele nao o diria.
As frequências locked é a técnica usada desde sempre. E era usada porque basicamente não havia melhor. Algo que agora há!
Eu questiono-te: Qual a vantagem de teres as frequências locked? Vou dar um exemplo.
A X tem locked. A PS5 não. A frequência varia conforme necessário.
Arrancas ambas as consolas. Estás no menu sem fazer nada:
Quanto está a X a debitar? 12.1 Tflops? A PS5? 0 Tflops.
E ambas estão a fazer o mesmo… ou seja… nada!
Agora corres um joguinho Indie levezinho.
Quanto está a X a debitar? 12.1 Tflops? A PS5? 1 Tflops.
E ambas estão a correr o mesmo jogo com as mesmas performances.
Daí que eu pergunto. Se a PS5 debita o que é preciso quando é preciso, qual a vantagem dos relógios fixos?
Tu sabes ler… e não te explicaram mal… Agora ou não compreendeste ou não quiseste compreender.
A PS5 tem relógios variáveis. Atualizado ao microsegundo. Ela debita aquilo que é necessário. Ora como nem sempre é necessário o máximo, ela não vai estar sempre no máximo. Vai estar quando for preciso, o que deve ser a maior parte do tempo, mas não sempre. Se estivesse sempre, poderia compensar bloquear as velocidades (na realidade não compensa por outras razões, e essas percebes no artigo de amanhã)
Qualquer hardware tem vantagem com a aceleração. Mais Mhz implicam que todo o sistema corre mais rápido. Como já viste em cima, os Tflops não comparam as duas consolas pois com 1 Tflop a PS5 pode igualar a X com 12.1.
Mas há mais. Os Tflops medem a performance das unidades de cálculo, as ALUs. Não medem a performance real do sistema.
Pode ser uma boa comparação se o resto foi semelhante, como aconteceu na geração passada, mas não aqui.
A PS5 é 22% mais rápida, e isso quer dizer que toda a rasterização, efectuada em unidades cuja performance não é medida pelas ALUs, tambem é 22% mais rápida a processar. Ou seja, há ganhos inerentes à maior velocidade que nem sequer são contabilizados pelos Tflops.
Depois a paralelização não é e nem nunca foi linear. É a lei de Amdahl! Quanto mais processadores, mais perda de eficiência tens pois a paralelização tem de ser perfeita. 52 Cu serão sempre preferíveis a 32, mas na realidade, não são 44% mais a nível de performance. 18 CU representa basicamente 50% mais de performance do que 12, mas 52 CU não representa 44% mais do que 36 CU. E porque?
Porque a posição na curva de Amdahl é bem diferente. A curva sobe bastante no início com o aumento de processadores, mostrando que os ganhos são muitos, mas quando te aproximas de valores mais elevados, a mesma não apresenta os mesmo ganhos. Eis o aspecto de uma curva (as inclinações podem variar, mas aqui uso esta para melhor perceberes)
Agora desconta aqui os 22% da velocidades, e a diferença entre as consolas não é nada de outro mundo.
Mas quanto ao Phil assumir a liderança em hardware, é uma verdade. Uma mera realidade! Independentemente disso, o hardware da X é mais potente (12.1 > 10.28), e quanto a isso nada há a dizer!
Isso vai-lhe trazer vantagens nos jogos? Claro que vai! Especialmente os concebidos nos motores actuais.
Terá sempre os melhores jogos? Isso é o que iremos ver mal os motores começem a escalar mipmappings, texturas e geometria, tal e qual como fazem com a resolução, de acordo com a velocidade do SSD!
Mas porque é que há jogos que a consola é mais barulhenta do que outros?
Eu a jogar Horizon zero dawn e god of war, a minha ps4 pro parece um avião a levantar vou.
Lê amanhã…
@Rui
Poderias por favor indicar onde o Phil assumiu a liderança?
Queria ler as palavras exactas e não encontro nada.
Esta na eurogamer as várias noticias e o que o phill disse numa entrevista.
Pois… mas o que eu estou a encontrar não é uma frase do Phil, mas sim do website que postou a entrevista, a Eurogamer.
O que o Rui se deve estar a referir é isto: “ When we saw the public disclosure, I felt even better about the choices that we made on our platform. And I kind of expected that I would… I had a lot of confidence in our hardware team. “
O resto da entrevista encontra se aqui:
https://sea.ign.com/hardware-1/159249/news/interview-head-of-xbox-phil-spencer-talking-xbox-series-x-unlocked-437
[OFF] The Last of Us 2 adiado 🙁
https://twitter.com/Neil_Druckmann/status/1245773277097644032?s=20
Já era previsto que os principais jogos de maio em diante fossem adiados. A questão agora é; será que os novos consoles serão também adiados?
É uma boa pergunta!
Daria jeito a Sony, para adiar também o Ghost of tsushima. Se não, o jogo poderia sair próximo da ps5 e os consumidores não lhe darem a devida atenção.
Mas como o lançamento da Xbox SX se deverá manter, o mesmo deve ser igual para a ps5
Eu acho muito dificil esses novos consoles nao serem adiados, mas vamos aguardar
E o problema de superaquecimento do SSD do PS5?
Não há nenhum problema de superaquecimento do SSD da PS5. O SSD da Sony nem sequer é dos mais rápidos que estão para sair.
saiu do grupo do discord de caixistas fazendo FUD.
Ótimas observações Mário. Não vi nenhum site trazer atenção a esses detalhes interessantes. Agora resta saber qual a solução que a Microsoft têm implementado no controlador. É interessante que a largura de banda máxima do barramento 320bits é 560 GB/s, e do barramento 192bits é 336 Gb/s e as duas partes não podem ser acedidos simultaneamente nas suas velocidades máximas. Então existem duas ofertas aqui, acesso sequencial e largura de banda simultânea, mas compartilhado. Isso mostra que basicamente, em determinados cenários, as especificações irão executar como foi afirmado, em alguns outros não. Assim como os Teraflops em placas gráficas de desktop são calculados em relógios de impulso, o máximo teórico, em oposição à sua constante garantida velocidade de clock. Nesse caso o acesso não pode ser pré-arranjado através de um mecanismo de mudança pelo qual todo o sistema sabe quando o acesso aos diferentes espaços de endereço vai estar disponível?
A tua pergunta está um bocado confusa, podes refazê-la?
Deixa-me só acrescentar que não compares a Ps5 com boost clocks de PC. Porque não tem absolutamente nada a ver. A única semelhança é a palavra boost.
Quando muito compara isto com a texnologia Max Q da Nvidia. Parece-me à primeira vista, relativamente similar.
Ambas as tecnologias prometem 10% mais de performance para os mesmos consumos.
Deixa que te diga que desconheço solução para este problema, uma vez que ele é fisico. E só vejo que isso se resolva com uma gestão muito cuidada do que vai para os 6 GB.
No global a largura de banda é sempre 560 GB, mas se usares os 6 GB tems de ler dos dois para garantir isso, senão a largura de banda cai e bastante.
Isto é relevante uma vez que nos casos passados esta situação teve grandes impactos na performance do GPU se fosse usada memória dos dois lados.
Realmente ficou estranha a minha dúvida. Para o Xbox e PS5 tanto CPU e GPU não estão acessando pool de memória compartilhada? (pelo menos em termos de controlador de memória).
Assim, ambos vão sofrer de forma aleatória accessos da CPU e da GPU. Se a CPU da PS5 está utilizando a largura da memória, a GPU fica prejudicada. Se houver um conjunto simétrico de acessos, o acesso da GPU para a RAM no caso da PS5 será pela metade 224 GB/s. Então vai surgir uma situação similar com o que acontece no Xbox. Só se a PS5 tem uma rota diferente da memória para a CPU e a GPU, nesse caso a PS5 teria uma vantagem.
O verdadeiro gargalo do XSX não está no acesso externo mas no interno, no cache L1. O L1 de RDNA é o L2 de GCN Vega com a diferença que ele está um nível sobre e serve para amortecer a carga de registro de dados sobre seu novo nível L2 (que é como fosse um L3) e ao mesmo tempo permitir leitura em velocidade dobrada pra cada WGP.
Cada cluster do Shader Engine tem sua rede de ULAs e 128KB de cache L1 e isso funciona de forma similar ao CCX, é como se fosse a estrutura de um CPU Quadcore.
Então o que a Microsoft fez? Adicionou 2 WGP por cluster elevando de 20 para 28, no console eles desativam 2 WGP então tem 2 Cluster com 6WGP e outros 2 com 7 WGP. O nível L1 não aumentou continua 128KB, só que agora compartilhado com mais clientes.
Em RDNA o Raster é feito na L1 e não na VRAM, isso foi a mudança que assim como as Geforces, adoraram a etapa Binner.
A AMD mostrou isso em Vega…
Que é parte da renderização Tiled muito conhecida dos PowerVR, onde o raster é feito em blocos não ordenados. Então como pode ver no diagrama da AMD. Os 28WGP completam exatamente o número máximo de clientes pendurados no cache adjunto aos RBEs e a Microsoft desativa esses 2 WGP ao mesmo tempo que explora um clock maior para equilibrar velocidade dos motores de função fixa com os programáveis, isso também significa que o rendimento de cada cliente individual cai. Por isso que o DDC será importante para o XSX e VRS e a MS vai valorizar isso. Pode haver pequenos overdraws devido a saturação da largura de banda do L1 usando o máximo de clientes, isso não ocorre no PS5 pois existe apenas 18 grupos ligados, significa cada cliente tem 16KB e o total de largura de banda 4,4TB/s, no XSX são 8KB e um total de 3,6TB/s. Ou seja, o fluxo de leitura do XSX ficará um pouco mais Wait que o do PS5 e a compensação é mais DDC e VRS.
Por acaso estive a ler isso ontem…
A solução seria dobrar o cache L1 o que implicaria em também dobrar o cache L2.
L1 de 4×128 para 8×128 total 1MB
L2 de 32×256 para 64×256 total 8MB
Por isso a AMD tem outra solução, usar HBM2 de 4096bits, assim ela pode dobrar L1 sem depender do L2 pois o HBM o substitui. É o que ocorre com Vega que não tem o L1 mas seu L2 faz o que o L1 RDNA faz.
Isso também permitiria eles chegar a 128ROPs. É isso que vão fazer nas GPUs maiores que 28WGP.
Agora, por que existe 4 Shader Engines? Porque é o que o controlador de comandos pode operar. 1 HWS, 4 ACEs, devemos nos lembrar que RDNA não é uma nova arquitetura em tudo mas sim um híbrido GCN cuja o propósito era melhorar operações por ciclo. Por isso até então a AMD só pode alongar seu número de unidades de computação e não aumentar o número de Shader Engines.
O meu palpite é que em um futuro próximo a AMD começe a pensar em GPUs ligadas pelo infinite fabric que é o que a Nvidia e Intel querem fazer.
Isso permitiria eles não serem obrigados a voltar pra HBM.
Quanto ao XSX ele estando nos mesmos limite do Navi10 significa ênfase em TOPs16/8,só ver como a MS enfatizou 25TF quando opera RT, a outra parte é o DXML cRNN, tudo que foi mostrado no DX12U.
Vamos fingir que RDNA aconteceu pois a Cerny e os demais engenheiros Sony não estavam satisfeitos com os ciclos de instruções GCN quando receberam a ordem vindo de cima, que o próximo hardware teria que se adequar aos acordos verdes Europeu. Então o que os caras Sony queriam era o máximo de operações FP/INT32 no menor CPI, então eles junto aos engenheiros da AMD começam a trabalhar na sua arquitetura sua condicionada enquanto a Microsoft pensa que tem que fazer o mesmo mas com maior poder. A Sony migrou para o Socket FP6 usado em chips menores que 300mm a MS permanece no mesmo Socket. Sony por exemplo tanto no PS4pro como no PS4s estava cortando custo do Socket, enquanto a Microsoft mantém o custo. Com custo e espaço a MS pede para AMD adicionar as mesmas plataformas que ela vinha trabalhando com a Nvidia, disso nasce o Socket XSX. Sony percebeu que ficou muito para trás e que isso pode impactar vendas, eles conversam com Cerny e ele propõe aumentar os clocks criando setups, isso permitiria manter uma assinatura regulatoria uma vez que o consumo de um chip é relativo ao calor dissipado, um cooler boxe e um gabinete bem condicionado resolveria. Só que a MS tem seus espiões industriais, então eles incrementam um gabinete e elevam seus Clocks. Isso deixa a Sony meio sem saída. Então temos uma Sony que ainda reluta para revelar seu console.
Meu palpite? A Sony pode está atrasando o PS5 com o objetivo de fazer o chip nos N6 que entra em produção de massa agora, isso permitiria a eles fazer um BGA 15% menor que os N7P. Então essas Specs de Cerny não são mais que uma estimativa, eles não tem o chip final em mãos.
O que penso é que o chip final deve ser feito em torno dos requisitos anunciados por Cerny mas sem ser qualquer tipo de gambiarra apenas para demonstrar equivalência.
Estavam muito bem quando te cingias aos factos… Começas a entrar em teorias e cai tudo por água abaixo…
Teorias não…
Isto não tem nada que saber… é equivalente ao Max-q da Nvidia. E não é preciso justificar nada com grandes teorias… senão com o facto que o Covid está a atrasar as coisas conforme planeadas.
Eu mesmo falei aqui que era equivalente ao Max Q lembra? E a Sony não está atrasando apenas pelo Covid, sempre foi um objetivo migrar de N7P para N6;
https://www.anandtech.com/show/14290/tsmc-most-7nm-clients-will-transit-to-6nm
– Novembro 2018 Ariel > N7 GPU clock 1800MHz
– Abril 2019 Gonzalo > N7P GPU 2000MHz
– Abril 2020 > N6 GPU 2200MHz
Lembra desse relato?
https://www.msn.com/pt-br/esportes/other/phil-spencer-afirma-que-j%C3%A1-est%C3%A1-jogando-no-xbox-scarlett/ar-BBXOAt7
Se Phil já estava jogando o XSX usa N7P. A Sony não tinha nem mesmo escolhido o design industrial do console ainda, então eles nunca pretendiam fazer isso em simultâneo com a MS. Isso significa que eles pretendiam lançar em um processo mais eficaz.
Ao invés de aumentar o chip, eles usam processos mais avançados para reduzir e atingir melhor a meta de consumo sem o custo do desenvolvimento de um woofer completamemte novo.
É o que estou falando em muitos comentários aqui, o chip final não é o que apareceu no Github que é uma versão mais antiga.
E atrasar não é o mesmo que adiar, a Sony pode está trocando o novembro de 2019 pelo março de 2020 permanecendo ainda dentro do seu trimestre fiscal.
Sim, lembro Shin. Mérito a quem o merece!
Quando ao N6 é uma possibilidade.
Dado o trabalho da MS com o One X, eu acredito que eles tem soluções para evitar a penalização das performances. Na entrevista a Digital Foundry eles dizem algumas coisas sobre o design de memória assimétrico. É melhor ler lá do que tentar decifrar algo que não se tem total conhecimento ou demonstrações, a não ser o fato de que o console pode executar Gears 5 em 4K 60 FPS e configurações gráficas melhoras que nem estão disponíveis na versão PC.
“Do ponto de vista da Microsoft, ainda é um sistema de memória unificada, mesmo que o desempenho possa variar.
Parece uma situação um tanto complexa, especialmente quando a própria Microsoft já entregou uma interface de memória mais tradicional e mais ampla no Xbox One X.”
Artigo de Richard Leadbetter, Editor de tecnologia, Digital Foundry
Gears 5 foi feito para correr numa máquina com 8 GB. Pode correr todo nos 10 GB rápidos.
A propósito, a Nvidia também falou muito sobre a memória assimétrica. Não ia ser um problema!
Daí que apesar de pessoalmente acreditar que poderá não ser um problema, vou esperar para ver.
O engenheiro de renderização da Crytek(Ali Salehi) deu uma entrevista ontem e disse o mesmo que você comentou sobre as memórias, Mário! Só não foi tão detalhado quanto você neste artigo! De forma resumida: Acredita que os pools de memória divididos serão um problema e que os 12 teraflops do XBOX só serão alcançados em casos específicos(talvez se referindo a jogos first party) que é mais um número teórico e da forma que o PS5 foi desenvolvido conseguirá tirar muito mais dele! Infelizmente em menos de 24hrs fizeram ele apagar a entrevista, talvez a M$ tenha ligado na Crytek.. o negócio tava pegando fogo em fóruns pelo mundo, muito estranho!
Que a divisão vai criar limitações… é um dado adquirido. Agora que proporção isso toma eu não sei dizer. Pode ser um problema, pode não ser. O que este engenheiro refere é coerente. 10 GB de memória rápida não vão chegar… Quando a PS5 usa os 16 GB, eles vão querer usar tambem. E isso vai descer a largura de banda útil.
A questão é que a Xbox precisa de mais largura de banda. A largura de banda só existe com um fim, o alimentar os processadores. Menos processadores requerem menos largura de banda, mais processadores, mais largura de banda.
Ignorando o CPU a PS5 tem 12.44 GB para cada CU. A X tem 10,7. Basicamente a proporção está muito equilibrada com a X a ter mais 6% de largura de banda por CU, se tiveres em conta que a PS5 trabalha com 22% mais relógio mas só tem 16.2% mais largura de banda.
Mas se este problema se coloca, a largura de banda por CU cai valentemente… Numa utilização mediana de ambas as partes da RAM tens 394 GB/s na memória rápida, o que dá 7,57 GB/s a cada CU.
Pode efectivamente ser um problema. Eu já o tinha referido, este senhor que lida com isto directamente também o refere.