EspadaDaJustiça

Na verdade as numeclaturas da Nvidia são bem simples. O que se tem ate agora é que o chip usado da GTX 680 sera o GK104. O GK100 não vai sair ainda, e sim sua versão revisada (GK110). Os motivos da Nvidia não lançar o GK100 ainda são "nebulosas" digamos assim. Pode ser desde design inapropriado para o processo TSMC 28 Nm HKMG HP, ou ate uma questão "mercadologica", ja que não precisaria de tanto poder , ja que a concorrente ate agora não apresentou uma GPU que represente uma ameaça, etc... porém pessoal o GK104 que esta aparecendo nos "Previews" é sem duvida muito eficaz. Bem balanceado com alto Shader Power, com bom nivel de Pixel Power (ROPS), e com TMUs de sobra (ate demais ). Para a nvidia é uma GPU consideravelmente barata pra se fabricar, e que vai render muito bem nos Wafers. Seu PCB tambem é bem simples (se comparada a uma High-End). Se a Nvidia vender por 500 Dolares, vai encher bem a conta no banco . Ou seja, ela não vale 500 dolares, porém a Nvidia tera todo o direito de colocar o valor que deseja (afinal a GTX 680 sera mais rapida que a HD 7970).

Sobre a IBM defender o SOI nunca foi novidade né, afinal foi ela a primeira introduzir o SOI . Sobre os custos, o que é claro é que, o FD-SOI de fato aumenta em media o custo do Wafer entre 10 a 20%. A Intel sempre foi resistente a usar o SOI alegando justamente isso, CUSTOS . E como os FinFets da Intel serão usados no tradicional CMOS, os custos não serão um problema aqui (pelo menos na teoria ). Vamos ver comos os FinFets da Intel vai render.

Sim Johannesrs, afinal o GK104 nos boatos esta sendo colocado como tendo 3.54 B Transistores, e isso em 28 Nm tende a ter um bom nivel de consumo. O legal dos boatos pelo que vi, foi o equilibrio entre ROPS, e Banda de Memoria. O pessoal pode achar estranho a GK104 ter 256 Bits de bus de memoria. porém os chips GDDR5 da Hynix H5GQ2H24MFR-ROC trabalham a 6 GHz Efetivos a 1.6 V. Com Isso voce tem 192 GB/s de banda nada mal para um bus de 256 bits não? . Claro que SE os Controladores realmente suportarem trabalhar a essa frequência. Ainda estou esperando as especificações completas, mas pelo que vi ate agora ta bem bacana. So achei um pouco exagerado tantos TMUs. Com tantos TMUs tanto a GK104 , quanto o Tahiti XT, pedem que os desenvolvedores começem a usar texturas mais precisas (FP 32), ou seja, mais pesadas. Mas isso ainda vai demorar, e o pessoal sabe muito bem devido a que.... . Vamos ver como vai ficar o preço né..... essa é a grande questão.

Esses boatos da GTX 680 estão uma "salada" terrivel . O engraçado é especular sobre o que teria acontecido com o GK100? Sera que o design dele ficou tão ruim que forçou a nvidia a ter que fazer uma revisão nele para então lançar como GK110? Se o preço de 550 Dolares se firmar de fato, imagine o tanto de lucro agregado que a nvidia vai faturar. O motivo é simples, SE os dados dos boatos sobre o GK104 se confirmarem, seria um chip bem mais barato para a Nvidia, e com o PCB mostrado nos boatos (256 Bits, com VRM "comportado") os custos para a Nvidia seriam bem mais baixos do que ao da GTX 580. Ou seja, basta pensam um pouco pra ver que nesse cenario, a nvidia vai montar uma placa para literalmente, Rechear a conta bancaria . Concorrencia é o que salva os nossos bolsos pessoal.

Bom Diego, sei que é uma pergunta *****, mas você ta abrindo o Driver Sweeper no modo de segurança como administrador pelo UAC certo? (imagino que voce esteja usando o Windows Seven) porque senão ele vai travar mesmo. Com relação a temperatura isso é muito relativo, como ficam as temperaturas no profile Idle (157/300)? Sobre vocês ter destravado o controle da tensão do clock pelo Afterburner, so vai influenciar se a tensão estiver alta. Como ta a tensão no profile Multimidia (400/900) ? Quando eu tinha a minha HD 5870 no profile Multimidia ficava bem perto dessas temperaturas que voce citou (vale lembrar que eu moro no Mato Grosso, onde as temperaturas são elevadas).

É isso mesmo, valeu pelo aviso . Pensei em um e escrevi o outro. kkkkkk

Nada melhor que mais boatos para nos enlouquecer de vez não é? . Bom eu QUERIA acreditar nisso, porém o problema nem é o proprio Slide em si (que de dados mesmo tem MUITO pouco) mais sim o post do seronx. Bom ele postou la "bonitinho" os supostos specs das novas GPUs, ate a proporção entre elas e os CUs e tal. SO QUE , os ROPS diferentemente dos TMUS e os Shaders NÃO possuem relação de dependencia direta com os CUs(o mesmo vale para os SMs da nvidia). Ou seja, pode ter quantos CUs quiser, nao existe uma obrigatoriedade de colocar mais ROPS porque voce tem mais CUs. Eu imagino que ele deve ter achado que era interligado igual os TMUs e acabou fazendo a media aritmética pra chegar a suposta proporção de ROPs por *****. So isso ja acaba com a credibilidade da tal informação. Ja o Slide, de tão simples e vago, pode ou não ser verdadeiro. Ate porque nada melhor pra AMD que apimentar ainda mais essa guerra contra a Nvidia.

Ficou bacana esse seu post. A TSMC ate agora não anunciou nenhum Node em SOI seja, FD-SOI ou PD-SOI, portanto as GPUs em 28 Nm que estão sendo feitas por ela estão usando o tradicional Bulk CMOS 28 nm HKMG HP. Tudo que se tem ate agora são boatos sobre que a TSMC pode a vir usar SOI nos processos mais a frente. Ou seja de SOI concreto mesmo entre essas foundries , so a GF mesmo . Ate porque o SOI é um processo que torna o Wafer mais caro para fabricar. E com isso nos temos que esperar a Intel brincar com os FinFETs pra ver como eles vão render de fato nos Ivy Bridges, até porque os FinFETs tambem trazem seus proprios desafios. porém com essa suposta paralização da produção de Wafers em 28 nm pela TSMC, ainda vai rolar muita coisa por ai.

Eu entendo o que quer dizer. Como você ja sabe as Otimizações do GNC dão ao Cape Verde sua cartada na questão de Eficiência nos Shaders. Vale lembrar que dependendo da Engine do jogo a ser testado os resultados vão variar (normal ). Em Engines menos Shader Intensivos a HD 7750 fica mais proxima a sua irmã maior. Eu vi testes em que a HD 7750 perde por quase o dobro de FPS(em relação a HD 7770), geralmente em games DX11 com Post-Processamento alto e em engines muito shader intensivas, em outros games a diferença cai muito. O que é normal não é meu caro amigo Sirro . No caso do Juniper XT (HD 5770) os 1360 GFlops SP em MAD não significam muita coisa, até porque o VLIW5 é consideravelmente ineficiente em relação ao GNC. Vertex Shader então, no VLIW5 era bem decepcionante. Ja no GNC, melhorou bem isso. Outro detalhe é que se você prestar atenção cada vez mais jogos estão introduzindo o famoso FXAA. O FXAA como filtro pos-processado a renderização em si, vai se beneficiar bem de uma arquitetura como o GNC, e com isso você ganha alguns frames aqui. Sobre os caches L1 D & I, basicamente qualquer Workload, dentro dos CUs que precisa ser sincronizada com os outros do grupo local, uma hora ou outra vai ter que usar eles;). Geralmente Hull e Domain Shaders tende a usar mais ele (jogos), e no GPGPU vai variar de muito ou pouco, dependendo da bendita (ou maldita ) aplicação. porém o que eu quis colocar, e que apesar de ser um cache Importante, são de fatos os outros detalhes da arquitetura usada nas Novas Radeons, que pesam mais na performance dos jogos. O Cache L2 então.... Porque se fosse um caso de cache muito congestionada a AMD teria por obrigação ter que mudar isso na etapa de design. Uma outra situação ainda mais bizarra é a performance MUITO pareada das novas HD 7800 com as TOPS HD 7900. Ai voce pode dizer, "Onde esta a magica ?", bom não tem magica , o motivo é que apesar das novas HDs 7800 terem bem menos Shaders que as HD 7900, o seu poder em termos de ROPs (ou o que eu costumo chamar de Pixel Power) TMUs, foram bem preservados se compararmos com as HDs 7900. Alem de possuirem um otimo "Shader Power" . porém é como eu disse, quanto mais Shader Intensiva é uma Engine, maior tende a ser essa diferença. Ou seja para as novas HD 7900 brilharem mesmo, so faltava mais ROPs (e com isso mais Rasterizers e assim maior poder de Tesselation) e novos jogos com Engines que de fato aproveitem essa super poder nos Shaders.

Na Verdade Sirro, não tem nada de estranho na performance o Cape Verde, dependendo de ONDE você olhar é claro . Em primeiro Lugar o cache L1 de Dados e Instruções que são Compartilhados por 3 ou 4 CUs é apenas de Leitura, e é usado mais para processos de compartilhamento rápido entre os CUs. Dentro de Cada ***** temos um outro Tipo de Cache L1 que o Cache de Texture Fetch, alem do Scheduler, e PRINCIPALMENTE temos a unidade Escalar. E fácil se esquecer dela, porém no GCN , esse unidade escalar tem um papel importante, de realizar calculos que não sao bem realizados pelas unidades vetoriais. O Scheduler ta ai, porque o GNC como uma arquitetura que agora nao depende mais ILP, deve gerenciar melhor os Warps entre as unidades vetoriais e PRINCIPALMENTE mandar os Warps certos para a unidade escalar. porém ele so gerencia o seu proprio *****, quem de fato é o Grande Scheduler do chip são os ACEs. Outra coisa MUITO importante é que agora o Cape Verde tem nada menos que o DOBRO de Cache L2. No Juniper XT (HD 6770) tinhamos 128 KB de Cache L2 para cada controlador de memoria, totalizando 256 KB De Cache L2. Ja no Cape Verde temos 512 KB de Cache Unificada. O L2 é de fato o grande compartilhador de dados para TODO o Chip, não apenas para os ROPS (que agora não tem mais uma conexão direta com o L2). Portanto o GNC com sua Unidade Escalar + aumento de clock + L2 enorme, tem muito mais peso nessa performance que o L1 D & I. Erro de design sem duvida que não é . Veja bem Sirro, o L1 D & I é bem pequeno e poderia ser aumentado sem muitas consequências. porém não é um Cache digamos CRITICO aqui. Ja o L2 compartilhado e o L1 de Texturas, esses sim, pesam mais nos jogos. O Aumento do L2 não é uma surpresa digamos assim, a Nvidia ja tem seguido essa linha, porém no caso dela, foi uma obrigação, ja que devido aos Multiplos Rasterizers (coisa que ate então nao se viu em GPUs) você precisava de um Cache L2 Grande e Unificado, senão o esquema do Fermi não funcionaria. Se me permite eu vou fazer uma consideração até , As GPUs tinham por caracteristica, justamente muitas Unidades de Execução e poucas areas de memorias (buffers, Registradores, Caches,etc..), ja as CPUs por outro lado sempre forem conhecidas por menos unidades de execução e mais areas de memoria dentro do Die. E o que estamos vendo agora? GPUs com mais area de memoria, perdendo sua eficiência em relação performance/Transistores, porém ganhando flexibilidade. Esse é o preço da Flexibilidade. Bom se o Slide que nosso amigo Jonny_br postou estiver correto, as HDs 7800 vão trabalhar com 2 Primitivas por Clock, ou seja, 2 Triangulos por Clock, que é a mesma capacidade de Rasterização do Tahiti. Ou seja Clock a Clock o mesmo poder de Tesselation. Vamos ver se eles vão fazer outros tipos de Cortes né

Sim Sirro, porém o pequeno adicional de Cache L1 não iria fazer milagres. E outra, SE os CUs estavam carentes de Cache L1 , porque raios a AMD iria colocar eles no conjunto de 4 CUs com a quantidade de Cache L1 atual? Seria um erro primario, pra não falar ridiculo . Pois isso, eu acredito mais na ideia de ela ter feito 4/3/3 pra melhorar os rendimentos dos Wafers, do que na ideia citada.

Pois é pessoal estão ai as Radeons 7700. Eu ja esperava uma performance moderada, nada de espetacular, porém respeitavel. A grande sacada aqui, foi o aumento do clock base do Chip pra 1 Ghz na HD 7770. Com isso a performance mantem um bom nivel, apesar do GNC não ser tão poderoso na relação area/transistores quanto o VLIW4, eficiência é agora a palavra de ordem . Confesso que achei estranho a AMD usar esquema de agrupamento de CUs 4/3/3 no Cape Verde. No Tahiti temos o esquema de agrupamento de 4 CUs usando o mesmo Cache L1 De instruções e Dados. Com o esquema em 3 CUs, temos uma subutilização dos Caches L1 de Dados e Instruções. Eles poderiam manter o esquema em 4/4/4, mas acredito que seja uma estrategia para obter melhor aproveitamento das fornadas do Cape Verde. Os TMUs e ROPs são identicos aos do Tahiti, inclusive o Crossbar que interliga os ROPs com os Controladores de memoria. O objetivo maior desse Crossbar seria criar uma flexibilidade maior na hora de se colocar ROPs e alimenta-los com barramentos de memoria. porém até agora não estou vendo muita serventia dele, pelo menos por enquanto.... De resto nada de novidade, CUs identicos internamente aos do Tahiti. Redução para apenas 1 Rasterizer, 1 Geometry Engine (2 de cada no Tahiti) o que é sensato, ja que temos apenas 16 ROPs agora , não temos necessidade de 2 Rasterizers aqui. Em termos de computação em FP32 MAD temos respeitaveis 1.28 Teraflops porém devido as GCN temos melhor utilização desses 1.28 Teraflops. Ja em FP64 temos apenas 80 Gigaflops .... porém devido apenas a uma limitação artificial, criada para focar esse tipo de aplicação nos produtos FirePRO. Baixo consumo (devido ao Processo TSMC 28 nm HKMG HP) , alem do Recurso PowerTune. porém o recurso que achei bem legal é o VCE, que nada mais é que a adição de um Encoder de Video via Hardware. Com isso você pode usar o poder da placa para criar videos usando o Encoder das novas radeons. Pro pessoal que gosta de editar e criar videos, é um recurso bem bacana. Placas legais, performance respeitavel (porém nada demais), tem potêncial, porém a AMD precisa apenas acertar o preço certo nelas.

Sim, o nosso amigo Sirroman esta certo. porém tanto o PS3 quanto o Xbox tambem usam APIs, Proprietarias é claro, mais usam. O PS3 usa LibGCM com a Linguagem Shader PSGL, e o Xbox 360 usa o Direct X, porém otimizado apenas para o hardware do Xbox que foi criado pelo Programa Microsoft XNA. O motivo de ser melhor aproveitado aqui nos consoles, é uma questão até que obvia, afinal sendo um Hardware FIXO, é MUITO MAIS fácil otimizar o codigo para rodar da melhor forma possivel. Justamente pelo Hardware ser FIXO, as APIs não precisam de muitas camadas de abstração, o que deixa a API mais direta ao hardware, do que as APIs usadas nos PCs. A Perca de performance APENAS pela API DirectX dos Pcs, chega de 30 a 40%. Devido as varias camadas de abstração que ela deve lidar, devido aos varios possiveis hardwares que você tem que estar preparado para lidar. Portanto ao mesmo tempo que a Flexibilidade dos PCs é seu diferencial, tambem é sua maldição . porém vou dizer uma coisa pra você, os jogos de hoje, não rendem bem nos Pcs, não é so pelas APIs não. O motivo vai desde PURA PREGUIÇA na otimização do Codigo por parte das Software House de games (afinal como a propria Ubisoft costuma dizer, "Não vale a pena otimizar games pra PC, devido a Enorme Pirataria existente") e falta de incentivos por parte dos fabricantes, Ex: INTEL, AMD. A Nvidia é uma das poucas que ainda investem mais nos contatos com as Software House de Games. A AMD tambem faz, porém ainda de maneria "TIMIDA".

Bom vai depender ONDE ela vai querer colocar força bruta . Se ela REALMENTE QUERER melhorar a performance nos jogos de forma significativa, a primeira coisa a se fazer seria melhorar o poder dos Rasterizers colocar 3 ou 4 Triangulos por clock, e com isso colocar mais ROPs. Seria bom tambem aumentar os SPs, mas eu acredito que nao tera muito aumento aqui, devido a densidade de transistores ser muito alta nos SIMD Clusters do GCN. Olha o problema da AMD com a Serie FireGL e a FirePro tem mais haver com suporte aos programas de Renderização Profissional como Maya, 3D Studio, etc.., alem de Suporte mais "aprimorado" aos Programas de CAD do que com a arquitetura de suas GPUs. O GCN não sera um ponto chave em produtos como FireGL, que são mais voltados para Renderização Profissonal, ja que basicamente falando, os processos envolvidos são bem semelhantes aos usados nos jogos. Ja para a Serie FirePro que é mais voltada para programas CAD, simulação financeira e estatistica, sem duvida que sera muito bem vindo. Bom vai depender se a Nvidia desistir do esquema PURAMENTE ESCALAR e criar Cluster semelhantes aos da AMD, coisa que não acredito acontecer tão cedo (MAS É POSSIVEL ) Não é que os Transistores sejam Enormes . E que os Cluster onde estão Os SPs são naturamente densos em termos de transistores, e ja que a Nvidia usa um Dominio de Clock, bem mais elevado para os Clusters do que para o Restante do Chip, torna mais difícil de controlar e prever como eles vão se comportar. E ai johannesrs tudo bom?. Não sei se sou digno pra fazer um Review Completo desses temas , mas vou falar um pouco sobre isso. Bom vamos dividir as diferenças basicas em dois temas, o primeiro sendo GPGPU e o segundo Renderização Tradicional, ok. GPGPU: Bom o Fermi nesse questão esta muito bem estabelecido. Não apenas na arquitetura do Hardware, mas PRINCIPALMENTE na parte de Software. A nvidia fez um bom trabalho em conseguir propagar os SDKs para desenvolvimento em CUDA, inclusive o Gromacs né, aderiu ao CUDA tambem. Bom ja na parte de hardware o Fermi tem como pontos chaves em GPGPU: * Unidades Sps Escalares de fácil Agendamento e Controle * SPs de ALTISSIMA eficiencia * Cache L2 UNIFICADO, COM NIVEIS DE HIERARQUIA * Grande Numero de Buffers e Registradores, em todo o chip * Compartilhamente do Endereçamento Fisico da memoria com a CPU do Sistema (MUITO UTIL quando você vai usar Ponteiros, quando estiver programando usando C++) Existe outros detalhes, mas não vamos criar um texto do tamanho de um livro certo?. Dentro esses detalhes o mais importante alem dos SP é sem duvida o Cache L2 Unificado. Para computação geral, é muito importante TODOS os Clusters, compartilhem o maximo possivel de dados, porque como temos operações MUITO diferentes sendo executadas quando estamos rodando aplicações FLOP intensivas, um Cluster com um determinado Wavefront (ou WARP) pode precisar de um determinado Dado, que foi alocado no Cache por outro Cluster. Dai compartilhar aqui é importante. Ja o Tahiti com o GCN, possui muitas coisas em comum, como Kernels Concorrentes, Grande numero de Buffers e Registradores, aumento de eficiencia e Flexibilidade dos Cluster SIMD, compartilhamento do endereçamento Fisico da Memoria, proteção ECC, etc... porém ainda possui certas diferenças, Os SPs do GCN apesar de Flexiveis, ainda não são Tão Flexiveis como os do Fermi. A AMD criou um Cluster com muitos Blocos SPs Superescalares no Esquema Vec16. Apesar do Agendamento dos Wavefronts( e de suas instruções) serem feitas de maneira semelhante aos do Fermi, ainda os WaveFronts da AMD são diferentes dos usados pela nvidia. porém o Tahiti é melhor em varios aspectos, como o esquema de dois motores DMI, para ter vantagem quando usar o PCI Express 3.0 (isso vai ser bemmmmm mais significativo para GPGPU do que para jogos), Melhor esquema de economia de energia, entre outros. Renderização Tradicional: Aqui as diferenças são bem mais claras, o Fermi possui maior poder em Blend e Pixel power (ROPs), menor poder em termos de Alocar e filtrar Texturas (TMUs), maior poder TEORICO em termos de Rasterização de Triangulos (Rasterizers) que é a chave para um Tesselation mais parrudo. porém o Tahiti, melhorou de forma consideravel a eficiencia dos Seus Rasterizers e do Tesselator. Conseguindo uma boa melhora aqui (mas não tão grande assim). Apesar de ter menos ROPs, eles funcionam muito bem, alem de ter a disposição MUITA banda de memoria para eles "comerem" . So não acho que a AMD melhorou de forma estão grande a eficiência deles (como ela diz nos seus Slides). Usar um Crossbar como intermediario entre os ROPS e os controladores de memoria, apesar de deixar mais Flexivel a montagem de produtos sem ter aquela dependencia de ROPS/Barramento de memoria, tem o inconveniente de uma maior latência. Eu acredito que a melhora seja mais pelo fato de um aumento muito alto de banda para eles, do que melhorias realizadas neles. É isso, espero ter ajudado. Não é bem isso Diego, o problema de ser querer fundir uma GPU com 2.64 B de transistores com uma CPU X86, alem do fato do consumo ser astronomicamente elevado, custo de produção alto, baixo aproveitamento por Wafer, é tambem que a performance vai ficar prejudicada em torno de 40 a 50% so pelas memorias usadas. Vale lembrar que o Trinity , como qualquer esquema de APU, vai usar a memoria do Sistema, que no melhor dos casos sera uma DDR3 rapida, se hipoteticamente tivessemos um esquema no Trinity de 4 Canais (quad Channel) e usassem DDR3 de 2133 Mhz teriamos em torno de 68 GB/s de banda de memoria, MUITO ABAIXO dos 176 GB/s que ela tem a disposição quando esta no PCB da HD 6970 . Portanto NÃO VALE A PENA, colocar uma GPU tão complexa e faminta por banda, em uma APU. JA na questão dos Consoles temos uma diferença aqui. As GPUs usadas nos consoles, tendem a ser mais comportadas na questão de consumo, devido a determinações de design. Alem do fato de que a maioria dos Consoles tendem a usar GPUs com memoria embutida no Die, as chamadas eDRAM. Elas são memorias que são construidas dentro do Die da GPU (consomem transistores) e tendem a ter uma Banda de memoria MUITO ALTA. porém seu custo por MB é muito elevado, e dessa forma, não se pode ter muitos Megabytes de eDRAM dentro de uma GPU. No Caso do Xenos do Xbox 360, são apenas 10 MB, o suficiente como Framebuffer em resoluções abaixo do Full HD.

Bom pessoal SOU EU que tenho que agradecer a vocês. Todos nos estamos aqui para isso, compartilhar conhecimentos , é isso que torna o nosso forum tão bom. Agora vamos ver como vai ficar a briga desses monstrinhos do Tahiti Vs Kepler.