Gerucht: AMD-ATi gaat gpu op cpu bakken

Als 90% toch voorspelbaar is, waarom start je dan zelf geen geruchtensite? Ach jaloezie ...

Cyrix MediaGX.

Eet smakelijk .

Die handel is overigens zoals je kunt lezen overgenomen door AMD en heet nu Geode, dus AMD heeft zoiets al in huis . De performance was kut trouwens.

Als je maar genoeg roddels rondstrooit, dan is het vanzelf ook wel eens waar. Inquirer vertelt al 10 jaar dat Dell AMD gaat verkopen.

Ik verdenk Dell er dan ook van dat ze hebben besloten AMD's te gaan voeren om van The Inq af te zijn....

En als je wilt upgraden later neem je toch een moederbord met pci-express. Lijkt me makkelijker, die grafische chips onboard zijn meestal toch niet zo sterk en als je dan een evenwaardige pci-express videokaart wilt ben je hooguit 60 euro kwijt.

Als je een GPU in je CPU hebt komen er in één klap een aantal problemen bij. Wat als de CPU perfect is, maar in de GPU een aantal pipelines niet werken of deze helemaal niet functioneert; in dat geval kun je dus niet alleen de GPU, maar ook de CPU weggooien.

Nowp ... dezelfde rules blijven bestaan. Als de GPU deel enkel broken pipes heeft, verkoopt men deze als mechien een 1Ghz + 16 pipes, ipv 2Ghz + 24pipes. Of men verkoopt deze mechien als 2Ghz + 16pipes en men maakt meer subcategories aan voor alle cpu-gpu.

Het wordt enkel een beetje ingewikkelder voor AMD om de juiste combinaties te bepalen.

En de Inquirer is soms toch dom... CPU + GPU op één core geen voordeel ... lol ... ze hebben blijkbaar geen idee hoeveel voordeel dat kan opleveren, bij het wegvallen van de trage verbinding tussen CPU & GPU.

En de Inquirer is soms toch dom... CPU + GPU op één core geen voordeel ... lol ... ze hebben blijkbaar geen idee hoeveel voordeel dat kan opleveren, bij het wegvallen van de trage verbinding tussen CPU & GPU.

Of misschien hebben ze dat juist wel.
De verbinding tussen CPU en GPU is meestal helemaal geen bottleneck.
Het gaat meestal om de CPU zelf of de GPU zelf, die de bottleneck zijn, maar zelden de communicatie, bij normale applicaties.
Een GPU is namelijk een accelerator, en is dus ontworpen om de CPU zo veel mogelijk te ontlasten. Dat houdt dus in dat de CPU zo min mogelijk hoeft te doen om graphics te genereren, wat oa inhoudt dat je zo min mogelijk data naar de GPU stuurt, en de GPU zo veel mogelijk zelf laat doen.
Er zit immers niet voor niets zo'n hoop geheugen op een videokaart. Dat zit er niet omdat de CPU constant een hoop data naar de CPU moet sturen, nee dat zit er zodat de CPU het eenmalig stuurt, en de GPU er daarna over kan beschikken.
Het is helemaal niet wenselijk dat de CPU veel data naar de GPU verstuurt, want als de CPU data moet versturen, kan ie niets anders, waardoor het effect van de acceleratie dus weer teniet wordt gedaan. De CPU is immers niet vrij om zich met andere dingen bezig te houden.
Sowieso is een CPU daar niet eens snel genoeg voor. De geheugeninterface van een videokaart heeft veel meer bandbreedte dan die van een CPU. De CPU zou de GPU dus alleen maar vertragen, als de GPU afhankelijk zou worden van de CPU voor data.

Ik beweer dan ook dat de communicatie geen enkel voordeel is.
Dit is redelijk makkelijk te onderbouwen door AGP4x, AGP8x en PCI-e 16x met elkaar te vergelijken.
Bij verder gelijke videokaarten zul je in de meeste gevallen niet of nauwelijks verschil in prestaties zien.
Conclusie: snellere communicatie tussen CPU en GPU is niet interessant.

Het lijkt me dan ook dat AMD geen CPU+GPU-combinaties voor de desktop-markt gaat maken.
Het zou wel interessant kunnen zijn voor bv embedded systemen/telefoons etc.

Vergeet niet dat de AMD cpu's de mem controller op de die hebben. Plak daar de gpu bij, en je zit goed. Waarom hebben gpu's zo veel bandbreedte (agp 8x, pci-x, etc) nodig?

Verder moet je het zo zien: dit zorgt voor een meer geintegreerde oplossing, wat een eenvoudiger mobo impliceert. Dat kan de hogere kosten van deze cpu+gpu al meer dan goedmaken.

Plus dat je niet off-chip hoeft voor communicatie, wat bv ook zeer veel stroom spaart.

Dit wordt geen high-end oplossing, maar kan een heel leuke low of zelfs mid-end oplossing bieden.
Vgl de chips die op de OLPC moeten.

Vergeet niet dat de AMD cpu's de mem controller op de die hebben. Plak daar de gpu bij, en je zit goed.

Nee, want zoals ik al zei, is een memorycontroller van een GPU compleet anders, en heeft veel meer bandbreedte.
Geintegreerde GPUs gebruiken in feite ook de memorycontroller van de CPU (meestal die van de chipset dus), en daardoor komen ze nooit vooruit.

Waarom hebben gpu's zo veel bandbreedte (agp 8x, pci-x, etc) nodig?

Dat hadden ze vroeger nodig, omdat de GPU nog geen GPU was, maar een dom processortje dat een polygon in 2d kon tekenen met een textuurtje erop.
De CPU moest dus de complete geometrie bewerken, en vertex voor vertex naar de GPU pompen. Daar had je een hoop bandbreedte voor nodig.
Maar sinds de opkomst van T&L is dat niet meer het geval (dit was omstreeks het AGP4x-tijdperk). Je uploadt gewoon je vertices, en om ze te tekenen hoef je alleen nog maar de transformatiematrix te versturen.
Veel minder bandbreedte dus.

Het enige probleem dat je nu nog hebt, is een eventueel tekort aan videogeheugen, zodat textures en andere data in- en uitgeswapt moeten worden.
In dat geval is het wel prettig om zoveel mogelijk bandbreedte te hebben.
Maar, een GPU gebruikt DMA om dit zelf te doen. De CPU komt hier niet aan te pas, en dat wil je ook niet. Het zou niet fijn zijn als je CPU stil komt te liggen zodra er een textuurtje geswapt moet worden, omdat de GPU ineens al je bandbreedte steelt.

Verder maakt PCI-e het mogelijk om ook snel het videogeheugen uit te lezen, wat bij oa toepassingen als GPGPU handig is. Dit is een toepassing waar het eventueel wel handig kan zijn om snellere communicatie te hebben tussen CPU en GPU, maar dit is geen technologie die je tegenkomt in normale 3d-applicaties. Dit is momenteel puur een academisch experiment.
De vraag is ook hoe belangrijk die communicatie is, omdat de bottleneck meestal het rekenwerk zal zijn, niet de input/output. Je kunt zelfs redeneren dat als de input/output de bottleneck is, dat het rekenwerk dan dermate triviaal moet zijn, dat je het sneller op de CPU kunt doen, omdat je dan de input/output kunt overslaan.

Verder moet je het zo zien: dit zorgt voor een meer geintegreerde oplossing, wat een eenvoudiger mobo impliceert. Dat kan de hogere kosten van deze cpu+gpu al meer dan goedmaken.

Dat is helemaal niet gezegd. Zoals je uit mijn bovenstaande verhaal kunt concluderen, MOET je een geheugencontroller op je videokaart hebben, en eigenlijk MOET je ook specifiek videogeheugen hebben, omdat standaard-geheugen meer gericht is op latency dan op bandbreedte. Videogeheugen is precies omgekeerd.
In dat geval moet je dus twee memorycontrollers via je socket gaan voeden (waarbij een GPU ook nog eens 256 bit is ipv 128 bit), dus je moet enorm veel pinnen op je socket maken. Ik denk dat dat niet eens mogelijk is. En anders wordt dat zeker heel erg duur.

Plus dat je niet off-chip hoeft voor communicatie, wat bv ook zeer veel stroom spaart.

Maar die communicatie is dus niet zo interessant, zoals ik al heb uitgelegd.

Dit wordt geen high-end oplossing, maar kan een heel leuke low of zelfs mid-end oplossing bieden.

Dat zei ik al, maar dan zijn de regels natuurlijk compleet anders. Voor high-end is het waarschijnlijk onhaalbaar, en voegt het verder ook niets toe qua performance.