RDNA4 (Navi 4X, Radeon RX 9000 Serie, 4nm, 2025)

[Schnitzl]

Ihr wisst aber alls schon dass es einen Verfügbarkeitsthread (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=620979) gibt???

[davidzo]

Ihr wisst aber alls schon dass es einen Verfügbarkeitsthread (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=620979) gibt???

Jo, ich bin dafür das alles was nicht zu N44 ist jetzt gelöscht wird. Wir sind schließlich im Speku-forum und N48 ist gelauncht. N48 Refresh Phantasien lasse ich durchgehen, aber das wird noch lange hin sein. Erstmal kommt hier N44!

[prinz_valium_2]

Wenn sich der kleine NAVI sehr gut takten lässt (bis 3.8GHz), mit 16GB kommt und zu ordentlichen Preisen, dann wäre das sogar eine gute "Mittelklasse GPU"

Will endlich von meiner 1070 weg, aber diese Preise und Verfügbarkeit...

Bandbreite wird natürlich ein Problem

[dildo4u]

Sie hat 8 oder 16GB das wird vom Speicherinterface bestimmt.

https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/AMD-Radeon-RX-9060-XT-mit-Navi-44-1467818

[Dino-Fossil]

Ich bezweifle, dass er sich deutlich von N48 absetzen wird in der Taktbarkeit. Beim aktuellen Preisgefüge wird die 16GB Version am Ende nicht mal unter 400€ kommen.
Andererseits muss man sich auch einigermaßen von der 7700XT absetzen, die vermutlich immer noch ein wenig stärker bleiben dürfte (zumindest in Raster). Damit besteht eine Restchance auf ca 350€.

[robbitop]

Wenn sich der kleine NAVI sehr gut takten lässt (bis 3.8GHz), mit 16GB kommt und zu ordentlichen Preisen, dann wäre das sogar eine gute "Mittelklasse GPU"

Will endlich von meiner 1070 weg, aber diese Preise und Verfügbarkeit...

Bandbreite wird natürlich ein Problem
Das Bandbreiten zu Rohleistungsverhältnis ist bei N44 das gleiche wie bei N48.
Die Taktraten werden sicherlich relativ ähnlich sein wie bei N48.

[E39Driver]

Ich würde ja eine kleine 75-Watt Sparversion vom Navi44 als 9050 begrüßen. Als Ablösung für meine 75 Watt RTX3050-6GB im Mini-Zweitsystem. Aber kommt vermutlich nicht, wenn die RTX5050 schon auf 130 Watt geprügelt wird

[robbitop]

Ich vermute für 75W ist N44 eine Nummer zu groß. Gehen tut alles - siehe die 75W Ada SKUs von Nvidia. Aber dann verliert man überproportional Takt und Leistung und die resultierende Leistung will keiner bezahlen (weil die Kosten ja nicht kleiner dadurch werden - oder kaum). Ist halt sehr nischig leider.

[basix]

Ich würde auch gerne wieder eine 75W Variante sehen. Aber da müsste sich AMD aber vermutlich strecken. Siehe Raffs Test, die 9070 bewegt sich bereits Default bei ~0.77V. Viel tiefer geht nicht mehr:
https://www.pcgameshardware.de/Radeon-RX-9070-XT-Grafikkarte-281023/Tests/Preis-Test-kaufen-Release-Specs-Benchmark-1467270/6/

Metro Exodus EE ist aber ein Power Virus. In den meisten anderen Spielen sieht es nicht so extrem aus.

Evtl. Low Voltage N44, welche keinen hohen Takt schaffen und auf 24 CU zurückgestutzt. Und langsamene 14...16Gbps GDDR6 mit reduzierter Spannung. Könnte knapp reichen für 75W. Bei sowas wie Metro würde der Takt aber vermutlich etwas einbrechen.

[mboeller]

Ich vermute für 75W ist N44 eine Nummer zu groß.

warum? Die N48 (9070) ging im Test bei Chips and Cheese bis auf 154w runter.
75W sollten/könnten also gerade so möglich sein bei der 8GB-Variante.

[robbitop]

warum? Die N48 (9070) ging im Test bei Chips and Cheese bis auf 154w runter.
75W sollten/könnten also gerade so möglich sein bei der 8GB-Variante.
Finde ich im Chips and Cheese Test gerade auf die Schnelle nicht. Ist das bei Volllast gemessen (Metro EE) und ist das TBP?

Ich würde auch gerne wieder eine 75W Variante sehen. Aber da müsste sich AMD aber vermutlich strecken. Siehe Raffs Test, die 9070 bewegt sich bereits Default bei ~0.77V. Viel tiefer geht nicht mehr:
https://www.pcgameshardware.de/Radeon-RX-9070-XT-Grafikkarte-281023/Tests/Preis-Test-kaufen-Release-Specs-Benchmark-1467270/6/

Man müsste zusätzlich noch massiv mit dem Takt runter. Der bringt immerhin lineare Absenkung der Leistungsaufnahme. Aber man sieht ja an den 75W Ada SKUs dass der Takt da ganz schön runtergeprügelt werden muss.

Gehen tut das alles. Aber wie gesagt sinkt die Performance ab einem gewissen Punkt sehr stark, die Kosten nicht mehr und entsprechend wäre das P/L einer solchen SKU wahrscheinlich furchtbar. Wahrscheinlich eine sehr kleine Marktnische.

[E39Driver]

Ist sicherlich eine Nische. Andererseits ist es der Kunde auch gewohnt für den kleinen SFX-Formfaktor etwas mehr zu bezahlen. Wenn man die Ersparnisse bei Kühlung, Wandlern und Platine gegenrechnet, könnte sich so eine kleine Karte evtl. doch rentieren. Mal abwarten ob etwas in diese Richtung kommt.

[mboeller]

Finde ich im Chips and Cheese Test gerade auf die Schnelle nicht. Ist das bei Volllast gemessen (Metro EE) und ist das TBP?


nur Timespy Werte:

https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2a3767de-f65b-443f-9218-26a516b047a4_1919x560.png

[basix]

Gehen tut das alles. Aber wie gesagt sinkt die Performance ab einem gewissen Punkt sehr stark, die Kosten nicht mehr und entsprechend wäre das P/L einer solchen SKU wahrscheinlich furchtbar. Wahrscheinlich eine sehr kleine Marktnische.

Die Alternative von AMD ist momentan die RX 6400. Eine 9050 / 9040 mit 24CU, 8GB, richtigen Video Encodern/Decodern und PCIe 5.0 x8 wäre ein riesiger Sprung.

Ich würde sowas sofort kaufen, wenn jemand keine iGPU hat oder die iGPU für den Workload nicht reicht. Und ohne PCIe Stromstecker ist das auch kein Problem.

[robbitop]

Die Alternative von AMD ist momentan die RX 6400. Eine 9050 / 9040 mit 24CU, 8GB, richtigen Video Encodern/Decodern und PCIe 5.0 x8 wäre ein riesiger Sprung.

Ich würde sowas sofort kaufen, wenn jemand keine iGPU hat oder die iGPU für den Workload nicht reicht. Und ohne PCIe Stromstecker ist das auch kein Problem.
Wir sind aber nicht die Masse. Und die Frage ist welches Budget jemand hat, der sich für eine 75W Karte interessiert? (und damit meine ich den Massenkäufer) Bringt dem ja nichts wenn die 75W Karte dann eine P/L hat die nicht so toll ist.
Klar gibt es immer auch Käufer für solche Dinge - aber die Masse?

[mczak]

Ich würde auch eher davon ausgehen dass die langsamste N44 Variante eher so bei mimimal ~110W liegen wird, weil es darunter kaum effizienter wird. Möglicherweise auch mehr, Nvidia macht's ja vor mit angeblich 130W bei der 5050 (die 4060 hat ja bloss 115W und dieser Chip hat ja mehr SMs).

[GerryB]

(die 4060 hat ja bloss 115W und dieser Chip hat ja mehr SMs).
die 4060 hat überhaupt keine Regelung/Begrenzung der Leistungsaufnahme, die wurde eingespart
(praktisch haben bereits nonOC-Modelle>120W)

[mczak]

die 4060 hat überhaupt keine Regelung/Begrenzung der Leistungsaufnahme, die wurde eingespart
(praktisch haben bereits nonOC-Modelle>120W)
Quelle? Das habe ich irgendwie verpasst. Seit Furmark populär ist brauchen eigentlich alle Karten eine Begrenzung, auch wenn die nicht supergenau zu sein braucht.
Ist aber auch egal, das ist die offizielle Angabe, und die ist nun mal offenbar höher bei der RTX 5050.

[GerryB]

Schau Dir das Launchreview bei Igor an.
oder besser mit "echten" 115W abgeregelt:
https://www.igorslab.de/nvidia-geforce-rtx-4060-8-gb-mit-echtem-115-watt-limit-getestet-ende-der-pracht/

macht locker mal 11% bei den minFps aus

und
Ja, Du hast Das verpasst, habe beim 4060/7600-Launch auch hier im 3dC darauf hingewiesen.

[Shaft]

Gab es derweil schon Updates oder geplant, die RT und Pathtracing Leistung verbessern?

Oder seitens Spiele Entwickler?

[GerryB]

Erstmal muss FSR3.1/4 in die Games, weil selten RT@4k-nativ genug Fps hat.(PT ist eeh Quark)
Wenn FSR4@Performance gut genug/erträglich ausschaut, dann hat man schon viel gekonnt.

bezgl. Treiber
Nach m.E. sind oder kommen mehr Vlk-Extensions nach und nach.

SN@vlk läuft auf RDNA4 schon ganz gut und auch bei mir@RDNA2 mit dem 25.3.1.

[Raff]

die 4060 hat überhaupt keine Regelung/Begrenzung der Leistungsaufnahme, die wurde eingespart
(praktisch haben bereits nonOC-Modelle>120W)

Selbstverständlich ist da eine Begrenzung drin, ansonsten gäbe es Fälle, wo die Karte auch mal 150+ Watt säuft. Die Telemetrie scheint nur "billig" zu sein, ungenau. Der einzige Fehler dabei ist, dass sie damals wie heute mit 115 Watt TGP angegeben wird, was sie selbst unter normaler Last nicht einhält. Ist aber kein Beinbruch, denn wenn die RTX 4060 eines kann, dann sparsam sein. Sonst ja nicht viel. ;)

MfG
Raff

[GerryB]

Die wird wohl einfach am Taktlimit laufen.
glaube nicht, das da 150W drin wären

[Raff]

Ein GPU-Tester kann eine Begrenzung zweifelsfrei feststellen: Wenn eine GPU ihren Takt und ihre Spannung deutlich senkt und trotzdem das Powerlimit ausgefüllt - oder in diesem Fall überfahren - wird, könnte die Grafikkarte noch deutlich mehr, darf aber nicht. Und das geschieht bei der RTX 4060 ständig. Das ist eine auf effektiv 125 Watt gedeckelte Karte.

MfG
Raff

[GerryB]

Na gut, dann haben wir zumindestens nen Vgl.wert für die neuen Karten.

[Karümel]

zSaFFQAsWYM

[Relex]

Anmerkung zum FSR4 vs DLSS Vergleich:

Der override via Nvidia App überschreibt nur das Frame Gen Model, NICHT aber das Upscaling Model. Der Upscaling override wird für Stalker 2 offiziell nicht unterstützt.
https://i.ibb.co/NnSMCG1K/Screenshot-2025-03-17-191548.png (https://ibb.co/93t7gdwW)

Um Transformer Upscaling zum laufen zu bekommen müsste man entweder die Nvidia App deinstallieren und via NV Inspector den Override erzwingen oder die DLL im Spielverzeichnis tauschen und via NV inspector das Preset K erzwingen.

@Raff kannst du bestätigen dass das so gemacht wurde?


Wobei das natürlich immer so ne Sache ist, etwas zu testen, was offiziell nicht untersützt wird. (aus womöglich guten Gründen).

Wie auch immer, wollte nur mal drauf hinweisen, dass DLSS4 Upscaling in Stalker 2 nur über umwege möglich ist.

[GerryB]

https://www.youtube.com/watch?v=N_Qn6Vn-Qig

bei manchen Games wird nur der Umweg über Optiscaler bleiben, weil derzeit noch nicht auf der Whitelist für FSR4

[w0mbat]

-> Scheint zu stimmen. Im Blockdiagramm führt AMD zwar diese "AI Accelerators" auf, aber das schein eine kleine Lüge zu sein. Sie meinen damit anscheinend echt einfach nur die WMMA Funktionalität der CUs.
Rolle zurück. Kann sein, dass RDNA4 doch eine dezidierte Matrix-Unit hat. Die kann man anscheinend auch direkt ansprechen. Mal schauen, ob ich das noch bestätigt bekomme :ugly:

[robbitop]

Der Durchsatz ist eigentlich auch viel zu hoch als dass das nur über die Vektoralus laufen soll. IMO. Vergleichbar zu Ada pro SM iirc

[w0mbat]

4 Matrix-Kerne pro WGP, insg. 96 insg. 128 auf Navi 48. ML instructions laufen auf den Matrix-Kernen, die ALUs selber sind nicht mehr beteiligt. Daher auch das FSR4-Problem für RDNA3. Hier würde es direkt ALU-Leistung klauen.

[Raff]

4 Matrix-Kerne pro WGP, insg. 96 auf Navi 48. ML instructions laufen auf den Matrix-Kernen, die ALUs selber sind nicht mehr beteiligt. Daher auch das FSR4-Problem für RDNA3. Hier würde es direkt ALU-Leistung klauen.

Hast du das direkt von AMD? Mir hat man das nicht so explizit, sondern schwammig zurückgespielt.

MfG
Raff

[w0mbat]

Nein, nicht offiziell von AMD. Aber George (C&C) kann die Matrix-Kerne direkt ansprechen, daher wissen wir, dass es sie gibt. Und die im Blockdiagram sind 4 pro WGP verzeichnet. Gut, da bildet AMD auch die dual-issue ALUs ab, aber das funktioniert bei Matrix-Kernen so ja nicht. 128 Kerne passt auch ganz gut zu den genannten FLOPS. Könnten theoretisch auch 64 größere sein, je nach dem wie genau es AMD mit dem Blockdiagram hält.

Beim RDNA3 Blockdiagramm schreibt AMD übrigens noch speziell "Float / INT / Matrix SIMD32" zu den ALUs. Bei RDNA4 steht nur noch "FMA/INT".

[mboeller]

hab die RDNA4 Threads kurz überflogen. Finde aber nix zu dem Interview

https://www.notebookcheck.com/AMD-Radeon-RX-9070-XT-verkauft-sich-zehnmal-besser-als-RX-7000-Serie-Preise-sinken-weiter-Richtung-UVP.986374.0.html

Lisa hat in einem Interview erwähnt, dass sich die RX9070xx Karten [in der ersten Woche] 10x besser verkaufen als die RX7000-Karten. WTF ...

https://www.youtube.com/watch?v=5djZ4Ux5YQU&t=22s

[HOT]

Man hat eben Monate jetzt vorproduziert und bei der 7000er hatte man 0 Ware.

[mboeller]

Man hat eben Monate jetzt vorproduziert und bei der 7000er hatte man 0 Ware.

naja, und die Kunden müssen die GPU's auch kaufen.
Wenn jetzt die RTX5070Ti für zB. 800,- Euro gut verfügbar wären würde das anders ausschauen.

[HOT]

Ist aber nicht so.

[w0mbat]

Hast du das direkt von AMD? Mir hat man das nicht so explizit, sondern schwammig zurückgespielt.

MfG
Raff
Mir wurde jetzt bestätigt, dass Navi 48 "unique tensor core transistors" hat. Direktes Zitat.

[robbitop]

Was auch wieder uneindeutig ist. Warum schwurbelt AMD da so rum? Klingt für mich als wäre da was hinterm Busch.

[w0mbat]

Naja, dass ist aus engineering Sicht schon eindeutig. Es gibt tensor cores mit "unique transistors", also werden hier nicht die schon bestehenden ALUs genutzt.

[mksn7]

Ist der Durchsatz ohne sparsity nicht einfach nur um das Verhältnis der Datentypbreiten höher? Also, für FP8 ein Faktor 4x mehr als FP32. Die execution width die es für den angegebenen Matrixdurchsatz braucht wäre also genauso breit wie für den Vektordurchsatz.

Das ist kein Beleg in irgendeine Richtung, macht aber die Vorstellung, dass es die gleichen execution units sind, logischer. Sparsity wäre natürlich noch ein extra feature.

[robbitop]

Naja, dass ist aus engineering Sicht schon eindeutig. Es gibt tensor cores mit "unique transistors", also werden hier nicht die schon bestehenden ALUs genutzt.

Man vermeidet aber unique Tensor Cores zu sagen. Man hängt noch „Transistors“ ran was schon durch Uneindeutigkeiten Hintertüren lässt. Und ohne Grund formuliert man es ja meist nicht so uneindeutig. Auch die slides erscheinen auffällig uneindeutig.

Unique Tensor Core Transistors könnten zB auch zusätzliche Transistoren sein welche die Tensor Fähigkeiten der ALUs aufbohren wie in der PS5pro.

Ich würde da nochmal nachfragen ob derjenige explizit sagen kann ob es separate Units gibt und ob die unabhängig von den FPUs rechnen können oder ob nur eins pro Takt geht. (weil zB nur scheduler ports für eines da oder nur register für eines da oder nur datenpfade für eines da oder aber Grundstrukturen des Rechenwerks wie eben genannt geteilt werden)

Ist der Durchsatz ohne sparsity nicht einfach nur um das Verhältnis der Datentypbreiten höher? Also, für FP8 ein Faktor 4x mehr als FP32. Die execution width die es für den angegebenen Matrixdurchsatz braucht wäre also genauso breit wie für den Vektordurchsatz.

Das ist kein Beleg in irgendeine Richtung, macht aber die Vorstellung, dass es die gleichen execution units sind, logischer. Sparsity wäre natürlich noch ein extra feature.

Sparsity kommt dann noch dazu. Das sind ggf auch „unique tensor core transistors“.

Laut dieser AMD slide (gefunden im chipsandcheese artikel):

https://i0.wp.com/substackcdn.com/image/fetch/f_auto%2Cq_auto%3Agood%2Cfl_progressive%3Asteep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F59d4b950-aba0-419b-b37a-ba7385f7f491_1921x1069.png?ssl=1

Ops pro CU:
FP32: 256
FP16: 1024/2048
FP8: 2048/4096

Erste Zahl ist ohne Sparsity, zweite mit Sparsity.

FP8 ist also steigt um Faktor 8 ohne Sparsity, mit um Faktor 16.

Das würde dagegen sprechen, dass es einfach ohne irgendwas zusätzliches so auf der Vektor ALU läuft

Ggf ist es trotzdem eine Einheit die wahlweise beides kann. Nvidias Tensor Cores rechnen statt Tensors wahlweise auch FP16 Vektor oder INT Vektor iirc.

Auf AMDs slides ist für RDNA4 IIRC keine extra Einheit eingezeichnet (oder?). Warum sollte man das nicht tun wenn es eine gibt?

[Achill]

Ich verstehe immer noch nicht warum hier so sehr nach einen Unterschied gesucht wird, wenn man faktisch gar nicht weiß, wie die Lösungen von AMD und NV dann wirklich in Transistoren gegossen aussehen.

Auch scheint hier immer die indirekt Annahme zu gelten, dass NV Tensor Cores Konzept "besser" ist, den Beweis bleibt man schuldig und/oder es gibt halt nur Annahmen ohne Substanz da kein Interna offenliegt oder die gleiche SW fair auf unterschiedlicher HW laufen könnte und damit vergleichbar wird.

Daher wiederhole ich noch einmal meine Aussage, dass es nicht das "richtige" HW-Konzept gibt, sondern imho den Einsatz von Investition und Material/Platz/.. in der Herstellung in den Kontext setzt mit dem was dann in der Software damit machbar ist.

Wie sehr da irgend etwas isoliert, entkoppelt, nebenläufig usw. ist, hat erstmal weniger Relevanz ...

[robbitop]

Ging überhaupt nicht darum was besser ist oder nicht sondern wie es im Detail implementiert ist. Und das ist eine durchaus interessante und legitime Frage.

[Achill]

Ging überhaupt nicht darum was besser ist oder nicht sondern wie es im Detail implementiert ist. Und das ist eine durchaus interessante und legitime Frage.

Ok, im Kern gehe ich da gern mit. Die nachfolgenden Formulierungen sind aber imho nicht neutral oder positiv belegt.

Was auch wieder uneindeutig ist. Warum schwurbelt AMD da so rum? Klingt für mich als wäre da was hinterm Busch.

Die rationale Erklärung wäre einfach, das man die Details nicht offen legen will? Man stelle sich vor, AMD hätte in ihren Folien "Matrix Accelerator Units / Cores" geschrieben, hätten wir dann die Diskussion auch? Wenn es dort stehen würde, wüssten wir mehr? Würde sich etwas mit diesem Wort/Wörtern ändern?

[robbitop]

Ich war darüber unerfreut, dass Aussagen zu technischen Details der Implementierung der uArch uneindeutig sind. Potentiell absichtlich uneindeutig. Und absichtlich Dinge hinter Uneindeutigkeit zu verstecken ist ein halber Schritt vor einer Lüge - sowas kann ich nicht ausstehen. So wie man zu RDNA3 auch die wmma Fähigkeiten halb als Matrix Cores bezeichnet hat (bzw. viel mit Implikation gearbeitet hat in der Hinsicht) aber knapp ohne zu lügen damit es keinen Ärger gibt.

Und wenn es eindeutig formuliert gewesen wäre hätten wir die Diskussion nicht. Gibt es separate Units und können die parallel arbeiten? Ja/nein? Stünde es da hätten wir das Thema logischerweise nicht. Es ist aber ein interessantes Detail zur high level uArch.

AMD kann machen was sie wollen. Aber IMO ist es albern. Selbst das verschlossene NV gibt im whitepaper dazu Preis wie es aufgebaut ist. Intel auch. Sowas ist keine rocket science wenn man so high level Zeug beschreibt. Und das tun sie in anderen Apsekten der uArch auch. Und ansonsten ist AMD auch immer sehr offen mit ihrer HW Doku. Konsistenz im Verhalten ist auch ein Indikator gekoppelt mit Nutzung oder Nichtnutzung von Uneindeutigkeit.

So ich würde jetzt gern zur eigentlichen HW Diskussion zurückkehren anstatt mich dafür rechtfertigen zu müssen an dieser teilzunehmen. ;)

[two_smoking_barrels]

Gibt es separate Units und können die parallel arbeiten? Ja/nein?

Heutzutage werden Instruktionen meisten Parallel abgearbeitet, ob da verschiedene Einheiten zugrundeliegen ist irrelevant. (Ggf. müssen die Instruktionen von verschiedenen Warps/Waves kommen, da GPUs streng in-Order arbeiten.) Problem ist nur, Parallelität meint nicht das, was Du denkst, es würde es bedeuten. Und das was Du denkst Parallelität meint, können GPUs nicht.

Beispielsweise kommen im Nvidia-Forum von Zeit zu Zeit immer wieder Fragen wie: "Können Cuda-Instruktionen und Tensor-Instruktionen parallel in einer SM arbeiten?" oder ähnliche Fragen. Abhängig vom genauen Wortlaut der Frage, antworten dann NVidia-Mitarbeiter mit "Eine SM (Streaming Multiprocessor) hat 4 SMSPs (Streaming Multiprocessor sub-Partition), welche eigene Rechenwerke und Scheduler haben. Daher in SMSP0 kann eine Tensorinstruktion ge-issued werden, während im selben Takt im SMSP1 eine Multiplikation ge-issued wird. Es gilt nur zu beachten, dass die 4 SMSPs, welche zu einer SM gehören sich einige Rechenwerke teilen (Texture Units, FP64 units bei Consumer GPUs etc.)" (Für AMD gilt exakt das gleiche nur das SMSP Compute Units oder CU heißen und SM WGP oder Work Group Processor heißen)

Spezifizieren die Fragesteller Ihre Frage und fragen, sowas wie: "Können in einer SMSP gleichzeitig Tensor-Instruktionen und FP32-Instruktionen abgearbeitet werden", kommt eine Antwort von NVidia-Mitarbeitern wie: "Als Entwickler ist sowas zu steuern komplett unmöglich, da Compiler und die in der Hardware verbauten Scheduler sich darum kümmern. Aber es ist möglich, das in einer SMSP beide Instruktionen gleichzeitig abgearbeitet werden, da die meisten Rechenwerke latenz haben und ge-pipelined sind. Wird beispielsweise eine FP32-Multiplikation im Takt 0 ge-issued, das Resultat kommt im Takt 4 und im Takt 1 wird eine Tensorbefehl ge-issued, welche das Ergebniss erst im Takt 5 zurückgibt, dann werden im Takt 2 und Takt 3 beide Rechenoperationen parallel ausgeführt."

Ich vermute mal, was Du meinst wäre: "Können CUs bei AMD oder SMSPs bei NVidia zusätzliche Warpes/Waves im gleichen Takt issuen, wenn man zusätzliche Rechenwerke, wie Matrixeinheiten verbaut?". Die Antwort lautet: "Nein". Bei Nvidia steht ganz klar im Whitepaper "32 threads/clk" also ein Warp32/Wave32 pro Takt. Ist dieser Wave/Warp eine Tensor-Operation, so ist das theoretisch eine entgangene FP32-Operation. Das hinzufügen zusätzlicher Matrix-Cores befähigt GPUs nicht 'kostenlos' mehrere Waves/Warpes im selben takt zu issuen. Die Zahl der verbauten Scheduler erhöht sich nicht, durch das Hinzufügen von Matrix-Cores. Bei AMD ist es etwas komplexer, da AMD-CUs dual-issue können. Ich kenne hier nicht die Bedingungen fürs dual-issue, aber selbst wenn eine CU eine Matrix-Operation zusammen mit einer Multiplikation dual-issuen kann, so ist es theoretisch ebenfalls eine entgangene FP32-Operation gegenüber das dual-issuen von 2 FP32-Operationen.

Gibt es separate Units und können die parallel arbeiten? Ja/nein?

Ist nur Spekulation meinserseits: Ja, ich habe den Eindruck es gäbe physikalisch seperate Schaltkreise, welche für die Beschleunigung für AI verwendet werden können, seit RDNA1. Bei Navi10lite (PS5) und Navi10 (RX 5700, rx5700xt) fehlt die Beschleunigung für das Dot Product / Kreuzprodukt, aber alle nachfolgende RDNA1-Grafikchip habe eine solche Beschleunigung (zumindesten ist es das, was Locuza Forschung ergeben hat). Es hieß damals schon bei RDNA1, das solche Instruktionen für das Beschleunigen von AI-Verwendet werden können. Ich hatte daher immer den Eindruck, das AMD irgendeine Art von Dot-Alu hat und diese Schrittweise ausgebaut hat.

Ich war darüber unerfreut, dass Aussagen zu technischen Details der Implementierung der uArch uneindeutig sind. Potentiell absichtlich uneindeutig. Und absichtlich Dinge hinter Uneindeutigkeit zu verstecken ist ein halber Schritt vor einer Lüge

Die ganzen Schaubilder und Whitepaper sind nur sehr starke Vereinfachungen des Internen Aufbaus. Natürlich ist es aufgrund der starken Vereinfachung alles extrem uneindeutig. Und natürlich ist diese Uneindeutigkeit Im Sinne der Hersteller. Man möchte ja nicht seiner Konkurrenz technisch tiefblickende Einsichten geben. Damit Du mal eine Vorstellung bekommst, was es alles für Rechenwerke in einer CU/SMSP geben könnte, habe ich mal ein Stack-OVerflow-Beitrag rausgesucht:

In Volta (CC7.0, 7.2) and Turing (CC7.5) each SM sub-partition can issue 1 instruction per cycle [Anm.: gemeint ist hier 1 Warp/cycle also 32 Instruction/Cycle]. The instruction [Anm.: Warp] can be issued to a local execution unit or the SM shared execution units.

ADU - Address Divergence Unit. The ADU is reponsible per thread address divergence handling for branches/jumps and indexed constant loads prior to instructions being forwarded to other execution units.
ALU - Arithmetic Logic Unit. The ALU is responsible for execution of most integer instructions, bit manipulation instructions, and logic instructions.
CBU - Convergence Barrier Unit. The CBU is repsonsible for barrier, convergence, and branch instructions.
FMA - Floating point Multiply and Accumulate Unit. The FMA is responsible for most FP32 instructions, integer multiply and accumulate instructions, and integer dot product.
FP16 - Paired half-precision floating point unit. The FP16 unit is responisble for execution of paired half-precision floating point instructions.
FP64 - Double precision floating point unit. The FP64 unit is responsible for all FP64 instructions. FP64 is often implemented as several different pipes on NVIDIA GPUs. The throughput varies greatly per chip.
LSU - Load Store Unit. The LSU is responsible for load, store and atomic instructions to global, local, and shared memory.
Tensor (FP16) - Half-precision floating point matrix multiply and accumulate unit.
Tensor (INT) - Integer matrix multiply and accumulate unit.
TEX - Texture Unit. The texture unit is responsible for sampling, load, and filtering instructions on textures and surfaces.
UDP (Uniform) - Uniform Data Path - A scalar unit used to execute instructions where input and output is identical for all threads in a warp.
XU - Transcendental and Data Type Conversion Unit - The XU is responsible for special functions such as sin, cos, and reciprocal square root as well as data type conversions.

Quelle: stackoverflow.com (https://stackoverflow.com/questions/61413176/interpreting-compute-workload-analysis-in-nsight-compute/61431557#61431557). In den Whitepaper findet man es leider nicht so ausführlich.

Disclaimer: Ich bin nur ein Laie, daher kann ich auch was fehlerhaftes erzählt haben.

[mboeller]

Zitat von robbitop Beitrag anzeigen

Ops pro CU:
FP32: 256
FP16: 1024


das es sich nicht länger um normale SIMD handelt wie noch bei RDNA3 siehst du ja IMHO schon am 4x höhere FP16 Wert. Ein normales SIMD hätte nur einen 2x höheren FP16-Wert.

Speku: schaut für mich als Laie eher so aus, als ob AMD jetzt Matrix-Einheiten verbaut hat, die man auch für Grafik (TMU, Vektor etc..) benutzen kann... oder so ähnlich.

Fehlt nur noch ein besserer FP64-Wert (also zB. 128 Ops pro CU) um dann für ihre Instinkt-APU/GPU's tauglich zu sein.

[davidzo]

Ich vermute mal, was Du meinst wäre: "Können CUs bei AMD oder SMSPs bei NVidia zusätzliche Warpes/Waves im gleichen Takt issuen, wenn man zusätzliche Rechenwerke, wie Matrixeinheiten verbaut?". Die Antwort lautet: "Nein". Bei Nvidia steht ganz klar im Whitepaper "32 threads/clk" also ein Warp32/Wave32 pro Takt. Ist dieser Wave/Warp eine Tensor-Operation, so ist das theoretisch eine entgangene FP32-Operation. Das hinzufügen zusätzlicher Matrix-Cores befähigt GPUs nicht 'kostenlos' mehrere Waves/Warpes im selben takt zu issuen. Die Zahl der verbauten Scheduler erhöht sich nicht, durch das Hinzufügen von Matrix-Cores.

Vielen Dank für deinen sehr interessanten Beitrag!

Wie kommt es dass jemand wie du bisher nicht im 3Dcenter angemeldet war und ausgerechnet jetzt registriert hat? Gibt es andere Foren wo man tiefergehend spekuliert als hier, außer chiphell, beyond3d und Anandtech?

[robbitop]

das es sich nicht länger um normale SIMD handelt wie noch bei RDNA3 siehst du ja IMHO schon am 4x höhere FP16 Wert. Ein normales SIMD hätte nur einen 2x höheren FP16-Wert.

Speku: schaut für mich als Laie eher so aus, als ob AMD jetzt Matrix-Einheiten verbaut hat, die man auch für Grafik (TMU, Vektor etc..) benutzen kann... oder so ähnlich.

Fehlt nur noch ein besserer FP64-Wert (also zB. 128 Ops pro CU) um dann für ihre Instinkt-APU/GPU's tauglich zu sein.
Wobei die PS5PRO ALUs auch deutlich höheren Durchsatz für INT8 schaffen ohne Matrixrechenwerke zu haben. Insofern weiß ich nicht ob das allein schon wirklich was aussagt.

[robbitop]

Vielen Dank für deinen sehr interessanten Beitrag!

Wie kommt es dass jemand wie du bisher nicht im 3Dcenter angemeldet war und ausgerechnet jetzt registriert hat? Gibt es andere Foren wo man tiefergehend spekuliert als hier, außer chiphell, beyond3d und Anandtech?
Es gibt/gab hier seit einer Weile einen Gast mit technisch sehr kompetenten Antworten. Ggf. hat dieser sich angemeldet ^^
Meine Vermutung ist, dass es sich um einen ehemaligen Nutzer des Forums handelt, der sich vor Jahren abgemeldet hat (ich wüsste schon wer da passen könnte). Ich kann aber auch falsch liegen. :D

[robbitop]

Heutzutage werden Instruktionen meisten Parallel abgearbeitet, ob da verschiedene Einheiten zugrundeliegen ist irrelevant. (Ggf. müssen die Instruktionen von verschiedenen Warps/Waves kommen, da GPUs streng in-Order arbeiten.) Problem ist nur, Parallelität meint nicht das, was Du denkst, es würde es bedeuten. Und das was Du denkst Parallelität meint, können GPUs nicht.

Beispielsweise kommen im Nvidia-Forum von Zeit zu Zeit immer wieder Fragen wie: "Können Cuda-Instruktionen und Tensor-Instruktionen parallel in einer SM arbeiten?" oder ähnliche Fragen. Abhängig vom genauen Wortlaut der Frage, antworten dann NVidia-Mitarbeiter mit "Eine SM (Streaming Multiprocessor) hat 4 SMSPs (Streaming Multiprocessor sub-Partition), welche eigene Rechenwerke und Scheduler haben. Daher in SMSP0 kann eine Tensorinstruktion ge-issued werden, während im selben Takt im SMSP1 eine Multiplikation ge-issued wird. Es gilt nur zu beachten, dass die 4 SMSPs, welche zu einer SM gehören sich einige Rechenwerke teilen (Texture Units, FP64 units bei Consumer GPUs etc.)" (Für AMD gilt exakt das gleiche nur das SMSP Compute Units oder CU heißen und SM WGP oder Work Group Processor heißen)

Spezifizieren die Fragesteller Ihre Frage und fragen, sowas wie: "Können in einer SMSP gleichzeitig Tensor-Instruktionen und FP32-Instruktionen abgearbeitet werden", kommt eine Antwort von NVidia-Mitarbeitern wie: "Als Entwickler ist sowas zu steuern komplett unmöglich, da Compiler und die in der Hardware verbauten Scheduler sich darum kümmern. Aber es ist möglich, das in einer SMSP beide Instruktionen gleichzeitig abgearbeitet werden, da die meisten Rechenwerke latenz haben und ge-pipelined sind. Wird beispielsweise eine FP32-Multiplikation im Takt 0 ge-issued, das Resultat kommt im Takt 4 und im Takt 1 wird eine Tensorbefehl ge-issued, welche das Ergebniss erst im Takt 5 zurückgibt, dann werden im Takt 2 und Takt 3 beide Rechenoperationen parallel ausgeführt."

Ich vermute mal, was Du meinst wäre: "Können CUs bei AMD oder SMSPs bei NVidia zusätzliche Warpes/Waves im gleichen Takt issuen, wenn man zusätzliche Rechenwerke, wie Matrixeinheiten verbaut?". Die Antwort lautet: "Nein". Bei Nvidia steht ganz klar im Whitepaper "32 threads/clk" also ein Warp32/Wave32 pro Takt. Ist dieser Wave/Warp eine Tensor-Operation, so ist das theoretisch eine entgangene FP32-Operation. Das hinzufügen zusätzlicher Matrix-Cores befähigt GPUs nicht 'kostenlos' mehrere Waves/Warpes im selben takt zu issuen. Die Zahl der verbauten Scheduler erhöht sich nicht, durch das Hinzufügen von Matrix-Cores. Bei AMD ist es etwas komplexer, da AMD-CUs dual-issue können. Ich kenne hier nicht die Bedingungen fürs dual-issue, aber selbst wenn eine CU eine Matrix-Operation zusammen mit einer Multiplikation dual-issuen kann, so ist es theoretisch ebenfalls eine entgangene FP32-Operation gegenüber das dual-issuen von 2 FP32-Operationen.



Ist nur Spekulation meinserseits: Ja, ich habe den Eindruck es gäbe physikalisch seperate Schaltkreise, welche für die Beschleunigung für AI verwendet werden können, seit RDNA1. Bei Navi10lite (PS5) und Navi10 (RX 5700, rx5700xt) fehlt die Beschleunigung für das Dot Product / Kreuzprodukt, aber alle nachfolgende RDNA1-Grafikchip habe eine solche Beschleunigung (zumindesten ist es das, was Locuza Forschung ergeben hat). Es hieß damals schon bei RDNA1, das solche Instruktionen für das Beschleunigen von AI-Verwendet werden können. Ich hatte daher immer den Eindruck, das AMD irgendeine Art von Dot-Alu hat und diese Schrittweise ausgebaut hat.



Die ganzen Schaubilder und Whitepaper sind nur sehr starke Vereinfachungen des Internen Aufbaus. Natürlich ist es aufgrund der starken Vereinfachung alles extrem uneindeutig. Und natürlich ist diese Uneindeutigkeit Im Sinne der Hersteller. Man möchte ja nicht seiner Konkurrenz technisch tiefblickende Einsichten geben. Damit Du mal eine Vorstellung bekommst, was es alles für Rechenwerke in einer CU/SMSP geben könnte, habe ich mal ein Stack-OVerflow-Beitrag rausgesucht:



Quelle: stackoverflow.com (https://stackoverflow.com/questions/61413176/interpreting-compute-workload-analysis-in-nsight-compute/61431557#61431557). In den Whitepaper findet man es leider nicht so ausführlich.

Disclaimer: Ich bin nur ein Laie, daher kann ich auch was fehlerhaftes erzählt haben.
Sehr guter Beitrag :)
Dennoch hier eine Rückfrage: ich meine mich entsinnen zu können, dass Nvidia das simultane Ausführen von Operationen auf Tensorcores und Vektor ALUs explizit erwähnt hat zum Ampere launch. Auch meine ich in nsight (dieses Tool wo man sich pro Frame Auslastung verschiedener Units anschauen kann) gesehen habe, dass Tensorcores und Vektoralus gleichzeitig ausgelastet waren für einen Teil der Frametime. Wie passt das zu obigem? :)

[two_smoking_barrels]

"simultane Ausführen von Operationen auf Tensorcores und Vektor ALUs explizit erwähnt hat zum Ampere launch" -> ich dachte ich habe 2 gut erklärte Möglichkeiten beschrieben, was das heißt. Falls nicht, bitte zitiere den unklaren Teil aus meiner Ursprungsbeitrag.

Ich denke, das beste ist, wenn ich mal direkt ein Nvidia-Mitarbeiter zitiere:
There are at least 2 factors to consider:
- All instructions are pipelined and have latency. For example, a multiply instruction issued in cycle 0 may not produce a result until e.g. cycle 4. Likewise for tensor core op (wmma). So if an ordinary multiply is issued in cycle 0, producing its result in cycle 4, and a tensor core op is issued in cycle 1, producing its result in cycle 5 (for the sake of discussion), then during cycles 2 and 3 the SM (functional units) are actively involved in processing both ops at the same time.

- Many modern SMs are broken into sub-partitions. Each sub-partition has a warp scheduler. So in the exact same cycle it is possible for a warp scheduler in sub-partition 0 to issue a tensor core op, while a warp scheduler in sub-partition 1 issues an ordinary multiply. These instructions would target separate functional units, of course.

Quelle: Nvidia-Forum (https://forums.developer.nvidia.com/t/concurrent-execution-of-cuda-and-tensor-cores/222985/5)
Folgender Link hilft vielleicht auch: Nvidia-Forum (https://forums.developer.nvidia.com/t/i-need-help-understanding-how-concurrency-of-cuda-cores-and-tensor-cores-works-between-turing-and-ampere-ada/286305)

"Auch meine ich in nsight (dieses Tool wo man sich pro Frame Auslastung verschiedener Units anschauen kann) gesehen habe, dass Tensorcores und Vektoralus gleichzeitig ausgelastet waren für einen Teil der Frametime." -> Nuancen wären noch interessant: Redet Nsight von SM oder SMSP? (Ich habe hier keine Nvidia-Gpu oder AMD-GPU zur Hand.)

Es gibt/gab hier seit einer Weile einen Gast mit technisch sehr kompetenten Antworten. Ggf. hat dieser sich angemeldet ^^
Meine Vermutung ist, dass es sich um einen ehemaligen Nutzer des Forums handelt, der sich vor Jahren abgemeldet hat (ich wüsste schon wer da passen könnte). Ich kann aber auch falsch liegen. :D
Nein, beides ist falsch. Ich bin auch kein Entwickler, programmiere keine GPUs oder CPUs. Ich habe mich nur ausführlich mit Schaltungstechnik im Studium beschäftigt.


Wie kommt es dass jemand wie du bisher nicht im 3Dcenter angemeldet war und ausgerechnet jetzt registriert hat?
Offen gesprochen: Das einige User meinen, Sie müssten im Sinne irgendwelcher Hersteller Reputationen von nem anderen Hersteller zerstören oder willentlich (technische) Erklärungen zitieren und falsch verstehen, um die Reputation eines Hersteller zu boosten, ist nicht cool.

Gibt es andere Foren wo man tiefergehend spekuliert als hier, außer chiphell, beyond3d und Anandtech?
Keine Ahnung. Es gibt noch das Nvidia Developer Forum (https://forums.developer.nvidia.com/c/accelerated-computing/cuda/cuda-programming-and-performance/7). Sehr cool das dort technisch versiertes Nvidia-Personal viele Fragen extrem präzise beantworten und auch Nachfragen beantworten, aber natürlich wird dort nicht unbeschwerrt spekuliert und die Erklärungen sind selbst für Laien, wie mich, oft schwierig, weil die Erklärungen sich eben an Software-Entwickler richten

[w0mbat]

Ich kann auch nochmal eine Rückfrage direkt an meinen AMD-Kontakt stellen, wenn ihr beim formulieren helfen wollt ;)

Und wie gesagt, George ist sich sicher, dass es extra "tensor cores" gibt. Aber klar, die sind Teil einer CU (bzw. WGP) und teilen sich Resourcen. Im Blockdiagram sind vier "AI Accelerators" eingezeichnet, aber da sind ja auch die doppelte Anzahl an ALUs zu sehen ("dual-issue"). Ich gehe also von dezidierten tensor cores aus, meine Frage wäre nun ob es 2 oder 4 pro WGP sind.

[AffenJack]

Ich kann auch nochmal eine Rückfrage direkt an meinen AMD-Kontakt stellen, wenn ihr beim formulieren helfen wollt ;)

Und wie gesagt, George ist sich sicher, dass es extra "tensor cores" gibt. Aber klar, die sind Teil einer CU (bzw. WGP) und teilen sich Resourcen. Im Blockdiagram sind vier "AI Accelerators" eingezeichnet, aber da sind ja auch die doppelte Anzahl an ALUs zu sehen ("dual-issue"). Ich gehe also von dezidierten tensor cores aus, meine Frage wäre nun ob es 2 oder 4 pro WGP sind.

Diese angeblichen "extra" Tensor Cores machen für mich sowohl bei AMD, als auch Nvidia nie wirklich Sinn. In Zeiten von Waferplatzlimitierung und Kosten soll man die Einheiten doppelt verbauen?

Ist es nicht sinnvoller, wenn sich Tensor Core und Alu die Schaltung intelligent teilen, so dass normale FP/Int Instruktionen von einem Teil des ganzen Tensor Cores ausgeführt werden, während man den Rest powergated? Normale ALU als Subcore vom Tensor Core?
Man könnte dann diskuttieren, ab welchem Zeitpunkt man einen wirklichen Tensor Core erhält. Solange die Ressourcen noch von der normalen ALU in irgendeiner Weise genutzt werden bliebe dann die normale ALU, während die restlichen Transistoren nur in TC-Betrieb aktiv sind.

Das passt für mich auch besser mit dem Post von two_smoking_barrels, wo auch Nvidia das simultane TC und Vektor ALU ausführen auf unterschiedlichen Sub-SM teilen definiert. Das würde zu normaler ALU als Subcore vom Tensor-Core passen.

Allerdings gibts dann natürlich wieder die Aspekte wie HPC Blackwell, wo Vektor-ALU sehr langsam geworden ist im Vergleich zu Tensor Core, was dem ganzen widerspricht und Blackwell Ultra, der für mich komplett unverständlich ist, weil man ohne mehr Platzbedarf den Durchsatz der Tensor Cores ohne Sparsity um 50% erhöht.

[robbitop]

Wenn man sich bei FSR4 und DLSS anschaut wie kurz die Matrixinstruktionen in ms pro Frametime gebraucht werden, würde es auch Sinn machen, sich das zu teilen, wenn es Transistoren spart.

[w0mbat]

Diese angeblichen "extra" Tensor Cores machen für mich sowohl bei AMD, als auch Nvidia nie wirklich Sinn. In Zeiten von Waferplatzlimitierung und Kosten soll man die Einheiten doppelt verbauen?

Ist es nicht sinnvoller, wenn sich Tensor Core und Alu die Schaltung intelligent teilen, so dass normale FP/Int Instruktionen von einem Teil des ganzen Tensor Cores ausgeführt werden, während man den Rest powergated? Normale ALU als Subcore vom Tensor Core?
Man könnte dann diskuttieren, ab welchem Zeitpunkt man einen wirklichen Tensor Core erhält. Solange die Ressourcen noch von der normalen ALU in irgendeiner Weise genutzt werden bliebe dann die normale ALU, während die restlichen Transistoren nur in TC-Betrieb aktiv sind.

Das passt für mich auch besser mit dem Post von two_smoking_barrels, wo auch Nvidia das simultane TC und Vektor ALU ausführen auf unterschiedlichen Sub-SM teilen definiert. Das würde zu normaler ALU als Subcore vom Tensor-Core passen.

Allerdings gibts dann natürlich wieder die Aspekte wie HPC Blackwell, wo Vektor-ALU sehr langsam geworden ist im Vergleich zu Tensor Core, was dem ganzen widerspricht und Blackwell Ultra, der für mich komplett unverständlich ist, weil man ohne mehr Platzbedarf den Durchsatz der Tensor Cores ohne Sparsity um 50% erhöht.
Das ist alles schon in die Umgebung integriert. Also als Teil von SM/CU. Bei AMD könnte die Integration noch näher sein als bei Nvidia.

Es geht vor allem darum abzugrenzen, ob man "einfach" WMMA auf den normalen Vector ALUs laufen lässt, oder ob es spezielle tensor core Transistoren gibt, die Matrizen deutlich schneller und effizienter bearbeiten können, als WMMA via Vector ALUs.

Und RDNA4 scheint hier - im Gegensatz zu RDNA3 - spezielle tensor core hardware zu haben. Dass dabei die gleichzeitige Ausführung von z.B. FP32 auf dem Teilbereich der CU, in dem der tensor core gerade aktiv ist, nicht funktioniert bedeutet nicht, dass es keine extra tensor cores gibt.

[Gipsel]

Dass dabei die gleichzeitige Ausführung von z.B. FP32 auf dem Teilbereich der CU, in dem der tensor core gerade aktiv ist, nicht funktioniert bedeutet nicht, dass es keine extra tensor cores gibt.Bandbreite der Registerfiles ist teuer. An der dürfte das vornehmlich hängen.

[mksn7]

Eine V_WMMA_F32_16X16X16_F16 Instruktion macht 16*16*16*2 = 8192 FP16 Flops. Ein FP16 Durchsatz von 1024 Flop/cyc/CU entspricht einem FP16 Durchsatz von 512 Flop/cyc/SIMD, also ist der inverse Durchsatz dieser Instruktion 16 Takte/(Instuction/CU).

Diese Instruction konsumiert drei FP16 Matrizzen mit jeweils 16*16 * 2B = 512B an Daten. Es werden also über 16 Takte 1536B konsumiert, das braucht eine Registerbandbreite von 96B/Takt. Ein simples FP32 FMA (das hat einen inversen Durchsatz von 1 cyc/instruction) braucht schon 3*4B*32 = 384B/Takt, es wäre also durchaus noch Luft bei der Registerbandbreite. Oder umgedreht, eine dieser 16x16x16xFP16 wmma instructions konsumiert die Registerbandbreite von ca 4 FP32 FMAs.

Es wäre also denkbar, dass in 16 Takten entweder 16x FP32 FMAs oder 1x FP16 WMMA + 12 FP32 FMAs gemacht werden können, falls die Ausführungseinheiten wirklich doppelt ausgelegt sind. Ein gewisses Maß an Parallelität wäre im Prinzip möglich, muss aber nicht sein. Ein issue cycle ist auf jeden Fall weg, aber das wäre ja nur einer von 16 cycles.

[Leonidas]

Offen gesprochen: Das einige User meinen, Sie müssten im Sinne irgendwelcher Hersteller Reputationen von nem anderen Hersteller zerstören oder willentlich (technische) Erklärungen zitieren und falsch verstehen, um die Reputation eines Hersteller zu boosten, ist nicht cool.

In der Tat. Dabei sollte es doch vor allem um eines gehen: Erkenntnisgewinn.

[gedi]

Ich kann auch nochmal eine Rückfrage direkt an meinen AMD-Kontakt stellen, wenn ihr beim formulieren helfen wollt ;)

Und wie gesagt, George ist sich sicher, dass es extra "tensor cores" gibt. Aber klar, die sind Teil einer CU (bzw. WGP) und teilen sich Resourcen. Im Blockdiagram sind vier "AI Accelerators" eingezeichnet, aber da sind ja auch die doppelte Anzahl an ALUs zu sehen ("dual-issue"). Ich gehe also von dezidierten tensor cores aus, meine Frage wäre nun ob es 2 oder 4 pro WGP sind.

Mich würde eher interessieren, ob Full tatsächlich=64CUs sind.

[davidzo]

Nein, beides ist falsch. Ich bin auch kein Entwickler, programmiere keine GPUs oder CPUs. Ich habe mich nur ausführlich mit Schaltungstechnik im Studium beschäftigt.


Okay, du scheinst einen Schwerpunkt bei Mikroarchitektur gesetzt zu haben.

Ich stimme dir zu dass der Fanboy-ism hier manchmal etwas kindisch wird.

Aber ich glaube das Interesse an Leaks und Spekulation über Hardware die in ein ein zwei drei Jahren erscheint überwiegt hier. Es ist die technische Faszination und der Umstand dass sich über interpretation dieser Andeutungen quasi die Zukunft lesen lässt.

[w0mbat]

Mich würde eher interessieren, ob Full tatsächlich=64CUs sind.
Sind es. Navi 48 hat 4 Shader Engines und jede SE hat 8 Dual Compute Units (aka WGP). Das heißt es gibt 4 x 8 x 2 = 64 CUs.

[Der_Korken]

Mich würde eher interessieren, ob Full tatsächlich=64CUs sind.

AMD ist ja bekannt dafür ihre Flagschiffe immer erst teildeaktiviert zu launchen, um dann nochmal nachzulegen. Angeblich schlummern sogar 72CUs im N48, die AMD aber erst in einem Stepping launchen wird, weil sie GDDR7 brauchen, um diese zu füttern, aber der GDDR7-Controller hat in der aktuellen Revision noch einen Bug. Damit wäre dann locker 5080-Performance drin.


/s
nur zur Sicherheit ...

[raffa]

edit: kleiner Nachtrag noch zum Chipaufbau, bin noch am schauen, scheint gut gemacht:
u8cfrJTdo0E

Das zweite Quartal bricht an. Irgendwas neues zu N44 in Sicht?
https://www.3dcenter.org/news/amds-radeon-rx-9060-xt-kommt-nun-doch-auf-navi-44-basis-mit-8-und-16-gb-vram

[Achill]

AMD ist ja bekannt dafür ihre Flagschiffe immer erst teildeaktiviert zu launchen, um dann nochmal nachzulegen. Angeblich schlummern sogar 72CUs im N48, die AMD aber erst in einem Stepping launchen wird, weil sie GDDR7 brauchen, um diese zu füttern, aber der GDDR7-Controller hat in der aktuellen Revision noch einen Bug. Damit wäre dann locker 5080-Performance drin.


/s
nur zur Sicherheit ...


Hab ich auch heute schon gehört, soll wahrscheinlich als 9070 XT Super starten und dann auch die 32GB VRAM mitbringen. Bestätigt also auch diese Vermutung die schon von ein paar Wochen die Runde machte.


... wir hatten immerhin den 1. April als ich es geschrieben habe.

[gedi]

Wurde aber von AMD seitens Azor bestritten. BTW. käme ich mir auch leicht veralbert vor! Nahe 5080 Performance geht auch jetzt bereits, je nach Spiel. Einfach pro Game ein eigenes OC-Profil anlegen und gut. Beim Einen gehen lediglich -80mV, beim Anderen -200mV. Zudem kann man pro Game eine geeignete Lüfterkurve anlegen. Besser geht es imo kaum!

[Nakai]

Ich hoffe immer noch, dass wir in einem Jahr eine 9080XT sehen mit 96CUs, 256 Bit GDDR7 und 128 MB LLC.

Eine SE bei N48 braucht etwa 35mm², leicht unter 10% vom gesamten Die.
Bei den Caches kann man das nicht so einfach hinskalieren, da verschiedene Cacheparzellen unterschiedlich groß sind. Da man nicht alle Chipteile aber nach oben skalieren muss, sollte ein hypothetischer N49 unter 500mm² rauskommen. Vor allem die kleineren Cacheblöcke machen Lust auf mehr.

Da haben bei AMD die GPU-Kollegen von den CPU-Kollegen schon etwas Hilfe bei der Packdichte bekommen haben.

[iamthebear]

Mich würde eher interessieren, ob Full tatsächlich=64CUs sind.

Ja sind es. Da braucht man nur auf den Die Shot schauen:

4 Shader Engines (gleiche Blöcke) mit je:
4x2 WGPs (gleiche Blöcke) mit je:
2 CUs (zweiter CU ist gespiegelt)

Achtung: Wenn man nicht genau schaut könnte man die Raster Engines für WGPs halten da diese ca. gleich groß sind aber die sehen anders aus.

[davidzo]

edit: kleiner Nachtrag noch zum Chipaufbau, bin noch am schauen, scheint gut gemacht:
https://youtu.be/u8cfrJTdo0E



Der Dieshot sieht verdammt nach N21 aus. Die Anordnung der Shaderengines, CUs und Command processor ist nahezu gleich. Dann der Infinitycache drum herum und an den langen Kanten die GDDR PHYs.
Auf den ersten Blick fehlen N48 nur die xGMI Links, vermutlich weil man kein DualGPU für Apple mehr bauen muss wie bei N21 noch.
Dafür sind dann zwei PHYs nach oben gewandert, welche auch wesentlich schmaler und länglicher geworden sind. N48 ist daher deutlich schmaler, nicht zuletzt aber auch durch den kleineren IFcache.


Das zweite Quartal bricht an. Irgendwas neues zu N44 in Sicht?
https://www.3dcenter.org/news/amds-radeon-rx-9060-xt-kommt-nun-doch-auf-navi-44-basis-mit-8-und-16-gb-vram
Nix, aber wenn man sich den N48 Launch anguckt kann es mit der Verfügbarkeit dann doch schnell gehen. Vermutlich hat sich AMD den fast botched Launch von N48 zu herzen genommen, wo man auf der CES trotz der Verschiebung eine Ankündigung machen wollte, aber noch ohne irgendwas zu sagen. Der eigentliche Launch im März ist aber gut aufgenommen worden von den Kunden und der Fachpresse, da es ein richtiger Hardlaunch mit Stückzahlen war.
Es wäre nur folgerichtig wenn die so einen Hardlaunch auch wieder bei N44 durchziehen.

[mksn7]

edit: kleiner Nachtrag noch zum Chipaufbau, bin noch am schauen, scheint gut gemacht:
https://youtu.be/u8cfrJTdo0E

Das zweite Quartal bricht an. Irgendwas neues zu N44 in Sicht?
https://www.3dcenter.org/news/amds-radeon-rx-9060-xt-kommt-nun-doch-auf-navi-44-basis-mit-8-und-16-gb-vram

Immer wieder beeindruckend wie die unscharfen Pixel dann doch Hardwareeinheiten zugeordnet werden können!

Beim Aufbau der Dual CUs wirds etwas ungenau:

Er sagt, "Why are there 4x the same structure per dual-cu?" und beantwortet das mit dual-issue. Das hat damit aber nichts zu tun, eine dual-cu/wgp hat eben 2x CU, und jede CU hat 2 x SIMD blocks (AMD hat auch schon bei GCN eine sub unit als ein "SIMD" bezeichnet). Die Dual Issue units sind innerhalb eines SIMDs platziert. AMD gibt weiterhin nur 32 "cores" pro SIMD an, auch wenn jeder "core" dual-issue kann.

Der Vergleich mit SMT passt hier aber überhaupt nicht. Das Aquivalent bei einer CPU wäre eine Aufweitung von 1x issue zu 2x issue (CPUs sind hier ja eher so bei 6-8x).

GPUs haben schon seit jeher eine SMT-artige Funktionsweise, mit 8-16 wave (warps) pro SIMD (SM quadrant oder subpartition). Dank dieser extremen Form von SMT sparen sich die GPUs die komplexen OoO Geschichten usw.

[w0mbat]

Doch, das ist "dual-issue". Im Blockdiagramm sind ja 4x 2xSIMD Blöcke verzeichnet und damit insg. 256 ALUs.

Und ja, der SMT-Vergleich ist nicht der beste. Bei dual-issue können ja, unter bestimmten Voraussetzungen, zwei shader gleichzeitig ausgeführt werden. Ist schon was anderes als einen 2. Thread laufen zu lassen, wenn der 1. Thread gerade Zeit hat. Aber die Grundidee ist ähnlich, nämlich mehr Leistung ohne alle Ausführungseinheiten zu verdoppeln.

[GerryB]

https://overclock3d.net/news/gpu-displays/amd-reportedly-preps-radeon-rx-9070-gre-gpu/

[Hakim]

Könnte der 5060Ti Konkurrent werden, falls die 9060er da Probleme haben sollten

[Der_Korken]

https://overclock3d.net/news/gpu-displays/amd-reportedly-preps-radeon-rx-9070-gre-gpu/

Warum werden 9060 und 9070 überhaupt getrennt? Man könnte die N44-Modelle doch einfach 9070LE und 9070XLE nennen, dann spart man sich die ganzen Zahlen.

[dargo]

Weil man sich an der Konkurrenz orientieren möchte, zumindest offiziell.

[dildo4u]

Jup das war das beste Marketing von AMD als man Ryzen direkt gegen Intel vergleichen konnte.
Leider ist das Dort auch total aus dem Ruder gelaufen auf Intel Seite.(265k=9900X?)

[x-force]

Jup das war das beste Marketing von AMD als man Ryzen direkt gegen Intel vergleichen konnte.

das hat schon mit athlon xp xxxx"+" angefangen. grober unfug war das...

[mksn7]

Doch, das ist "dual-issue". Im Blockdiagramm sind ja 4x 2xSIMD Blöcke verzeichnet und damit insg. 256 ALUs.


So wie du das sagst stimmt es auch. Vielleicht hab ich ja auch falsch verstanden was er in dem Moment gemeint hat, aber für mich hört es sich so an als würde er da 2 CU pro dual-CU mal dual issue = 4 SIMD's da drin sehen. Dann hätte er den Faktor 2x von 2 SIMDs pro CU unterschlagen und falsch als dual-issue identifiziert.

Das Blockdiagram sah bei RDNA1/2 ja schon genauso aus, auch ohne dual-issue.


Bei dual-issue können ja, unter bestimmten Voraussetzungen, zwei shader gleichzeitig ausgeführt werden. Ist schon was anderes als einen 2. Thread laufen zu lassen, wenn der 1. Thread gerade Zeit hat. Aber die Grundidee ist ähnlich, nämlich mehr Leistung ohne alle Ausführungseinheiten zu verdoppeln.


Das geht eben leider nicht. Die zwei seperaten vector execution units werden über eine v_dual_xxx_f32 Instruktion verwendet, die zwei Instruktionen des gleichen Typs aus dem gleichen thread kombiniert. Also eigentlich ist RDNA immer noch single issue (jedenfalls für vector instructions), aber manche Instruktionen sind einfach etwas dicker.

[Gipsel]

Das geht eben leider nicht. Die zwei seperaten vector execution units werden über eine v_dual_xxx_f32 Instruktion verwendet, die zwei Instruktionen des gleichen Typs aus dem gleichen thread kombiniert. Also eigentlich ist RDNA immer noch single issue (jedenfalls für vector instructions), aber manche Instruktionen sind einfach etwas dicker.Genau. Das Dual/Multi-Issue Ding ist unabhängig vom "Multithreading". GCN/RDNA können jeden (jeden vierten für GCN*) Takt zu einer anderen Wavefront wechseln, was eine Art des Multithreading ist ("Barrel computing", fine-grained temporal Multithreading, maskiert Latenzen). Multi-Issue entspricht eher der Superskalarität bei CPUs (nur daß wir hier keine skalaren sondern hauptsächlich Vektoreinheiten haben).
Multi-Issue bei GCN und auch RDNA geht nur zwischen verschiedenen Instruktionstypen und nur aus einer Wavefront (das ist quasi der Hardware-Thread). Also in einem Takt kann GCN/RDNA also einen Vektorbefehl, einen Skalarbefehl und z.B. einen Texturfetch zu genau einer Wavefront absetzen (und noch LDS bzw. Export, aber bei zu vielen ist es praktisch wegen fehlender Registerbandbreite nicht möglich), aber nicht 2 Vektorbefehle (die zweite Vektor-ALU kann wie mskn7 ganz richtig sagt, nur über spezielle Befehle benutzt werden, die quasi VLIW2 machen [allerdings ziemlich restriktiv]).

*: GCN führt Vektorbefehle über 4 Takte aus. Die skalare ALU wechselt jeden Takt zwischen den 4 Wavefronts, die gerade auf den 4 Vektor-ALUs (über jeweils 4 Takte, aber jeweils um einen Takt versetzt) ausgeführt werden.

[mksn7]

Kann echt nur aus der gleichen wave geissued werden? Ich hatte gehofft es geht in jedem Takt eine vekcor instruction von hier, eine scalar instruction von da, und dann noch von irgendeiner anderen wave noch ein load...

Das macht es ja wesentlich restriktiver die unterschiedlichen execution units tatsächlich gleichzeitig zu benutzen.

[robbitop]

Gab es mit Wave64 nicht weniger Restriktionen was dual issue angeht? :)

[Der_Korken]

Mal eine ganz laienhafte Frage: Für Dual-Issueing müssen doch physisch auch doppelt so viele ALUs vorhanden sein, die auch ihre eigenen Datenpfade mitbringen müssen und sogar parallel zu den "normalen" ALUs Daten aus den Registern lesen (und schreiben) können müssen. Wenn diese Ports aber so selten genutzt werden können, lohnt sich der Aufwand dann überhaupt? Hätte man statt 4xSIMD32 mit Dual-Issue nicht z.B. lieber 5xSIMD32 ohne Dual-Issue auf die gleiche Fläche bauen können für eine deutlich konsistentere Performance und einfacheres Scheduling/Compiling?

[mksn7]

Bei wave64 ist im Prinzip jede instruction eine dual-issue instruction. Die Limitierung wegen der Registerbandbreite gibt es aber weiterhin.
Manche Restriktionen, wie dass zwei Register aus unterschiedlichen register file banks sein müssen, fallen aber ganz natürlich weg, weil das für die zwei 32x Register die ein 64x Register immer gilt.
Ich könnte mir vorstellen dass der Haupteinsatzzweck der extra execution units der wave64 mode ist, und die v_dual instructions in wave32 nur zusätzlich ganz nett sind.

Die Registerbandbreite ist eben nicht verdoppelt, deswegen auch viele der Restriktionen. Zu einem extra SIMD-Block gehört noch so viel mehr, wie z.B. eine scalar unit, scalar register file, vector register file, scheduler usw. Wie so oft, sind die extra execution units wohl vergleichsweise günstig, und daher ist es ok wenn sie auch nur ein bisschen was helfen.

[robbitop]

Baut der Shadercompiler für RDNA3 (und 4) denn mittlerweile vermehrt wave64 Instructions? Ich meine mich erinnern zu können, dass die Spieleleistung von RDNA3 seit 2022 immer weiter angestiegen ist.

[mksn7]

Baut der Shadercompiler für RDNA3 (und 4) denn mittlerweile vermehrt wave64 Instructions? Ich meine mich erinnern zu können, dass die Spieleleistung von RDNA3 seit 2022 immer weiter angestiegen ist.

Ein shader program ist entweder komplett in wave64 oder wave32. Das kann der Treiber vor dem Kompilieren entscheiden. Es ist also nicht schwierig wave64 zu verwenden, nur die Entscheidung was besser ist, ist nicht unbedingt trivial.

Ich hab mal gehört dass die Mesa Treiber teilweise einfach alle pixel shader als wave64 und vertex shader als wave32 bauen.

[Raff]

"Pinnacle of Rasterizing Fakes": RDNA 4 schlägt RDNA 3 -> https://www.pcgameshardware.de/The-Last-of-Us-Part-2-Remastered-Spiel-74482/Specials/PC-Release-Review-Steam-Test-Benchmarks-1469049/3/ :D

MfG
Raff

[GerryB]

Frametimes = !?

Hat da nicht jeder Hersteller schon nen gameready Treiber?
zumindestens AMD läuft rund

[gedi]

Also die vermutlichen Specs zur GRE enttäuschen doch sehr, insbesondere dessen, dass man keinen Gegner zur 5070 hat.

Daher meine Vermutung: 48CUs und 16GB mit 18(.5)mt/s, welcher weniger Völker bekommt, um einer Non-XT durch OC/UV nicht zu nahe kommt.

[DrFreaK666]

Also die vermutlichen Specs zur GRE enttäuschen doch sehr, insbesondere dessen, dass man keinen Gegner zur 5070 hat...

Wieso ist die 9070 für ca. 10€ mehr kein Gegner?

[gedi]

Wieso ist die 9070 für ca. 10€ mehr kein Gegner?

Weil sie schneller ist und man NV Anteile abnehmen sollte. Eine GRE für 549€ würde bei gleicher Performance zur 5070, schon etwas Druck aufbauen können.

[raffa]

Eine 12GB GRE wär ein prima Gegner zu 5070, allerdings genauso uninteressant.

Ich versuchs nochmal anders, 12GB sind einfach knapp und solche Karten sollten nicht mehr als 300€/$ kosten.

[gedi]

Mehr als 449€ auf keinen Fall. Aber AMD ist AMD und NV ist NV. Von daher ergibt eine 12 GB keinen Sinn für mich. Eine GRE mit 16GB langsamerem Vram bei 48 CUs bei 185w hört sich für mich perfekt an!

[GerryB]

9070xt = 4k
9070 = UWQHD
GRE = WQHD

da reichen 12GB@192bit vermutlich in vielen Games, wenn nicht, dann hilft FSR

Die Bandbreite sollte gar kein Problem sein, falls der Cache nicht beschnitten wird.
Da könnte man 25% unter der XT gut leben, ... muss erstmal soviel GPU-Leistung erlaubt werden.
(sicherlich steuerbar über Takt+Watt)

btw.
praktisch = reale Preise
XT = 729€
nonXT = 629€
GRE= 529E
ne 5060Ti wird wohl auch bei >500€ landen

449€ ist nicht lohnend für den grooooßen Chip, Marge gegen Null ?

[The_Invisible]

Nvidia geht effizienter mit vram um, daher ist es bei AMD schon vor Nvidia ein problem

[dargo]

Nvidia geht effizienter mit vram um, daher ist es bei AMD schon vor Nvidia ein problem
Dieses Märchen hält sich hartnäckig. :tongue: Ich würde zu gern wissen wie oft bei solchen Aussagen rBar bei NV einfach nur Off ist. :ulol:

[dildo4u]

Gibt halt ständig neue Beispiele Total Ausfall der RX7600 in Last of US.
4070 hat die selben Frametimes wie 7800XT etc.

https://www.computerbase.de/artikel/gaming/the-last-of-us-part-2-benchmark-test.91962/seite-2#abschnitt_benchmarks_in_wqhd_uwqhd_und_ultra_hd

[dargo]

Ohne rBar Off bei AMD glaube ich da erstmal gar nichts.

[Shaft]

Dieses Märchen hält sich hartnäckig. :tongue: Ich würde zu gern wissen wie oft bei solchen Aussagen rBar bei NV einfach nur Off ist. :ulol:


Also wwnn ich mich nicht irre hatte pcgh letztens wieder grafikkarten 8gb vs 16 gb getestet.

Mit dem Ergebnis,wie auch bekannt, das nvidia ein besseres speichermanagment hat.

Man möge mich korregieren.

[dargo]

Und PCGH testet Radeons mit rBar Off? Kann ich mir kaum vorstellen. Das Problem bei Geforces ist, dass der Treiber je nach Game automatisch rBar deaktiviert weil es damit auf Geforces immer wieder mal Probleme gibt. Insofern sind sämtliche Tests völlig intransparent bei diesem Thema. Dadurch kommen dann solche Gerüchte @Speichermanagement.

Edit:
Imo wird das Thema aber eh völlig überbewertet. Wer sich heute noch 8GB bei ner Graka antut hat am falschen Ende gespart. Selbst 12GB halte ich mittlerweile für eher fraglich bei einer geplanten Lebensdauer von 3-4 Jahren. Eine Lebensdauer von nur 2 Jahren betrachte ich nicht mehr da in diesem Zeitraum zu wenig beim Fortschritt der IHVs passiert.

[Lurtz]

9070xt = 4k
9070 = UWQHD
GRE = WQHD

da reichen 12GB@192bit vermutlich in vielen Games, wenn nicht, dann hilft FSR

Der VRAM-Bedarf hat viel mehr mit der Engine/dem Spiel als der Auflösung zu tun. Keine Ahnung woher dieses Gleichsetzen von GPUs mit Auflösung auf einmal kommt (außer von nVidias PR-Folien).

[DrFreaK666]

Weil sie schneller ist und man NV Anteile abnehmen sollte...

Und mit einer schnelleren Grafikkarte für den gleichen Preis nimmt man keine Anteile ab? Verstehe die Logik nicht

[dildo4u]

Die 9700 ist zu teuer das geht aus jedem Test hervor nur ca die selbe Leistung für den Selben Preis ist nichts was vorher zum Erfolg geführt hatte.
Die 4070 hat alle 16 GB AMD Karten um 500€ zusammen mehrfach überholt.

[raffa]

Eine GRE mit 48 CU und 16GB@18 Gbps wär jedenfalls das interessantere Produkt als eine mit 12GB.

[][immy]

Die 9700 ist zu teuer das geht aus jedem Test hervor nur ca die selbe Leistung für den Selben Preis ist nichts was vorher zum Erfolg geführt hatte.
Die 4070 hat alle 16 GB AMD Karten um 500€ zusammen mehrfach überholt.

Aber wie immer unterdimensioniert Nvidia den Speicher und bremst seine Karten trotz der hohen Preise künstlich aus.
Selbst die 3070/3080 wäre mit mehr Speicher heute noch gut dabei.

Hier altern dann AMDs Karten mit mehr Speicher besser.

Von den 9070er Karten bin ich nicht wirklich enttäuscht, aber mit einer rx7900xt sehe ich aktuell auch keine wirkliche Mehrleistung die einen größeren Unterschied machen würde.

Die Preise sind aber tatsächlich aktuell noch zu hoch, aber der Markt gibt es halt her.
Dank trumps Zöllen und dem damit verbundenen gesunkenen Konsum (wird wohl kommen) könnten die Preise aber tatsächlich wieder sinken.

Die weitere Entwicklung wird dann aber fraglich. Der Markt dreht sich dann ggfs tatsächlich komplett zugunsten von ki Chips.

[Denniss]

Nvidia ist "effizienter" weil der Treiber bei Speichermangel von sich aus die Texturqualität senkt um VRAM zu sparen. AMD macht das "bisher" nicht.
HWUB hatte da mal ein Vid mit ner 3070 und Hogwarts Legacy wo man das schön sehen konnte

[dildo4u]

Nvidia ist "effizienter" weil der Treiber bei Speichermangel von sich aus die Texturqualität senkt um VRAM zu sparen. AMD macht das "bisher" nicht.
HWUB hatte da mal ein Vid mit ner 3070 und Hogwarts Legacy wo man das schön sehen konnte
Dort haben sie keine 8 GB AMD Karte gegen getestet weil es in der Klasse keine gibt daher kann man die Aussage nicht machen.

[Ex3cut3r]

Nvidia ist "effizienter" weil der Treiber bei Speichermangel von sich aus die Texturqualität senkt um VRAM zu sparen. AMD macht das "bisher" nicht.
HWUB hatte da mal ein Vid mit ner 3070 und Hogwarts Legacy wo man das schön sehen konnte

Afaik nein. Das war damals ein Vergleich mit der 3070 8GB vs einer AMD GPU mit 12 oder 16GB. Da langten 8GB mit Max Details hinten und vorne nicht. Sodass dann die Engine sich entschließt, da verringere ich eben die allgemeine Texturen Qualität, wenn der Speicher nicht da ist.

[aufkrawall]

Ja, Texturmatsch kanns natürlich auch auf Radeon mit zu wenig VRAM geben.
Wenigstens stirbt auf einer 6700 XT ohne rBAR die Performance nicht so arg wie auf einer B580...

[Lurtz]

Wie soll das auch gehen? Die GPU weiß doch nicht welche Textur sie wie behandeln muss, damit noch ein einigermaßen konsistenter Eindruck entsteht?

[Dino-Fossil]

Eine 9070 GRE 12 GB wäre ein durchaus interessantes Update für meine 6700 10 GB, aber die kam damals für eine UVP von ca 400€ und war dann nach nicht all zu langer Zeit für knapp über 300 zu haben. Bei N48 sehe ich das leider aktuell nicht...

[Raff]

Und PCGH testet Radeons mit rBar Off? Kann ich mir kaum vorstellen. Das Problem bei Geforces ist, dass der Treiber je nach Game automatisch rBar deaktiviert weil es damit auf Geforces immer wieder mal Probleme gibt. Insofern sind sämtliche Tests völlig intransparent bei diesem Thema. Dadurch kommen dann solche Gerüchte @Speichermanagement.

Das sind keine Gerüchte, sondern (im Falle der PCGH-Messreihen (https://www.pcgameshardware.de/Nvidia-Geforce-Grafikkarte-255598/Specials/8-vs-16-GByte-Speicher-Test-RTX-4060-Ti-1467834/)) aufwendige Tatsachenbeschreibungen dessen, was die Grafikkarten im Auslieferungszustand leisten. Woher das nun im Detail kommt, spielt erst mal keine Rolle. Doch eines bleibt: 8 GiByte auf einer Geforce "reichen" länger als 8 GiByte auf einer Arc oder Radeon. Ich weiß, dass du (aus mir unerklärlichen Gründen) ungern PCGH-Inhalte konsumierst, aber in diesem und vielen anderen Fällen lege ich dir das ans Herz. Es ist immer gut, wenn man einsieht, dass man viele Dinge nicht weiß, obwohl man das glaubt. Dafür gibt es verrückte Leute, die jeden Tag nichts anderes machen und daher tatsächlich so etwas wie Wissen - oder zumindest fundierte Erfahrung - haben. :)

Nvidia ist "effizienter" weil der Treiber bei Speichermangel von sich aus die Texturqualität senkt um VRAM zu sparen. AMD macht das "bisher" nicht.
HWUB hatte da mal ein Vid mit ner 3070 und Hogwarts Legacy wo man das schön sehen konnte

Das ist übrigens nicht korrekt, weder damals noch heute. Die Streaming-System einiger Spiele reduzieren auf jeder Grafikkarte Oberflächendetails, wenn die VRAM-Kacke am Dampfen ist. Siehe den Link oben, der zu zwei aktuellen Artikeln und Videos führt. :)

Ja, Texturmatsch kanns natürlich auch auf Radeon mit zu wenig VRAM geben.
Wenigstens stirbt auf einer 6700 XT ohne rBAR die Performance nicht so arg wie auf einer B580...

Jo. Das Verhalten von Battlemage ist wirklich kurios. Da wirkt es im VRAM-Grenzbereich oft, als wäre der Treiber immer noch nicht fertig.

MfG
Raff

[Slipknot79]

Man möge mich korregieren.


K, korrigieren. (y)

[dargo]

Das sind keine Gerüchte, sondern (im Falle der PCGH-Messreihen (https://www.pcgameshardware.de/Nvidia-Geforce-Grafikkarte-255598/Specials/8-vs-16-GByte-Speicher-Test-RTX-4060-Ti-1467834/)) aufwendige Tatsachenbeschreibungen dessen, was die Grafikkarten im Auslieferungszustand leisten. Woher das nun im Detail kommt, spielt erst mal keine Rolle.

Und sowas kommt von sogenannten "Profis". xD Jeder weiß, dass rBAR mehr VRAM in Anspruch nimmt (was kein Wunder ist, schließlich sollen Zugriffe zwischen CPU und GPU dadurch eingespart werden), die PCGH offenbar nicht. Oder verschweigt es aus welchen Gründen auch immer und schnürt sich dann nicht nachvollziehbare Schlussfolgerungen bezüglich Speichermanagement zusammen. Aber keine Sorge... CB macht das gleiche. Ernst gemeinte Frage... habt ihr im Spiel XY überhaupt schon mal AMD und NV mit rBAR Off verglichen?

Edit:
Im Prinzip ist es ganz einfach. Bei Grakas mit knappen VRAM sollte man rBAR deaktivieren wenn man nicht unbedingt upgraden oder diverse Grafikoptionen die den VRAM belegen reduzieren möchte. Völlig egal ob NV oder AMD. Sowas erwarte ich von Redaktionen als Tipps an die Spieler da draußen. Natürlich kann es passieren, dass rBAR Off trotzdem keine Besserung bringt. Je nachdem halt wieviel VRAM fehlt. Paar Hundert MB werden mit rBAR Off jedenfalls frei was hier und da den Arsc. retten kann.

[basix]

Nvidia bricht später ein als AMD, OK. Dafür hat man oftmals weniger glatte Frametimes, auch wenn genug VRAM da ist. Zumindest ist das mein Eindruck. TLOU-P2 ist da ein Extrembeispiel.

Ich habe dort stark den Eindruck, dass das an Nvidias aggressiveren VRAM-Management liegt. Das senkt den VRAM-Bedarf aber verschlechtert auch die Frametimes, wenn mal etwas zu viel aus dem VRAM geworfen wurde. Ob wirklich das die Ursache ist weiss ich nicht (ist schwierig zu überprüfen), aber es wäre irgendwie schlüssig. Nvidias Treiber und die höhere CPU-Belastung könnte ein weiterer Grund dafür sein.

AMD sollte HBCC wieder einführen, das hatte in einigen Spielen gute Vorteile gebracht. Heute könnte das sogar noch effektiver sein, da man relativ gesehen schneller "nachladen" kann:
- Vega 64 = 480 GByte/s
- Vega 64 = 8GByte
- RX 9070 XT = 640 GByte/s -> 1.33x
- RX 9070 XT = 16 GByte -> 2x
- PCIe 3.0 x16 = 16 GByte/s
- PCIe 5.0 x16 = 64 GByte/s -> 4x

[Shaft]

K, korrigieren. (y)


Danke.

[Ex3cut3r]

AMD sollte HBCC wieder einführen, das hatte in einigen Spielen gute Vorteile gebracht. Heute könnte das sogar noch effektiver sein, da man relativ gesehen schneller "nachladen" kann:
- Vega 64 = 480 GByte/s
- Vega 64 = 8GByte
- RX 9070 XT = 640 GByte/s -> 1.33x
- RX 9070 XT = 16 GByte -> 2x
- PCIe 3.0 x16 = 16 GByte/s
- PCIe 5.0 x16 = 64 GByte/s -> 4x

Gibt mittlerweile "Sampler Feedback" hier spart man z.B. bei HL2 RTX

4-6GB wenn ON.

https://youtu.be/NfgJJbtfjs8?t=16

Es ist leider sehr schade, dass es immer so lange dauert, bis neue Tech auch wirklich bei den DEVs und den Spielen ankommt.

[Raff]

Und sowas kommt von sogenannten "Profis". xD Jeder weiß, dass rBAR mehr VRAM in Anspruch nimmt (was kein Wunder ist, schließlich sollen Zugriffe zwischen CPU und GPU dadurch eingespart werden), die PCGH offenbar nicht. Oder verschweigt es aus welchen Gründen auch immer und schnürt sich dann nicht nachvollziehbare Schlussfolgerungen bezüglich Speichermanagement zusammen. Aber keine Sorge... CB macht das gleiche. Ernst gemeinte Frage... habt ihr im Spiel XY überhaupt schon mal AMD und NV mit rBAR Off verglichen?

Edit:
Im Prinzip ist es ganz einfach. Bei Grakas mit knappen VRAM sollte man rBAR deaktivieren wenn man nicht unbedingt upgraden oder diverse Grafikoptionen die den VRAM belegen reduzieren möchte. Völlig egal ob NV oder AMD. Sowas erwarte ich von Redaktionen als Tipps an die Spieler da draußen. Natürlich kann es passieren, dass rBAR Off trotzdem keine Besserung bringt. Je nachdem halt wieviel VRAM fehlt. Paar Hundert MB werden mit rBAR Off jedenfalls frei was hier und da den Arsc. retten kann.

Yep, die PCGH hat keine Ahnung. Die stochern tage-, teils wochenlang im Nebel und präsentieren stichhaltige, vergleichbare Benchmarks mit Werkseinstellungen, anstatt einfach zu wissen bzw. Dinge passend zu biegen. Was für Anfänger. :biggrin: Warum versuche ich eigentlich immer wieder, mit dir zu diskutieren? Sogar bei TLOUP2 schreibst du das Gleiche wie PCGH, aber öffentlich zustimmen würdest du trotzdem nicht. ;)

MfG
Raff

[dargo]

Yep, die PCGH hat keine Ahnung.
Wenn du meinst.... sie vergleicht halt in diesem Fall Äpfel mit Birnen. Werkseinstellungen sind manchmal eben Äpfel/Birnen Vergleiche.

[Ex3cut3r]

rBar bringt auf Nvidia Karten aber in der Tat selten einen Performance Gain und Standard ist es eben in 94% der Spiele eh aus. Bzw. hat gar kein Profil dafür.

Von daher absolut legitim, dass Raff den Ist zustand testet. Warum sollte ich rBar Global im Inspector anschalten, wenn es nichts bringt und nur VRAM frisst? :D

Bei AMD ist das anders, dort ist eh immer an Global und es bringt auch meistens sehr gute Gains.

[][immy]

Gibt mittlerweile "Sampler Feedback" hier spart man z.B. bei HL2 RTX

4-6GB wenn ON.

https://youtu.be/NfgJJbtfjs8?t=16

Es ist leider sehr schade, dass es immer so lange dauert, bis neue Tech auch wirklich bei den DEVs und den Spielen ankommt.

Ja, das ist schon interessant. Wobei ich mir aber gut vorstellen kann, das das vor allem bei älteren Titeln deutlich einfacher umzusetzen ist, als bei Titeln mit deutlich mehr Details. HL2 ist ja nun schon etwas älter.

Aber etwas unschön das solche Techniken so vernachlässigt werden. Aber ist auch klar warum. Solange man die Technik nicht braucht kostet es nur Zeit und die Grafik verbessert sich dadurch ja erst mal nicht. Es stehen am ende nur mehr Ressourcen zur Verfügung.
Da sehe ich nur sehr wenige studios, die sich überhaupt mit Optimierung auf der Ebene beschäftigen. Bin mir nicht mal sicher ob die id engine das inzwischen beherrscht. Und die sind ja neuerdings deutlich näher an MS dran.

[dargo]

rBar bringt auf Nvidia Karten aber in der Tat selten einen Performance Gain und Standard ist es eben in 94% der Spiele eh aus. Bzw. hat gar kein Profil dafür.

Von daher absolut legitim, dass Raff den Ist zustand testet. Warum sollte ich rBar Global im Inspector anschalten, wenn es nichts bringt und nur VRAM frisst? :D

Niemand kritisiert hier, dass die PCGH im Werkszustand testet! Ich kritisiere ledeglich, dass die PCGH dann davon falsche Schlüsse zieht bezüglich "effizienteres" Speichermanagement bei Nvidia weil eben NV im Treiber öfter rBAR deaktiviert. Und wo habe ich geschrieben du bzw. die Geforce User allgemein sollen rBAR manuell aktivieren? Mal weniger reindichten als ich geschrieben habe!

[Zossel]

Dynamic Register Allocation on AMD's RDNA 4 GPU Architecture (https://chipsandcheese.com/p/dynamic-register-allocation-on-amds)

[GerryB]

Dynamic Register Allocation on AMD's RDNA 4 GPU Architecture (https://chipsandcheese.com/p/dynamic-register-allocation-on-amds)
nice findings

Bin mal gespannt, wieviele Dev´s das dann beachten.
Ist das auf der PS5pro auch schon so?

[basix]

Gibt mittlerweile "Sampler Feedback" hier spart man z.B. bei HL2 RTX

SFS ist ein sehr nützliches Feature, sicher. HBCC ist hier allerdings etwas anders gelagert:
- Nützt auch bei Spielen ohne SFS
- Ist ergänzend / parallel zu SFS. HBCC kann auch ausserhalb von Texturen wirken.

Eine UE5 wird vermutlich nur begrenzt von HBCC profitieren können, da dort bereits sehr feingranular alles gestreamt oder on-the-fly gebuildet wird. Bei anderen Engines dürfte HBCC schon nützlich sein. Ich kann mir gut vorstellen, dass eine 8GB + HBCC Karte erst später zu Problemen führt als es heute bei einer 8GB Nvidia Karte der Fall ist.

[Raff]

GlsMt8BwqHY

:D :ugly:

MfG
Raff

[robbitop]

Schade, dass man HBCC nie auf RDNA portiert hat. Zumindest als optionales Feature.

[Achill]

Schade, dass man HBCC nie auf RDNA portiert hat. Zumindest als optionales Feature.

Es ist m.W. keine SW sondern HW, kann also in dem Sinne nicht "portiert" werden. Zwar liefen Spiele mit HBCC besser, wenn man über der VRAM Grenze lage, es gab aber trotzdem immer Lags. Darüber hinaus macht es die Architektur komplexer, weil die GPU (bzw. auch der Treiber / Shader-Compiler) mit unterschiedlichen Latenzen beim Zugriff auf VRAM (bzw. erst nachladen via HBCC) umgehen muss und auch die Auslastung vom PCIe Bus sicherlich Einfluß hat.

=> Es war sicherlich einfacher, der GPU mehr VRAM mitzugeben als pot. für viele verschiedene Spiele+Anwendungen Profile zu erstellen und pflegen.

--
Btw. War nicht DirectX Sampler Feedback mit DirectStorage Nachfolger von dem Ansatz, muss halt nur via SW umgesetzt werden?

[GerryB]

SF verwendet einen dynamischen MipMap LOD, damit die Texturen für den Hintergrund nicht soviel Platz+Bandbreite
unnötig verbrauchen.(nur so detailliert, das die Qualität nicht abnimmt, mit steigender Entfernung reicht weniger)

Da gabs schon ein Video von MS.(vor langer Zeit, ... man staune=auf der XBox)

Ob nun die Texturen für das Game in unterschiedlichen Größen/Resis auf der NVMe vorliegen müssen, oder von der GPU selbst
runtergerechnet werden, who knows.
Wenn das Game ne Textur für ne Entfernung Z anfordert, müsste also der Treiber selbst entscheiden, wie hoch die Textur
aufgelöst sein muss.(braucht nicht 4k-texturen vorhalten)

[dildo4u]

Paar Preis Spekulationen 9600XT 16GB maximal 380$ 9700GRE 450$.

xFrb-lmhyP0

[Iscaran]

9060 XT mit 16 GB für 380 $ => *0.88*1.19 => ~400€...klingt recht vernünftig.

350€ wären mir noch lieber aber insgesamt könnte das endlich was für ein Upgrade werden. Solange es mind. x2 bis x3 RX6600 ist.

Vor allem die 16 GB klingen hier gut. 8 GB kommen mir definitiv nicht mehr ins Haus, aber 12 GB hat schon wieder eher was von "Übergangslösung"...

[Der_Korken]

Finde die Meldung passt besser hier rein als in den Review-Thread: Hardware-Bug in N48 bezüglich Hierachical-Z (https://www.phoronix.com/news/RADV-Workaround-HiZ-RDNA4)

Hab von der Materie nicht genug Ahnung, um da was zur Performance rauszulesen. Bisher hatte ich davon nichts mitbekommen.

[raffa]

Da steht aber auch
"It turns out the RadeonSI Gallium3D driver and AMD PAL code for AMDVLK already have a similar workaround in place for the buggy HiZ/HiS on RDNA4 GPUs."

Computerbase hat an Linux Test gemacht, und unter andrem amdvlk 2025.Q1.3 mit mesa 25.0.1 (ohne diesen und andre fixes), und da sieht man schon, das radv noch nicht rund läuft auf rdna4:
https://www.computerbase.de/artikel/grafikkarten/amd-radeon-rx-9070-xt-linux-test.91853/

[davidzo]

350€ wären mir noch lieber aber insgesamt könnte das endlich was für ein Upgrade werden. Solange es mind. x2 bis x3 RX6600 ist.

2x - 3x ist Wunschdenken. Realistisch eher 1.8x

Doppelt so schnell wie die RX6600 sind 6800xt oder RTX4070. Da wird man mit 32CU nicht heran kommen. Wenn man auf 7700Xt / RX6800 Level kommt wäre das schon eine außerordentliche Leistung.

Der Chip soll nur 152mm2 groß sein. Mit gewöhnlichem GDDR6 kann AMD die 8GB version und den Cutdown als 9050 verramschen. Mit etwas Glück wird die 9060XT hochgezüchtet sein um nvidias 5060ti zu bedrängen, aber darunter würde die Effizienz nicht wenig leiden. Wahrscheinlicher ist dass AMD nicht groß binned und stattdessen einen soliden RTX5060 counter bringt mit biszu 10% mehr Performance und dem Speicherausbau einer teureren 5060ti 16G.

[basix]

7700XT Niveau wäre ziemlich ordentlich, ja. 6800XT sogar sehr gut.

Die 152mm2 sind aber vermutlich falsch. Oder woher hast du den Wert? N48 ist ja deutlich grösser geworden als es lange in der Gerüchteküche so geheissen hat. Ich lasse mich gerne überraschen aber selbst 50% von N48 wäre aussergewöhlich klein.

[basix]

Angeblich 3.2 GHz Boost auf der RX 9060 XT mit N44:
https://videocardz.com/newz/amd-radeon-rx-9060-xt-features-2048-cores-boost-clock-of-3-2-ghz
[...]the RX 9060 XT will ship with a 2620 MHz game clock and a 3230 MHz Boost clock.

Das wäre ziemlich genau +10% auf eine 9070 XT. Also stark geprügelt. Wer wettet mit? 180W?

[Nakai]

Wird eher bei ~200mm² liegen, vielleicht ein Stück drunter. Viele Blöcke innerhalb der GPU braucht es hald immer.

[prinz_valium_2]

9070GRE mit 3.3GHz wäre bestimmt eine feine Karte

[Iscaran]

2x - 3x ist Wunschdenken. Realistisch eher 1.8x


Hmmm, das seh ich etwas optimistischer als du.

Eine 6600 hat 134% im Index.

x2 wären ~268%. Schon eine 7700 XT hat 285%

https://www.computerbase.de/news/grafikkarten/radeon-rx-9060-xt-mehr-details-zum-gegner-der-nvidia-geforce-rtx-5060-ti.92190/
Laut CB taktet eine potentiell 9060 XT recht hoch.
Eien 9070 XT hat ~ 1.8x mal so viel (Papier)-Rechnenleistung
Eine 9070 immerhin noch ~1.4x mal so viel

Von 9070 XT ~500% /1.8 = 278%
von 9070 ~440% / 1.4 = 314%

Ich würde mal schon die Prognose wagen, dass die 9060 XT (16 GB) damit durchaus im Bereich 7700 XT (oder etwas darüber landen dürfte)

Das wären dann auf jeden Fall >x2 bis hin zu x2.35 (unrealistisch)

Aber so im Bereich 280-290% würde ich die 9060 XT schon sehen.

[Der_Korken]

Angeblich 3.2 GHz Boost auf der RX 9060 XT mit N44:
https://videocardz.com/newz/amd-radeon-rx-9060-xt-features-2048-cores-boost-clock-of-3-2-ghz


Das wäre ziemlich genau +10% auf eine 9070 XT. Also stark geprügelt. Wer wettet mit? 180W?

180W könnten schon hinkommen. Das sind Taktbereiche, die nur die 340W-Modelle (bei der 9070XT) erreichen, wenn man denen noch +10% PT gibt. Ohne UV natürlich, stock V/f-Kurve. Geteilt durch 2 ist man bei 180-190W. Gegen die 9070 wird die Effizienz absolut meh sein.

[basix]

Die 7600 XT lag auch bei bereits 190W.

[raffa]

Die RX 6600 war halt top effizient, ~130W Boardpower. Mit etwas UV und leicht gedeckeltem Takt ein Traum in dieser hinsicht.

Ich will Faktor 2, auch bei der Effizienz. Das könnte drin sein. Mit einer 9070 ists jedenfalls drin. : )

3dcenter 4k index:
9070: 440% 220W
6600: 134% 132W

Milchmädchen sagt dazu: (440/220)/(134/132)=1,97

[gedi]

2048 Recheneinheiten, 128-Bit bei GDDR6. Was wird das? Ich sehe die 9060xt deutlich hinter einer 5060ti. Ich hoffe auf ein 350€-Produkt für die 16GB-Version und 280€ für die 8GB ...

[raffa]

Das wird man sehen, irgendwie glaub ich nach den 9070ern nicht dass AMD die 60er verkackt.

Die 16G könnte der geistige Nachfolger der 6600(XT) werden.

Und FSR4 wird dazu beitragen, dass man gut mit der kleinen Karte auskommt, denn wenn man bedenkenlos upscalen kann, fällt die Auflösungschwäche weniger ins Gewicht.

[GerryB]

der hohe Takt sieht eher aus wie geistiger Nachfolger der 6650/6750xt = hochgeprügelt

Bei dem hohen Takt + kleinen Fläche, bin ich mal auf die Temps gespannt.

[raffa]

true, true.

Die Leute scheinen sich ziemlich wenig zu stören an zu hoch geprügelten Chips, und wenn die Dinger idle und teillasteffizient sind wie die 70er und sich zudem ähnlich gut sparsam machen lassen und dann auch noch der Preis stimmt, why not.

180W, -55mV, -20% PT = feine 144W Karte.

@gedi: Spannend ists freilich schon, wie gut das Ding rennt bei 128-Bit bei GDDR6 und 2048 Kernen

[Oranje7]

Das Prügeln des Chips bekommt man ja schon in den Griff, indem man im Treiber das PT einfach mit einem Klick reduziert.
Gefühlt ist nicht mehr das übertakten das Ding sondern die Hardware Sparsamer zu machen

[basix]

RDNA4 Raytracing Verbesserungen:
https://chipsandcheese.com/p/rdna-4s-raytracing-improvements

[GerryB]

https://www.techpowerup.com/335842/amd-readies-radeon-rx-9060-xt-for-may-18-launch

[davidzo]

Die 152mm2 sind aber vermutlich falsch. Oder woher hast du den Wert? N48 ist ja deutlich grösser geworden als es lange in der Gerüchteküche so geheissen hat. Ich lasse mich gerne überraschen aber selbst 50% von N48 wäre aussergewöhlich klein.

Angeblich fehlen die Media engines und wer weiß vielleicht hat AMD sogar bei den Display engines gekürzt. Aber ja, GB206 ist auch 181mm2, da muss AMD nicht wesentlich kleiner werden um günstiger zu sein. Man hat ja noch den GDDR6 Preisvorteil.



Von 9070 XT ~500% /1.8 = 278%
von 9070 ~440% / 1.4 = 314%

Ich würde mal schon die Prognose wagen, dass die 9060 XT (16 GB) damit durchaus im Bereich 7700 XT (oder etwas darüber landen dürfte)

Das wären dann auf jeden Fall >x2 bis hin zu x2.35 (unrealistisch)

Aber so im Bereich 280-290% würde ich die 9060 XT schon sehen.
Das ist jetzt Haarspalterei. Auf die 268% bin ich auch gekommen, aber da wusste ich noch nichts vom höheren Takt.
Der Vergleich zur 9070 hinkt, da jene die gleiche Bandbreite wie die XT zur Verfügung hat.

Der halbierte IFcache und das lediglich 128bit große Interface wird bei der 9060XT schon reinschlagen in 4K. Da hilft dann auch der hohe Takt nicht mehr aus.
Ich bleibe dabei, wenn sie die 7700XT bei 285% erreicht wäre das gut. Mehr Leistung vielleicht in 1080p, aber nicht in 4K, denn dazu fehlt einfach die Bandbreite.

Das würde trotzdem reichen um die 5060ti ernsthaft zu bedrohen, insbesondere die 8Gb Version und um die Vanilla 5060 vermutlich klar zu schlagen.

Auch dass die bereits vorbereitete 9070GRE jetzt erstmal doch nicht kommt spricht dafür dass AMD entschieden hat dass man die nicht braucht um Nvidia ordentlich zu ärgern.

Netter Move von AMD auf 3,2Ghz zu gehen wo sie doch wissen dass Nvidia mit Blackwell taktmäßig nicht mithalten kann. Sinnvoller wäre die Karte für den Nutzer sicherlich bei 2,8Ghz Boosttakt und mit 140Watt. Aber das lässt sich ja nachträglich einstellen.

der hohe Takt sieht eher aus wie geistiger Nachfolger der 6650/6750xt = hochgeprügelt

Bei dem hohen Takt + kleinen Fläche, bin ich mal auf die Temps gespannt.
Temps werden kein Problem da die meisten Karten eh wieder 300mm lange triplefan karten werden wo anderthalb bis zwei lüfter flow through sind. Moderne Midrange Karten haben heutzutage die Highendkühler von gestern minus ein-zwei Heatpipes und mehr Plastik bei der Fanshroud.
Sieht man ja bei GB206 auch dass die Kühlung bei son einer Auslegung kein Problem mehr ist.

[basix]

2048 Recheneinheiten, 128-Bit bei GDDR6. Was wird das? Ich sehe die 9060xt deutlich hinter einer 5060ti. Ich hoffe auf ein 350€-Produkt für die 16GB-Version und 280€ für die 8GB ...

Was heisst deutlich? 10% langsamer? Das wäre 10% schneller als eine 4060 Ti, was auch mit GDDR6 drin liegt (9060XT = 20Gbps; 4060 Ti = 18Gbps).

350 Euro wäre schön. Ich vermute 370 Euro. Wäre 1.1x P/L verglichen zur ~10% schnelleren 5060 Ti. Nicht mega geil aber immerhin. Wenn AMD es mit Marktanteilen ernst meint, sollten sie allerdings 350 Euro ansetzen, ja.

Die 8GB Variante kann AMD von mir aus sein lassen ;) Die sollten lieber eine 9060 non-XT mit 12GByte rausbringen (96bit, 28CU, etwas geringerer Takt wie die 9070 und somit sehr effizient). Das Ding ist dann zwar auch mit 20Gbps leicht bandbreitenlimitiert, aber die 12GB würden für ein 299 Euro Produkt sehr schön passen.

Angeblich fehlen angeblich die Media engines und wer weiß vielleicht hat AMD sogar bei den Display engines gekürzt. Aber ja, GB206 ist auch 181mm2, da muss AMD nicht wesentlich kleiner werden um günstiger zu sein. Man hat ja noch den GDDR6 Preisvorteil.

AMD hat sicher gestutzt. Ich erwarte ~50% N48 oder ziemlich exakt GB206 Die Size. Aber nicht 150mm2.

[GerryB]

Temps werden kein Problem da die meisten Karten eh wieder 300mm lange triplefan karten werden
große Kühler allein lösen aber nicht das Hotspotproblem

btw.
NV als Vorbild anzuführen ist wertlos, weil dort der Hotspot gar nicht angezeigt werden darf.

[davidzo]

große Kühler allein lösen aber nicht das Hotspotproblem

btw.
NV als Vorbild anzuführen ist wertlos, weil dort der Hotspot gar nicht angezeigt werden darf.

Jein. Große Kühler helfen schon das abzumindern. Es handelt sich ja immer noch um eine Kette von Temperaturwiderständen. Wenn ich da ganz am Ende einen Widerstand verkleinere, dann ändert sich der Widerstand am Anfang der Kette zwar nicht, aber das Ganze bewegt bewegt sich in einen weniger problematischen Bereich.

Beispiel: Ein Hotspot der +25° höher liegt als die Average Die Temperatur ist dann ein Problem wenn die Average Temp über 80°C liegt. Wenn sie bei 55-60 dümpelt, dann ist das weniger ein Problem.

[GerryB]

Du bist noch gedanklich bei alten Gens mit großen Chips oder low Power Settings.

mit PL+10 gehts schnell über 30°Delta bei der 9070xt(x)
ne 9060XT soll evtl. auch >3100 takten, wäre damit in dem Bereich

(x) aktuelles Bsp. aus dem Luxx siehe Anhang

[basix]

Wunsch für die 9060 XT und 9060 mit N44:
- 32 CU // 28 CU
- 3.2 GHz // 2.7 GHz
- 128bit // 96bit
- 16 GByte // 12GByte
- 20 Gbps // 20 Gbps

[Hakim]

Irgendwie habe ich die Befürchtung das der Abstand zum N48 zu groß wird mit 9060, die 9070 GRE würde es ja dann machen, aber soll ja angeblich erst Q4 kommen

[davidzo]

Du bist noch gedanklich bei alten Gens mit großen Chips oder low Power Settings.

mit PL+10 gehts schnell über 30°Delta bei der 9070xt(x)
ne 9060XT soll evtl. auch >3100 takten, wäre damit in dem Bereich

(x) aktuelles Bsp. aus dem Luxx siehe Anhang

Okay, dann halt 35°C Delta. Ändert nichts an der Sache dass ein Delta ausgehend von 55°C akzeptabler ist als eines welches von 70 oder 80Grad ausgeht. Viel hilft viel ist zwar nicht Materialeffektiv, aber bringt trotzdem was bei der Kühlung. Ryzen 7000 lief ja auch sehr heiß und trotzdem hat man nicht gesagt "nimm nen kleineren Kühler, ist eh egal, da das problem nicht die Abwärme in Watt ist sondern der Hotspot".

Sicherlich bringen vaporchamber und flüssigmetall bei einem kleinen Chip mehr als einfach nur ehr gesteckte Alulamellen auf längeren Heatpipes. heißt aber nicht dass Heatpipes und mehr Lamellen nichts mehr bringen. Zumal drei bis vier 8mm Heatpipes (oder 2x8 +2x6mm; 1x10 + 2x8) bei nur 180Watt auch noch nicht wirklich von Dryout bedroht sind.

[BavarianRealist]

Irgendwie habe ich die Befürchtung das der Abstand zum N48 zu groß wird mit 9060, die 9070 GRE würde es ja dann machen, aber soll ja angeblich erst Q4 kommen

Diese GRE ist meines Erachtens eher eine Ausschuss-Verwertung schlechter N48-Dice, die nicht mal für eine 9070 ausreichen. Wenn diese GRE nun verschoben wird, hoffe ich, dass die Fehlerrate der N48 nun geringer ausfällt, als ursprünglich erwartet, sodass man abwarten könnte, bis genug Ausschuss an N48-Dice hierfür angefallen sind.

[DozerDave]

Ich glaube, dass die 9070GRE eher das 5070-non-TI Konkurrenzprodukt sein soll.
Leider ist die 9070-non-XT noch zu teuer.

[GerryB]

die nonXT swift ist ein Riesenprügel und auch die 649€ wert
3x90er für 220W reicht

[DozerDave]

Du hast mich nicht verstanden.
AMD muss zum gleichen Preis das bessere Produkt bieten (mehr VRAM oder Leistung) oder deutlich günstiger werden (9060) um langfristig Marktanteile zu gewinnen.

[GerryB]

NEIN
Die Leistung+Effizienz der 16GB-9070nonXT passt bereits.(ggü. ner 12GB-5070)
Wem´s nicht reicht, der hatte soundso nicht vor bei red zu kaufen.

Spekus zur 9060nonXT gehen momentan eeh von <5060 aus.
JA, da gehts nur über den Preis.
mal sehen, ob AMD am 18. auch was zu der Kleinen 8GB sagt
normalerweise <12GB-B580 vom Preis her

Insgesamt verstehe ich nicht, wenn Du auf die 9060nonXT wartest, warum Dich der Preis der viel größeren 9070nonXT
stört.(da fehlt jeder Zusammenhang)

[DozerDave]

Wo habe ich geschrieben, dass ich auf die 9060 non-XT warte?

Wenn AMD die 9060 XT günstiger und nur als 16 GB Variante auf den Markt bringt, verschieben sich hoffentlich mal die Marktanteile:
gUWS8JPG91M

Es muss endlich bei den Konsumenten ankommen, dass AMD eine echte Alternative zu NVIDIA ist, vorausgesetzt die Hardware ist gut und die Treiber sind stabil.
Das gilt für 9060 und 9070.

[GerryB]

Wo habe ich geschrieben, dass ich auf die 9060 non-XT warte?

oder deutlich günstiger werden (9060)

Schreib einfach mal, was Dich tatsächlich(x) interessiert, statt AMD irgendwelche Ratschläge zugeben.

(x) Preisrange und Fps in Game XYZ @Resi
bitte konkret benennen

[DozerDave]

Nö, ist ja hier der Speku-Thread.

[dildo4u]

NEIN
Die Leistung+Effizienz der 16GB-9070nonXT passt bereits.(ggü. ner 12GB-5070)
Wem´s nicht reicht, der hatte soundso nicht vor bei red zu kaufen.

Spekus zur 9060nonXT gehen momentan eeh von <5060 aus.
JA, da gehts nur über den Preis.
mal sehen, ob AMD am 18. auch was zu der Kleinen 8GB sagt
normalerweise <12GB-B580 vom Preis her

Insgesamt verstehe ich nicht, wenn Du auf die 9060nonXT wartest, warum Dich der Preis der viel größeren 9070nonXT
stört.(da fehlt jeder Zusammenhang)
AMD ist zu teuer der ganze Punkt der Karten ist das GDDR6 Preisvorteile bringen soll.

https://www.pcgameshardware.de/Radeon-RX-9070-XT-Grafikkarte-281023/News/Preisvergleich-mit-Geforce-RTX-5070-und-Ti-1471242/

[GerryB]

What?
16GB bei der 9070 statt 12GB bei der 5070 sind kein Deal?

btw.
Was preislich möglich ist, wird man dann bei der GRE sehen.
12GB vs. 12GB
wobei AMD deutlich höhere Kosten durch den großen Chip hat
Vramkosten alleine sind nicht Alles!

[dildo4u]

Das hatte schon die 7800XT und die war billiger als die 4070.
9700 kostet deutlich mehr als 5070.

[w0mbat]

:ugly:

[GerryB]

9700 kostet deutlich mehr als 5070.
geb Dir bitte mal etwas mehr Mühe, ... 9070 statt 9700 darf man ruhig hinschreiben

die 9070 ist aber auch ein ganzes Mue schneller+effizienter, ... Preis passt
die 5070 ist DOA, ... Punkt!

[dildo4u]

geb Dir bitte mal etwas mehr Mühe, ... 9070 statt 9700 darf man ruhig hinschreiben

die 9070 ist aber auch ein ganzes Mue schneller+effizienter, ... Preis passt
die 5070 ist DOA, ... Punkt!

Die 9070XT hat bessere Preis Leistung das ist das selbe Spiel wie es AMD immer macht bei NV ist der Abstand von 5070 zu TI viel größer.

https://youtu.be/gWIIA-a9Q9A?si=E-6sO_MGO7o0UPRp&t=765

[DrFreaK666]

Das hatte schon die 7800XT und die war billiger als die 4070.
9700 kostet deutlich mehr als 5070.

Die 9070 kostet 10% mehr, hat laut CB +6% mehr Performance und +33% mehr RAM.
Sehe nicht, dass die 9070 im Vergleich teurer ist, "kostet deutlich mehr" schon gar nicht

[dildo4u]

Die Taktik ist klar aktuell will AMD natürlich nur das teure Modell verkaufen bei Nvidia nutzt die 5070 ein kleinern Chip und weniger Vram.
Der AMD Chip ist von der Größe eher bei der 5080 was erklärt warum sich nicht unter 600€ fallen.

[Palpatin]

Gerade mal ein wenig über den Teich geschaut. Kann es sein das beide Karten in den USA nur weit über dem UVP erhältlich sind. Günstigste 5070 die gefunden hab 670$ und günstigste 9070 750$.

[GerryB]

Die 9070XT hat bessere Preis Leistung das ist das selbe Spiel wie es AMD immer macht bei NV ist der Abstand von 5070 zu TI viel größer.
die XT macht nur für 4k Sinn, darunter reicht auch ne nonXT
749€ vs 649€ sind >15% mehr, ... sicherlich nicht so easy bei gleichen Watt erzielbar

Die nonXT lässt sich auch OCen.(100€ gespart)
siehe Anhang

Falls Jemand mal ne 9070xt auf 233W runterregeln könnte, bitte gegentesten.
Interessanterweise ist der TSE-GT1 gar nicht so sehr im PL, sieht man an der 5070 OC,
bleibt trotz mehr Watt unter ferner liefen.

[Prinzenrolle]

die 9070 ist aber auch ein ganzes Mue schneller+effizienter, ... Preis passt
die 5070 ist DOA, ... Punkt!

Solche Diskussionen sind immer wieder lustig mitanzusehen.
Nein, du musst AMD kaufen, nein du musst Nvidia kaufen, anstatt wie seit 20 Jahren Vor- und Nachteile zu sehen, werden Kirschen gepickt.
Ergibt genauso viel Sinn eine 5070 zu kaufen wie eine 9070.

[GerryB]

Stagnation = sinnvoll ?
Oder werden Deine Monis immer kleiner?

Nach m.E. werden 6800/6900-Besitzer nicht auf 12GB wechseln.
Im Prinzip tuen sich selbst manche 7900-Besitzer schwer damit,
obwohl N48 durch hervoragende minFps glänzt.

btw.
Es soll wohl keine 9060xt-8GB geben.
(passend dazu)

[gedi]

Hab ich auch gelesen, gehe allerdings nur vom Retail-Markt aus. In Fertigrechnern werden sich wahrscheinlich auch manch 8GB-Modelle tummeln.

[G3cko]

die XT macht nur für 4k Sinn, darunter reicht auch ne nonXT


Das ist immer die dämlichste Aussage überhaupt. Das entscheidet die Software und vor allem wie lange du die Karte nutzen willst.

15-20% hin oder her ist vollkommen egal. Ob du heute eine GTX1080Ti oder Vega64 im Rechner hast. Beides mittlerweile lahm. Wenn die non-XT an ihre Grenzen stößt, dann wird es der XT nicht anders ergehen.

[dildo4u]

Angebliche 9070 GRE Performance ziemlich schwach hoffentlich unter 500€.


https://videocardz.com/newz/amd-launches-radeon-rx-9070-gre-in-china-officially-6-faster-than-rx-7900-gre

[GerryB]

Das ist immer die dämlichste Aussage überhaupt. Das entscheidet die Software und vor allem wie lange du die Karte nutzen willst. ...
Ob du heute eine GTX1080Ti oder Vega64 im Rechner hast. ...

Dein Vgl. ist aber auch schon krass, ... mit 8 Jahre alter Hardware.

Die Meisten werden wohl nach 4,5 Jahren wechseln.
(aufgrund von neuen Features)

649€ für die 9070nonXT sind dann gerademal 12€/Monat.
abzgl. Wiederverkaufswert der alten Graka = <7€/Monat
(6700xt abgeben für 249€)

[Dino-Fossil]

Etwas schneller als 7900GRE ist ziemlich genau die erwartbare Performance.

[raffa]

Ob man sich ne 9070 XT oder eine 9070 holt, ist auch eine Entscheidung, ob man sich ne 300W oder lieber ne 220W Gpu in den Rechner packen will. Ich tendiere da zu letzterem.

[GerryB]

btw.
Die 220W für die GRE klingen ziemlich hoch gegriffen, ... Custom?
MBA dann 190W

[basix]

220W werden auf der AMD Seite genannt. Wird also schon Default sein. Und es macht schon Sinn, wenn man die 9070XT vs. non-XT vergleicht.

Nur 18 Gbps beim VRAM überaschen mich aber ein wenig. Aber man will wohl Geld sparen. Mal schauen, wie stark die Karte an der Bandbreite hängen wird.

+6% zur 7900 GRE sind mMn ziemlich gut für so wenig Bandbreite. Die 9070XT hat AMD mit +38% angegeben und die 9070 mit +20%. Die haben aber 1.49x VRAM-Bandbreite sowie 1.33x mehr L2$ & Infinity-Cache.

Die ~500 Euro in China wären ~450...460$ MSRP. Ungefähr da, wo ich es erwartet habe.

[Leonidas]

Spezifikationen der Radeon RX 9000M Serie:
https://www.3dcenter.org/news/news-des-2627-april-2025

[DrFreaK666]

... Die Meisten werden wohl nach 4,5 Jahren wechseln.
(aufgrund von neuen Features)...

Ich behaupte mal, dass es nicht so ist