Ir ao conteúdo
  • Cadastre-se

EspadaDaJustiça

Membro Pleno
  • Posts

    791
  • Cadastrado em

  • Última visita

Tudo que EspadaDaJustiça postou

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. É isso mesmo, valeu pelo aviso . Pensei em um e escrevi o outro. kkkkkk
  7. 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.
  8. 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.
  9. 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.
  10. 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é
  11. 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.
  12. 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.
  13. 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".
  14. 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.
  15. 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.
  16. Ola Diego, pelo que eu me lembro daquela nossa conversa, você tinha perguntando qual era a diferença real entre os SPs do esquema Dedicado entre Pixel e Vertex (anterior ao R600 da AMD e G80 da Nvidia) e do esquema atual de Shaders Unificados. Dai eu te expliquei que o esquema anterior nos não tinhamos SPs, e sim os Pixels Pipelines e Vertex Pipelines, que apesar de serem bem poderosos em suas funções, não tinham a flexibilidade requerida nos Games Pós DX9. E que o esquema de SPs apesar de não serem muito poderosos (ja que 1 Pixel Pipeline/Vertex Pipeline da 7800 GTX ele é bem mais poderoso, do que 1 SP do Esquema Shaders Unificados da 8800 GTX por exemplo) eles conseguiam ser melhores devido ao conjunto de VARIOS SPs juntos, e que no fim das contas apesar de você ter que gastar mais transistores/area com o esquema Shader Unificados, você resolvia o problema de balanço entre utilização entre Pixel e Vertex Shader. Era isso se não me falha a memoria . Bom essa questão entre os SPs da AMD e da nvidia é sem duvida bem pertinente né . Vejam que sem duvida o esquema VLIW era interessante em se usar nos games, era simples e com boa relação performance/ Transistores. E com isso a AMD/ATI conseguia criar boas GPUs com bem menos transistores que sua Rival Nvidia. porém o VLIW tambem tem seus problemas, nos games por exemplo, quando precisava usar Vertex Shaders, o VLIW não era tão bom, quanto nos Shaders do Pixel Shader. Não apenas isso, mas como ja disse, toda a questão do Agendamento dos Wavefronts, torna o VLIW muito dependente de melhorias no Compilador, o que torna a parte de Software CRUCIAL aqui. Lembram que não era incomum, a AMD/ATI lançar Drivers com melhorias de ate 30 ou 40% de aumento do performance em certos jogos, isso não é "milagre" mas devido a fraquesa do VLIW, se tinha que ficar MUITO TEMPO otimizando o Compilador para refinar a performance. TEM QUE TER MUITO SACO pra ficar fazendo isso . O VLIW foi um bom esquema, que na minha opnião compriu bem seu papel. Mas o mundo gira, e o futuro agora demanda GPGPU, e o GCN ta ai pra isso. Uma detalhe aqui entre nos do Clube do Hardware , quando a AMD ou a Nvidia lança essas arquiteturas novas e diz: "Nos estamos criando um novo esquema que é otimizado em Games e GPGPU" eu paro e ficando pensando, Eles querem enganar quem com isso??? TA NA CARA, que o foco das arquiteturas ate agora, desde o G80 e o R600, esta indo em direção ao GPGPU. Não acham estranho a HD 7970 ter 4.31 Bilhões de Transistores (quase o dobro do Cayman XT) para ter um aumento tão "moderado" na performance nos jogos? Dai vem os caras dizerem, " Ah mais os Drivers estão imaturos ainda". Tudo bem, drivers mais maduros ajudam sim, porém ajudam mais em eliminar BUGS entre outros problemas do que melhorar performance propriamente dita. E agora com o GCN, esta desculpa ainda fica mais difícil de ser justificada. Mas é apenas a minha opnião .
  17. Nos jogos era digamos "Adequado", porém conforme o tempo foi passando, cada vez mais os fabricantes de GPUs se viram em um dilema. As GPUs estavam muito limitadas apenas No segmento Multimidia, na qual se destacavam mais em games. porém com a vinda das APUs os processadores começavam a incorporar funções antes exclusivas das GPUs. Por uma questão de sobrevivencia as GPUs precisavam de novos mercados. Por sua natureza SIMD altamente paralela, as GPUs se encaixavam bem em programas chamados FLOPS intensivos, na qual, são programas que demandam altissimo poder em computação com numeros em ponto flutuante. Que eram programas que as tradicionais CPUs X86 simplesmente não davam conta do recado . (Claro que poderiamos criar Cluster com varias CPUs X86, porém isso não era muito satisfatorio, alem de ser econômicamente ineficiente). Dessa forma o GPGPU se viu em uma escalada para o futuro. Com o surgimento de GPUs, não apenas criadas para renderização, mas tambem para computação FLOPS de alto desempenho. Dai temos o problema, como o VLIW não se dava bem com Wavefronts dependentes entre si, não era adequado para GPGPU. Outro detalhe importante sobre o VLIW é que o AGENDAMENTO de quais instruções iriam ser executadas primeiro dentro do Wavefront, eram ja definidas na compilação, dessa forma, o compilador tem um papel IMPORTANTE na performance geral do esquema, ja que dependendo da ordem escolhida, podemos ter baixa ou alta performance, principalmente em Linguagem de alto nivel de abstração. Em jogos isso não é um problema, ja que neles podemos facilmente compilar e agendar as Instruções mais apropiadas dentro do Wavefront, ja que são na sua grande maioria bem semelhantes. porém instruções de computação Geral, a coisa muda. Em GPGPU podemos ter programas que precisem de um Agendamento dinamico, ja que teremos varios tipos de Wavefronts dependentes. Olha um exemplo bacana que peguei da net de um exemplo mais adequado para o VLIW: Ja aqui é um exemplo onde temos wavefronts dependentes entre si, na qual é inadequado pro VLIW: É ai que o GCN brilha. O GCN tambem tem SPs no esquema SIMD, porém o GCN tem grupos grande de SPs. No atual GCN temos por "CORE" 4 Grupos compostos de nada menos que 16 SPs, sendo que esses são homogeneos entre si (semelhante aos usados no VLIW4, apenas por efeito de comparação ). porém o que torna o GCN melhor no GPGPu é justamente o esquema de utilização dos Wavefronts e seu Agendamento. No GCN, temos um Agendador por hardware, que fica responsavel em agendar dinamicamente as instruções dentro dos Wavefronts conforme a necessidade. Assim como na figura acima, caso se tenha Wavefronts dependentes entre si, você não tera problemas de performance, ja que o agendador, ira ajustar as instruções de acordo com o que esta sendo trabalhado. Isso é similar no Fermi, que tambem tem seu proprio Agendador de Warps via Hardware. Veja que um Agendador por hardware requer transistores dentro do Die, e portanto torna a GPU mais complexa para se fabricar, porém a torna mais dinamica, fator importante hoje em dia. O Legal disso é que tirando o peso do agendamento do compilador, pelo menos em TEORIA, não deveremos mais sofrer de quedas bruscas de performance por causa de problemas nos drivers (pelo menos no que se refere aos Shaders). Veja que o VLIW tambem tem seus pontos de brilho em operações de GPGPU, como Decripitar Chaves por Brute-Force, na qual a GPU ira efetuar TODAS as possiveis variações de letras e numeros em formato string. São operações Paralelas e não dependentes entre si. porém ate mesmo nisso o GNC não tera nenhum problema em se ajustar . Bom EU SEI que você tem o conhecimento que o motivo da AMD ter mais SPs é devido justamente a adoção de SIMDs com SPs SuperEscalares, devido ao que ja dissemos antes. A nvidia usa a abordagem de SPs Escalares, que são mais simples de serem gerenciados. Bom quando pegamos a PERFORMANCE EM MAD precisão Simples o esquema de Shaders da AMD sempre deram um banho em termos de performance teorica certo? O motivo de que nos games a performance se mater "parecida" com as GPUs da nvidia, tem mais a ver com as outras etapas da renderização, do que dos Shaders propriamente. Se pegarmos em Testes Sinteticos os Shaders da AMD, que damandam BASICAMENTE MUITO Pixel Shader, teremos de fato uma boa vantagem da AMD nesse teste (lembra do que eu disse do VLIW? ). porém se eu pegar um Teste sintetico como foco Vertex Shader, a coisa muda, a nvidia atualmente tem vantagem aqui. . porém o que torna a performance mais "parea" é que as GPUs Da Nvidia, possuem mais "PIXEL POWER" e "BLEND POWER" devido aos ROPs mais Parrudos usados pela nvidia. Alem das Otimizações que a Nvidia fez nos seus TMUs para contrabalançar os TMUs da AMD. Alem disso, o que torna a vida da nvidia mais confortavel, é que justamente por não usar o VLIW, e ter um Agendador por hardware, não é necessario toda uma otimização MASSIVA para que eu possa ter uma boa performance usando as GPUs dela. Coisa que era preciso fazer nas GPUs da AMD, se eu quisesse mostrar todo o seu poder. Claro que o GCN não é de "graça". Os CORES ou CUs são bem mais complexos dos que os CORES usados no VLIW, ou seja, são mais densos em termos de transistores. Basta você olhar que a HD 7970 tem quase o DOBRO de transistores do que o Cayman, porém apenas 33% a mais de unidades de Shaders e TMUs, e O MESMO Numero de ROPS. Bom é isso, realmente eu escrevi demais, peço desculpas de exagerei.
  18. So Espero que a Nvidia tome vergonha na cara, e melhore a eficiência dos seus ROPs, ao invés de querer colocar um Kepler em um barramento de memoria de 512 Bits ..... Outro desejo meu, é que ela melhore esse esquema de 4 Rasterizers, que na teoria deveriam gerar quase 4 Triangulos por Clock, mas que na pratica mal consegue chegar a 2 por clock..... Enfim, tomara que o Kepler não decepcione.....
  19. Bom se a HD 7770 tiver realmente 896 SPs, então teremos um Cape Verde XT composto de 14 CUs, totalizando 896 SPs + 14 SPs Escalares + 56 TMUs. Teremos então 2 Barramentos de 64 bits (128 bits), ou seja 4 Grupos ROPS de 4 Color ROPS e 16 Z/Stencil Cada um, totalizando 16 Color ROPS e 64 Z/Stencil. Se compararmos com a HD 5770 (Juniper XT) de 800 SPs em VLIW5 + 40 TMUs, e com 16 ROPS e 64 Z/Stencil. Porque a HD 7770 deveria ser tão mais poderosa? Basta vocês repararem nas especificações de cada uma, e veram que não houve quase aumento nenhum em termos de unidades. A Banda de memoria da HD 7770 se a GDDR5 dela for de 1125 Mhz, teremos 72 GB/s de banda, contra 76.8 GB/s da HD 5770.... O que ajuda ,é sem duvida, o Clock base elevado, se for mesmo 1 GHZ. porém mesmo com 1 GHZ, contra os 850 MHZ da HD 5770, teremos 1.79 Teraflops em MAD de precisão Simples, contra 1.36 Teraflops em MAD de precisão Simples. Ou seja, pouca diferença real. porém como os Shaders do GNC são bem mais otimizados, esse poder sera melhor aproveitado no Cape Verde. Com isso não adianta esperar MUITA COISA, não acham
  20. Bem Evandro, certamente que adicionar Rops e Rasterizer mais poderosos, tem seus custos tanto em consumo, quanto area/transistores. porém pelo consumo que a placa apresenta EU acredito que não foi isso que impediu a AMD. A AMD nunca foi do tipo de colocar Muito "PIXEL POWER" em suas placas, e mesmo assim elas redem bem. Acredito que a AMD quis ser mais "cuidadosa" em tornar o design da GPU o menos complexo possivel, afinal ela esta usando o recem liberado processo de 28 Nm HP HKMG da TSMC . porém Evandro, sem duvida que com Mais Rops e Rasterizers essa placa iria render bem mais, principalmente pra galera que usa 3 ou mais monitores então, iria ADORAR isso . Outra coisa, e que com essa GPU, fica mais confortavel montar uma Dual GPU, ja que temos uma GPU bem "comportada" no quesito consumo.
  21. Ola Pessoal, bem o review dessa danada finalmente saiu . Bem, a placa sem duvida é um belo monstrinho, mas devo admitir que esperava algo mais poderoso.... porém ao verificar as especificações da pra ver do porque não ter sido mais poderosa. Vejam bem, o GCN sem duvida é a UNICA mudança significativa dessa nova geração das placas da AMD. Eu me lembro que costumava postar que a AMD/ATI usava força bruta com media eficiência, enquanto a Nvidia usava menos força com alta eficiência. Pois é, a AMD agora pegou a ideia da Nvidia, em criar Shaders mais OTIMIZADOS, ao invés de apenas adicionar força bruta massiva. O que é bom não apenas nos jogos, mas em GPGPU. O grande problema dos Shaders da arquitetura VLIW era justamente sua baixa constancia em desempenho. Ja que o VLIW depende de Warps Longos, não dependentes de instruções posteriores, para ser de fato, rapida. porém na parte de Função FIXA (ROPS, TMUS, Rasterizers, Tesselator) praticamente não teve mudanças. E é justamente ai que mora o "problema". Na placa de video, temos varias unidades que trabalham em conjunto, para que tenhamos uma performance satisfatoria. Cada parte tem seu peso, de acordo com o que é realizado. Os TMUS são responsaveis pelo endereçamente dos Texels, assim como sua filtragem. Nas placas da AMD, desde da Serie HD 4000, TMUs não são mais um problema, até superando a Nvidia nesse conceito. JA nos ROPS, temos um certo "entrave" aqui. Devido justamente aos Rasterizer terem sido mantidos em 16 pixels cada um (32 pixels total), a AMD decidiu manter a capacidade dos ROPS em 32 Color Pixels. Os GRUPOS ROPs são IDENTICOS aos da HD 6900, cada um capaz de fazer Blend em 4 Color ROPS e 16 Z/Stencil ROPS. Vale lembrar que a AMD tem uma certa flexibilidade entre os GRUPOS ROPS e os controladores de memoria, mas não vamos entrar em detalhes por agora. Os Rasterizer são 2 (IGUAL a serie HD 6900) Cada um Rasteriza Triangulos de ate 16 pixels cada um. Os Tesselators , foram melhorados, principalmente em Fatores de Tesselação acima de 7. Melhoraram o tamanho dos buffers, assim como a reutilização dos Vertex Shaders (similar ao que a Nvidia fez na Serie GTX 500). Bom pra encurtar, a palavra chave da HD 7970 é OTIMIZAÇÃO. E graças ao GCN, o compilador não é mais um grande responsavel pela perca de performance. Dessa forma, novos Drivers podem melhorar, mas não vão poder trazer "milagres".
  22. Bom, eu tenho uma noticia não estão boa pra quem pensa em comprar o ST2000DL003 Barracuda Green 2TB. No forum da Seagate, tem um numero cada vez maior de usuarios com o seguinte problema: * Durante um Certo tempo, o HD para de ser reconhecido no SETUP, e não volta a ser reconhecido de jeito nenhum. Isso ocorreu com varios usuarios, com varias configurações diferentes. * Esse problema Ocorre Especificamente com o ST2000DL003 com a P/N:9VT166. * Não importa se o Firmware é CC31 ou o ultima versão (CC32) o problema ocorre em ambas as versões. * Por mais estranho que pareça ate agora a Seagate não anunciou publicamente que esse modelo tenha vindo com problemas de fabricação. porém o numero de problemas continua crescendo. * Aqui vai o link do Forum oficial da Seagate de usuarios tendo esse problema: http://forum.seagate.com/t5/Barracuda-XT-Barracuda-Barracuda/ST2000DL003-Barracuda-Green-not-detected-at-BIOS/td-p/87154 Eu tive o desprazer de ter comprado um desses la em Pedro Juan - PY. Depois que vi a provavel bomba relogio que tinha em mãos, mandei trocar na mesma hora . Boa sorte pro pessoal.
  23. O ideal é você verificar se o Seu CSS esta com todos os patches de atualizações instalados. O drivers 9.12 foi o que funcionou melhor no pc do meu amigo, claro que cada caso é um caso . Eu ja tinha visto em varios foruns, inclusive os da Nvidia e AMD, de pessoas reclamando da performance da HD 5770 e HD 4890 , GTX 260, justamente nesse game o Counter Strike Source. Como eu não gosto desse jogo, eu não tenho como testa-lo. Esse games da Valve antigos, costumam dar trabalho . Alguem ai do Forum, que ainda roda isso , poderia comentar a respeito?
  24. Sobre o CSS, é um problema dos drivers mesmo. Os Drivers da serie 10 e 11 não se dão bem com ele. Se o CSS é tão importante pra você, sugiro voltar ao Catalyst 9.12, que para o CSS da uma boa ajuda. Fiz esse teste no pc de um amigo, e como ele gosta do CSS, testei o 9.12 e ficou bom.

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas comunidades sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×
×
  • Criar novo...