Xbox One - Review e questões técnicas...

sirroman · 30 de junho de 2013

O luta danada para entender esse pessoal da Digital Foundry... só trabalhando lá... para falar "a mesma língua"!
Vamos ao que interessa.

Rumores

"Informantes" disseram ao Digital Foundry que a ESRAM (memória embutida) do Xbox One é ainda mais "potente" (do que aparenta) e a Microsoft está com expectativas elevadas em relação a perspectiva anterior, durante a pré-produção do console. O boato é que a ESRAM apresenta níveis de taxa de transferência de dados de até 88% mais elevado.

A largura de banda do X1 não é um destaque, visto o emprego da GDDR3, o que não se compara favoravelmente a memória GDDR5 de 8GB (e a APU) usadas no PS4.

Mas os "32 MB de RAM estática incorporado" dentro do processador do Xbox tem como objetivo fazer a diferença e foi pensado para manter uma taxa de transferência máxima teórica de 102 GB/s - ainda aquém dos 176 GB/s do PlayStation 4.

Agora que o chip de silício está disponível, a Microsoft revisou seu projeto e acredita que 192GB/s é teoricamente possível.

Então, como poderia as próprias equipes de tecnologia internas da Microsoft terem subestimado a capacidade de seu próprio hardware por uma margem tão grande?

Ainda de acordo com as fontes, a alegação de largura de banda originais deriva de um cálculo bastante básico - 128 bytes por bloco, multiplicado pela velocidade GPU de 800MHz: oferece-se a taxa de transferência máxima anterior de 102.4GB/s.

Acredita-se que este cálculo se mantém fiel, separado de leitura / gravação, operações "de" e "para" o ESRAM.

No entanto, com produção de silício em estágio final, os técnicos da Microsoft descobriram que o hardware é capaz de ler e escrever ao mesmo tempo. Aparentemente, existem peças de processamento do ciclo de "buracos" que podem ser utilizados para operações adicionais. Mas o desempenho máximo teórico é uma coisa e a prática é outra. Em cenários que simulam a vida real, acredita-se que 133GB/s de transferência foi alcançado com operações "alfa", "mistura FP16 (x4)".

"Desempenho máximo teórico é uma coisa, mas em cenários da vida real, acredita-se que 133GB/s de transferência foi alcançado com algumas operações ESRAM".

Embora nenhuma das fontes não estejam "a par" de todos os problemas de produção que a Microsoft pode (ou não) estar enfrentando com seu novo aparelho, as fontes acreditam que ela está fazendo títulos para o X1 e não foram informadas de quaisquer outros aspectos acerca dos desafios de produção.

fonte: EuroGamer

Vi isso, deve ajudar, mas não muda o fato que o X1 vai ter um sistema de memória muito mais complexo que o do PS4 o que pode limitar as coisas "na prática".

Por outro lado, se bem feito, o SW do X1 talvez possa ser substancialmente melhor em algumas coisas específicas?

Gotoa · 1 de julho de 2013

Por outro lado, se bem feito, o SW do X1 talvez possa ser substancialmente melhor em algumas coisas específicas?

Temos que reconhecer que a MS fez um bom trabalho com o Xbox One (tanto quanto a Sony fez com o PS4); ela só "deslizou" no "marketing", e principalmente, na desastrosa tentativa de implementar medidas de austeridade e DRM (que poderiam levar o seu novo aparelho a "extinção"); e ela tem outros "alvos" além dos tradicionais gamers, pretende ser uma "central multimidia" também.

Vi isso, deve ajudar, mas não muda o fato que o X1 vai ter um sistema de memória muito mais complexo que o do PS4 o que pode limitar as coisas "na prática".

Sobre "limitações", ninguém pode afirmar nada ainda - são apenas especulações, os consoles ainda não "sairam do forno" ou não "chegaram a mesa" dos consumidores (tanto Xbox One quanto PS4).

O que tem me preocupado é se a MS vai ou não implementar a fonte interna no seu novo aparelho que é consideravelmente poderoso (a Sony vai implementar no PS4).

Confesso que não sou "consumidor cobaia" e vou ficar com meu console atual até as coisas melhorarem. O mais sensato é aguardar mais de 1 ano, esperar como o X1 vai se portar no mercado, é um prazo razoável para constatar se haverá problemas e como eles serão resolvidos.

Gotoa · 2 de julho de 2013

A M$ tem potencial, SIM, Jimmyzika e eu acreditava nele (X1) no início... talvez o patrão da empresa esteja "mal assessorado", se é que vocês me entendem.

O CEO da Microsoft, Steve Ballmer, acumulará também a tarefa de presidente de negócios interativos (e, consequentemente, do Xbox One) na empresa. O executivo revelou a mudança em carta publicada na qual deseja boa sorte para Don Mattrick, que acaba de deixar o cargo para se tornar o CEO da produtora de games sociais Zynga.

"Essa é uma grande oportunidade para Don e desejo todo sucesso a ele", disse o executivo. "Nesses seis anos, ele e seu time atingiram muitas metas. A Xbox Live cresceu de 6 para 48 milhões de usuários", nota Ballmer, que também fala sobre grandes resultados com o acessório Kinect e jogos de Xbox 360.

No comunicado, Ballmer explica que o cargo de Mattrick não receberá substituto imediatamente e todos os empregados dessa divisão passam a prestar contas diretamente para ele. "Os subordinados de Don responderão a mim e continuaremos o trabalho diário como um time, particularmente focados no lançamento do Xbox One em novembro", disse Ballmer.

O executivo também enalteceu o trabalho que a empresa em geral está fazendo com o Xbox One. "Eu estou incrivelmente orgulhoso dos esforços e da visão que culminaram no Xbox One. Estou particularmente animado de ver como o novo Xbox fará bem para os nossos aparelhos e serviços, unindo o que há de melhor na Microsoft", disse Ballmer a respeito da interação entre os aplicativos e diferentes dispositivos da MS que serão compatíveis com o Xbox One.

"Obrigado, Don, por nos dar um caminho para redefinir completamente a indústria do entretenimento", concluiu Ballmer.

O Xbox One foi anunciado em 21 de maio nos Estados Unidos. O novo console chegará em novembro ao Brasil por 2.199 reais, com Kinect incluso.

fonte: Abril

sirroman · 3 de julho de 2013

Sobre "limitações", ninguém pode afirmar nada ainda - são apenas especulações, os consoles ainda não "sairam do forno" ou não "chegaram a mesa" dos consumidores (tanto Xbox One quanto PS4).

N tem para onde correr não, o sistema de memória do X1 é mais complexo do que o do PS4. Isso obrigatoriamente é uma limitação. Desenvolvedores de jogos para consoles são acostumados com problemas como esses, mas não deixa de ser uma limitação ao menos no início da vida do console.

Gotoa · 3 de julho de 2013

N tem para onde correr não, o sistema de memória do X1 é mais complexo do que o do PS4. Isso obrigatoriamente é uma limitação. Desenvolvedores de jogos para consoles são acostumados com problemas como esses, mas não deixa de ser uma limitação ao menos no início da vida do console.

Prezado membro, na sua opinião - contando com suas observações e experiência, qual seria então a razão da MS implementar um sistema de memória mais complexo no X1 (em comparação ao PS4)? Se deve a redução de custos na produção? Ou teria outro motivo?

sirroman · 5 de julho de 2013

Prezado membro, na sua opinião - contando com suas observações e experiência, qual seria então a razão da MS implementar um sistema de memória mais complexo no X1 (em comparação ao PS4)? Se deve a redução de custos na produção? Ou teria outro motivo?

Rapaz custo de produção não dá para ter certeza. Basicamente a M$ vai economizar em componentes externos (memória GDDR5 do PS4 é bem mais cara que a DDR3 e consome mais energia também) em troca de gastar mais no chip, pois essa ESRAM está completamente integrada no chip (ou mais especificamente no "die"), logo aumenta consideravelmente o tamanho do chip (falam em 40%, mas eu digo de cabeça).

A questão é que eu não tenho todas as informações para analisar todos os custos e benefícios de cada uma das implementações. Gente muito mais esperta debate sobre isso e apesar de algumas terem opiniões mais fortes, ninguém está realmente acusando a M$, no geral dizem que provavelmente não foi a melhor opção.

Assim, a ESRAM tem uma latência bem menor que a GGDR5 e a DDR3 (tipo, astronomicamente melhor) e a velocidade dela também é comparativamente muito grande, acontece que ela ocupa muito espaço e assim tem uma capacidade de memória diminuta. Assim a M$ tem 32mb de memória disponível que provavelmente é o sonho de todo o desenvolvedor... mas ainda é apenas 32 mb.

Para superar esse problema a M$ aparentemente desenvolveu diversos mecanismos, como os move engines, e também recentemente atualizou o DX (agora 11.2) com recursos que permitem um uso bem mais inteligente da memória... Parece que a M$ quis desde o começo repetir o sucesso que foi a microarquitetura do X360 (é semelhante, com um sister die de memória) e acabou deixando tudo bem mais complexo do que precisava ser. SE ela vai conseguir traduzir essas vantagens específicas em melhor qualidade é outros quinhentos.

No fim das contas pode até ser que o X1 tenha um sistema de memória que forneça muito mais performance que o do PS4 e os jogos do X1 podem ter certas características consideravelmente melhores que o do PS4... se o desenvolvedor souber gerenciar tudo corretamente.

Inclusive eu tenho certeza que alguns jogos vão sair assim: desenvolvedor para console é uma raça acostumada a se virar com o que tem (leia-se o povo que mexeu com o Cell do PS3) e tirar o máximo que pode, além de que a M$ vai abrir os cofres para financiar o que for necesário e assim ganhar alguma vantagem no mercado. O problema é que no começo os jogos podem (não digo vão pois desenvolvedor já mexeu com coisa mais estranha e a M$ deve disponibilizar as melhores ferramentas que tiver disponível) sofrer um pouco (assim como os multiplataformas).

E, por outro lado e na minha opinião, a Sony simplesmente escolheu a solução mais simples e direta (tanto que pôde economizar espaço no chip suficiente para colocar uma GPU maior). Eu gostei das escolhas da Sony no PS4.

PS.: só para eu ser o mais completo possível, tecnicamente a M$ vai poder diminuir o tamanho do chip (reduzindo a litografia da fabricação do chip, dos 28nm de agora para, digamos 20nm ou ainda menor) e isso pode fazer com que daqui a uns 2~3 anos o X1 seja mais barato que o PS4 (até porque a GDDR5 pode acabar sendo substituida por outro tipo de memória o que aumentaria novamente o seu custo). Certamente isso também foi levado em conta pela M$, mas é algo bem relativo... Precisamos ver se vai valer a pena ou não.

PPS.: moderação, se decidirem que esse post não é adequado aqui, por favor, migrem para o tópico apropriado para tal.

Gotoa · 6 de julho de 2013

N tem para onde correr não, o sistema de memória do X1 é mais complexo do que o do PS4. Isso obrigatoriamente é uma limitação. Desenvolvedores de jogos para consoles são acostumados com problemas como esses, mas não deixa de ser uma limitação ao menos no início da vida do console.

Prezado membro, na sua opinião - contando com suas observações e experiência, qual seria então a razão da MS implementar um sistema de memória mais complexo no X1 (em comparação ao PS4)? Se deve a redução de custos na produção? Ou teria outro motivo?

Rapaz custo de produção não dá para ter certeza.

Será?

Então porque a MS não apostou também na "solução mais simples e direta" da concorrência?

Por isso perguntei se existia outra razão além dessa.

Basicamente a M$ vai economizar em componentes externos (memória GDDR5 do PS4 é bem mais cara que a DDR3 e consome mais energia também) em troca de gastar mais no chip, pois essa ESRAM está completamente integrada no chip (ou mais especificamente no "die"), logo aumenta consideravelmente o tamanho do chip (falam em 40%, mas eu digo de cabeça).

A questão é que eu não tenho todas as informações para analisar todos os custos e benefícios de cada uma das implementações. Gente muito mais esperta debate sobre isso e apesar de algumas terem opiniões mais fortes, ninguém está realmente acusando a M$, no geral dizem que provavelmente não foi a melhor opção.

E quem tem as "informações técnicas" além daqueles que estão envolvidos diretamente (e indiretamente) no processo de produção (e testes...)?

Assim, a ESRAM tem uma latência bem menor que a GGDR5 e a DDR3 (tipo, astronomicamente melhor) e a velocidade dela também é comparativamente muito grande, acontece que ela ocupa muito espaço e assim tem uma capacidade de memória diminuta. Assim a M$ tem 32mb de memória disponível que provavelmente é o sonho de todo o desenvolvedor... mas ainda é apenas 32 mb.

Eu pergunto: essa será a "carta na manga" da MS?

Para superar esse problema a M$ aparentemente desenvolveu diversos mecanismos, como os move engines, e também recentemente atualizou o DX (agora 11.2) com recursos que permitem um uso bem mais inteligente da memória... Parece que a M$ quis desde o começo repetir o sucesso que foi a microarquitetura do X360 (é semelhante, com um sister die de memória) e acabou deixando tudo bem mais complexo do que precisava ser. SE ela vai conseguir traduzir essas vantagens específicas em melhor qualidade é outros quinhentos.

Temos que reconhecer que a MS fez um bom trabalho com o Xbox One (tanto quanto a Sony fez com o PS4); ela só "deslizou" no "marketing", e principalmente, na desastrosa tentativa de implementar medidas de austeridade e DRM (que poderiam levar o seu novo aparelho a "extinção"); e ela tem outros "alvos" além dos tradicionais gamers, pretende ser uma "central multimidia" também.

Acredito que o X1 estará "a altura" da concorrência, vai conquistar seu público, e tudo na medida do possível. E qualquer empresa desse segmento está sujeita a falhas e imprevistos.

No fim das contas pode até ser que o X1 tenha um sistema de memória que forneça muito mais performance que o do PS4 e os jogos do X1 podem ter certas características consideravelmente melhores que o do PS4... se o desenvolvedor souber gerenciar tudo corretamente.

Inclusive eu tenho certeza que alguns jogos vão sair assim: desenvolvedor para console é uma raça acostumada a se virar com o que tem (leia-se o povo que mexeu com o Cell do PS3) e tirar o máximo que pode, além de que a M$ vai abrir os cofres para financiar o que for necesário e assim ganhar alguma vantagem no mercado. O problema é que no começo os jogos podem (não digo vão pois desenvolvedor já mexeu com coisa mais estranha e a M$ deve disponibilizar as melhores ferramentas que tiver disponível) sofrer um pouco (assim como os multiplataformas).

Cada um se vira com o que pode e o que tem, não é?

Na época do X360 (e PS3) a mentalidade era outra. Os profissionais das produtoras de hoje saberão lidar melhor com essas novas plataformas, visto que os consoles estão se tornando cada vez mais parecidos com os PC.

Repare que o Xbox One (e PS4) sem valem de tecnologias da AMD: isso é a evidência de uma mudança na "mentalidade da indústria".

Frank Azor, gerente geral da Alienware disse outra vez que: "Se você olhar para o que a Microsoft e a Sony estão fazendo, eles estão pegando PCs e colocando em sua sala de estar. É uma CPU AMD, é uma APU da AMD, é um disco rígido de pc. É inacreditável!"

"Você está instalando jogos agora em vez de executá-los somente pelos discos, porque isso é a coisa certa a ser feita; Você está baixando jogos digitalmente que estamos fazendo no PC durante anos; eles estão se integrando a certos aspectos da TV e outras funcionalidades (...)."

E, por outro lado e na minha opinião, a Sony simplesmente escolheu a solução mais simples e direta (tanto que pôde economizar espaço no chip suficiente para colocar uma GPU maior). Eu gostei das escolhas da Sony no PS4.

Confesso que não sou "consumidor cobaia" e vou ficar com meu console atual até as coisas melhorarem. O mais sensato é aguardar mais de 1 ano, esperar como o X1 vai se portar no mercado, é um prazo razoável para constatar se haverá problemas e como eles serão resolvidos.

Vou esperar um tempo, para ver como os consoles irão se comportar, e principalmente, se os jogos irão usufruir das tecnologias empregadas.

Eu confesso que gostei mais do PS4, mas se houver reduções no custo final do aparelho e houver bons títulos a preços acessíveis para o X1, aí vou considerar a aquisição do último. Mas no presente momento, deixei a decisão "em aberto".

Esperando para ver se sai o conteúdo da revista e comparar com as minhas impressões e achismos.

PS.: só para eu ser o mais completo possível, tecnicamente a M$ vai poder diminuir o tamanho do chip (reduzindo a litografia da fabricação do chip, dos 28nm de agora para, digamos 20nm ou ainda menor) e isso pode fazer com que daqui a uns 2~3 anos o X1 seja mais barato que o PS4 (até porque a GDDR5 pode acabar sendo substituida por outro tipo de memória o que aumentaria novamente o seu custo).
Certamente isso também foi levado em conta pela M$, mas é algo bem relativo... Precisamos ver se vai valer a pena ou não.

Não tenho "bola de cristal" (ou máquina do tempo), mas dá para fazer previsões com os dados que temos disponíveis...

sirroman · 7 de julho de 2013

Vamos por partes ^^.

E quem tem as "informações técnicas" além daqueles que estão envolvidos diretamente (e indiretamente) no processo de produção (e testes...)?

Sinceramente? Apenas o pessoal que esta diretamente relacionado mesmo... No maximo da para analisar depois de tudo os indicios e dizer se foi isso ou aquilo.

Quanto ao ESRAM

Eu pergunto: essa será a "carta na manga" da MS?

Tipo, pelo simples fato da M$ ter gasto uma BOA parte do die nessa memoria ela claramente "colocou o dinheiro" nessa solucao, n posso dizer que é uma "carta na manga" hehe, mas certamente é a carta que a M$ tem na mao. Foi uma aposta.

Será?
Então porque a MS não apostou também na "solução mais simples e direta" da concorrência?

Por isso perguntei se existia outra razão além dessa.

EU acho que foi uma questao do ponto de partida. A M$ tinha o sistema muito bom do X360 e resolveu construir algo em cima, semelhante. Certamente funciona, certamente tem suas vantagens (e desvantagens), mas a Sony simplesmente chegou na prancheta sem ter uma ideia marcada e chegou a uma solucao a primeira vista mais simples e... por que n? elegante (pois esses move engines n parecem muito bonitos olhando de longe n....)

Mas só para ficar claro, os engenheiros da M$ e da AMD n fizeram uma loucura: foi uma escolha consciente que pode ser benefica ou n.

Acredito que o X1 estará "a altura" da concorrência, vai conquistar seu público, e tudo na medida do possível. E qualquer empresa desse segmento está sujeita a falhas e imprevistos.

Sem duvida. Mais sobre isso a seguir:

Cada um se vira com o que pode e o que tem, não é?

Na época do X360 (e PS3) a mentalidade era outra. Os profissionais das produtoras de hoje saberão lidar melhor com essas novas plataformas, visto que os consoles estão se tornando cada vez mais parecidos com os PC.

Repare que o Xbox One (e PS4) sem valem de tecnologias da AMD: isso é a evidência de uma mudança na "mentalidade da indústria".

Frank Azor, gerente geral da Alienware disse outra vez que: "Se você olhar para o que a Microsoft e a Sony estão fazendo, eles estão pegando PCs e colocando em sua sala de estar. É uma CPU AMD, é uma APU da AMD, é um disco rígido de pc. É inacreditável!"

"Você está instalando jogos agora em vez de executá-los somente pelos discos, porque isso é a coisa certa a ser feita; Você está baixando jogos digitalmente que estamos fazendo no PC durante anos; eles estão se integrando a certos aspectos da TV e outras funcionalidades (...)."

Concordo, os resultados disso tudo a gente ainda n sabe (OBVIO xD) mas é provavel que as coisas fiquem mais simples para o desenvolvedor.

O risco que a M$ tem que saber manejar é equilibrar a dificuldade do seu sistema de memoria contra o da Sony, pois se tudo ficar muito mais fácil, alguns desenvolvedores podem simplesmente considerar que n vale a pena investir no X1, o que poderia fazer com que uma boa parcela dos 3rd parties lancem seus produtos principalmente no PS4 (com ports meia-bocas), dificultando a posicao competitiva do X1, fazendo com que o PS4 tenha uma vantagem na userbase que venha a mudar a ideia das OUTRAS desenvolvedoras, que focariam no PS4, o que novamente complicaria a situacao do X1 e... nesse circulo vicioso a Sony ganharia o mercado.

MAS tb pode acontecer que, ja que os custos globais de desenvolvimento devem cair, as desenvolvedoras vão... poder dispor de recursos para otimizar melhor para o X1, nesse caso fazendo com que as vantagens que o HW do X1 apresenta se materializem nos jogos, possivelmente mudando o equilibrio da balanca e dando uma vantagem para a M$.

Tb tem gente que acha que os consoles vão simplesmente desaparecer, n da pra saber o que vai acontecer. xD

Vou esperar um tempo, para ver como os consoles irão se comportar, e principalmente, se os jogos irão usufruir das tecnologias empregadas.
Eu confesso que gostei mais do PS4, mas se houver reduções no custo final do aparelho e houver bons títulos a preços acessíveis para o X1, aí vou considerar a aquisição do último. Mas no presente momento, deixei a decisão "em aberto".

A rigor o x1 nao ta "caro" em relação ao PS4, a diferenca entre os dois é justificada pelo Kinect. Agora: sera que o Kinect realmente é um fator que vai valer essa diferenca? A M$ claramente errou no modelo de negocios inicial, ela foi apressada demais querendo empurrar pela goela aquele negocio de always-on e etc, etc. N sei ela escolheu o momento certo de empurrar o Kinect como esta planejando fazer agora (mas se você me perguntar eu diria que sim, a hora é essa pois daqui a cinco anos o Kinect pode se tornar irrelevante), mas ela esta investindo pesado nisso.

Não tenho "bola de cristal" (ou máquina do tempo), mas dá para fazer previsões com os dados que temos disponíveis...

Sim, mas o que eu quis dizer com aquilo é que a M$ tem MAIS a ganhar em uma eventual reducao de custos com a diminuicao da litografia dos chips, pois ela ja economiza nos demais componentes (PCB, memoria, etc), então a reducao dos custos no chip vai ser substancial. Alem disso a M$ tb é bem mais agressiva nos shrinks e revisoes de chips que a Sony (pode ver que foram varias revisoes do chip do X360), então ela deve ter levado isso em conta desde o primeiro dia.

Gotoa · 8 de julho de 2013

Sinceramente? Apenas o pessoal que esta diretamente relacionado mesmo... No maximo da para analisar depois de tudo os indicios e dizer se foi isso ou aquilo.

Tem aqueles que lidam indiretamente com o projeto também - os "não-técnicos" ou administradores; se bobear, até o patrão da empresa (você acha que ele não quer saber onde estão aplicando os seus fundos?)

Quanto ao ESRAM:
Tipo, pelo simples fato da M$ ter gasto uma BOA parte do die nessa memoria ela claramente "colocou o dinheiro" nessa solucao, n posso dizer que é uma "carta na manga" hehe, mas certamente é a carta que a M$ tem na mao. Foi uma aposta.

Cada empresa vai dar suas "cartadas", só que nesse jogo acho que ninguém vai perder!

EU acho que foi uma questao do ponto de partida. A M$ tinha o sistema muito bom do X360 e resolveu construir algo em cima, semelhante. Certamente funciona, certamente tem suas vantagens (e desvantagens), mas a Sony simplesmente chegou na prancheta sem ter uma ideia marcada e chegou a uma solucao a primeira vista mais simples e... por que n? elegante (pois esses move engines n parecem muito bonitos olhando de longe n....)

Elegante... pelo visto dinheiro não é problema para certas empresas!

Mas só para ficar claro, os engenheiros da M$ e da AMD n fizeram uma loucura: foi uma escolha consciente que pode ser benefica ou n.

Isso só veremos com o tempo!

Concordo, os resultados disso tudo a gente ainda n sabe (OBVIO xD) mas é provavel que as coisas fiquem mais simples para o desenvolvedor.

Com certeza, agora a realidade é outra.

A rigor o x1 nao ta "caro" em relação ao PS4, a diferenca entre os dois é justificada pelo Kinect. Agora: sera que o Kinect realmente é um fator que vai valer essa diferenca? A M$ claramente errou no modelo de negocios inicial, ela foi apressada demais querendo empurrar pela goela aquele negocio de always-on e etc, etc. N sei ela escolheu o momento certo de empurrar o Kinect como esta planejando fazer agora (mas se você me perguntar eu diria que sim, a hora é essa pois daqui a cinco anos o Kinect pode se tornar irrelevante), mas ela esta investindo pesado nisso.

MAS tb pode acontecer que, ja que os custos globais de desenvolvimento devem cair, as desenvolvedoras vão... poder dispor de recursos para otimizar melhor para o X1, nesse caso fazendo com que as vantagens que o HW do X1 apresenta se materializem nos jogos, possivelmente mudando o equilibrio da balanca e dando uma vantagem para a M$.

Ouvi boatos por aí... dizendo que o custo do novo Kinect é uns 50~60 dólares, avulso; então meu amigo, está caro (considerando a arquitetura do PS4 e o acessório dele que é opcional).

Sim, mas o que eu quis dizer com aquilo é que a M$ tem MAIS a ganhar em uma eventual reducao de custos com a diminuicao da litografia dos chips, pois ela ja economiza nos demais componentes (PCB, memoria, etc), então a reducao dos custos no chip vai ser substancial. Alem disso a M$ tb é bem mais agressiva nos shrinks e revisoes de chips que a Sony (pode ver que foram varias revisoes do chip do X360), então ela deve ter levado isso em conta desde o primeiro dia.

Então se formos levar em consideração o seu raciocínio (e se ele se materializar após lançamento e os primeiros meses de vida no mercado e a "evolução" dos jogos na plataforma), é bem mais sensato aguardar por uma "revisão", ao invés de adquirir a "primeira edição". Deixe que os "fanboys da marca" sejam os "vanguardistas" (ou a "linha de frente") e abram alas para os consumidores mais exigentes!

sirroman · 9 de julho de 2013

Ouvi boatos por aí... dizendo que o custo do novo Kinect é uns 50~60 dólares, avulso; então meu amigo, está caro (considerando a arquitetura do PS4 e o acessório dele que é opcional).

$50 reais aqui, acolá, fica na margem de lucro. Mas eu acho improvável que o Kinect avulso fique por ai, deve ser mais perto dos $100.

Então se formos levar em consideração o seu raciocínio (e se ele se materializar após lançamento e os primeiros meses de vida no mercado e a "evolução" dos jogos na plataforma), é bem mais sensato aguardar por uma "revisão", ao invés de adquirir a "primeira edição". Deixe que os "fanboys da marca" sejam os "vanguardistas" (ou a "linha de frente") e abram alas para os consumidores mais exigentes!

Isso é com todo eletrônico, quem compra de largada paga mais caro.

Mas uma revisão do chip deve demorar pelo menos 2 anos, mais ou menos o tempo em que elas devem estar planejando fazer uma revisão do HW. Mas acho que a Sony vai demorar mais, em torno dos 3 anos.

gandalfnho · 4 de setembro de 2013

Data de lançamento anunciada

Foi anunciado hoje que o Xbox One deverá ser lançado dia 22 de novembro em 13 países: Austrália, Áustria, Brasil, Canadá, França, Alemanha, Irlanda, Itália, México, Nova Zelândia, Espanha, Reino Unido e Estados Unidos.

Além disso, o executivo de marketing do Xbox, Yusuf Mehdi, confirmou que o CPU do console passou de 1.6 Ghz para 1.75 GHz.

Fonte: IGN

Gotoa · 15 de setembro de 2013

Mas uma revisão do chip deve demorar pelo menos 2 anos, mais ou menos o tempo em que elas devem estar planejando fazer uma revisão do HW. Mas acho que a Sony vai demorar mais, em torno dos 3 anos.

Ambas contam com "belos" (e eficientes) aparelhos, vão mexer agora para que, né?

Data de lançamento anunciada
Foi anunciado hoje que o Xbox One deverá ser lançado dia 22 de novembro em 13 países: Austrália, Áustria, Brasil, Canadá, França, Alemanha, Irlanda, Itália, México, Nova Zelândia, Espanha, Reino Unido e Estados Unidos.

Além disso, o executivo de marketing do Xbox, Yusuf Mehdi, confirmou que o CPU do console passou de 1.6 Ghz para 1.75 GHz.

Fonte: IGN

Só o valor final dele - aqui no Brasil, é que está desanimando... Só os "fãs da marca e jogos exclusivos" é que vão comprar "de cara" no ano de lançamento.

sirroman · 3 de outubro de 2013

Sobre o hardware do Xbox1

http://www.eurogamer.net/articles/digitalfoundry-vs-the-xbox-one-architects

Gotoa · 10 de outubro de 2013

Sobre o hardware do Xbox1
http://www.eurogamer.net/articles/digitalfoundry-vs-the-xbox-one-architects

Boa Sirroman! Material de primeira!

Análise e trechos do artigo

O que achei interessante e digno de ser citado aqui:

"The combined system bandwidth controversy

Baker is keen to tackle the misconception that the team has created a design that cannot access its ESRAM and DDR3 memory pools simultaneously. Critics say that they're adding the available bandwidths together to inflate their figures and that this simply isn't possible in a real-life scenario."

"You can think of the ESRAM and the DDR3 as making up eight total memory controllers, so there are four external memory controllers (which are 64-bit) which go to the DDR3 and then there are four internal memory controllers that are 256-bit that go to the ESRAM. These are all connected via a crossbar and so in fact it will be true that you can go directly, simultaneously to DRAM and ESRAM," he explains.

"We had to pull over all of our vertex buffers and all of our textures out of system memory concurrent with going on with render targets, colour, depth, stencil buffers that were in eDRAM. Of course with Xbox One we're going with a design where ESRAM has the same natural extension that we had with eDRAM on Xbox 360, to have both going concurrently. It's a nice evolution of the Xbox 360 in that we could clean up a lot of the limitations that we had with the eDRAM."

"The Xbox 360 was the easiest console platform to develop for, it wasn't that hard for our developers to adapt to eDRAM, but there were a number of places where we said, 'gosh, it would sure be nice if an entire render target didn't have to live in eDRAM' and so we fixed that on Xbox One where we have the ability to overflow from ESRAM into DDR3, so the ESRAM is fully integrated into our page tables and so you can kind of mix and match the ESRAM and the DDR memory as you go... From my perspective it's very much an evolution and improvement - a big improvement - over the design we had with the Xbox 360. I'm kind of surprised by all this, quite frankly."

"Oh, absolutely. And you can even make it so that portions of our your render target that have very little overdraw... for example if you're doing a racing game and your sky has very little overdraw, you could stick those sub-sets of your resources into DDR to improve ESRAM utilisation," he says, while also explaining that custom formats have been implemented to get more out of that precious 32MB.

"On the GPU we added some compressed render target formats like our 6e4 [6 bit mantissa and 4 bits exponent per component] and 7e3 HDR float formats [where the 6e4 formats] that were very, very popular on Xbox 360, which instead of doing a 16-bit float per component 64bpp render target, you can do the equivalent with us using 32 bits - so we did a lot of focus on really maximising efficiency and utilisation of that ESRAM."

Memory bandwidth for next-gen consoles is clearly a hot topic in tech discussions. GDDR5 is a known technology and its capabilities in terms of throughput are well-known. ESRAM is a different matter entirely, and especially after Microsoft massively revised Xbox One's bandwidth figures upwards, there have been demands for the tech team to show their calculations.

Here, Nick Baker does just that:

"[ESRAM has four memory controllers and each lane] is 256-bit making up a total of 1024 bits and that in each direction. 1024 bits for write will give you a max of 109GB/s and then there's separate read paths again running at peak would give you 109GB/s.

"What is the equivalent bandwidth of the ESRAM if you were doing the same kind of accounting that you do for external memory? With DDR3 you pretty much take the number of bits on the interface, multiply by the speed and that's how you get 68GB/s. That equivalent on ESRAM would be 218GB/s. However just like main memory, it's rare to be able to achieve that over long periods of time so typically an external memory interface you run at 70-80 per cent efficiency.

"The same discussion with ESRAM as well - the 204GB/s number that was presented at Hot Chips is taking known limitations of the logic around the ESRAM into account. You can't sustain writes for absolutely every single cycle. The writes is known to insert a bubble [a dead cycle] occasionally... one out of every eight cycles is a bubble so that's how you get the combined 204GB/s as the raw peak that we can really achieve over the ESRAM. And then if you say what can you achieve out of an application - we've measured about 140-150GB/s for ESRAM.

"That's real code running. That's not some diagnostic or some simulation case or something like that. That is real code that is running at that bandwidth. You can add that to the external memory and say that that probably achieves in similar conditions 50-55GB/s and add those two together you're getting in the order of 200GB/s across the main memory and internally."

So 140GB-150GB is a realistic target and DDR3 bandwidth can really be added on top?

"Yes. That's been measured."

"Sony was actually agreeing with us. They said that their system was balanced for 14 CUs. They used that term: balance. Balance is so important in terms of your actual efficient design. Their additional four CUs are very beneficial for their additional GPGPU work. We've actually taken a very different tack on that. The experiments we did showed that we had headroom on CUs as well. In terms of balance, we did index more in terms of CUs than needed so we have ***** overhead. There is room for our titles to grow over time in terms of ***** utilisation."

Microsoft's approach to asynchronous GPU compute is somewhat different to Sony's - something we'll track back on at a later date. But essentially, rather than concentrate extensively on raw compute power, their philosophy is that both CPU and GPU need lower latency access to the same memory. Goossen points to the Exemplar skeletal tracking system on Kinect on Xbox 360 as an example for why they took that direction.

"Exemplar ironically doesn't need much ALU. It's much more about the latency you have in terms of memory fetch, so this is kind of a natural evolution for us," he says. "It's like, OK, it's the memory system which is more important for some particular GPGPU workloads."

The team is also keen to emphasise that the 150MHz boost to CPU clock speed is actually a whole lot more important than many believe it is.

"Interestingly, the biggest source of your frame-rate drops actually comes from the CPU, not the GPU," Goossen reveals. "Adding the margin on the CPU... we actually had titles that were losing frames largely because they were CPU-bound in terms of their core threads. In providing what looks like a very little boost, it's actually a very significant win for us in making sure that we get the steady frame-rates on our console."

"We've got a lot of CPU offload going on. We've got the SHAPE, the more efficient command processor relative to the standard design, we've got the clock boost - it's in large part actually to ensure that we've got the headroom for the frame-rates," Goossen continues - but it seems that the systems's Data Move Engines can help the GPU too."

sirroman · 12 de outubro de 2013

Boa Sirroman! Material de primeira!

Como causou certa confusão, postaram a transcrição integral da entrevista:

http://www.eurogamer.net/articles/digitalfoundry-the-complete-xbox-one-interview

Gotoa · 14 de outubro de 2013

Como causou certa confusão, postaram a transcrição integral da entrevista:
http://www.eurogamer.net/articles/digitalfoundry-the-complete-xbox-one-interview

Mais uma vez, valeu pela transcrição do artigo! Material de primeira! O primeiro artigo já tinha abrido meu apetite e esse saciou minha curiosidade! Mas lembre-se: é apenas uma entrevista! Só vamos constatar quando ambos consoles forem definitivamente lançados e testados por sites especializados, e principalmente, pelos jogadores no mundo afora!

Até que o artigo anterior que você postou não estava tão confuso, apenas textos dispersos. De certa forma o artigo não estava "didático" e haviam lacunas, mas deixaram apenas o "substancial".

Digital Foundry: What were your takeaways from your Xbox 360 post-mortem and how did that shape what you wanted to achieve with the Xbox One architecture?

Nick Baker: It's hard to pick out a few aspects we can talk about here in a small amount of time. I think one of the key points... We took a few gambles last time around and one of them was to go with a multi-processor approach rather than go with a small number of high IPC [instructions per clock] power-hungry CPU cores. We took the approach of going more parallel with cores more optimised for power/performance area. That worked out pretty well... There are a few things we realised like off-loading audio, we had to tackle that, hence the investment in the audio block. We wanted to have a single chip from the start and get everything as close to memory as possible. Both the CPU and GPU - give everything low latency and high bandwidth - that was the key mantra.

Some obvious things we had to deal with - a new configuration of memory, we couldn't really pass pointers from CPU to GPU so we really wanted to address that, heading towards GPGPU, compute shaders. Compression, we invested a lot in that so hence some of the Move Engines, which deal with a lot of the compression there... A lot of focus on GPU capabilities in terms of how that worked. And then really how do you allow the system services to grow over time without impacting title compatibility. The first title of the generation - how do you ensure that that works on the last console ever built while we value-enhance the system-side capabilities.

Digital Foundry: You're running multiple systems in a single box, in a single processor. Was that one of the most significant challenges in designing the silicon?

Nick Baker: There was lot of bitty stuff to do. We had to make sure that the whole system was capable of virtualisation, making sure everything had page tables, the IO had everything associated with them. Virtualised interrupts.... It's a case of making sure the IP we integrated into the chip played well within the system. Andrew?

Andrew Goossen: I'll jump in on that one. Like Nick said there's a bunch of engineering that had to be done around the hardware but the software has also been a key aspect in the virtualisation. We had a number of requirements on the software side which go back to the hardware. To answer your question Richard, from the very beginning the virtualisation concept drove an awful lot of our design. We knew from the very beginning that we did want to have this notion of this rich environment that could be running concurrently with the title. It was very important for us based on what we learned with the Xbox 360 that we go and construct this system that would disturb the title - the game - in the least bit possible and so to give as varnished an experience on the game side as possible but also to innovate on either side of that virtual machine boundary.

We can do things like update the operating system on the system side of things while retaining very good compatibility with the portion running on the titles, so we're not breaking back-compat with titles because titles have their own entire operating system that ships with the game. Conversely it also allows us to innovate to a great extent on the title side as well. With the architecture, from SDK to SDK release as an example we can completely rewrite our operating system memory manager for both the CPU and the GPU, which is not something you can do without virtualisation. It drove a number of key areas... Nick talked about the page tables. Some of the new things we have done - the GPU does have two layers of page tables for virtualisation. I think this is actually the first big consumer application of a GPU that's running virtualised. We wanted virtualisation to have that isolation, that performance. But we could not go and impact performance on the title.

We constructed virtualisation in such a way that it doesn't have any overhead cost for graphics other than for interrupts. We've contrived to do everything we can to avoid interrupts... We only do two per frame. We had to make significant changes in the hardware and the software to accomplish this. We have hardware overlays where we give two layers to the title and one layer to the system and the title can render completely asynchronously and have them presented completely asynchronously to what's going on system-side.

System-side it's all integrated with the Windows desktop manager but the title can be updating even if there's a glitch - like the scheduler on the Windows system side going slower... we did an awful lot of work on the virtualisation aspect to drive that and you'll also find that running multiple system drove a lot of our other systems. We knew we wanted to be 8GB and that drove a lot of the design around our memory system as well.

Digital Foundry: Were you always targeting 8GB right from the beginning?

Andrew Goossen: Yeah I think that was a pretty early decision we made when we were looking at the kind of experiences that we wanted to run concurrently with the title. And how much memory we would need there. That would have been a really early decision for us.

Digital Foundry: CPU-side, I'm curious. Why did you choose eight Jaguar cores rather than, say, four Piledriver cores? Is it all about performance per watt?

Nick Baker: The extra power and area associated with getting that additional IPC boost going from Jaguar to Piledriver... It's not the right decision to make for a console. Being able to hit the sweet spot of power/performance per area and make it a more parallel problem. That's what it's all about. How we're partitioning cores between the title and the operating system works out as well in that respect.

Digital Foundry: Is it essentially the Jaguar IP as is? Or did you customise it?

Nick Baker: There had not been a two-cluster Jaguar configuration before Xbox One so there were things that had to be done in order to make that work. We wanted higher coherency between the GPU and the CPU so that was something that needed to be done, that touched a lot of the fabric around the CPU and then looking at how the Jaguar core implemented virtualisation, doing some tweaks there - but nothing fundamental to the ISA or adding instructions or adding instructions like that.

Digital Foundry: You talk about having 15 processors. Can you break that down?

Nick Baker: On the SoC, there are many parallel engines - some of those are more like CPU cores or DSP cores. How we count to 15: [we have] eight inside the audio block, four move engines, one video encode, one video decode and one video compositor/resizer.

The audio block was completely unique. That was designed by us in-house. It's based on four tensilica DSP cores and several programmable processing engines. We break it up as one core running control, two cores running a lot of vector code for speech and one for general purpose DSP. We couple with that sample rate conversion, filtering, mixing, equalisation, dynamic range compensation then also the XMA audio block. The goal was to run 512 simultaneous voices for game audio as well as being able to do speech pre-processing for Kinect.

Digital Foundry: There's concern that custom hardware may not be utilised in multi-platform games but I'm assuming that hardware-accelerated functions would be integrated into middlewares and would see wide utilisation.

Nick Baker: Yeah, Andrew can talk about the middleware point but some of these things are just reserved for the system to do things like Kinect processing. These are system services we provide. Part of that processing is dedicated to the Kinect.

Andrew Goossen: So a lot of what we've designed for the system and the system reservation is to offload a lot of the work from the title and onto the system. You have to keep in mind that this is doing a bunch of work that is actually on behalf of the title. We're taking on the voice recognition mode in our system reservations whereas other platforms will have that as code that developers will have to link in and pay out of from their budget. Same thing with Kinect and most of our NUI [Natural User Interface] features are provided free for the games - also the Game DVR.

Digital Foundry: Perhaps the most misunderstood area of the processor is the ESRAM and what it means for game developers. Its inclusion sort of suggests that you ruled out GDDR5 pretty early on in favour of ESRAM in combination with DDR3. Is that a fair assumption?

Nick Baker: Yeah, I think that's right. In terms of getting the best possible combination of performance, memory size, power, the GDDR5 takes you into a little bit of an uncomfortable place. Having ESRAM costs very little power and has the opportunity to give you very high bandwidth. You can reduce the bandwidth on external memory - that saves a lot of power consumption as well and the commodity memory is cheaper as well so you can afford more. That's really a driving force behind that. You're right, if you want a high memory capacity, relatively low power and a lot of bandwidth there are not too many ways of solving that.

Digital Foundry: And there wasn't really any actual guarantee of availability of four-gigabit GDDR5 modules in time for launch. That's the gamble that Sony made which seems to have paid off. Even up until very recently, the PS4 SDK docs still refer to 4GB of RAM. I guess Intel's Haswell with eDRAM is the closest equivalent to what you're doing. Why go for ESRAM rather than eDRAM? You had a lot of success with this on Xbox 360.

Nick Baker: It's just a matter of who has the technology available to do eDRAM on a single die.

Digital Foundry: So you didn't want to go for a daughter die as you did with Xbox 360?

Nick Baker: No, we wanted a single processor, like I said. If there'd been a different time frame or technology options we could maybe have had a different technology there but for the product in the timeframe, ESRAM was the best choice.

Digital Foundry: If we look at the ESRAM, the Hot Chips presentation revealed for the first time that you've got four blocks of 8MB areas. How does that work?

Nick Baker: First of all, there's been some question about whether we can use ESRAM and main RAM at the same time for GPU and to point out that really you can think of the ESRAM and the DDR3 as making up eight total memory controllers, so there are four external memory controllers (which are 64-bit) which go to the DDR3 and then there are four internal memory controllers that are 256-bit that go to the ESRAM. These are all connected via a crossbar and so in fact it will be true that you can go directly, simultaneously to DRAM and ESRAM.

Digital Foundry: Simultaneously? Because there's been a lot of controversy that you're adding your bandwidth together and that you can't do this in a real-life scenario.

Nick Baker: Over that interface, each lane - to ESRAM is 256-bit making up a total of 1024 bits and that's in each direction. 1024 bits for write will give you a max of 109GB/s and then there's separate read paths again running at peak would give you 109GB/s. What is the equivalent bandwidth of the ESRAM if you were doing the same kind of accounting that you do for external memory... With DDR3 you pretty much take the number of bits on the interface, multiply by the speed and that's how you get 68GB/s. That equivalent on ESRAM would be 218GB/s. However, just like main memory, it's rare to be able to achieve that over long periods of time so typically an external memory interface you run at 70-80 per cent efficiency.

The same discussion with ESRAM as well - the 204GB/s number that was presented at Hot Chips is taking known limitations of the logic around the ESRAM into account. You can't sustain writes for absolutely every single cycle. The writes is known to insert a bubble [a dead cycle] occasionally... One out of every eight cycles is a bubble, so that's how you get the combined 204GB/s as the raw peak that we can really achieve over the ESRAM. And then if you say what can you achieve out of an application - we've measured about 140-150GB/s for ESRAM. That's real code running. That's not some diagnostic or some simulation case or something like that. That is real code that is running at that bandwidth. You can add that to the external memory and say that that probably achieves in similar conditions 50-55GB/s and add those two together you're getting in the order of 200GB/s across the main memory and internally.

One thing I should point out is that there are four 8MB lanes. But it's not a contiguous 8MB chunk of memory within each of those lanes. Each lane, that 8MB is broken down into eight modules. This should address whether you can really have read and write bandwidth in memory simultaneously. Yes you can there are actually a lot more individual blocks that comprise the whole ESRAM so you can talk to those in parallel and of course if you're hitting the same area over and over and over again, you don't get to spread out your bandwidth and so that's why one of the reasons why in real testing you get 140-150GB/s rather than the peak 204GB/s is that it's not just four chunks of 8MB memory. It's a lot more complicated than that and depending on how the pattern you get to use those simultaneously. That's what lets you do read and writes simultaneously. You do get to add the read and write bandwidth as well adding the read and write bandwidth on to the main memory. That's just one of the misconceptions we wanted to clean up.

Andrew Goossen: If you're only doing a read you're capped at 109GB/s, if you're only doing a write you're capped at 109GB/s. To get over that you need to have a mix of the reads and the writes but when you are going to look at the things that are typically in the ESRAM, such as your render targets and your depth buffers, intrinsically they have a lot of read-modified writes going on in the blends and the depth buffer updates. Those are the natural things to stick in the ESRAM and the natural things to take advantage of the concurrent read/writes.

Digital Foundry: So 140-150GB/s is a realistic target and you can integrate DDR3 bandwidth simultaneously?

Nick Baker: Yes. That's been measured.

http://images.eurogamer.net/2013/articles//a/1/6/1/2/9/1/9/11.png/EG11/resize/600x-1
http://images.eurogamer.net/2013/articles//a/1/6/1/2/9/1/9/22.png/EG11/resize/600x-1

http://images.eurogamer.net/2013/articles//a/1/6/1/2/9/1/9/77.png/EG11/resize/600x-1

http://images.eurogamer.net/2013/articles//a/1/6/1/2/9/1/9/33.png/EG11/resize/600x-1

http://images.eurogamer.net/2013/articles//a/1/6/1/2/9/1/9/44.png/EG11/resize/600x-1

http://images.eurogamer.net/2013/articles//a/1/6/1/2/9/1/9/55.png/EG11/resize/600x-1

http://images.eurogamer.net/2013/articles//a/1/6/1/2/9/1/9/66.png/EG11/resize/600x-1

Digital Foundry: On the leaked whitepapers, peak bandwidth was a lot smaller and then suddenly we ran a story [based on an internal Xbox One development blog] saying that your peak bandwidth doubled with production silicon. Was that expected? Were you being conservative? Or did you get hands-on time with your final processor and figured out that - wow - it can do this?

Nick Baker: When we started, we wrote a spec. Before we really went into any implementation details, we had to give developers something to plan around before we had the silicon, before we even had it running in simulation before tape-out, and said that the minimum bandwidth we want from the ESRAM is 102GB/s. That became 109GB/s [with the GPU speed increase]. In the end, once you get into implementing this, the logic turned out that you could go much higher.

Andrew Goossen: I just wanted to jump in from a software perspective. This controversy is rather surprising to me, especially when you view ESRAM as the evolution of eDRAM from the Xbox 360. No-one questions on the Xbox 360 whether we can get the eDRAM bandwidth concurrent with the bandwidth coming out of system memory. In fact, the system design required it. We had to pull over all of our vertex buffers and all of our textures out of system memory concurrent with going on with render targets, colour, depth, stencil buffers that were in eDRAM.

Of course with Xbox One we're going with a design where ESRAM has the same natural extension that we had with eDRAM on Xbox 360, to have both going concurrently. It's a nice evolution of the Xbox 360 in that we could clean up a lot of the limitations that we had with the eDRAM. The Xbox 360 was the easiest console platform to develop for, it wasn't that hard for our developers to adapt to eDRAM, but there were a number of places where we said, "Gosh, it would sure be nice if an entire render target didn't have to live in eDRAM," and so we fixed that on Xbox One where we have the ability to overflow from ESRAM into DDR3 so the ESRAM is fully integrated into our page tables and so you can kind of mix and match the ESRAM and the DDR memory as you go.

Sometimes you want to get the GPU texture out of memory and on Xbox 360 that required what's called a "resolve pass" where you had to do a copy into DDR to get the texture out - that was another limitation we removed in ESRAM, as you can now texture out of ESRAM if you want to. From my perspective it's very much an evolution and improvement - a big improvement - over the design we had with the Xbox 360. I'm kind of surprised by all this, quite frankly.

Digital Foundry: Obviously though, you are limited to just 32MB of ESRAM. Potentially you could be looking at say, four 1080p render targets, 32 bits per pixel, 32 bits of depth - that's 48MB straight away. So are you saying that you can effectively separate render targets so that some live in DDR3 and the crucial high-bandwidth ones reside in ESRAM?

Andrew Goossen: Oh, absolutely. And you can even make it so that portions of your render target that have very little overdraw... For example, if you're doing a racing game and your sky has very little overdraw, you could stick those subsets of your resources into DDR to improve ESRAM utilisation. On the GPU we added some compressed render target formats like our 6e4 [six bit mantissa and four bits exponent per component] and 7e3 HDR float formats [where the 6e4 formats] that were very, very popular on Xbox 360, which instead of doing a 16-bit float per component 64pp render target, you can do the equivalent with us using 32 bits - so we did a lot of focus on really maximizing efficiency and utilisation of that ESRAM.

Digital Foundry: And you have CPU read access to the ESRAM, right? This wasn't available on Xbox 360 eDRAM.

Nick Baker: We do but it's very slow.

Digital Foundry: There's been some discussion online about low-latency memory access on ESRAM. My understanding of graphics technology is that you forego latency and you go wide, you parallelise over however many compute units are available. Does low latency here materially affect GPU performance?

Nick Baker: You're right. GPUs are less latency sensitive. We've not really made any statements about latency.

Digital Foundry: DirectX as an API is very mature now. Developers have got a lot of experience with it. To what extent do you think this is an advantage for Xbox One? Bearing in mind how mature the API is, could you optimise the silicon around it?

Andrew Goossen: To a large extent we inherited a lot of DX11 design. When we went with AMD, that was a baseline requirement. When we started off the project, AMD already had a very nice DX11 design. The API on top, yeah I think we'll see a big benefit. We've been doing a lot of work to remove a lot of the overhead in terms of the implementation and for a console we can go and make it so that when you call a D3D API it writes directly to the command buffer to update the GPU registers right there in that API function without making any other function calls. There's not layers and layers of software. We did a lot of work in that respect.

We also took the opportunity to go and highly customise the command processor on the GPU. Again concentrating on CPU performance... The command processor block's interface is a very key component in making the CPU overhead of graphics quite efficient. We know the AMD architecture pretty well - we had AMD graphics on the Xbox 360 and there were a number of features we used there. We had features like pre-compiled command buffers where developers would go and pre-build a lot of their states at the object level where they would [simply] say, "run this". We implemented it on Xbox 360 and had a whole lot of ideas on how to make that more efficient [and with] a cleaner API, so we took that opportunity with Xbox One and with our customised command processor we've created extensions on top of D3D which fit very nicely into the D3D model and this is something that we'd like to integrate back into mainline 3D on the PC too - this small, very low-level, very efficient object-orientated submission of your draw [and state] commands.

http://images.eurogamer.net/2013/articles//a/1/6/2/0/6/6/2/91.jpeg.jpg/EG11/resize/600x-1/quality/91

"Neither Sony nor Microsoft will admit it, but their base graphics architecture does tally very closely with AMD's Pitcairn (left) and Bonaire (right) designs respectively, as found in the Radeon HD 7870 and the HD 7790. The Xbox designers have yet to convince a lot of gamers that a smaller graphics core can produce comparable results, while the benefits of its faster CPU with additional fixed function silicon have been largely ignored."

Digital Foundry: When you look at the specs of the GPU, it looks very much like Microsoft chose the AMD Bonaire design and Sony chose Pitcairn - and obviously one has got many more compute units than the other. Let's talk a little bit about the GPU - what AMD family is it based on: Southern Islands, Sea Islands, Volcanic Islands?

Andrew Goossen: Just like our friends we're based on the Sea Islands family. We've made quite a number of changes in different parts of the areas. The biggest thing in terms of the number of compute units, that's been something that's been very easy to focus on. It's like, hey, let's count up the number of CUs, count up the gigaflops and declare the winner based on that. My take on it is that when you buy a graphics card, do you go by the specs or do you actually run some benchmarks? Firstly though, we don't have any games out. You can't see the games. When you see the games you'll be saying, "What is the performance difference between them?" The games are the benchmarks. We've had the opportunity with the Xbox One to go and check a lot of our balance. The balance is really key to making good performance on a games console. You don't want one of your bottlenecks being the main bottleneck that slows you down.

Balance is so key to real effective performance. It's been really nice on Xbox One with Nick and his team and the system design folks have built a system where we've had the opportunity to check our balances on the system and make tweaks accordingly. Did we do a good job when we did all of our analysis a couple of years ago and simulations and guessing where games would be in terms of utilisation? Did we make the right balance decisions back then? And so raising the GPU clock is the result of going in and tweaking our balance. Every one of the Xbox One dev kits actually has 14 CUs on the silicon. Two of those CUs are reserved for redundancy in manufacturing. But we could go and do the experiment - if we were actually at 14 CUs what kind of performance benefit would we get versus 12? And if we raised the GPU clock what sort of performance advantage would we get? And we actually saw on the launch titles - we looked at a lot of titles in a lot of depth - we found that going to 14 CUs wasn't as effective as the 6.6 per cent clock upgrade that we did. Now everybody knows from the internet that going to 14 CUs should have given us almost 17 per cent more performance but in terms of actual measured games - what actually, ultimately counts - is that it was a better engineering decision to raise the clock. There are various bottlenecks you have in the pipeline that [can] cause you not to get the performance you want [if your design is out of balance].

Nick Baker: Increasing the frequency impacts the whole of the GPU whereas adding CUs beefs up shaders and ALU.

Andrew Goossen: Right. By fixing the clock, not only do we increase our ALU performance, we also increase our vertex rate, we increase our pixel rate and ironically increase our ESRAM bandwidth. But we also increase the performance in areas surrounding bottlenecks like the drawcalls flowing through the pipeline, the performance of reading GPRs out of the GPR pool, etc. GPUs are giantly complex. There's gazillions of areas in the pipeline that can be your bottleneck in addition to just ALU and fetch performance.

If you go to VGleaks, they had some internal docs from our competition. Sony was actually agreeing with us. They said that their system was balanced for 14 CUs. They used that term: balance. Balance is so important in terms of your actual efficient design. Their additional four CUs are very beneficial for their additional GPGPU work. We've actually taken a very different tack on that. The experiments we did showed that we had headroom on CUs as well. In terms of balance, we did index more in terms of CUs than needed so we have ***** overhead. There is room for our titles to grow over time in terms of ***** utilisation, but getting back to us versus them, they're betting that the additional CUs are going to be very beneficial for GPGPU workloads. Whereas we've said that we find it very important to have bandwidth for the GPGPU workload and so this is one of the reasons why we've made the big bet on very high coherent read bandwidth that we have on our system.

I actually don't know how it's going to play out of our competition having more CUs than us for these workloads versus us having the better performing coherent memory. I will say that we do have quite a lot of experience in terms of GPGPU - the Xbox 360 Kinect, we're doing all the Exemplar processing on the GPU so GPGPU is very much a key part of our design for Xbox One. Building on that and knowing what titles want to do in the future. Something like Exemplar... Exemplar ironically doesn't need much ALU. It's much more about the latency you have in terms of memory fetch [latency hiding of the GPU], so this is kind of a natural evolution for us. It's like, OK, it's the memory system which is more important for some particular GPGPU workloads.

Digital Foundry: With regards the benefits of the 6.6 per cent GPU clock speed boost over the 17 per cent of extra compute power offered by the two redundant compute units, is there a chance that they might have been ROP-bound in that scenario? 16 ROPs is another point of differentiation up against the 32 in the competition.

Andrew Goossen: Yes, some parts of the frames may have been ROP-bound. However, in our more detailed analysis we've found that the portions of typical game content frames that are bound on ROP and not bound on bandwidth are generally quite small. The primary reason that the 6.6 per cent clock speed boost was a win over additional CUs was because it lifted all internal parts of the pipeline such as vertex rate, triangle rate, draw issue rate, etc.

The goal of a 'balanced' system is by definition not to be consistently bottlenecked on any one area. In general with a balanced system there should rarely be a single bottleneck over the course of any given frame - parts of the frame can be fill-rate bound, other can be ALU bound, others can be fetch bound, others can be memory bound, others can be wave occupancy bound, others can be draw-setup bound, others can be state change bound, etc. To complicate matters further, the GPU bottlenecks can change within the course of a single draw call!

The relationship between fill-rate and memory bandwidth is a good example of where balance is necessary. A high fill-rate won't help if the memory system can't sustain the bandwidth required to run at that fill rate. For example, consider a typical game scenario where the render target is 32bpp [bits per pixel] and blending is disabled, and the depth/stencil surface is 32bpp with Z enabled. That amount to 12 bytes of bandwidth needed per pixel drawn (eight bytes write, four bytes read). At our peak fill-rate of 13.65GPixels/s that adds up to 164GB/s of real bandwidth that is needed which pretty much saturates our ESRAM bandwidth. In this case, even if we had doubled the number of ROPs, the effective fill-rate would not have changed because we would be bottlenecked on bandwidth. In other words, we balanced our ROPs to our bandwidth for our target scenarios. Keep in mind that bandwidth is also needed for vertex and texture data as well, which in our case typically comes from DDR3.

If we had designed for 2D UI scenarios instead of 3D game scenarios, we might have changed this design balance. In 2D UI there is typically no Z-buffer and so the bandwidth requirements to achieve peak fill-rate are often less.

Digital Foundry: The GPU compute comparison seems to be about Xbox One's high coherent read bandwidth vs. raw ALU on PS4. But don't the additional ACEs added to PS4 aim to address that issue?

Andrew Goossen: The number of asynchronous compute queues provided by the ACEs doesn't affect the amount of bandwidth or number of effective FLOPs or any other performance metrics of the GPU. Rather, it dictates the number of simultaneous hardware "contexts" that the GPU's hardware scheduler can operate on any one time. You can think of these as analogous to CPU software threads - they are logical threads of execution that share the GPU hardware. Having more of them doesn't necessarily improve the actual throughput of the system - indeed, just like a program running on the CPU, too many concurrent threads can make aggregate effective performance worse due to thrashing. We believe that the 16 queues afforded by our two ACEs are quite sufficient.

Another very important thing for us in terms of design on the system was to ensure that our game had smooth frame-rates. Interestingly, the biggest source of your frame-rate drops actually comes from the CPU, not the GPU. Adding the margin on the CPU... we actually had titles that were losing frames largely because they were CPU-bound in terms of their core threads. In providing what looks like a very little boost, it's actually a very significant win for us in making sure that we get the steady frame-rates on our console. And so that was a key design goal of ours - and we've got a lot of CPU offload going on.

We've got the SHAPE, the more efficient command processor [relative to the standard design], we've got the clock boost - it's in large part actually is to ensure that we've got the headroom for the frame-rates. We've done things on the GPU side as well with our hardware overlays to ensure more consistent frame-rates. We have two independent layers we can give to the titles where one can be 3D content, one can be the HUD. We have a higher quality scaler than we had on Xbox 360. What this does is that we actually allow you to change the scaler parameters on a frame-by-frame basis. I talked about CPU glitches causing frame glitches... GPU workloads tend to be more coherent frame to frame. There doesn't tend to be big spikes like you get on the CPU and so you can adapt to that.

What we're seeing in titles is adopting the notion of dynamic resolution scaling to avoid glitching frame-rate. As they start getting into an area where they're starting to hit on the margin there where they could potentially go over their frame budget, they could start dynamically scaling back on resolution and they can keep their HUD in terms of true resolution and the 3D content is squeezing. Again, from my aspect as a gamer I'd rather have a consistent frame-rate and some squeezing on the number of pixels than have those frame-rate glitches.

Digital Foundry: So often you're CPU bound. That explains why so many of the Data Move Engine functions seem to be about offloading CPU?

Andrew Goossen: Yeah, again I think we under-balanced and we had that great opportunity to change that balance late in the game. The DMA Move Engines also help the GPU significantly as well. For some scenarios there, imagine you've rendered to a depth buffer there in ESRAM. And now you're switching to another depth buffer. You may want to go and pull what is now a texture into DDR so that you can texture out of it later and you're not doing tons of reads from that texture so it actually makes more sense for it to be in DDR. You can use the Move Engines to move these things asynchronously in concert with the GPU so the GPU isn't spending any time on the move. You've got the DMA engine doing it. Now the GPU can go on and immediately work on the next render target rather than simply move bits around.

Nick Baker: From a power/efficiency standpoint as well, fixed functions are more power-friendly on fixed function units. We put data compression on there as well, so we have LZ compression/decompression and also motion JPEG decode which helps with Kinect. So there's a lot more than to the Data Move Engines than moving from one block of memory to another.

Digital Foundry: Another thing that came up from the Hot Chips presentation that was new information was the eMMC NAND which I hadn't seen any mention of. I'm told it's not available for titles. So what does it do?

Andrew Goossen: Sure. We use it as a cache system-side to improve system response and again not disturb system performance on the titles running underneath. So what it does is that it makes our boot times faster when you're not coming out of the sleep mode - if you're doing the cold boot. It caches the operating system on there. It also caches system data on there while you're actually running the titles and when you have the snap applications running concurrently. It's so that we're not going and hitting the hard disk at the same time that the title is. All the game data is on the HDD. We wanted to be moving that head around and not worrying about the system coming in and monkeying with the head at an inopportune time.

Digital Foundry: Can you talk us through how you arrived at the CPU and GPU increases that you did and did it have any effect on production yield?

Nick Baker: We knew we had headroom. We didn't know what we wanted to do with it until we had real titles to test on. How much do you increase the GPU by? How much do you increase the CPU by?

Andrew Goossen: We had the headroom. It's a glorious thing to have on a console launch. Normally you're talking about having to downclock. We had a once in a lifetime opportunity to go and pick the spots where we wanted to improve the performance and it was great to have the launch titles to use as the way to drive an informed decision performance improvements we could get out of the headroom.

Digital Foundry: So can you tell us how much power Xbox One takes from the wall, during gameplay for example?

Microsoft PR: That's not a figure we're disclosing at this time.

Nick Baker: But we've said on other forums as well that we have implemented multiple power levels - we scale all the way from full power down to 2.5 per cent depending on the scenario.

Digital Foundry: Yeah I heard about that, I'm just interested in the final figure. I guess I'll need to measure the final console at the wall when I get one! Just a final question. It's more of a personal question really. You've been working on Xbox hardware for many years, you've been working on Xbox One for many years. We saw last week the production run kicking off. How does that feel to see the culmination of your work?

Nick Baker: Yeah, getting something out is always, always a great feeling [but] my team works on multiple programs in parallel - we're constantly busy working on the architecture team.

Andrew Goossen: For me, the biggest reward is to go and play the games and see that they look great and that yeah, this is why we did all that hard work. As a graphics guy it's so rewarding to see those pixels up on the screen.

O X1 tem um bom potencial mas deve sofrer um pouco no início no SW, mas deve também ganhar uma boa vantagem por causa do Kinect. É ele que vai fazer a diferença, ao meu ver, principalmente com a queda da Nintendo.

Só o Kinect? Será só isso o diferencial?

Vou te mostrar a diferença caro amigo. Além do Kinect, ele será uma "central de multimídia": conta com ambiente multitarefa, ou melhor, o "Snap Mode" - pode-se usar vários aplicativos na mesma tela; o Xbox One integrará diversos serviços em um só aparelho, como o acesso aos canais da "TV fechada", provedor de filmes, internet, músicas, videos e Skype. E ainda tem mais: aquilo que de fato agrega valor a um console, os jogos!

Dentre os jogos divulgados - exclusivos e não exclusivos, temos: Minecraft, Skylanders: Swap Force, Fifa 14, Forza 5, NBA Live 14, UFC, Call of Duty: Ghosts, Quantum Breaker, Halo 5, Gears of War 4, Killer Instinct, Banjo-Kazooie 4, Fable 4, Battlefield 4, Dead Rising 3, Dragon Age: Inquisition, Dying Light, Ryse: Son of Rome, Assassin's Creed 4, Final Fantasy 15, Need For Speed Rivals, The Witcher 3: Wild Hunt, Mad Max, The Elder Scrolls Online e Watch Dogs. Serão pelo menos 50 jogos, lançados nos meses de vendas do Xbox One.

sirroman · 15 de outubro de 2013

Só o Kinect? Será só isso o diferencial?
Vou te mostrar a diferença caro amigo. Além do Kinect, ele será uma "central de multimídia": conta com ambiente multitarefa, ou melhor, o "Snap Mode" - pode-se usar vários aplicativos na mesma tela; o Xbox One integrará diversos serviços em um só aparelho, como o acesso aos canais da "TV fechada", provedor de filmes, internet, músicas, videos e Skype. E ainda tem mais: aquilo que de fato agrega valor a um console, os jogos!

Dentre os jogos divulgados - exclusivos e não exclusivos, temos: Minecraft, Skylanders: Swap Force, Fifa 14, Forza 5, NBA Live 14, UFC, Call of Duty: Ghosts, Quantum Breaker, Halo 5, Gears of War 4, Killer Instinct, Banjo-Kazooie 4, Fable 4, Battlefield 4, Dead Rising 3, Dragon Age: Inquisition, Dying Light, Ryse: Son of Rome, Assassin's Creed 4, Final Fantasy 15, Need For Speed Rivals, The Witcher 3: Wild Hunt, Mad Max, The Elder Scrolls Online e Watch Dogs. Serão pelo menos 50 jogos, lançados nos meses de vendas do Xbox One.

Acho que no começo a diferença vai ser do kinect sim, acredito que o PS4 deve ter vantagem gráfica no início por causa da simplicidade do HW. O X1 deve equiparar ou mesmo superar depois, mas no começo a vantagem que o X1 vai ter será o Kinect mesmo (na minha opinião a central de multimídia não é um diferencial grande o bastante para realmente "vender" o X).

Claro que é tudo chute meu.

Gotoa · 15 de outubro de 2013

Acho que no começo a diferença vai ser do kinect sim, acredito que o PS4 deve ter vantagem gráfica no início por causa da simplicidade do HW. O X1 deve equiparar ou mesmo superar depois, mas no começo a vantagem que o X1 vai ter será o Kinect mesmo (na minha opinião a central de multimídia não é um diferencial grande o bastante para realmente "vender" o X).
Claro que é tudo chute meu.

Kinect? Será? Eu não tenho e não conheço ninguém que use, sério! Não me faz falta alguma!

Sobre "a central multimídia", pode até ser que não seja um diferencial. Mas os jogos, serão sim, principalmente os exclusivos! E na prática, acho que ambos vão rodar bem os jogos não exclusivos - cada um será desenvolvido e apropriado para cada plataforma, como acontece nos últimos anos da atual geração.

tamazi · 15 de outubro de 2013

Na boa, nada mais peso de papel que o Kinect/Move e etc, poucas pessoas tem, poucas pessoas usam e quando usa usa por um curto periodo, eu me inclu-o nessa.

sirroman · 16 de outubro de 2013

Kinect é divertido pra caramba para festas. Acho que o appeal para os usuários comuns não pode ser desconsiderado

Gotoa · 17 de outubro de 2013

Kinect é divertido pra caramba para festas. Acho que o appeal para os usuários comuns não pode ser desconsiderado

Sim, claro. O único problema foi a MS obrigar os consumidores a adquirirem e pagarem pelo Kinect (que aumentou o valor final do X1). O certo, era manter o aparelho avulso, como "opcional" (para os "usuários comuns", como você disse).

Com o Kinect integrado e os "extras embutidos" (é de fato, uma "Central de Multimídia"), o Xbox One não vai custar 4.000 reais!

Na boa, nada mais peso de papel que o Kinect/Move e etc, poucas pessoas tem, poucas pessoas usam e quando usa usa por um curto periodo, eu me inclu-o nessa.

Concordo! Também estou nessa lista! E fiquei "bolado" quando a MS resolveu "enfiar a perfumaria goela abaixo" dos jogadores-consumidores! Mas pelo menos o Xbox One virá "completo" e não vai custar o dobro (ou o tripo, ou o quádruplo) do que realmente vale!

tamazi · 17 de outubro de 2013

Kinect é divertido pra caramba para festas. Acho que o appeal para os usuários comuns não pode ser desconsiderado

Quando opcional é sim divertido, concordo, tenho o Move, comprei separadamente e uso no max uma vez a cada dois meses, nos demais 59 dias é um peso de papel.

Concordo! Também estou nessa lista! E fiquei "bolado" quando a MS resolveu "enfiar a perfumaria goela abaixo" dos jogadores-consumidores! Mas pelo menos o Xbox One virá "completo" e não vai custar o dobro (ou o tripo, ou o quádruplo) do que realmente vale!

exato, ele deixou de ser um acessório e se tornu parte do equipamento.

sirroman · 19 de outubro de 2013

Sim, claro. O único problema foi a MS obrigar os consumidores a adquirirem e pagarem pelo Kinect (que aumentou o valor final do X1). O certo, era manter o aparelho avulso, como "opcional" (para os "usuários comuns", como você disse).
Com o Kinect integrado e os "extras embutidos" (é de fato, uma "Central de Multimídia"), o Xbox One não vai custar 4.000 reais!

Concordo! Também estou nessa lista! E fiquei "bolado" quando a MS resolveu "enfiar a perfumaria goela abaixo" dos jogadores-consumidores! Mas pelo menos o Xbox One virá "completo" e não vai custar o dobro (ou o tripo, ou o quádruplo) do que realmente vale!

Quando opcional é sim divertido, concordo, tenho o Move, comprei separadamente e uso no max uma vez a cada dois meses, nos demais 59 dias é um peso de papel.
exato, ele deixou de ser um acessório e se tornu parte do equipamento.

Ai que tá, se todo mundo tem então o desenvolvedor não tem desculpa para não usar, então as chances de ele ser mais útil/relevante (ou seja, não usar apenas de vez em quando, mas sim na maioria das vezes) fica maior. Achei acertada a decisão, mas encareceu o bichinho.

tamazi · 23 de outubro de 2013

Seguindo os passos do Xbox 360, o Xbox One também será fabricado no Brasil. A Agência Nacional de Telecomunicações (Anatel) disponibilizou a informação em seu site - que mostra os dados de homologação do aparelho no Brasil.

Isso significa que o videogame da Microsoft pode ser vendido por um preço mais baixo do que o concorrente, o PS4.

Em contato anterior com Época NEGÓCIOS, a Microsoft havia informado que não se pronunciaria sobre onde seu novo console seria produzido.

Nas fotos do aparelho publicadas no site da Anatel é possível ver o selo com a informação "Produzido no pólo industrial de Manaus".

http://s2.glbimg.com/sAsmoqHfyzZAhddpP0_8yVPy43uQhnTfeCcRVLr6VoFIoz-HdGixxa_8qOZvMp3w/e.glbimg.com/og/ed/f/original/2013/10/23/xbox_one_manaus.jpg

Selo com a informação "Produzido no pólo industrial de Manaus". (Foto: Reprodução Internet/sistemas.anatel.gov.br)

http://s2.glbimg.com/K74BORWow0XDWHr-8Ua5BQ3XWwfTFjfVIDmkvC8KaSEElFQuXssPpp_rb0l02snt/e.glbimg.com/og/ed/f/original/2013/10/23/anatel.jpg

Certificado do Xbox divulgado no site da Anatel: 1540 é o número do modelo do Xbox One (Foto: Reprodução Internet/sistemas.anatel.gov.br)

Fonte

-----------------------

Por isso que a M$ não se pronunciou e ficou na sua? Certa ela!

tamazi · 27 de novembro de 2013

Principais peças responsáveis pela diferença no preço seriam os chips de controle do Kinect e o processador da AMD.

Uma empresa de pesquisa de mercado norte-americana chamada IHS decidiu desmontar os consoles PlayStation 4 e Xbox One para saber como são as peças utilizadas na fabricação deles. Depois de analisar componente por componente, os analistas chegaram à conclusão de que o console da Microsoft tem motivos para ser mais caro do que o da Sony — lembrando, é claro, que estamos falando do mercado dos Estados Unidos.

Segundo os especialistas, a fabricação do Xbox One custa US$ 90 a mais do que a do PlayStation 4. Há dois itens que seriam os principais responsáveis para a grande diferença no preço de fabricação dos novos video games. O primeiro deles é o sensor integrado para o reconhecimento de movimentos do Kinect (não o aparelho, apenas o sensor do próprio console), que pode custar até US$ 75.

O outro componente que encarece a fabricação do Xbox One é um microprocessador da AMD. Um chip similar está presente nos dois consoles, mas a diferença é que o que está no aparelho da Microsoft adiciona algumas funções gráficos ao processamento, custando cerca de US$ 10 a mais do que a versão do PlayStation 4. Os analistas concluem que o Xbox One custa cerca de US$ 330 para ser construído, enquanto o PS4 fica próximo dos US$ 240.

TecMundo