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.