G92-270/"8800 Gt"

[Kursk_crash]

x

Não sei até que ponto,

no design do chip, seja "simples" adicionar mais steam processors...

sem implicar um redesenho total do chip... e portanto sem esse dado, nada podemos afirmar

 

[Ansatsu]

Não sei até que ponto,

no design do chip, seja "simples" adicionar mais steam processors...

sem implicar um redesenho total do chip... e portanto sem esse dado, nada podemos afirmar

Mas se os transistores aumentam de 681 para ~1000, isso quer dizer que houve um redesenho do chip. E esses 320 Milhões a mais, foram usados para alguma coisa.

Repara que são quase 50% a mais de transistors. De certeza que é para aumentar o numero de SP's.

 

[Crusher]

Mas se os transistores aumentam de 681 para ~1000, isso quer dizer que houve um redesenho do chip. E esses 320 Milhões a mais, foram usados para alguma coisa.

Repara que são quase 50% a mais de transistors. De certeza que é para aumentar o numero de SP's.

Se souberes quantos transistores ocupam 128SP no G80, então tinhas mesmo mesmo mesmo certeza que seriam stream processors a fazerem parte dos 320milhões...

Mas se fizeres as contas se esses 320 milhões fossem só dos SPs, então o resto do chip seria só também SPs, o que não faz sentido obviamente.

 

[JPgod]

É provável em vez de ser 192, ser 160... O resto ser usado num bus de 512 bits, por exemplo

 

[Ansatsu]

Se souberes quantos transistores ocupam 128SP no G80, então tinhas mesmo mesmo mesmo certeza que seriam stream processors a fazerem parte dos 320milhões...

Mas se fizeres as contas se esses 320 milhões fossem só dos SPs, então o resto do chip seria só também SPs, o que não faz sentido obviamente.

se tu reparares 681 Milhões de transistores dão 128 SP, e mais todas as outars coisas que não são poucas,

Eu não sei, mas digamos que os 128SP gastam 500 Milhões dos 681. Vais dizer então que 320 Milhões não davam à vontade para 64?

 

[Crusher]

se tu reparares 681 Milhões de transistores dão 128 SP, e mais todas as outars coisas que não são poucas,

Eu não sei, mas digamos que os 128SP gastam 500 Milhões dos 681. Vais dizer então que 320 Milhões não davam à vontade para 64?

Se assim for, daria. Mas como não sei quantos transistores ocupam todos os 128 SPs no G80 só estamos aqui a especular.

Nota que a GTS só por ter 96SPs e ter um pouco menos de largura de banda, já perde uns 40% para GTX.

Este G92 com 160SPs podia ser um número para começar mais os 512bits de bus que irá ter, mais clocks e mais um pouco de sal e azeite, já devia dar para duplicar a performance da G80.

 

[blastarr]

Se assim for, daria. Mas como não sei quantos transistores ocupam todos os 128 SPs no G80 só estamos aqui a especular.

Nota que a GTS só por ter 96SPs e ter um pouco menos de largura de banda, já perde uns 40% para GTX.

Este G92 com 160SPs podia ser um número para começar mais os 512bits de bus que irá ter, mais clocks e mais um pouco de sal e azeite, já devia dar para duplicar a performance da G80.

Duvido que a Nvidia use um bus de 512bit.
Simplesmente não é necessário, as G8x já fazem um uso muito mais eficaz da largura de banda disponível do que as R6xx, e um bus mais largo implica um PCB mais complexo, mais chips de memória RAM por placa, etc.
Se houver um aumento do bus, acho improvável que passe dos 448bit, mas tudo é possível daqui por 4 ou 5 meses.
-----------------------------------------------------------------------------------------


Por outro lado, não podem somar os Scalar Processors e dizer que vai ter 160, 192, 256 ALU's, etc. Não é assim tão linear.
Relembro que os Scalar Processors da G92 vão suportar cálculos em dupla precisão (FP64), que não existe nas G8x.
Só isso já chega para aumentar significativamente a complexidade de cada um.

A tudo isto, há aínda o facto de serem 100% escalares (ao contrário do que acontece nas AMD R6xx). Isto significa que a Nvidia pode até optar por manter um nº relativamente reduzido de ALU's comparativamente com as G80, mas aumenta o nº de estágios para cada uma delas de forma a atingir velocidades de relógio mais elevadas.



Uma pista para a evolução dos clock domains separados nas unidades de shading para uma futura terceira geração (depois das Geforce 7 e Geforce 8) pode muito bem ser isto:

http://www.beyond3d.com/content/pr/31

 

[Crusher]

Uma pista para a evolução dos clock domains separados nas unidades de shading para uma futura terceira geração (depois das Geforce 7 e Geforce 8) pode muito bem ser isto:

http://www.beyond3d.com/content/pr/31

Mas não estou a ver isso já na G92... também só estou a ver pela data da notícia, porque nos bastidores não sei nada.

Mas se pelos rumores diz que vai ter consumos parecidos com o G80...

 

[blastarr]

Mas não estou a ver isso já na G92... também só estou a ver pela data da notícia, porque nos bastidores não sei nada.

Mas se pelos rumores diz que vai ter consumos parecidos com o G80...

Na notícia do link diz "(...)after a successful evaluation(...)".
Se calhar até podem ter avaliado a tecnologia da Azuro no próprio desenho do G92, gostaram do que viram, e assim decidiram comprar uma licença comercial.
Daí que a confirmação oficial do negócio só tenha chegado mais tarde. Pelo menos é possível.

 

[Ansatsu]

Já agora, porque G92 e não G90? lol... Não tem logica ser G92.

 

[blastarr]

Já agora, porque G92 e não G90? lol... Não tem logica ser G92.

G71 também não tinha lógica em relação à G70 (anteriormente a Nvidia usava 5 ou o 8 no final do nome de código de um refresh, i.e., NV30->NV35->NV38, NV20->NV25, NV10->NV15, etc).

Só o NV45 quebrou essa tradição antes da G71, pois não passava de um NV40 + chip HSI no mesmo package de forma a convertê-lo de AGP8x para PCI-Express x16, e não era um refresh, apenas o mesmo chip, clocks, features, etc, com um novo interface.

 

[Kursk_crash]

Duvido que a Nvidia use um bus de 512bit.
Simplesmente não é necessário, as G8x já fazem um uso muito mais eficaz da largura de banda disponível do que as R6xx, e um bus mais largo implica um PCB mais complexo, mais chips de memória RAM por placa, etc.
Se houver um aumento do bus, acho improvável que passe dos 448bit, mas tudo é possível daqui por 4 ou 5 meses.
-----------------------------------------------------------------------------------------


Por outro lado, não podem somar os Scalar Processors e dizer que vai ter 160, 192, 256 ALU's, etc. Não é assim tão linear.
Relembro que os Scalar Processors da G92 vão suportar cálculos em dupla precisão (FP64), que não existe nas G8x.
Só isso já chega para aumentar significativamente a complexidade de cada um.

A tudo isto, há aínda o facto de serem 100% escalares (ao contrário do que acontece nas AMD R6xx). Isto significa que a Nvidia pode até optar por manter um nº relativamente reduzido de ALU's comparativamente com as G80, mas aumenta o nº de estágios para cada uma delas de forma a atingir velocidades de relógio mais elevadas.



Uma pista para a evolução dos clock domains separados nas unidades de shading para uma futura terceira geração (depois das Geforce 7 e Geforce 8) pode muito bem ser isto:

http://www.beyond3d.com/content/pr/31

aumentar "estágios" nos shaders não sei se será bem por aí a coisa... contrapõe um pouco a ideia actual da nvidia em manter os stream processors simples... daí a grande escabilidade e o elevado clock alcançado.. se aumentarmos os estádios vamos estar a complexar mais as coias..

eu aponto mais em manter a actual estrutura da placa. === "proven tecnology"

e fazer a precisão dupla. e usar os restantes transistors em meter o chip NVIO dentro do core principal... agora já deve ser possível !!!!!

 

[blastarr]

aumentar "estágios" nos shaders não sei se será bem por aí a coisa... contrapõe um pouco a ideia actual da nvidia em manter os stream processors simples... daí a grande escabilidade e o elevado clock alcançado.. se aumentarmos os estádios vamos estar a complexar mais as coias..

eu aponto mais em manter a actual estrutura da placa. === "proven tecnology"

e fazer a precisão dupla. e usar os restantes transistors em meter o chip NVIO dentro do core principal... agora já deve ser possível !!!!!

Aumentar o nº de estágios não faz, por si só, aumentar a complexidade dos shaders.
Continua a ser in-order, ou seja, um shader pode começar e acabar de processar uma instrução, com outra num estágio intermédio, tudo num só ciclo de relógio.
Na R600 tens 5 unidades, mas como não são escalares corres o risco de ver 4 delas paradas num dado ciclo de relógio, à espera que a outra termine o seu trabalho, antes de começar a processar outro conjunto de dados.
Assim, a G80 faz auto-load balancing e todas as 128 ALU's estão sempre a ser utilizadas a cada ciclo de relógio.
A R600 está dependente do compilador de software para ordenar e distribuir o trabalho. Não só introduz mais latência, como uma aplicação está sempre dependente de optimizações do driver de software para utilizar a placa ao máximo, e mesmo assim haverá sempre ALU's em idle, enquanto outras estão a ser sobrecarregadas.


Uma boa analogia é um conjunto de canos para a água.
Num sistema tens vários canos ligados à mesma fonte, que permitem a passagem de uma gota de cada vez -largura-, mas que pode ter várias gotas em diferentes pontos ao longo do percurso do cano.
Noutro sistema tem vários canos ligados à mesma fonte, e também permitem a passagem de uma gota de cada vez, mas onde cada gota toma o cano na sua totalidade, ou seja, enquanto a primeira não sair do outro lado, a segunda não pode sequer entrar. E as que estão lá dentro têm de esperar para processar a sua tarefa, não podem "saltar" do cano para um outro menos congestionado.

 

[Kursk_crash]

Aumentar o nº de estágios não faz, por si só, aumentar a complexidade dos shaders.
Continua a ser in-order, ou seja, um shader pode começar e acabar de processar uma instrução, com outra num estágio intermédio, tudo num só ciclo de relógio.
Na R600 tens 5 unidades, mas como não são escalares corres o risco de ver 4 delas paradas num dado ciclo de relógio, à espera que a outra termine o seu trabalho, antes de começar a processar outro conjunto de dados.
Assim, a G80 faz auto-load balancing e todas as 128 ALU's estão sempre a ser utilizadas a cada ciclo de relógio.
A R600 está dependente do compilador de software para ordenar e distribuir o trabalho. Não só introduz mais latência, como uma aplicação está sempre dependente de optimizações do driver de software para utilizar a placa ao máximo, e mesmo assim haverá sempre ALU's em idle, enquanto outras estão a ser sobrecarregadas.


Uma boa analogia é um conjunto de canos para a água.
Num sistema tens vários canos ligados à mesma fonte, que permitem a passagem de uma gota de cada vez -largura-, mas que pode ter várias gotas em diferentes pontos ao longo do percurso do cano.
Noutro sistema tem vários canos ligados à mesma fonte, e também permitem a passagem de uma gota de cada vez, mas onde cada gota toma o cano na sua totalidade, ou seja, enquanto a primeira não sair do outro lado, a segunda não pode sequer entrar. E as que estão lá dentro têm de esperar para processar a sua tarefa, não podem "saltar" do cano para um outro menos congestionado.

ora aí está.. a R600 tem 5 unidades no mesmo sahder processors e não 5 shaders units..
daí o falso número dos 320... é mais 64 !!!

e vê-se bem a diferença do compilador de software, pois com os drivers aquilo ganha performance admirável em cada revisão..

quanto ao possível aumento dos estágios ou estádios nos shaders da G92.. também pode dar-se o caso que a instrução ter que ser "esvaziada" e com isso perder-se tempo a "limpar" o pipe..
Não será um bom exemplo, pois os P4 são out-of-order, mas havia modelos anteriores com estágios brutais...longíssimos... então o itanium era desesperante...!!!! acabaram por abandonar isso no core2.. 11 ou 12 estágios.. tal como a AMD vinha a fazer..

num processador in order.. típico de consolas.. pode ou não ser favorável... é uma questão de ponderar os prós e os contras..

mas eu nesses milhões apostava simplesmente, na inclusão do chip de NVIO (já devem ser uns bons 150 milhões de Transistors)... e o restante para os shaders de precisão dupla... e o que resta para alguns tweaks aqui e ali..

e mantendo a mesma estrutura, que já deu provas que é boa.

 

[blastarr]

ora aí está.. a R600 tem 5 unidades no mesmo sahder processors e não 5 shaders units..
daí o falso número dos 320... é mais 64 !!!

e vê-se bem a diferença do compilador de software, pois com os drivers aquilo ganha performance admirável em cada revisão..

quanto ao possível aumento dos estágios ou estádios nos shaders da G92.. também pode dar-se o caso que a instrução ter que ser "esvaziada" e com isso perder-se tempo a "limpar" o pipe..
Não será um bom exemplo, pois os P4 são out-of-order, mas havia modelos anteriores com estágios brutais...longíssimos... então o itanium era desesperante...!!!! acabaram por abandonar isso no core2.. 11 ou 12 estágios.. tal como a AMD vinha a fazer..

num processador in order.. típico de consolas.. pode ou não ser favorável... é uma questão de ponderar os prós e os contras..

mas eu nesses milhões apostava simplesmente, na inclusão do chip de NVIO (já devem ser uns bons 150 milhões de Transistors)... e o restante para os shaders de precisão dupla... e o que resta para alguns tweaks aqui e ali..

e mantendo a mesma estrutura, que já deu provas que é boa.

Lê bem o que eu disse.
A instrução num shader ALU escalar não impede a entrada (ou saída) de uma outra instrução no mesmíssimo shader, mas num outro ponto (estágio) do pipeline de execução.

BTW, os P4 eram escalares, mas os Core 2 também são.
Têm menos estágios, é certo, mas processam até quatro instruções por ciclo de relógio, ao passo que o Pentium 4 se ficava pelas três.
Ou seja, o Core 2 aínda é mais out-of-order do que o Pentium 4.
E os P4 eram fracos porque as instruções x86, ao contrário das instruções paralelizáveis de um processador gráfico, são muito sensíveis à latência introduzida por estágios adicionais no pipeline de cada ALU.
As GPU's são latency-tolerant até certo ponto, daí o facto de possuirem muito menos memória cache L1 e L2 do que as CPU's, que precisam destas para tentar evitar as cache misses.

 

[JPgod]

O facto das gráficas ter memória com um bus elevado e frequências altas já torna grandes caches L1 e L2 menos necessárias...

 

[blastarr]

O facto das gráficas ter memória com um bus elevado e frequências altas já torna grandes caches L1 e L2 menos necessárias...

Não compares a largura de banda por um bus de 512bit e memórias a 2000MHz+, com memória GDDR3/4 "colada" ao resto da CPU com um bus e latências muito menores.
A diferença continua a ser abismal.

 

[JPgod]

Mas bem menor que nos cpus a 128 bits e 1000 mhz...

 

[blastarr]

Mas bem menor que nos cpus a 128 bits e 1000 mhz...

Pensas que a largura do bus interno e a latência das memórias cache L2 se mantêm imutáveis ?
Aínda guardo para aqui umas velharias com 256KB de cache L2, dos tempos em que esta ficava instalada na motherboard.

 

[Zar0n]

A tudo isto, há aínda o facto de serem 100% escalares (ao contrário do que acontece nas AMD R6xx). Isto significa que a Nvidia pode até optar por manter um nº relativamente reduzido de ALU's comparativamente com as G80, mas aumenta o nº de estágios para cada uma delas de forma a atingir velocidades de relógio mais elevadas.

Aumentar o nº de estágios não faz, por si só, aumentar a complexidade dos shaders.
Continua a ser in-order, ou seja, um shader pode começar e acabar de processar uma instrução, com outra num estágio intermédio, tudo num só ciclo de relógio.

Assim, a G80 faz auto-load balancing e todas as 128 ALU's estão sempre a ser utilizadas a cada ciclo de relógio.
A R600 está dependente do compilador de software para ordenar e distribuir o trabalho. Não só introduz mais latência, como uma aplicação está sempre dependente de optimizações do driver de software para utilizar a placa ao máximo, e mesmo assim haverá sempre ALU's em idle, enquanto outras estão a ser sobrecarregadas.

Como erradamente estas a tantar divulgar os SP da R600 n são o problema, aliás no caso da performance da R600 estarem estrangulados já k a placa n consegue por no ecrã a velociade suficiente.

Mas em termos de poder de calculo bruto são superiores.

Na R600 tens 5 unidades, mas como não são escalares corres o risco de ver 4 delas paradas num dado ciclo de relógio, à espera que a outra termine o seu trabalho, antes de começar a processar outro conjunto de dados.

Isso k acabaste de descrever nunca vai acontecer em cenários reais.

De piko os SP's da R600 são superiores mas no worst case senario são inferiores à G80.

Mas devido a optimizações é mais provável ela na media de aplicações estar mais perto do máximo teórico, nunca do mínimo.

As vantagem dos SP's da R600 é k com menos transitores tens um máximo teórico de poder de calculos superior, a desvantagem é k são mais complexos e tb é por isso k a Nvidia os consegue correr a uma velocidade tão elevada.

E n é k no caso da Nvidia esteja tudo a ser usado a 100%, há dependências e há limitações por outras partes do GPU e largura de banda dos mesmos.

Assim, a G80 faz auto-load balancing e todas as 128 ALU's estão sempre a ser utilizadas a cada ciclo de relógio.
A R600 está dependente do compilador de software para ordenar e distribuir o trabalho. Não só introduz mais latência, como uma aplicação está sempre dependente de optimizações do driver de software para utilizar a placa ao máximo, e mesmo assim haverá sempre ALU's em idle, enquanto outras estão a ser sobrecarregadas.

Já disse antes k n n vão estar sempre a 100% por factores externos, e isso de k a R600 é tudo por software e ridículo, em ambas ha hardware a tratar disso, as optimizações são o override do load balancing pelas equipas de drivers k podem melhorar a load melhor k um sistema automático.