News AMD Radeon: R9 390X mit Hawaii und 8 GB GDDR5, Fiji mit neuem Namen

[Shaav]

Was für eine TDP wird eigentlich von der R9 390x erwartet? Wird die eher bei 200 lögen wie die 980 oder bei 300 wie der r9 290x? Ich habe gehört der HBM-Speicher soll zu einer deutlich geringerem Leistungsaufnahme führen.

 

[r4yn3]

Gerüchten zufolge bis 300W. Ich denke aber mal man wird sich an der 250W Marke orientieren. Ich vermute stark, dass was man mit HBM alles an W einspart, legt man bei der GPU obendrauf.

 

[kisser]

Da wird nicht viel durch HBM eingespart, vielleicht so um die 20 Watt.

 

[Shaav]

oha, das wäre ja blöd

 

[fitzelsche]

Na dann. Ist ja im Endeffekt wie breitere Schlappen aufs Auto zu montieren. Sieht nach viel aus. Schneller wird's dennoch nicht.

Fazit: Ich bleibe dann erst mal bei meiner 290X mit 8 Gig...

 

[Dark_Knight]

Und woher nehmt ihr alle das Wissen, das es so kommen wird? Ich meine bisher hat AMD selber nicht einmal seine Karten der x3xx Serie vorgestellt und schon wissen alle wie genau der Stromverbrauch ist, wie schnell die Karten sind, welche Features sie haben, wie HBM mit der GPU zusammen läuft, wie viel Geld AMD damit verdient usw.
Ich muss irgendwie jetzt min. 1 Monat in Schockstarre verweilt haben, das ich all die ganzen Veröffentlichungen verpasst habe.

Selber denken scheint auch in diesem Forum nicht mehr nötig zu sein. Wenn man sich die einzelnen Threads, allein in diesen Forenbereich durchliest, dann könnte man auf die Idee kommen, dass man bei RTL ist. Und nicht in einem Forum für Computer/Konsolen interessierte Menschen, die mehr können als eine Flasche Bier mit ihren Zähnen aufmachen und sich über den letzten Promiausrutscher aufzuregen.

 

[MHumann]

Um jetzt mal zu Fakten zurück zu kommen:
Ab wann ist nun die Vorstellung geplant? Bei der Vielzahl der Beiträge und "News" blicke ich nicht mehr durch...

Plane aktuell meine 7850 durch was neues zu ersetzen. Dank Asus Cashback wäre eine R9 290 drinne, mehr als 250€ wollte ich eigentlich nicht ausgeben. Oder doch warten, bis die neuen Generationen raus sind, auf die neuen Generationen setzen oder auf eine Preissenkung der 970er warten? Schwierig das ganze, hätte aber schon gerne mal ne Karte mit der ich in FullHD in hoch bis Ultra spielen kann. Bei neueren Spielen geht mit der 7850 oft geradeso mittel :-/

 

[R4sh]

anscheinend sollen sie in 2wochen vorgestellt werden, also nach der e3

 

[KenshiHH]

16. Juni zur PC Gaming Show soll doch nun die Vorstellung kommen wenn's nicht der 2.Juni auf der Computex wird.

Naja die Cashback aktion lohnt nur noch bei guten angeboten, seit der aktion sind die preise um den jeweiligen cashback wert gestiegen :/

 

[Krautmaster]

Ich denke fast nicht, dass es Nai ums "brauchen" geht sondern vielmehr dass man es dennoch verwenden wird. Das ist doch gerade der Punkt.
Es ist prinzipiell immer günstiger Datenpaket x auf mehrere Bänke,Slices,Module,whatever zu verteilen und parallel zu lesen/schreiben.
Das ist doch gerade der Grund warum das angewandt wird. (oder....?)
Verbesserung der Zugriffszeiten, ausnutzen der vorhandenen speicherbandreite(n) etc.pp.
Es gibt für mein Verständnis keinen logischen Grund diese Technik der Speicherverwaltung wegzulassen.

so hab ichs auch verstanden. Man setzt den High Bandwidth Memory ja sicher gerade auch wegen der Bandbreite ein. Im Prinzip kjann man über die nachher bereitstehende Bandbreite herausfinden wie AMD den Memory ansopricht, oder?

 

[Daedal]

http://www.eurogamer.net/articles/digitalfoundry-2015-amd-reveals-hbm-future-of-graphics-ram-tech

As opposed to the GDDR5 system of individual modules soldered to the board and connected to the GPU's memory controller, HBM offers up a much more refined solution. Individual memory modules are stacked one on top of another, connected by 'through-silicon-vias' (TSVs) and separated by microbumps.

Weiterhin:

AMD says that the PCB footprint of its R9 290X GPU and RAM is 9900mm2, and says that an HBM-based equivalent would be less than 4900mm2. That's a PCB that's over 50 per cent smaller - so potentially, the upcoming Radeon flagship should not only be immensely powerful but there may well be small form-factor PC applications too.

Das Problem mit GDDR5 RAM

Part of GDDR5’s problem is how the chips connect to the GPU. GDDR5 RAM uses contacts at the edges of the individual chips. To add more bandwidth, you add more chips. But those chips must be laid out on a videocard’s circuit board alongside each other, which leads to a suburban sprawl-like issue. Besides consuming a lot of space on the printed circuit board, it also means very long wires or traces must be run to reach the GPU. And it’s not just the RAM chips—the power plants or voltage regulators to run that suburban sprawl also have to be factored in. Because you’re pushing more signals along longer wires, you have to use more power, which means larger voltage regulators.

Die Lösung durch HBM:

HBM addresses the limitations of GDDR5 by going vertical like a high-rise. By stacking four memory chips, AMD can get the RAM closer to the GPU, which shortens the wire length drastically. Unlike GDDR5, HBM RAM uses a technique called through-silicon vias or TSVs, that string wires vertically through holes in a stack of chips. Each layer also connects to the next directly using tiny bump contacts.

Because the layers interconnect and the wires don’t have to go as far to reach the GPU, it’s possible to make the bus far wider without incurring the power consumption of GDDR.

Das Speicherinterface wird nicht mehr bis zur GPU durchgeleitet. Die Bandbreite wäre gar nicht machbar mit dem Signalweg. Also muss es eine Zwischenstation geben die diese Signalwege kurz hält und die eine Anbindung an die GPU herstellt.

Das beschreibt Joe Marci hier:
Joe Marci= CTO bei AMD und früherer JEDEC-Vorsitzender.

http://techreport.com/review/28294/amd-high-bandwidth-memory-explained

Macri explained that the interposer is completely passive; it has no active transistors because it serves only as an electrical interconnect path between the primary logic chip and the DRAM stacks.

Dies ist ein HBM-Speichercontroller auf dem Stack. Weiterführend:

Each HBM memory stack consists of five chips: four storage dies above a single logic die that controls them. These five chips are connected to one another via vertical connections known as through-silicon vias (TSVs). These pathways are created by punching a hole through the silicon layers of the storage chips. Macri said those storage chips are incredibly thin, on the order of 100 microns, and that one of them "flaps like paper" when held in the hand.
[...]
In this first implementation, each DRAM die in the stack talks to the outside world by way of two 128-bit-wide channels. Each stack, then, has an aggregate interface width of 1024 bits (versus 32 bits for a GDDR5 chip). At 1 Gbps, that works out to 128 GB/s of bandwidth for each memory stack.

AMD did much of the initial the heavy lifting, designing the interconnects, interposer, and the new DRAM type.

Another advantage of HBM is that it requires substantially less die space on the host GPU than GDDR5. The physical interfaces, or PHYs, on the chip are simpler, saving space. The external connections to the interposer are arranged at a much finer pitch than they would be for a conventional organic substrate, which means a more densely packed die. Macri hinted that even the data flow inside the GPU itself could be optimized to take advantage of data coming in "in a very concentrated hump."

Then again, the power-efficiency numbers Macri provided only include the power used by the DRAMs themselves. The power savings on the GPU from the simpler PHYs and such may be considerable.

In fact, he said that current GPUs aren't terribly efficient with their memory capacity simply because GDDR5's architecture required ever-larger memory capacities in order to extract more bandwidth. As a result, AMD "never bothered to put a single engineer on using frame buffer memory better," because memory capacities kept growing. Essentially, that capacity was free, while engineers were not. Macri classified the utilization of memory capacity in current Radeon operation as "exceedingly poor" and said the "amount of data that gets touched sitting in there is embarrassing."

Niemand ist scharf darauf dieses ineffiziente Speichersubsystem weiter zu benutzen. Das wird es so einfach nicht mehr geben bei HBM.

Da kann sich jetzt jeder selber sein Bild machen, ich biete keine weiteren Erläuterungen oder Diskussionen mehr zu den Informationen an die ich hier verlinke.

 

[r4yn3]

Du verstehst nach wie vor deine eigenen Quellen nicht...müssen wir dir das nun wirklich übersetzen?

Hinzu kommt, dass das was du alles highlightest, nicht mal im Ansatz ein Widerspruch zu dem ist wovon Nai und Ich hier seiten lang schreiben.

Tut mir leid das zu sagen, aber du trollst hier auf übelste Art und Weise. Das traurige ist nur, dass dir das manche Leute hier tatsächlich als Fachwissen abkaufen.

 

[Nai]

Because the layers interconnect and the wires don’t have to go as far to reach the GPU, it’s possible to make the bus far wider without incurring the power consumption of GDDR.

Das Speicherinterface wird nicht mehr bis zur GPU durchgeleitet. Die Bandbreite wäre gar nicht machbar mit dem Signalweg. Also muss es eine Zwischenstation geben die diese Signalwege kurz hält und die eine Anbindung an die GPU herstellt.

Ich würde mal sagen, dass ist ganz klar auf dieses Bild bezogen:

Die Wires werden kürzer, weil HBM kleiner und damit näher am GPU-DIE ist. Somit braucht man dafür nicht einmal eine "Zwischenstation" bei HBM.

Interessanterweise scheinen die Wires von den DRAM-DIEs des HBM-Stacks auf den von dir geposteten Bild auch einfach durch das Phy durchgeschleift zu werden (obwohl nicht nicht viel davon halte zu viel in eine schematische Skizze hineinzuinterpretieren)

Dies ist ein HBM-Speichercontroller auf dem Stack. Weiterführend:

Hier steht immer noch nirgends, dass dort ein Memorycontroller ist. Es wird von Kontrolllogik geredet, was aber keinem Memory-Controller, indem Sinne was man unter einem Memory Controller versteht, gleich kommt. Sonst hätte der HBM-Stack eine komplett andere Ansteuerung als im Standard beschrieben.

Der Rest deines Posts sind mal wieder Off-Topic-Zitate und Werbeaussagen . . . . .

 

[Daedal]

Nun da du gar keine Quellen hast und ebenso Nai keine einzige Quelle hat, kann ich dir leider überhaupt nichts zu euren Quellen sagen, ausser dass selbst gemalte Bildchen wenig überzeugen. Die muss man auch nicht verstehen...

Auch wirst du mir sicherlich nach wie vor einen Quelle zeigen wo Fijis 4096-bit Speicherinterface auf der GPU zu finden ist. Ich gehe davon aus du suchst nocht und ignorierst daher alle Anfragen für Beweise deiner Behauptungen. Also werde ich mich gedulden bis du etwas gefunden hast.

Ich glaube auch kaum, dass Nai mit dir übereinsstimmen in allem was du so geschrieben hast.

 

[r4yn3]

Wir müssen keine Quellen bringen, es steht alles genauso in deinen Quellen. Nur begreifst du einfach nichts, wovon dort die Rede ist, bzw interpretierst alles falsch.

 

[Daedal]

hier steht immer noch nirgends, dass dort ein Memorycontroller ist. Es wird von Kontrolllogik geredet, was aber keinem Memory-Controller, indem Sinne was man unter einem Memory Controller versteht, gleich kommt. Sonst hätte der HBM-Stack eine komplett andere Ansteuerung als im Standard beschrieben.

Also die Kontrolllogik des Speichers ist kein Speicherkontroller. Na dann ist es schwierig einen gemeisamen Begriff zu finden. Du scheinst ein eigenes Lexikon zu haben. Zudem ist es nicht Offtopic nur weil du zu faul bist den Rest zu lesen.

Du versuchst nach wie vor auf rhetorischem Wege etwas zu beweisen. Ich spreche von Memory-Management des HBM-Speicherkontrollers und wie die Rows und Columns angesprochen werden auf den unterschiedlichsten Detailebenen und du meinst du kannst das nun so locker mit "Ansteuerung" auf die GPU Seite verlegen und aus GPU-Sicht keine Änderung deklarieren. Witzig, denn das selbe schrieb ich auch: Aus Softwaresicht und aus Sicht der GPU ändert sich nichts in der Ansteuerung. Dies wird auch beschrieben warum das so ist in den verlinkten Quellen. Da du offenscihtlich nur diese Perspektive kennst, wird sich auch bei dir in 15 Seiten nichts verändert haben. Bleib dabei, denn mehr musst du anscheinend auch nicht wissen für deine Tätigkeit.

Ergänzung (1. Juni 2015)

Wir müssen keine Quellen bringen, es steht alles genauso in deinen Quellen. Nur begreifst du einfach nichts, wovon dort die Rede ist, bzw interpretierst alles falsch.

Na dann ist ja alles bewiesen worden von dir. Auf welcher Schule geht das als Argument durch?

Dann kannst du mir sicherlich auch erklären wie sich die Größe des Speicherinterfaces auf der GPU in Fläche ändern wird von 512 bit -> 4096 bit
Da ich der Unwissende bin, erleuchte mich bitte.

P.S.: Was Nai begriffen hat ist, dass programmierbares ECC und ein gemischter Betrieb mit seiner Definition von "Interleave" nicht plausibel ist.

 

[r4yn3]

Es ist so schlimm wie du trollst, und gleichzeitig versuchst deinen Kopf aus der Schlinge zu ziehen und dem du nun tust, als hättest du das alles Memory Management anders gemeint.

Alleine schon die Tatsache dass du:
Because the layers interconnect and the wires don’t have to go as far to reach the GPU, it’s possible to make the bus far wider without incurring the power consumption of GDDR.
in eigenen Worten in:
Das Speicherinterface wird nicht mehr bis zur GPU durchgeleitet. Die Bandbreite wäre gar nicht machbar mit dem Signalweg. Also muss es eine Zwischenstation geben die diese Signalwege kurz hält und die eine Anbindung an die GPU herstellt.
übersetzt, zeigt, dass du obendrein noch massive Englisch defizite hast. Du verstehst noch nicht mal den Sinn dieses einen Satzes....da verwundert es kaum dass du den Rest nicht verstehst.

Die Fläche wird kleiner, da die Logik zum ansprechen der Slices ausgelagert wurde. Nicht mehr, nicht weniger. Fiji ist nach wie vor das Gehirn mit dem MC, nicht dein geliebter Logic Die.
Die Fläche wird ebenso erheblich kleiner, da die ganzen Datenleitungen, 4096, durch den Interposer um ein vielfacher kleiner werden...was auch des öfteren in den Quellen erwähnt wird.

Nur weil die Breite von 512 auf 4096 ansteigt, heißt das nicht, dass der MC und das SI auch mm² bezogen größeren werden. Scheinst du des öfteren nicht zu verstehen.

Ein Stack liefert 128GB/s zur GPU. Die Fomel zum ausrechnen einer Speicherbandbreite kennst du hoffentlich...

 

[Dimez]

Um jetzt mal zu Fakten zurück zu kommen:
Ab wann ist nun die Vorstellung geplant? Bei der Vielzahl der Beiträge und "News" blicke ich nicht mehr durch...

Plane aktuell meine 7850 durch was neues zu ersetzen. Dank Asus Cashback wäre eine R9 290 drinne, mehr als 250€ wollte ich eigentlich nicht ausgeben. Oder doch warten, bis die neuen Generationen raus sind, auf die neuen Generationen setzen oder auf eine Preissenkung der 970er warten? Schwierig das ganze, hätte aber schon gerne mal ne Karte mit der ich in FullHD in hoch bis Ultra spielen kann. Bei neueren Spielen geht mit der 7850 oft geradeso mittel :-/

Sitze im selben Boot :-/.
Ich warte auf AMDs "neue" Palette, sollte mich davon im Preissegment 300-400,-EUR nichts überzeugen werde ich zum ersten mal eine Nvidia kaufen....vermutlich dann eine 970er (Speicherkrüppel hin oder her) wenn diese unter 300,-EUR zu bekommen sind. Evtl. später noch eine zweite. Eine 290er mit oder ohne x stellt für mich aktuell keine Alternative da, allein schon wegen der Größe der GPU.

 

[Nai]

Nun da du gar keine Quellen hast und ebenso Nai keine einzige Quelle hat

1. Für allgemeine grundlegende Konzepte braucht man jetzt nicht unbedingt Quellen.
2. Ich habe schon des öfteren auf den Standard (https://www.jedec.org/standards-documents/docs/jesd235) verwiesen. Das ignoriest du aber mal wieder.

Also die Kontrolllogik des Speichers ist kein Speicherkontroller. Na dann ist es schwierig einen gemeisamen Begriff zu finden. Du scheinst ein eigenes Lexikon zu haben. Zudem ist es nicht Offtopic nur weil du zu faul bist den Rest zu lesen.

Ich habe doch schon 5 mal beschrieben, was ein Speichercontroller macht: Das Umwandeln von Addressen in Rows/Columns/Bänke und das Ansteuern des DRAMs bzw. die Kommunikation mit dem DRAM über eben diese Granularität unter Berücksichtigung der Timing-Restriktionen und das Refresh des DRAMs. Genau das ist es was man von einem Speichercontroller gemäß diversen Quellen erwartet. Und hier widerspricht der Standard der Tatsache, dass auf HBM ein Memory-Controller ist, weil man HBM gemäß des Standards eben analog wie gewöhnlichen DRAM über Rows Columns Bänke inklusive Timing-Restriktionen und seperate Refresh-Befehle ansteuern muss.


Nehmen wir einfach einmal an, auf dem HBM-Logic-DIE wäre ein Speichercontroller. Wieso steuere ich ihn dann gemäß des Standards analog zu GDDR5 an, also genau so als ob er keinen Memory-Controller hätte? Wäre doch schrecklich ineffizient, wenn sich dennoch GPU-seitig ein Memory-Controller um die Timing-Restriktionen und um die Addressumwandlung kümmern müsste, wenn das bereits auf dem Logic-DIE geschieht. Wieso verkauft dann NW-Logic einen Memory-Controller für ASICs, der gemäß Blockdiagramm genau das macht, was man von einem gewöhnlichen Memory-Controller erwartet?

Unter Kontrollogik werden diverse Funktionalitäten wie wahrscheinlich das Refresh (erfordert ja ein Read gekoppelt an ein Write, welches immer DRAM-intern durchgeführt wird) oder das Self-Refresh bei Standby zusammengefasst.

Ich spreche von Memory-Management des HBM-Speicherkontrollers . . . .

Ein Speichercontroller macht kein Memory-Management

. . . . und wie die Rows und Columns angesprochen werden auf den unterschiedlichsten Detailebenen und du meinst du kannst das nun so locker mit "Ansteuerung" auf die GPU Seite verlegen und aus GPU-Sicht keine Änderung deklarieren. Witzig, denn das selbe schrieb ich auch: Aus Softwaresicht und aus Sicht der GPU ändert sich nichts in der Ansteuerung.

Ok, wenn sich für die GPU nichts ändert sind wir uns ja zumindest mal einig, dass wir auf der GPU weiterhin einen "klassischen" Memory-Controller benötigen, sogar wenn du die ganze Zeit immer etwas anderes geschrieben hast.

P.S.: Was Nai begriffen hat ist, dass programmierbares ECC und ein gemischter Betrieb mit seiner Definition von "Interleave" nicht plausibel ist.

Habe ich das? Was schireb ich dazu:

Ich weiß nicht aus welcher zuverlässigen Quelle die Idee des Mischens von ECC und nicht ECC kommt. Die einzige (unzuverlässige) Quelle die ich finde ist diese:
http://www.hardwareluxx.de/index.php...reite-ist.html
Aus Anwendungssicht wäre der Nutzen aus Kombination von ECC und nicht ECC ersteinmal stark eingeschränkt und würde zudem Anpassungen an den APIs erfordern, wo man für Speicherbereiche ECC einstellen kann. Andere Quellen reden nur davon, dass ECC und nicht ECC HBM das selbe physikalische Interface verwenden. Selbst wenn man bei HBM ECC und nicht ECC kombinieren würde: Hier müsste dann das Interleaving nur zwischen den Stacks nach ihrem ECC-Support unterscheiden.

Und eine zuverlässige Quelle fehlt immer noch. Die zusätzlichen Beschreibungen aus dieser Quelle lesen sich auch etwas nach Ahnungslosigkeit des Autors.

 

[Daedal]

1. Für allgemeine grundlegende Konzepte braucht man jetzt nicht unbedingt Quellen.
2. Ich habe schon des öfteren auf den Standard (https://www.jedec.org/standards-documents/docs/jesd235) verwiesen. Das ignoriest du aber mal wieder.

Da wir alle wissen was das ist, uns jedoch nicht einig sind ob das bei HBM ebenfalls zutrifft, solltest du mal überlegen was deine Quellen belegen sollen.

1. Hat sich geändert wie in den Quellen zu HBM gezeigt.
2. Ist HBM dort spezifiziert.

Selbst wenn man bei HBM ECC und nicht ECC kombinieren würde: Hier müsste dann das Interleaving nur zwischen den Stacks nach ihrem ECC-Support unterscheiden.

Bedeutet tatsächlich, dass vielleicht nicht alle 4 Stacks in der Form die Daten "Interleaven" wie du sagtest. Wie sollte dies gehen ansonsten?

Wenn wie dort beschrieben, der Speichercontroller der GPU 2 GB jeweils als getrennte Pools ansprechen kann, ist eben dies gegeben: Getrennte Verwaltung und keinerlei "Interleaving". Was hindert die GPU nun daran diese beiden Pools unterschiedlcih zu takten?