aziebert

Os FX-6 e FX-4 devem vir com cooler normal (versões de 95w) e o mesmo cooler dos X6 nas versões de 125w. Talvez os FX-8 venham com um cooler tipo torre, mas é pouco provável, mais fácil vir com o cooler dos X6 também. Watercooler da AMD era só rumor. Mas a Intel vai lançar um da Asetek como "acessório original": http://www.legitreviews.com/article/1707/1/

A caixa normal dos FX-6000 e 4000 (só os 8000 vem na lata de biscoito). http://www.planet3dnow.de/vbulletin/showpost.php?p=4503161&postcount=660

Os "SPs" da arquitetura CGN (Radeon HD 7000) serão bem mais complexos, lembram até os núcleos do Larrabee, que são praticamente um monte de Pentium "I". Meu palpite é que o tal do Grand-Fusion use esses núcleos como FPU do processador. Mas isso só lá pra 2013...

Só não sei se isso é específico do BD rodando AVX ou se é deficiência do conjunto mesmo.

Evandro, uma correçãozinha: O E-240 é single core 1.5GHz O E-300 é dual core 1.3GHz O E-350 é dual Core 1.6GHz. E o E-450 é dual core 1.3GHz/1.65GHz (Turbo) Isso tudo com TDP de 18w (Zacate) O E-300 substitui o E-240 (portanto o único Single Core será aposentado), e o E-450 substitui o E-350 (além de Turbo, o E-450 tem um clock um pouquinho maior na GPU). Em 9w (Ontario), o C50 (dual core 1GHz) será substituído pelo C-60 (1GHz, Turbo para 1.3GHz). Não estou encontrando informações sobre a versão single core, mas é provável que seja eliminada também.

Claro, eles estão mais que certos em privilegiar o maior público. O problema é que o compilador mais usado é feito pela Intel, ele pode simplesmente "esquecer" de implementar algumas otimizações para processadores concorrentes, mesmo que elas já sejam suportadas. E a Intel vai muito se preocupar em implementar otimizações que só o concorrente suporta né... O que vejo como ideal seria que todo mundo adotasse como padrão o GCC, por exemplo. E que AMD e Intel fizessem elas mesmas as bibliotecas de otimização para os seus processadores. Justamente para pegar carona em programas otimizados para Intel. Assim, quando o Haswell sair e o mercado todo começar a otimizar seus programas para FMA3, os processadores AMD também serão beneficiados. Enquanto isso, quem quiser otimizar especificamente para AMD, já pode aproveitar o suporte a FMA4 desde o Bulldozer.

wencell, FMA é uma espécie de atalho. A grosso modo é como fundir 2 linhas de código em uma só (uma multiplicação e uma soma). Teoricamente qualquer programa pode se beneficiar disso, desde que o compilador saiba aproveitar o recurso. O que me preocupa disso é justamente como os processadores Intel ainda não suportam FMA e os compiladores mais usados tendem a privilegiar os processadores Intel em termos de otimização, muitos programas novos podem continuar saindo sem tirar proveito do FMA...

Nav, o Eduardo deve estar muito melhor habilitado a comentar sobre o assunto do que eu. Mas pelo que entendi dos comentários do desenvolvedor do X264 o BD é um pouco lento para executar SSE e AVX. Agora as instruções XOP são fantásticas. Realizar uma CABAC com SSE, AVX ou FMA demora cerca de 340 ciclos. Fazendo uma boa otimização "na unha" ele conseguiu baixar para 253 ciclos. Fazendo uns ajustes rápidos em assembly para aproveitar as XOP ele baixou para 93 ciclos! Uma coisa interessante é que o BD suporta FMA (Fused Multiply ADD) nos registros de SSE. Outro detalhe que chamou atenção é que operações MOVE (pelo que eu entendi ele se refere a mover dados de um registro a outro) são "de gratis". Isso seria uma novidade exclusiva do AVX, mas o BD faz também para outras instruções. Uma observação é que o Bulldozer suporta FMA4, o SandyBridge não suporta FMA e a Intel só implementará suporte a FMA3 no Haswell. E parece que o Piledriver vai suportar FMA3 também. FMA3 e FMA4 são coisas diferentes porque com FMA3 você multiplica dois números, soma com um terceiro mas tem que salvar o resultado em um dos 3 registros usados. Com FMA4 você multiplica dois números, soma com um terceiro e salva o resultado em um quarto registro. Assim você não precisa se preocupar em perder/modificar dados de entrada, o que facilita bastante a programação (ou pelo menos o trabalho do compilador).

O desenvolvedor do X264 conseguiu acesso SSH a um BD e parece bem animado: http://www.xtremesystems.org/forums/showthread.php?265710-AMD-Zambezi-news-info-fans-!&p=4964335&viewfull=1#post4964335

Não sei se já levantaram isso por aqui: http://semiaccurate.com/forums/showpost.php?p=136384&postcount=2206 Backup: He is not all that close.But he made some reliable hints in the past: I was expecting a july-august BD lunch, and he told me "dont expecting anything till october".When some benchs are posted showing L2-L3 writes, he told me: forget it!Its a crippled ES sample,a bug or a fake. And he told me the core frequency(3.6) of 8150 before was made official. So, he looks reliable... TRUST but VERIFY.

i3 2120 (3.3GHz) IE9 158.1ms +/- 0.7% FF7 190.2ms +/- 1.8% Chrome14 201.3ms +/- 0.6% Pelo que vi aqui, o IE fez um bom uso de dois threads (um em cada núcleo, cerca de 60% de uso em cada núcleo).

jonny, como o MP Ratio foi maior que 4 no BD podemos concluir que o Cinebench usa muito mais as ALUs que as FPUs.

@Evandro, minha sugestão também é pra fechar esse tópico quando o BD sair, criar um novo pras CPUs Bulldozer e derivados (Zambezi, Vishera...) e outro para APUs (Llano, Trinity...). E quem sabe um terceiro para APUs de baixo consumo (Zacate/Ontario, Wichita...).

Assim como os Core i3 estão lavando todos os AMDs atuais em jogos, o FX-4 deve se sair muito bem, devido ao clock padrão alto. (4GHz sem turbo)

????? A diferença foi de 1w em idle e 7w em full. i7 2600k idle 102 full 204 FX-8150 idle 103 full 211 (as cores estão invertidas, verde é AMD em idle, azul é Intel em idle e vermelho é full load rodando Cinebench) Mas vale lembrar que isso tudo pode ser mentira.

teste de consumo é do OBR, então não dá pra ter certeza... mas se for verdade está muito bom, mesmo tendo TDP de 125w o BD consome pouco mais que o i7 2600k (que tem TDP de 95w, e sua placa mãe não tem northbridge)

A Crosshair V não tem esse morrinho:

E de onde você tira o PCIe ?

Vale lembrar que o roadmap ali mostrado é só de Mobile. Steamroller é a terceira geração da arquitetura Bulldozer. (Bulldozer -> Piledriver -> Steamroller) Se esses módulos estarão em uma CPU ou APU, e em que socket isso vai funcionar é outra história... O Vishera ainda deve ser feito em 32nm. E o Wichita deve ser feito em 28nm na TSMC. Quanto a compatibilidade de socket entre AM3+ e FM2, não faz sentido. Os processadores do AM3+ precisam de um link Hyper Transport para se comunicar com o northbridge, onde ficar o controlador de PCI Express. Os processadores do FM2 tem controlador PCIe integrado mas não tem Hyper Transport. Aquele retângulo no meio do AM3+ é um detalhe puramente mecânico. Assim como o fato de terem feito os furos um pouco mais grossos. O FM2 deve sim ser retrocompativel com o FM1 (tanto o Llano deve funcionar em placas FM2 quanto o Trinity em placas FM1). Mas resolveram fazer o Vishera no AM3+ para prolongar a vida da plataforma. O Komodo seria FM2.

Pelo que eu entendi, a FlexFP tem duas FPUs de 128 bits, para instruções de 256 bits o decodificador pode escolher se vai usar as duas simultaneamente e executar a instrução em 1 ciclo ou usar só uma e executar em 2 ciclos. De acordo com a carga dos dois núcleos do módulo.

Oficialmente os SandyBridge suportam apenas DDR3-1333, mas a controladora de memória tem multiplicadores para até 2133MHz. Agora, isso só funciona em placas P67 ou Z68. H61 e H67 são limitadas a DDR3-1333. donanimhaber vazou benchmarks oficiais: http://www.techpowerup.com/152569/AMD-FX-8150-Looks-Core-i7-980X-and-Core-i7-2600K-in-the-Eye-AMD-Benchmarks.html http://www.donanimhaber.com/islemci/galerileri/AMD-Bulldozer-FX-resmi-test-sonuclari_1.htm

Sim, nos Athlon e Phenom o HTT só é usado para se comunicar com o chipset. Enquanto nos Opteron ele também (ou é principalmente) usado para se comunicar com outros processadores. O Llano não tem HTT porque tem PCIe integrado. O Komodo teria PCIe e HTT, reforçando sua vocação para máquinas de cluster de GPUs. @Strikethrough O Komodo teria até 10 núcleos (5 módulos Piledriver, antes conhecido como Enhanced Bulldozer), HTT e PCIe integrado. Portanto seria necessário um novo socket (ou usar o do Llano, já que no desktop, tendo PCIe integrado, o HTT não é necessário). O Vishera terá 8 núcleos (4 módulos Piledriver) e apenas HTT, portanto ainda pode funcionar no AM3+.

Por HT nesse caso me refiro a Hyper Transport. (eu devia ter clocado HTT) Mesmo tendo PCIe integrado (o que elimina a necessidade de um northbridge na placa, e portanto um barramento Hyper Transport para se comunicar com tal northbridge) a versão server do Komodo teria também Hyper Transport (para comunicação com outros processadores). Esse arranjo é semelhante ao da versão server do SandyBridge-E e reforça a tendência cada vez maior da construção de clusters de GPU, pois o PCIe integrado implica numa "utilização ótima" de pelo menos duas placas de vídeo para cada processador instalado.

Essa notícia está brotando em tantos sites que deve ser verdade. Acho bom mesmo. Seria uma sacanagem muito grande exigir uma atualização de plataforma (AM3->AM3+) para suportar o Bulldozer pra logo depois (mesmo Q4 2012 seria "logo" nesse caso) descontinuar a plataforma... O Komodo era interessante. A versão server teria PCIe e HT, como no SandyBridge-EP (PCIe e QPI). Para o desktop o interessante é eliminar o northbridge e aproveitar os mesmos southbridges das APUs. Talvez até o mesmo socket (FM1/FM2), mas aí cairia no problema de ter CPUs e APUs na mesma plataforma (confusão quanto a se o vídeo onboard vai funcionar ou não, como no LGA 1156). Quem sabe no futuro veremos APUs high-end com mais CPU que GPU (4 módulos e uma GPUzinha como a do Ontario/Zacate, por exemplo), aí sim faz sentido unificar a plataforma. como hoje é sexta, o Aaronage do amdzone preparou uma nova versão do avatar do bulldozer patrolando o i7 e um papel de parede pra galera: http://www.flickr.com/photos/aaronage/6173084234/in/photostream http://i1183.photobucket.com/albums/x479/Aaronage/bulldozerwalppaperfx.png

Mesmo com a miniaturização para 32nm, ao colocar mais dois núcleos já se atingiria a mesma TDP com as mesmas frequências atuais. Portanto em aplicações que não usam todos os núcleos o desempenho seria o mesmo. Uma nova arquitetura era necessária para obter mais desempenho. Calma que falta pouco.