News AMD Carrizo mit 30 Prozent mehr Transistoren als Kaveri

[Locuza]

@ han

Es soll theoretisch so angedacht sein, dass die integrierte Southbridge deaktivert wird, falls eine externe besteht.

 

[pipip]

Moment mal, wenn jetzt die Southbridge mit in den Chip wandert, dann heißt das doch, dass man Carrizo vermutlich nicht in seinem alten FM2+-Board betreiben können wird oder? Sonst wäre die SB ja zweimal da?

Doch kann trotzdem funktionieren, indem der Chipsatz in der APU einfach deaktiviert wird, sobald er auf dem FM2+ Sockel sitzt.

Mich interessiert, ob Carrizo L in der Tat ein Beema Nachfolger ist. Meiner Vermutung ist eher, dass Nolan weiterhin Beema Nachfolger ist, und Carrizo L eher ein Chip ist, der bis auf den Core, identisch mit Carrizo ist. Das heißt eventuell sogar die gleiche GPU Features (HSA 1.0), oder einfach eine große GCN IGP verbindet.

Der Sockel ist offensichtlich der "gleiche". Beide nämlich FP4 BGA, im Vergleich hat Kaveri FP3 BGA und Beema FT3 BGA.

Wieso steht auf der Roadmap Puma bei Beema und Puma+ bei CarrizoL

 

[han123]

Ah ok, sehr fein.

 

[think->write!]

Parallel dazu wurde die offizielle Tablett/Notebook-Roadmap aktualisiert, die Carrizo nur detaillierter offenbart. Für den Desktop liegen in dieser keine neuen Informationen vor, das Jahr 2015 wird dort ebenso wie im Server-Bereich gar nicht berücksichtigt.

So wäre das Updates viel sinnsoller und veständlicher. Zu Desktop wurd nichts gesagt an der Präsentation, wieso also was dazu schreiben, wenn man klar hinschreiben kann worum es ging bei der Präsentation.

 

[pipip]

ONH
Aber sonst erreicht der Thread nicht mehr Klicks, weil immerhin kann man so die ganzen Leute mit :
"Wäre schön wenn auch mal ein FX auf den Markt kommt" oder ähnliche anlocken. Weiteres folgen dann Antworten mit, "abwarten, 2016 soll eine neue Architekur kommen" ect ect.
Du verstehst ja auch gar nichts vom News schreiben ....not


Aber ja, schade ist es trotzdem, wäre doch eine News zum Desktop Ableger für mich interessant gewesen. Wobei ich gespannt bin, ob die Excavator Cores schneller sein werden, oder einfach nur effizienter.

 

[Mr.Kaijudo]

Klar wäre GDDR5 auf jeden Fall schneller. Aber wenn man wieder einen Blick auf die Konsolen wirft, dann reicht bei der Xbox One auch der DDR3-2133 mit dem kleinen eSRAM, der aber auch nicht gerade unglaublich schnell angebunden ist.

Die Xbone hat ein 256Bit Speicherinterface! DDR3 Ram nur 64.

Zum Thema da wird ja 2015 gar nichts von AMD kommen, mobil sind die Teile immer sehr spät gestartet und am Desktop kommen die ja anscheined erst nach Q2 2015.

 

[Nitschi66]

Na hoffen wir mal das Carrizo-L aka Puma+ dann auch HSA unterstützt, Puma tut das nämlich nicht.

 

[Daedal]

Die Xbone hat ein 256Bit Speicherinterface! DDR3 Ram nur 64.

Zum Thema da wird ja 2015 gar nichts von AMD kommen, mobil sind die Teile immer sehr spät gestartet und am Desktop kommen die ja anscheined erst nach Q2 2015.

Mit HP als strategischer Partner wird das wohl anders werden. Produktseiten sind schon online und werben mit HSA:
http://www8.hp.com/us/en/ads/new-style-it/elitedesk-705-mini.html
Die ganze 705er Serie.

Ergänzung (20. November 2014)

Na hoffen wir mal das Carrizo-L aka Puma+ dann auch HSA unterstützt, Puma tut das nämlich nicht.

Stimmt doch gar nicht. Selbst Jaguar war schon mit HSA ausgestattet wobei der CPU-Kern für HSA unerheblich ist.

 

[DvP]

Die Xbone hat ein 256Bit Speicherinterface! DDR3 Ram nur 64.

Na dann wissen wir ja was gemacht werden muss ;-) Vielen Dank für die Info übrigens. Hatte ich bisher noch gar nirgends gelesen.

 

[think->write!]

Stimmt doch gar nicht. Selbst Jaguar war schon mit HSA ausgestattet wobei der CPU-Kern für HSA unerheblich ist.

Was richtig ist, da ist das Problem aber auch das die GPU den RAM nicht mit 48bit Adressieren kann wie es bei AMD64 Prozessoren seit Ewigkeiten der Fall ist aus dem Grund kann gibt es keine gemeinsame Speicheradressierung, wodurch HSA praktisch nicht genutzt werden kann. Wobei ich mich Frage, wieso dass das so ist Kaveri soll es ja können. Und die GPU basiert auf dem gleiche Stand ... Vermutlich ein Bug, bis Nov letztes Jahr hies es ja noch Beema könne HSA.

 

[Krethi & Plethi]

Was richtig ist, da ist das Problem aber auch das die GPU den RAM nicht mit 48bit Adressieren kann wie es bei AMD64 Prozessoren seit Ewigkeiten der Fall ist aus dem Grund kann gibt es keine gemeinsame Speicheradressierung

wie kommst du darauf?

 

[Daedal]

Das heisst es doch auch immer noch. Das mit der 40-bit Adressierung ist doch lediglich ein Spruch in einem Forum gewesen. Wenn GPU und CPU die selben 40-bit Adressen nutzen ist das doch völlig wurscht. Die PS4 jedenfalls hat HSA Unterstützung mit eben diesen Jaguar Cores.
http://www.heise.de/newsticker/meld...et-Unified-Memory-Xbox-One-nicht-1939716.html

 

[Krethi & Plethi]

Now what’s interesting is that the unified address space that will be used is the x86-64 address space. All instructions sent to a GCN GPU will be relative to the x86-64 address space, at which point the GPU will be responsible for doing address translation to local memory addresses.

http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute/6

 

[think->write!]

Wenn GPU und CPU die selben 40-bit Adressen nutzen ist das doch völlig wurscht.

Stimmt beide sollten den Speicher jedoch gleich Adressieren das scheint bei Kabini und Beema nicht der Fall zu sein. Und an der CPU liegt es nicht sondern an der GPU.

Das sagt nichts über die PS4 aus, bei der hat die APU(GPU Teil) wohl mehr von den Features welche aufch in Kaveri benutzt werden und bei der XONE liegt die wohl näher an Kabini, nicht umsonnst sollen die APU verschiedene Revision Guides benötigen es soll glaub ich 3 Geben einer für Kabini einer für XONE und einer für die PS4. Mal abgesehen davon kann man in Prop. Systemenen machen was man will und kann auch AMD64 so umbiegen das die auch virtuelle 40bit adressierung verwendet oder die GPU auch 48bit virtuelle Adressierung verwendet.

Quelle:
http://www.google.ch/url?sa=t&rct=j...=dG3LaWZRgW72DL7VX5sZmw&bvm=bv.80120444,d.ZWU

Bei der GPU spec steht die GPU verwendet ein 40bit vAdressspace bei der CPU ein 48bit vAdressspace. eod

 

[Daedal]

Jede APU hat einen gemeisamen Speichercontroller seit Llano und Zacate - dass hier CPU und GPU verschieden adressieren sollen halte ich für völlig ausgeschlossen, selbst wenn man es wollte. Diese 40-bit Story hat keinerlei belegte Quelle und ist nicht sinnvoll technisch. Für gemeinsame Speicheradressierung ist es egal ob gemeinsam 32-bit, 40-bit oder 1-Bit addressiert werden - es bleibt gemeinsam addressiert

 

[Krethi & Plethi]

Stimmt beide sollten den Speicher jedoch gleich Adressieren das scheint bei Kabini und Beema nicht der Fall zu sein. Und an der CPU liegt es nicht sondern an der GPU.

und wieder unsinn, belegen kannst du diese FALSCHAUSSAGEN wohl nicht?

 

[think->write!]

Quelle:
http://www.google.ch/url?sa=t&rct=j&...80120444,d.ZWU

Bei der GPU spec steht die GPU verwendet ein 40bit vAdressspace bei der CPU ein 48bit vAdressspace. eod

und wieder unsinn, belegen kannst du diese FALSCHAUSSAGEN wohl nicht?

Siehe oben. eod

Für gemeinsame Speicheradressierung ist es egal ob gemeinsam 32-bit, 40-bit oder 1-Bit addressiert werden - es bleibt gemeinsam addressiert

Schön kurz zusammengefasst nur macht AMD das bei Beema nicht. siehe oben

 

[Daedal]

Der Link ist tot ONH...

Edit : war nur im Zitat tot. Ging im Original. Doch in der Quelle fand ich lediglich das hier:

64-bit integer registers, 48-bit virtual addresses, and 40-bit physical addresses

Vielleicht erklärt dies das Missverständniss, doch dies sind Spezifikationen der AMD x86-x64 Erweiterung.

 

[Krethi & Plethi]

du bist wie ein bekannter von mir, etwas behaupten udn sich auf einen beleg beziehen den man offensichtlich nicht versteht^^

aber gut, EOD, weil es eh keinen sinn macht!

 

[think->write!]

Vielleicht erklärt dies das Missverständniss, doch dies sind Spezifikationen der AMD x86-x64 Erweiterung.

Und die muss AMD einhalten, weiter unten bei der GPU Spec da steht 40-bit virtual addresses. Ein speichercontroller, aber 2 adressbereiche, daher wird iommu benötigt und beema hat da ein bug,welcher das Nutzen verunmöglicht.