News SiSoftwares Benchmark-Datenbank listet erneut AMD-Prototypen

[heikosch]

In den letzten Tagen wurde viel spekuliert, ob AMDs kommende Radeon-GPU mit dem Codenamen Fiji tatsächlich auf HBM (High Bandwidth Memory) setzen wird. Erste PCBs zur Herstellung der ersten Grafikkarten wurden angeblich bereits versendet. Nun ist in der SiSoftware-Datenbank wie zuletzt auch schon bei einem mutmaßlichen Carrizo-Prototypen ein Eintrag erschienen, der auf die Verwendung von HBM hinweist und mehrere Anwendungsmöglichkeiten offen lässt.
(…)

» Artikel lesen

 

[Atombossler]

Ja, die Gerüchte häufen sich

 

[Stefan Payne]

Das heißt, neue Mainboards mit bereits verlötetem HBM könnten

Ähm, nein, das macht überhaupt keinen Sinn, da HBM auf den Träger, auf dem das 'Mutter Die' Sitz, gepflanzt wird.

Sprich: auf die APU selbst würd mans tackern, den Boards kann das völlig egal bleiben.
Zumal es auch keinen halbwegs brauchbaren Port zwischen Board, Chipsatz oder ähnlichem gibt, was auch nur ansatzweise dazu in der Lage wäre, die benötigten Bandbreiten zu schaffen.

Kurz:
Das macht so keinen Sinn, wies geschrieben ward...

 

[amdfanuwe]

Eventuell Iceland?
Als kleine billige und sparsame Einstiegslösung.
Hätten wir bald das Portfolio für die 3xx Serie zusammen:
< 350 Iceland
350 Bonaire
360
370 Tonga
380 Hawaii
390 Fiji

Die Lücke zwischen Bonaire und Tonga ist mir zu groß. Da fehlt noch was.

 

[unl34shed]

Ich hoff jetzt mal, dass es eine APU ist, mit 2GB shared memory also je 1GB für system und GPU und das PCIe3 ein auslesefehler ist, was steht da eigentlich bei bekannten APUs?

Für die Kleinen GPUs wäre es mMn. overkill, aber wenn der Prozess funktioniert, warum nicht....

 

[Woerns]

Wenn man schon mal dabei ist, RAM auf den Träger der CPU zu setzen, und sich ein vereinfachtes Boardlayout zum Nebenziel gesetzt hat, kann man eigentlich die SSD in Form von NAND auch gleich mit dazu packen.
Das wäre dann halt weniger was für uns Bastler sondern eher eine nicht veränderbare Konfiguration, die das Boardlayout drastisch vereinfachen würde. Und wenn man schon so starr ist, kann man die APU (da fehlt dann noch das Wort, das neben CPU und GPU auch RAM und SSD mit einbezieht) auch gleich auflöten.
Wenn man bedenkt, dass im Mobilbereich sowieso fast niemand sein Gerät aufmacht, noch nicht einml, um Speicher zu erweitern, könnte das einen Markt haben.
MfG

 

[mmoses]

Ich hoff jetzt mal, dass es eine APU ist, mit 2GB shared memory also je 1GB für system und GPU

Bei aller Träumerei, aber GiB "on dye" sehe ich da wirklich noch nicht!!! auch 2016 oder 2017 nicht...

Für die Kleinen GPUs wäre es mMn. overkill, aber wenn der Prozess funktioniert, warum nicht....

Grundsätzlich müssen die sich aber was überlegen , seit DDR4 auch für Carizzo negiert wird schon bei Richland und definitiv bei Kaveri erweist sich die RAM-Anbindung stetig eher als Nadelöhr denn Flaschenhals

Mmoe

 

[sompe]

Wobei ich es für durchaus möglich halte das man ei den Modellen im Vollausbau zu einer MCM Lösung greifen und unter den Deckel einen Speicherchip unterbringen könnte, sofern dafür genügen Platz vorhanden ist. Zusammen mit Bandbreitensparmaßnamen wie beim Tonga könnte man so sicherlich noch einiges aus der alten DDR3 Speicheranbindung rauskitzeln.

Na ich bin mal gespannt wie der Prozessor letztendlich wieklich ausschaut.

 

[OBrian]

Das grundsätzliche Problem mit HBM ist ja, daß die RAM-Menge festgelegt ist und zudem noch relativ gering ist. Bei einer Grafikkarte wäre das noch verschmerzbar, weil es da eh festgelegte Mengen gibt und die üblicherweise auch ausreichen. Aber wenn man eine APU mit HBM ausstattet, dann wird man auf jeden Fall auch zusätzlich noch RAM-Slots anbieten müssen, weil der eine Nutzer mit 2 GB hinkommt (und mehr aus Kostengründen auch nicht will), der andere aber 16 GB braucht. HBM kann hier also wirklich nur eine Art "Level-4-Cache" darstellen. Gleichzeitig wäre es so denkbar, daß ein Carrizo mit HBM weiterhin in FM2+-Boards untergebracht werden kann.

So ganz glauben kann man das aber nicht. Erstens sind die Angaben reichlich widersprüchlich (Carrizo sollte doch 512 Shader haben, und bei 2048 bit HBM kommen bei aktuellem Technikstand zwangsläufig 2 GB raus), aber das könnten Teildeaktivierungen aus Testgründen oder zur Verwirrung sein (daß das hier leakt, war denen ja wohl klar). Zweitens aber dürfte ein Chip mit HBM auf einem Interposer aktuell noch deutlich teurer in der Herstellung sein, und in dem preissensitiven Markt, in dem Carrizo eingesetzt wird, wird das zuviel sein. Ob damit auch soviel mehr Performance erzielt wird, daß sich höhere Preise erzielen lassen, ist fraglich, denn dafür muß die CPU-Performance deutlich gesteigert werden, aber viel mehr RAM-Bandbreite bringt für die CPU eher wenig, besonders bei nur 4 Kernen.

Also ich warte lieber ab und erwarte nicht zu viel.

 

[Gast11062015]

denn dafür muß die CPU-Performance deutlich gesteigert werden,

das gesamt paket muss passen, und eine apu hat bei der cpu dafür genug leistung

 

[amdfanuwe]

Für die Kleinen GPUs wäre es mMn. overkill, aber wenn der Prozess funktioniert, warum nicht....

Wieso overkill? Wenn außer der Bandbreite noch andere Vorteile da sind, geringerer Stromverbrauch, weniger Platzverbrauch, wesentlich vereinfachtes Boardlayout, billigeres Board...
Kommt halt auf die Gesamtkosten an.

--- Update ---

Das grundsätzliche Problem mit HBM ist ja, daß die RAM-Menge festgelegt ist und zudem noch relativ gering ist. Bei einer Grafikkarte wäre das noch verschmerzbar, weil es da eh festgelegte Mengen gibt und die üblicherweise auch ausreichen. Aber wenn man eine APU mit HBM ausstattet, dann wird man auf jeden Fall auch zusätzlich noch RAM-Slots anbieten müssen,

Seh ich nicht so. Gibt ja schon viele Smartphones, Tablets, Netbooks, Laptops, Thin Clients bei denen es auch nicht möglich ist den Speicher aufzurüsten. (Am ärgerlichsten bei den Laptops die nur einen Speicherkanal bestückt haben).
Desktop APUs werden wohl vorwiegend mit 4GB kommen, für die meisten Windows Surfer voll ausreichend.
Und für die Poweruser wirds dann sicher auch die gehobene Klasse mit 16GB RAM geben.
Seh ich also kein Problem.
Ändern sich die Anforderungen, wird in der nächsten Generation eben angepasst.
Kann mich nicht erinnern in den letzten 10 Jahren außer mal eine Festplatte am bestehnden System etwas geändert zu haben. Wenns nötig war, gabs eben direkt neues Board, CPU, Speicher und Grafikkarte.

 

[Holt]

HBM kann hier also wirklich nur eine Art "Level-4-Cache" darstellen.

Genauso ist es, das kommt vor allem der GPU in der APU zugute und daher ist es auch Illusion zu glauben, man könnte damit die Chipsätze oder das Boarddesign vereinfachen. Und womöglich noch NANDs und einen SSD Controller in die CPU zu integrieren, ist gleich ganz unrealistisch und auch nicht wünschenswert, allenfalls für kompakte Mobilgeräte, wo es sowieso nur wenig RAM und wenig NANDs und wenige feste Konfigurationen gibt.

 

[Woerns]

Hatte das nicht eher OBian gesagt?

Natürlich ist HBM in "normalen" Systemen eher wie L4 zu verstehen.
Allerdings gibt es für einfache Systeme, die nicht erweiterbar sein müssen, die Möglichkeit, die APU mitsamt HBM bereits als vollwertig zu betrachten und durch einen vereinfachten Sockel und triviales Boardlaout Kosten zu sparen. Das ist sicher nicht Ziel der ersten HBM-Implementierungen, wird aber möglicherweise kommen.
MfG

 

[unl34shed]

Den HBM muss man doch gar nicht als Cache verwenden. Den kann man doch auch parallel zum DDR3 verwenden, dann kommen die Daten aus der einen RAM-hälfte eben schneller an, das interessiert doch kein Programm (außer Realtime-Anwendungen, aber da verwendet man kein Windows). Den Speicherbereich könnte man ja sogar im BIOS speziell der GPU zuordnen (oder ggf. die Speicherverwaltung von Windows patchen). Unterumständen könnte man sogar soweit gehen und einen kleinen Teil des HBM für die ganzen Windows System-daten reservieren, die immer aufgerufen werden.

Wer schreibt denn vor, dass Speicher auf der selben "Ebene" gleich schnell/langsam sein muss?

Auch widerspricht das ganze nicht dem HSA Ansatz, denn einer CPU ist es egal, was für Speicher in welcher Menge und Geschwindigkeit an ihr hängt (solange der/die Speichercontroller das ab kann natürlich). Aus Sicht der CPU sind das alles nur Adressen, wie schnell der Speichercontroller die Daten liefert/speichert interessiert nicht, dann wird halt länger gewartet.

 

[Woerns]

Wär aber auch nicht schlecht, in der APU den HBM gerade sowohl der CPU als auch der GPU zuzuordnen, Stichwort SVM: "shared virtual memory". Das steht auch erst an, wenn z.B. OpenCL 2.0 etabliert ist, und durch SVM keine Kopierarbeiten mehr vonnöten sind, wenn CPU und GPU zusammenarbeiten sollen.
MfG

 

[unl34shed]

Jain, für reine CPUs ist ddr3 (meist) schnell genug. Wichtig ist bei den apus ja die Speicher Geschwindigkeit nur wegen der GPU als vram (im Prinzip ein GPU-cache) für die ganzen Berechnungen.

Und bezüglich SVM spricht doch nichts dagegen. Kann kaveri ja jetzt schon. Man müsste nur einen der ddr3 controller durch einen hbm controller ersetzten, vereinfacht gesagt. Kla wären 32GB HBM besser, weil man sich dann gar keine sorgen mehr um den RAM machen muss, aber so weit sind wir noch nicht.

 

[Woerns]

Für 32GB HBM muss erst noch eine Anwendung gefunden werden...
Wenn derzeit GPGPU berechnet wird, dann müssen die Programme auch mit sagen wir mal 2-4GB auskommen.
MfG

 

[drSeehas]

...
< 350 Iceland
350 Bonaire
360
370 Tonga
380 Hawaii
390 Fiji

Die Lücke zwischen Bonaire und Tonga ist mir zu groß. Da fehlt noch was.

Da schwirrten doch mal Bermuda und Maui rum.