Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD/ATI - RDNA2 ohne HBM??
Wildfoot
2020-11-01, 00:13:47
Hallo Leute
Bald sollen sie ja kommen, die neuen RDNA2 Karten von AMD. Mein Favorit wäre ja die RX6900XT (gewesen).
ABER! Wo bleibt das HBM?? Alle diese Karten (RX6800, RX6800XT und RX6900XT) basieren wieder/noch auf GDDR6 RAM.
Ich dachte eigentlich, dass HBM nun der "defacto" Standard auf diesen neuen High-End Karten ist?
Wird hier bald mal noch was in dieser Form nachgeschoben, oder ist nichts derartiges geplant? Da sind ja meine 16GB HBM2 auf meiner FE fast noch schneller.
Komische Strategie irgenwie.... :uconf2:
Gruss Wildfoot
CompuJoe
2020-11-01, 00:23:40
In Zukunft mit Infinity Cache (der wachsen wird) und evtl. Chiplet ab der nächsten Generation werden wohl so hohe Bandbreiten und dadurch auch hohe kosten (Interposer usw.), und Stromverbrauch nicht mehr notwendig sein.
Das rennen um die höchste Bandbreite ist vorbei, zum Glück.
Benutzername
2020-11-01, 00:26:44
Hallo Leute
Bald sollen sie ja kommen, die neuen RDNA2 Karten von AMD. Mein Favorit wäre ja die RX6900XT (gewesen).
ABER! Wo bleibt das HBM?? Alle diese Karten (RX6800, RX6800XT und RX6900XT) basieren wieder/noch auf GDDR6 RAM.
Ich dachte eigentlich, dass HBM nun der "defacto" Standard auf diesen neuen High-End Karten ist?
Wird hier bald mal noch was in dieser Form nachgeschoben, oder ist nichts derartiges geplant? Da sind ja meine 16GB HBM2 auf meiner FE fast noch schneller.
Komische Strategie irgenwie.... :uconf2:
Gruss Wildfoot
Durch den Cache spart AMD effektiv Bandbreite ein und kann so auf den sauteueren HBM Speicher verzichten, der auch noch teuer in der Verarbeitung ist. Dann sind weiter weg liegende RAM Bausteine auch besser kühlbar. Also warum HBM verbauen, wenn die Übertragungsgeschwindigkeit gar nciht benöigt wird allem Anschein nach?
(das basiert jetzt so auf dem was Ich aus den bisherigen Präsentationen, Artikeln etc. rausgezogen habe)
Wildfoot
2020-11-01, 02:03:20
O.K. :up:
Wenn dem so ist, sehr gut. ;)
Das klang halt eben vor noch nicht all zu langer Zeit komplett anders.
Hehe, dann sollte ich meine 4 HBM Karten (2x Vega 64 und 2x FE) besser behalten, das sind dann schon bald Zeugen ausgestorbener Technologie. :D
Gruss Wildfoot
Geldmann3
2020-11-01, 02:12:45
Ich bin mir nicht so sicher, dass höhere Bandbreiten nun sinnlos sind. Beispielsweise vermute ich, dass Big-Navi unter 1440p so schnell ist, weil der Infinity-Cache für diese Auflösung gerade ansatzweise groß genug ist, weshalb die Performance unter 4k bereits leicht einbricht und unter 6k verliert man wahrscheinlich bereits deutlich gegen die 3090.
Ich denke die Karten wären durchweg ca. 10% schneller, wenn sie schnellen HBM-Speicher hätten. Denn das bisschen Cache ist bei den zu verarbeitenden Datenmengen ein Tropfen auf den heißen Stein. Jedoch hätte es aktuell unverhältnismäßig viel Chipfläche gefressen.
Ich könnte mir daher auch gut vorstellen, dass man ein paar GB HBM Speicher in Zukunft eventuell als Second-Level-Cache verwendet und das Speicherinterface dafür einer der ersten Anwendungszwecke für Chiplets auf GPUs wird. Wahrscheinlich nur bei den highest-end GPUs.
Da es bis vor kurzem noch Gerüchte über ein 384bit Speicherinterface bei einigen Big-Navi Samples gab vermute ich, hat man die Entscheidung für 256Bit erst recht spät getroffen, wird die Option in der nächsten Generation, unter 5nm, allerdings wieder aufgreifen.
CompuJoe
2020-11-01, 05:15:55
Ich bin mir nicht so sicher, dass höhere Bandbreiten nun sinnlos sind. Beispielsweise vermute ich, dass Big-Navi unter 1440p so schnell ist, weil der Infinity-Cache für diese Auflösung gerade ansatzweise groß genug ist, weshalb die Performance unter 4k bereits leicht einbricht und unter 6k verliert man wahrscheinlich bereits deutlich gegen die 3090.
Ich denke die Karten wären durchweg ca. 10% schneller, wenn sie schnellen HBM-Speicher hätten. Denn das bisschen Cache ist bei den zu verarbeitenden Datenmengen ein Tropfen auf den heißen Stein. Jedoch hätte es aktuell unverhältnismäßig viel Chipfläche gefressen.
Ich könnte mir daher auch gut vorstellen, dass man ein paar GB HBM Speicher in Zukunft eventuell als Second-Level-Cache verwendet und das Speicherinterface dafür einer der ersten Anwendungszwecke für Chiplets auf GPUs wird. Wahrscheinlich nur bei den highest-end GPUs.
Da es bis vor kurzem noch Gerüchte über ein 384bit Speicherinterface bei einigen Big-Navi Samples gab vermute ich, hat man die Entscheidung für 256Bit erst recht spät getroffen, wird die Option in der nächsten Generation, unter 5nm, allerdings wieder aufgreifen.
Keiner sagt Sinnlos, ist nur nicht mehr so wichtig.
Jetzt 128MB + 256Bit, nächste Gen. 256MB + 384Bit usw.
Die Speichertechnik entwickelt sich ja auch weiter, man ist dadurch nicht mehr auf das max. mögliche angewiesen was uns zu gute kommt, das kann man dann in die Profischiene schieben so wie es nVidia jetzt schon macht, HBM bei Volta usw.
AMD kommen jetzt die Erfahrungen mit dem HBCC der letzten Generationen zu gute, ich denke viele Techniken davon fließen in den Infinity Cache mit ein.
Der HBCC sortiert nach Platzbedarf und/oder Latenz und Bandbreite, und kann im Extrem sogar auf die SSD zurückgreifen (da winkt die Microsoft DirectStorage Api) das wird in Zukunft je nach Anforderung angepaßt.
Geldmann3
2020-11-01, 11:54:11
Keiner sagt Sinnlos, ist nur nicht mehr so wichtig.
Jetzt 128MB + 256Bit, nächste Gen. 256MB + 384Bit usw.
Die Speichertechnik entwickelt sich ja auch weiter, man ist dadurch nicht mehr auf das max. mögliche angewiesen was uns zu gute kommt, das kann man dann in die Profischiene schieben so wie es nVidia jetzt schon macht, HBM bei Volta usw.
AMD kommen jetzt die Erfahrungen mit dem HBCC der letzten Generationen zu gute, ich denke viele Techniken davon fließen in den Infinity Cache mit ein.
Der HBCC sortiert nach Platzbedarf und/oder Latenz und Bandbreite, und kann im Extrem sogar auf die SSD zurückgreifen (da winkt die Microsoft DirectStorage Api) das wird in Zukunft je nach Anforderung angepaßt.
Ja, so sehe ich das auch.
konkretor
2020-11-01, 12:15:18
HBM Speicher ist ganz klar gestrichen. Schade aber wenn es auch so hin zu kriegen ist, wieso HBM drauf klopfen. DDR6 und 256 Bit Speicher+ Cache Anbindung sind wirtschaftlicher.
Daher kein Hardware pr0n mehr.....
:-(
basix
2020-11-01, 12:37:51
128MB Cache on Chip ist auch sexy ;)
Lehdro
2020-11-01, 16:37:56
Ich bin mir nicht so sicher, dass höhere Bandbreiten nun sinnlos sind. Beispielsweise vermute ich, dass Big-Navi unter 1440p so schnell ist, weil der Infinity-Cache für diese Auflösung gerade ansatzweise groß genug ist, weshalb die Performance unter 4k bereits leicht einbricht und unter 6k verliert man wahrscheinlich bereits deutlich gegen die 3090.
Andersrum wird ein Schuh draus: Ampere kriegt erst ab 1440p halbwegs und ab 4k vollends die Rohpower auf die Straße. Sieht man ganz gut bei den 3080 vs 2080 Benchmarks, die skalieren da auch ohne CPU Limit komplett anders. HWU hat dazu auch ein Video gemacht:
c7npXXyXJzI
Ironischerweise verhält sich Ampere wie GCN in der Hinsicht: Man braucht große Pixelmengen um die Architektur auszulasten.
han_solo
2020-11-01, 16:49:32
Ich mein, es könnte ja durchaus noch eine 6950 und 6970 geben... :freak:;D
Tesseract
2020-11-01, 17:15:57
wie kommt ihr alle auf die idee der cache würde bandbreite vollständig ersetzten?
mal abgesehen davon dass GPUs schon seit ewigkeiten caches haben helfen die zwar bei bestimmten zugriffsmustern aber wenn man jeden frame 8GB+ daten aus dem vram braucht müssen auch 8GB+ aus dem vram gelesen werden, cache hin oder her.
selbstverständlich würde sowohl RDNA2 als auch ampere von HBM profitieren und früher oder später wird HBM allein aus energieeffizienzgründen auch kommen müssen. solange man mit ach und krach mit GDDR durchkommt macht man das halt um kosten zu sparen.
hängt zum teil aber sicher auch damit zusammen, dass die ausgebauten HBM-kapazitäten alle in den HPC-markt gehen, der den herstellern jeden HBM-chip der vom band läuft aus den händen reißt.
Rabiata
2020-11-01, 21:05:03
wie kommt ihr alle auf die idee der cache würde bandbreite vollständig ersetzten?
mal abgesehen davon dass GPUs schon seit ewigkeiten caches haben helfen die zwar bei bestimmten zugriffsmustern aber wenn man jeden frame 8GB+ daten aus dem vram braucht müssen auch 8GB+ aus dem vram gelesen werden, cache hin oder her.
selbstverständlich würde sowohl RDNA2 als auch ampere von HBM profitieren und früher oder später wird HBM allein aus energieeffizienzgründen auch kommen müssen. solange man mit ach und krach mit GDDR durchkommt macht man das halt um kosten zu sparen.
hängt zum teil aber sicher auch damit zusammen, dass die ausgebauten HBM-kapazitäten alle in den HPC-markt gehen, der den herstellern jeden HBM-chip der vom band läuft aus den händen reißt.
Deshalb scheint AMD ja auch mit einer separaten Architektur im HPC-Markt weiterzumachen. Tom's Hardware vermutet (https://www.tomshardware.com/news/amd-arcturus-vega-gpu-support,39935.html), daß die HPC-Karten weiterhin Vega-basiert sein werden.
Offenbar sind die Anforderungen unterschiedlich genug, daß eine separate Entwicklung für die Zukunft besser ist. Oder anders formuliert, die clevere Cache-Lösung fürs Gaming ist vermutlich für viele HPC-Probleme keine Verbesserung.
Wildfoot
2020-11-01, 21:16:05
Spannende Diskussion, also ist HBM doch nicht tot.
Hätte mich irgenwie auch erstaun. Im Zuge der Effizienz- und Performace-Steigerung galt schon von je her, wenn möglich, alles auf einem Chip unter zu bringen. Ich erinnere in diesem Zusammenhang immer gerne an den Übergang vom Katmai auf den Coppermine. ;) Aber das ist eine andere Baustelle.
Also wird es in Zukunft doch noch/wieder Karten mit HBM geben?
Gruss Wildfoot
Rabiata
2020-11-01, 21:30:57
Also wird es in Zukunft doch noch/wieder Karten mit HBM geben?
Gruss Wildfoot
Als Compute-Karten ja, aber als Gamer-Karten vorerst nicht mehr. Ich bin nicht mal sicher, ob die Compute-Karten noch einen Videoausgang und Treiber für DX 12/Vulkan/(was auch immer fürs Gaming aktuell ist) haben werden.
Bei den Nachfolgern von Ampere und RDNA2 ist natürlich wieder alles offen. Vielleicht reicht die Bandbreite von GDDR6 da trotz Caches nicht aus, dann wäre HBM wieder ein Thema. Zumindest im High End.
Hakim
2020-11-01, 21:33:15
Mir persönlich wäre auch HBM lieber gewesen, so hat man etwas was noch keiner vorher in der Form hatte und etwas Verunsicherung hervorrufen kann. Was auch noch dazu kommt das AMD bei GDDR im Multimonitor Mode den Ram Takt nicht gesenkt hat und dadurch im Idle Modus etwas viel verbraucht hat, das war bei HBM egal weil es von Haus aus einfach wenig schluckt. Bin mal auf jetzt die neue Reihe gespannt ob sie es diesmal besser gemacht haben.
RyoHazuki
2020-11-10, 00:44:00
O.K. :up:
Wenn dem so ist, sehr gut. ;)
Das klang halt eben vor noch nicht all zu langer Zeit komplett anders.
Hehe, dann sollte ich meine 4 HBM Karten (2x Vega 64 und 2x FE) besser behalten, das sind dann schon bald Zeugen ausgestorbener Technologie. :D
Gruss Wildfoot
So wie der RAMBUS. Verdammt war der beeindruckend...
Kann sich jemand vorstellen, dass der Infinity Cache einen abgekoppelten Takt besitzt ? Ich brenne darauf die Zugriffszeiten zu erfahren.
Wildfoot
2020-11-10, 21:07:01
Ausser dass man einen CRIMM bei nicht Vollbestückung brauchte. Das war eher "nervig".
Und einen guten Draht zum Stromlieferanten sollte man auch haben, respektive kriegte man als Grossabnehmer Sonderkonditionen. :D
Wann genau sollen die Karten eigentlich schon wieder kommen (die RX6900XT)?
Gruss Wildfoot
SKYNET
2020-11-10, 23:00:55
Ausser dass man einen CRIMM bei nicht Vollbestückung brauchte. Das war eher "nervig".
Und einen guten Draht zum Stromlieferanten sollte man auch haben, respektive kriegte man als Grossabnehmer Sonderkonditionen. :D
Wann genau sollen die Karten eigentlich schon wieder kommen (die RX6900XT)?
Gruss Wildfoot
anfang dezember wenn ich mich nicht irre...
Benutzername
2020-11-10, 23:15:52
anfang dezember wenn ich mich nicht irre...
RX6800 und XT am 18. November, RX6900Xt am 8. Dezember.
https://videocardz.net/amd-radeon-rx-6900-xt
Wildfoot
2020-11-11, 01:22:07
Aha. O.K.
Merci fürs Update. ;)
Gruss
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.