Quem precisa de pesquisar aqui é outra pessoa...
Tanto o Timna como o MediaGX eram simplesmente SOCs (system-on-a-chip). O conceito SOC já existe há mais de 20 anos e consiste em integrar numa só die várias porções de lógica para fins distintos. Muitos sistemas baseados em autómatos já usam SOCs desde que existem e desde então também já foi usado em PDAs, telemóveis, set-top-boxes, GPS, TVs, leitores de DVD, etc.
O MediaGX e o Timna tinham gráficos incorporados, mas a porção de lógica que tratava dos gráficos estava separada da parte que constituía o CPU.
O projecto Fusion é algo completamente diferente dessas arquitecturas. Existem porções de lógica exclusivas para CPU e outras exclusivas para GPU, mas a maioria trata-se de memória e blocos de processamento versáteis q.b. para serem atribuídos para uma ou outra função. A eficácia deste tipo de arquitectura é completamente diferente da de um simples SOC x86.
Aliás, para saberes a diferença principal entre um SOC e o Fusion basta ver o post do qual fizeste quote a troçar (devias ao menos ter lido que assim aprendias qualquer coisinha):
- Estamos a falar da integração de funções gráficas numa
CPU para PC's, e tu vens com SoC para handhelds, STB's, TV's, etc.
Confundir o mercado altamente integrado e lucrativo das CE's com o mercado costumizável/
upgrade-prone por natureza dos PC's é algo..., bom, não é nada.
- Depois falas da atribuição de tarefas separadas no MediaGX para gráficos e para "tarefas que constituem a CPU", seja lá o que queres dar a entender (presumo que sejam apps general purpose). Quer dizer, uma GPU não tem lógica ? O que é uma ALU, por exemplo ?
Eu entendo a tua tentativa de raciocínio.
Estás a ir na conversa de que, potencialmente, um dos muitos cores de uma CPU moderna poderia ser dotado de tarefas vectoriais específicas para processar gráficos.
Sim, isso funciona em gráficos low-end, nem eu nunca disse que não.
Mas qualquer GPU moderna
discrete é "multi-core" por natureza, com dezenas de pipelines de renderização a trabalhar em paralelo, e
toda a die é usada para isso mesmo, com performance a condizer.
Numa CPU terás, no máximo, uma pequena percentagem do total da die para gráficos, sob a forma de um core dedicado com memória partilhada pelo resto do processador.
Essa memória, por não ser soldada directamente no mesmo PCB, nunca poderá beneficiar das latências mais baixas, largura de banda e consequente performance da memória especializada numa gráfica discrete.
Até a chamada memória "stacked" que a Intel propôs na última IDF só serviria como uma forma de cache de grandes dimensões, porque nunca se poderia ampliar a sua capacidade sem trocar a CPU por inteiro.
GPU's integradas numa CPU nunca serão tão rápidas como as GPU's dedicadas.
Até porque desenvolver uma GPU é mais rápido e barato do que desenhar uma CPU, especialmente uma com a "bagagem" de quase trinta anos do x86.
Depois falam das "sinergias" que uma integração de pipelines gráficos com processamento de instruções x86 traria, como se de uma poção mágica se tratasse que pouparia tarefas a ambos.
O problema é que processar gráficos é um tipo de computação completamente diferente de processar AI ou correr um anti-vírus, gerir uma base de dados, web-server, etc.
É essa a razão pela qual os motores gráficos processados "por software" em CPU's x86 foram abandonados em favor da aceleração por hardware em placas 3D, via API's que acedem directamente ao hardware 3D (Glide, PowerSGL, etc), ou pelo menos, às funções que este tem suportar para funcionar com essa API (DirectX HAL, etc).
Aliás, a tendência é para que o DirectX 10 *liberte* aínda mais as CPU's de processamento relacionado com gráficos e física, para diminuir os casos de "CPU limitation" que é tão frequente em jogos DX9 com o hardware 3D high-end actual, quando combinado com CPU's x86.
Não apenas no novo modelo de drivers do Windows Vista, mas também na eficiência das gráficas.