Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020)

[deekey777]

...

Ein anderes Fragezeichen wäre noch, wie diese Zusammenfassung der zwei gepaarten CUs in dem "workgroup processor" genau funktioniert. Kooperation zwischen den 2 CUs erfordert vermutlich, daß sich diese zwei CUs den LDS teilen (1x128kB statt 2x64kB?). Allerdings würde ich da gerne noch mehr drüber erfahren.
Folie 18, oder? Darum auch "Dual Compute Unit" (Folie 8)? Wird auch Scalar DC und Shader IC untereinader "gesharet"? Denn Folie 10 ist anders gestaltet.

[Mandalore]

Kann jemand der die Materie gut versteht etwas in Bezug auf dieses Super SIMD Patent und RDNA sagen? Wurde dies jetzt implementiert oder nicht? Weil rein von meinem momentanen Kenntnisstand schaut es soweit eigentlich implementiert aus, sicher bin ich mir aber nicht...


Hier das Patent: http://www.freepatentsonline.com/20180121386.pdf

[Gipsel]

Folie 18, oder? Darum auch "Dual Compute Unit" (Folie 8)? Wird auch Scalar DC und Shader IC untereinader "gesharet"? Denn Folie 10 ist anders gestaltet.
Ja, auch der L1-sD$ und der L1-I$ werden zwischen den beiden gepaarten CUs geteilt. Das war bei GCN aber ähnlich (sogar unter bis zu 4 CUs geteilt). Neu wäre, daß man sich den LDS teilt, wodurch eine Workgroup auf 2 CUs aufgeteilt werden kann. Im Prinzip hätte man somit auch fast sagen können, daß Navi 10 aus 20 CUs besteht, die jeweils 4 vALUs mit 32 Lanes besitzen. Aber die TMUs werden wohl nicht geteilt (zumindest ist es nicht eingezeichnet). Das ist vermutlich fast das Einzige, was die Beschreibung als CUs mit vier 32 Lanes breiten vALUs verhindert.

================================

Kann jemand der die Materie gut versteht etwas in Bezug auf dieses Super SIMD Patent und RDNA sagen? Wurde dies jetzt implementiert oder nicht? Weil rein von meinem momentanen Kenntnisstand schaut es soweit eigentlich implementiert aus, sicher bin ich mir aber nicht...

Hier das Patent: http://www.freepatentsonline.com/20180121386.pdfNein. Weiterhin pro vALU ein Registerfile.

[Mangel76]

https://www.hardwareluxx.de/images/cdn01/DE91A5F07903413F93E9F2E7C47D7CD2/img/DEC4AAFDCE594F85B9C766C1201C999B/E3-NVIDIA-TDP-TGP_DEC4AAFDCE594F85B9C766C1201C999B.jpg

Quelle: HWLUXX (https://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/49921-nvidia-stichelt-mit-tdp-und-tgp-gegen-amd.html)

NVIDIA stichelt gegen AMD. Ich frage mich dabei aber, warum die Differenz bei NVIDIA so viel größer ist (2080 67W, bei AMD max. 45W). Außerdem gibt es bisher keine offiziellen Angaben von AMD zum GPU-only-Verbrauch.

[Locuza]

[...]
Ein anderes Fragezeichen wäre noch, wie diese Zusammenfassung der zwei gepaarten CUs in dem "workgroup processor" genau funktioniert. Kooperation zwischen den 2 CUs erfordert vermutlich, daß sich diese zwei CUs den LDS teilen (1x128kB statt 2x64kB?). Allerdings würde ich da gerne noch mehr drüber erfahren.
Da gab es einen kleinen Absatz in den Compiler-Patches für Navi, als ich vor einigen Wochen reingeschaut habe:
"In WGP mode the waves of a work-group can be executing on either CU of the WGP.
Therefore need to wait for operations to complete to ensure they are visible to waves in the other CU as the L0 is per CU.
Otherwise in CU mode and all waves of a work-group are on the same CU which shares the same L0.

The L0 cache keeps all memory operations in order for work-items in the same wavefront.

If no cross address space ordering then an LDS waitcnt is not needed as LDS operations for all waves are executed in a total global ordering as observed by all waves.
Required if also synchronizing with global/GDS memory as LDS operations could be reordered with respect to later global/GDS memory operations of the same wave."

[dargo]

https://www.hardwareluxx.de/images/cdn01/DE91A5F07903413F93E9F2E7C47D7CD2/img/DEC4AAFDCE594F85B9C766C1201C999B/E3-NVIDIA-TDP-TGP_DEC4AAFDCE594F85B9C766C1201C999B.jpg

Quelle: HWLUXX (https://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/49921-nvidia-stichelt-mit-tdp-und-tgp-gegen-amd.html)

NVIDIA stichelt gegen AMD. Ich frage mich dabei aber, warum die Differenz bei NVIDIA so viel größer ist (2080 67W, bei AMD max. 45W). Außerdem gibt es bisher keine offiziellen Angaben von AMD zum GPU-only-Verbrauch.
Die können sticheln bis sie blau werden. Fakt ist, dass zwischen RTX2060 und RX5700 nur noch 20W Unterschied liegen. Da hat AMD erstmal den Abstand von GTX1060 auf RX580 deutlich verkleinert. 20W sind in meinen Augen nichts für vergleichbare Leistungsklasse. Und bis Nvidia mit 6nm kontern kann dauert es noch lange genug.

[Ex3cut3r]

Die können sticheln bis sie blau werden. Fakt ist, dass zwischen RTX2060 und RX5700 nur noch 20W Unterschied liegen. Da hat AMD erstmal den Abstand von GTX1060 auf RX580 deutlich verkleinert. 20W sind in meinen Augen nichts für vergleichbare Leistungsklasse. Und bis Nvidia mit 6nm kontern kann dauert es noch lange genug.

Wie kommst du darauf? Ich kann nur von meiner 2080 reden, die darf out of the box 225W schlucken. IMO stimmen die TGP Angaben. Eine 260 ist vom Chip her Drei Viertel weniger als von der 2080 .Also rechne ich 65W unterschied und das trotz 12nm vs 7nm.

[w0mbat]

Les noch mal was er geschrieben hat ;)

[Mangel76]

Wie kommst du darauf? Ich kann nur von meiner 2080 reden, die darf out of the box 225W schlucken. IMO stimmen die TGP Angaben. Eine 260 ist vom Chip her Drei Viertel weniger als von der 2080 .Also rechne ich 65W unterschied und das trotz 12nm vs 7nm.

Er meint den Unterschied zwischen 5700 und 2060, der deutlich kleiner ist als der zwischen 580 und 1060. Dabei ist jedoch der Leistungsvorsprung der 5700 gegenüber der 2060 noch deutlich größer als der der 580 gegenüber der 1060.

[w0mbat]

Eine RX 590 hat auch ne TDP von 225W, Navi ist auf jeden Fall deutlich effizienter. Vielleicht passen sie nach dem Nvidia-"Super"-Konter doch noch die Preise etwas an :D

[Ex3cut3r]

Im ersten Satz meinte er/steht doch das zwischen 2060 und 5700 nur 20W Unterschied wäre, was definitiv nicht stimmt, denn 225W verbraucht meine 2080 mit Powerlimit @ 100% spricht Standard ohne was zu verändern. Eine 260 frisst nie im Leben 200W oder mehr. Die TGP Angaben stimmen da schon von Nvidia, so fair sollte man schon sein.

[w0mbat]

Les noch mal!

Die RTX 2060 hat ne TDP von 160W, die RX 5700 (non-XT!) ne TDP (TBP) von 180W. Laut AMD ist die RX 5700 ca. 10% schneller als eine RTX 2060, hat aber nur eine 20W höhere TDP (TBP). Die RX 5700 taktet eindeutlich näher am sweetspot als die RX 5700 XT, ist daher auch effizienter.

[Ex3cut3r]

Achso non XT.. ja dann hat er natürlich recht. Sry. Bin wohl durch für heute.

[dargo]

Les noch mal!

Die RTX 2060 hat ne TDP von 160W, die RX 5700 (non-XT!) ne TDP (TBP) von 180W. Laut AMD ist die RX 5700 ca. 10% schneller als eine RTX 2060, hat aber nur eine 20W höhere TDP (TBP). Die RX 5700 taktet eindeutlich näher am sweetspot als die RX 5700 XT, ist daher auch effizienter.
Eben... die 5700 scheint einen besseren Betriebspunkt zu haben.

[Digidi]

Kann man denn schon was aus den Gaming Benchmarks ableiten wo AMD schneller wurde? Bei Tombraider hat sich an der Leistung ja nichts geändert. Bei Assasins Odysee lässt wohl das bessere Frontent durchscheinen.

[w0mbat]

Eben... die 5700 scheint einen besseren Betriebspunkt zu haben.
Allein die 2GB mehr VRAM gegenüber der 2060 kosten doch schon etwas. Hat wer ne Ahnung wie viel Strom 2GB GDDR6 brauchen?

[BlacKi]

Eben... die 5700 scheint einen besseren Betriebspunkt zu haben.
praktisch gleich. gibst du der 2060 12% mehr power(180w), kann sie die 10% leistung die fehlt ausgleichen.

[dargo]

Allein die 2GB mehr VRAM gegenüber der 2060 kosten doch schon etwas. Hat wer ne Ahnung wie viel Strom 2GB GDDR6 brauchen?
Es kommt ja noch die 2060 Super mit 8GB und etwas mehr Shader. Beim Verbrauch wird das wohl ein Kopf an Kopf Rennen.

btw.
Ich bin echt gespannt ob die RX5700 noch etwas schneller als die V64 Referenz sein wird. Sollte das der Fall sein hat AMD mit Navi den Stromverbrauch praktisch bei gleicher Performance halbiert.

praktisch gleich. gibst du der 2060 12% mehr power(180w), kann sie die 10% leistung die fehlt ausgleichen.
Ich spreche vom besseren Betriebspunkt im Vergleich zur RX5700 XT. ;)

[Pirx]

kein riesiges Kunststück bei solch einer verbesserten Fertigung

[w0mbat]

Naja, TSMC non-EUV 7nm Prozess ist jetzt nicht der Mega-Hammer. So toll verbessert ist die Fertigung nicht.

[Unicous]

7nm HPC ungleich 7nm FF, das vergessen hier einige immer wieder.:rolleyes:

Mit EUV könnte das noch einmal ganz anders aussehen, also abwarten und Tee trinken.

[Ravenhearth]

btw.
Ich bin echt gespannt ob die RX5700 noch etwas schneller als die V64 Referenz sein wird. Sollte das der Fall sein hat AMD mit Navi den Stromverbrauch praktisch bei gleicher Performance halbiert.
Naja, die 5700 wird nicht mehr als max. 5% schneller sein, das reicht für die doppelte Perf/W nicht aus. Die TDP ist -40%, verrechnet mit der höchstens 5% höheren Leistung käme man auf -43% bei der gleichen Leistung bzw. 75% mehr Perf/W. Für -50% müsste die 5700 bei 180W schon 20% schneller sein.

[dargo]

Woher weißt du schon wieviel eine RX5700 bei einem Powerlimit von 150W langsamer ist als mit 180W? Zur Skalierung ist noch Null bekannt. Auch wissen wir noch gar nicht wie die RX5700 zur V64 steht was Performance angeht.

[Ravenhearth]

Ich habe nur spekuliert. Aber ich denke kaum, dass die 5700 die V64 um mehr als 5% überholen wird, wenn die XT laut AMD nur 14% schneller als die V64 sein soll...

Edit: Die V64 kannst du durch ein reduziertes PT übrigens auch schon massiv effizienter machen. Eine Stock-V64 mit einer (hypothetischen) optimierten 5700 zu vergleichen ist daher auch nicht ganz fair.

[Käsetoast]

Wobei man als positiven Effekt was Navi angeht ja immer auch im Hinterkopf behalten muss, dass Vega mit stromsparenderem HBM Speicher agiert was die Effizienz beim nackten Vergleich der Verbrauchswerte für Navi indirekt nochmal anhebt. Ich bin dahingehend mit Navi schon ganz zufrieden - sowas in der Richtung hätte halt schon mit Vega eintreten müssen anstatt das sich da erst jetzt mit Navi nennenswert was tut, aber besser spät als nie...

[Blediator16]

kein riesiges Kunststück bei solch einer verbesserten Fertigung

Der Node Vorsprung juckt halt nicht. Nvidia kann doch auch. Wenn sie es jetzt nicht tun, dann Pech gehabt. Nächstes Jahr treten dann beide mit 7nm EUV an.

Bei Intel hat es das letzte Jahrzehnt doch auch niemanden gejuckt. Das was zählt ist das Hier und Jetzt.

[dargo]

Wobei man als positiven Effekt was Navi angeht ja immer auch im Hinterkopf behalten muss, dass Vega mit stromsparenderem HBM Speicher agiert was die Effizienz beim nackten Vergleich der Verbrauchswerte für Navi indirekt nochmal anhebt. Ich bin dahingehend mit Navi schon ganz zufrieden - sowas in der Richtung hätte halt schon mit Vega eintreten müssen anstatt das sich da erst jetzt mit Navi nennenswert was tut, aber besser spät als nie...
Stimmt... diesen Punkt komplett vergessen. Schade, dass Navi10 nicht mit HBM kam. Klar... aus Kostengründen irgendwo nachvollziehbar.

[SKYNET]

Stimmt... diesen Punkt komplett vergessen. Schade, dass Navi10 nicht mit HBM kam. Klar... aus Kostengründen irgendwo nachvollziehbar.

warten wir doch mal den dicken navi ab... könnte mir vorstellen das der mit 16GB HBM kommen wird... :)

[dargo]

Da würde ich sogar drauf wetten, dass der mit 16GB HBM kommt. Alles andere macht Ende 2020 keinen Sinn in dieser Leistungsklasse.

[BlacKi]

ich glaub eher das noch ein kleinerer kommt. das Highend/enthusiast segment ist sowieso das unrentabelste. low end wäre auf 7nm wohl profitabler.

[iuno]

Eine RX 590 hat auch ne TDP von 225W, Navi ist auf jeden Fall deutlich effizienter.
Eine 590 ist eine doppelt hochgepruegelte 150 W Karte...

Bei Navi hat man sich offenbar noch besonnen und die 2x8-Pin, die vorsichtshalber auf den Produktbildern drauf sind, nochmal weg gemacht. Das koennte das Ergebnis schon etwas schoenzeichnen. Haette man dasselbe bei Vega gemacht, haette die auch problemlos mit 225 W kommen koennen, ohne nennenswert an Leistung zu verlieren.

Warten wir mal die Tests ab, aber ich bin von der Navi Effizienz nicht ueberzeugt.

Kooperation zwischen den 2 CUs erfordert vermutlich, daß sich diese zwei CUs den LDS teilen (1x128kB statt 2x64kB?)..
Das Schaubild deutet ja jedenfalls darauf hin

https://pics.computerbase.de/8/8/1/1/7/24-1080.ffd84ff2.jpg

[SKYNET]

Eine 590 ist eine doppelt hochgepruegelte 150 W Karte...

Bei Navi hat man sich offenbar noch besonnen und die 2x8-Pin, die vorsichtshalber auf den Produktbildern drauf sind, nochmal weg gemacht. Das koennte das Ergebnis schon etwas schoenzeichnen. Haette man dasselbe bei Vega gemacht, haette die auch problemlos mit 225 W kommen koennen, ohne nennenswert an Leistung zu verlieren.

Warten wir mal die Tests ab, aber ich bin von der Navi Effizienz nicht ueberzeugt.

veil mehr interessiert mich, wie gut sich navi takten und undervolten lässt... erstrecht die 5700... wäre ne coole wachablöse für die 580er im 2. rechner.

[Brillus]

ich glaub eher das noch ein kleinerer kommt. das Highend/enthusiast segment ist sowieso das unrentabelste. low end wäre auf 7nm wohl profitabler.

Ich hoffe das noch was kleines kommt. Desktop Variante so um P10 performance rum damit es auch in bessere Lapis passt. Hoffe nächstes Jahr auf einen 8c und Navi umsteigen zu können.

[Daredevil]

Anscheinend kommt auch ne 2080ti Super..... Big Navi incoming? (:

[Mr.Scott]

7nm HPC ungleich 7nm FF, das vergessen hier einige immer wieder.:rolleyes:

Mit EUV könnte das noch einmal ganz anders aussehen, also abwarten und Tee trinken.


"7nm" ist sowieso nur für´s Marketing!

Vergleiche mal "7nm TSMC" mit "10nm Intel"

Ich glaube da würden sich einige Leute hier wundern :rolleyes:

[MadPenguin]

"7nm" ist sowieso nur für´s Marketing!

Vergleiche mal "7nm TSMC" mit "10nm Intel"

Ich glaube da würden sich einige Leute hier wundern :rolleyes:

Sollen wir dich ernst nehmen? 10nm Intel ist tot. Theoretisch und hypothetisch kann er noch so geil sein, wenn man dann nicht produzieren kann, dann ist es halt irgendwie doof, oder? :freak:

[w0mbat]

10nm Intel? Ahhh, ein Gespenst :D

[Ex3cut3r]

2021/2022 ist wohl der Intel 10nm Ready. Der 10 Kerner soll ja noch mit 14nm++++++++ kommen. Leider sind 10 Kerne auch keine 12 oder gar 16 Kerne. Dumm gelaufen.

[dildo4u]

Eine 590 ist eine doppelt hochgepruegelte 150 W Karte...

Bei Navi hat man sich offenbar noch besonnen und die 2x8-Pin, die vorsichtshalber auf den Produktbildern drauf sind, nochmal weg gemacht. Das koennte das Ergebnis schon etwas schoenzeichnen. Haette man dasselbe bei Vega gemacht, haette die auch problemlos mit 225 W kommen koennen, ohne nennenswert an Leistung zu verlieren.

Nicht wirklich das Gegenstück zur 590 kommt sofort,das ist die ominöse 10 Tflops Karte.

[AffenJack]

Zur Density wurde IIRC noch nichts gesagt:
P10: 24,56 Mio Tr/mm²
N10: 41,03 Mio Tr/mm²
V7: 39,96 Mio Tr/mm²

Man bekommt also nur 67 % mehr Density. Und N10 hat kaum eine andere Density als V7 - da wurde ja aufgrund von I/O etc hier schon eine deutlich andere Density vermutet (und man lag hier offenbar daneben).

Man sollte eben nicht nur träumen. Wie lange musste man hier dauernd lesen, dass 7nm dreifache Density bringt, obwohl klar war, dass es max zweifach wird und anscheinend nichtmal das möglich ist. Die große Frage ist, ob 7nm EUV von TSMC in der HPC Version nur genauso kleine Vorteile wie 7nm EUV Mobile bringt oder ob 7nm EUV HPC nochmal so ein Sprung wie 7nm DUV ist.

[Mr.Scott]

Sollen wir dich ernst nehmen? 10nm Intel ist tot. Theoretisch und hypothetisch kann er noch so geil sein, wenn man dann nicht produzieren kann, dann ist es halt irgendwie doof, oder? :freak:
10nm Intel? Ahhh, ein Gespenst :D
2021/2022 ist wohl der Intel 10nm Ready. Der 10 Kerner soll ja noch mit 14nm++++++++ kommen. Leider sind 10 Kerne auch keine 12 oder gar 16 Kerne. Dumm gelaufen.

Ok, anders gesagt.
7nm != 7nm
7nm ist mehr Marketing als die echte Einheit in "nm"
Auf dem Papier ist Intels 10nm besser als TSMC's 7nm.

[robbitop]

IIRC galt das für den ursprünglichen 10 nm Prozess. Intel musste da etwas nachlockern. Entsprechend dürfte er mit TSMCs 7 nm Prozess vergleichbar sein.
Bis Intels 10 nm Prozess auf anständige Taktraten kommt (10nm+), ist TSMC schon bei 6 nm und der nächste Fullnode mit 5 nm ist dann auch nicht mehr weit entfernt.

[Gipsel]

Man sollte eben nicht nur träumen. Wie lange musste man hier dauernd lesen, dass 7nm dreifache Density bringt, obwohl klar war, dass es max zweifach wird und anscheinend nichtmal das möglich ist.Das waren immer bis zu 3x und auch von den verwendeten Bibliotheken abhängig (also ob man auf Performancesteigerungen zum Großteil verzichtet und maximale Dichte haben will oder eben nicht). Außerdem reden wir hier von keinem TSMC-internen Vergleich, sondern 14/12nm GF vs. 7nm TSMC und Du vergißt auch ganz ungeniert den IO-Bereich (enthält kaum Transistoren und schrumpft kaum bis gar nicht). Wieviel bei Logik/SRAM beim gleichen Schritt von GF14/12nm zu TSMC 7nm geht (ebenfalls mit high performance libraries, die weniger Transistoren pro Fläche nutzen), zeigt übrigens Zen2. Kannst ja da mal die Flächen eines CCX vergleichen (und Zen2 hat ja mehr Transistoren im Kern, allein schon wegen doppelt breiten Vektor-Pipelines und sonstigem aufgebohrten Krams). Da siehst Du Deine >=2x Transistordichte. ;)

[robbitop]

Hinzu kommt: Die besonders hohe Dichte war IIRC auch nicht beim HPC Prozess sondern beim mobilen 7 nm.

[Mr.Scott]

Sollen wir dich ernst nehmen? 10nm Intel ist tot. Theoretisch und hypothetisch kann er noch so geil sein, wenn man dann nicht produzieren kann, dann ist es halt irgendwie doof, oder? :freak:
10nm Intel? Ahhh, ein Gespenst :D
2021/2022 ist wohl der Intel 10nm Ready. Der 10 Kerner soll ja noch mit 14nm++++++++ kommen. Leider sind 10 Kerne auch keine 12 oder gar 16 Kerne. Dumm gelaufen.

Ok, anders gesagt.
7nm != 7nm
7nm ist mehr Marketing als die echte Einheit in "nm"
Auf dem Papier ist Intels 10nm besser als TSMC's 7nm.

[Gipsel]

Hinzu kommt: Die besonders hohe Dichte war IIRC auch nicht beim HPC Prozess sondern beim mobilen 7 nm.
Mit 6T Libraries iirc (das ergibt gegenüber 9T logischerweise praktisch eine 50% erhöhte Transistordichte, da jede Zelle nur 2/3 der Höhe aufweist, gegenüber 7.5T immerhin noch 25% mehr Dichte).

Und da ich ja Zen ins Spiel gebracht habe, nur der CCX liegt in GF 14nm/12nm bei 31,8 Mio Tr./mm². Mit 16MB L3 läge er bei 60mm² (CCX mit 8MB L3 mißt 44mm² bei angeblich 1,40Mrd. Transistoren; die 8MB L3 alleine messen 16mm²). Ein Zen2 CCX in 7nm und 16MB L3 kommt auf 31,3mm². Und ich vermute mal, Zen2 verbaut mehr als +4,3% Mehrtransistoren im CCX gegenüber Zen (31,3mm²/30mm² - 1), was 2x Flächenskalierung wäre. Also ein Zen2 CCX liegt sicher bei >60 Mio Tr./mm².

[Blediator16]

Ok, anders gesagt.
7nm != 7nm
7nm ist mehr Marketing als die echte Einheit in "nm"
Auf dem Papier ist Intels 10nm besser als TSMC's 7nm.

Auf dem Papier ist TSMC 5nm besser als das 10nm Papier ;D

[Denniss]

Ok, anders gesagt.
Auf dem Papier ist Intels 10nm besser als TSMC's 7nm.Das war in der Tat so. Der 10nm funktionierte aber nicht und wurde eingestampft bzw überarbeitet und hat einiges an Packdichte verloren. Funktioniert aber scheinbar immer noch nicht so recht, man spart zwar Strom aber bekommt die Taktraten bei weitem nicht hin.

[SKYNET]

Das war in der Tat so. Der 10nm funktionierte aber nicht und wurde eingestampft bzw überarbeitet und hat einiges an Packdichte verloren. Funktioniert aber scheinbar immer noch nicht so recht, man spart zwar Strom aber bekommt die Taktraten bei weitem nicht hin.


das teil ist wie der P-M seinerzeit... viel IPC aber hoher takt war nen wunschtraum... das gleiche schicksal wird jetzt wieder kommen, fette IPC aber takt? nö... super für ULV cpus die lange durchhalten müssen, ohne allzuviel leistung zu bringen(gammel laptops fürs surfen und office).

[deekey777]

Ja, auch der L1-sD$ und der L1-I$ werden zwischen den beiden gepaarten CUs geteilt. Das war bei GCN aber ähnlich (sogar unter bis zu 4 CUs geteilt). Neu wäre, daß man sich den LDS teilt, wodurch eine Workgroup auf 2 CUs aufgeteilt werden kann. Im Prinzip hätte man somit auch fast sagen können, daß Navi 10 aus 20 CUs besteht, die jeweils 4 vALUs mit 32 Lanes besitzen. Aber die TMUs werden wohl nicht geteilt (zumindest ist es nicht eingezeichnet). Das ist vermutlich fast das Einzige, was die Beschreibung als CUs mit vier 32 Lanes breiten vALUs verhindert.

...

Da muss ich glatt an die Meldungen denken, dass Navi 10 mit 20 CUs kommt. Im Endeffekt ist es egal, es zählt ja die Leistung. Aber die kreative Zählweise kann den einen oder anderen stören.

[robbitop]

Mit 6T Libraries iirc (das ergibt gegenüber 9T logischerweise praktisch eine 50% erhöhte Transistordichte, da jede Zelle nur 2/3 der Höhe aufweist, gegenüber 7.5T immerhin noch 25% mehr Dichte).

Ist das eigentlich der einzige Unterschied zw. dem HPC und mobile Prozess? Das würde dann ja nur SRAM betreffen. Ich hatte aufgrund der recht großen Spreizung zw. der mobile und HPC in Bezug auf Packdichte vermutet, dass man die Logiktransistoren auch deutlich enger packen kann.

[Gipsel]

Ist das eigentlich der einzige Unterschied zw. dem HPC und mobile Prozess?Welche Cell libraries man nutzt, bleibt wohl jedem Kunden selbst überlassen. Es könnte aber sein, daß für mobile gar keine 9T angeboten werden, keine Ahnung.
Das würde dann ja nur SRAM betreffen. Ich hatte aufgrund der recht großen Spreizung zw. der mobile und HPC in Bezug auf Packdichte vermutet, dass man die Logiktransistoren auch deutlich enger packen kann.Nein, das betrifft auch (bzw. vor allem) Logik. Das T in 9T oder 7.5T bzw. 6T stehen nicht für die Anzahl der Transistoren für ein Bit in einer SRAM-Zelle, sondern für die "Höhe" einer Logikzelle (gemessen in "tracks", was der minimale metal pitch des Prozesses ist [üblicherweise von M2, also M2P]). In höhere Zellen passen mehr parallele Fins rein (wieviele genau, hängt vom fin pitch ab [und auch, ob man neben der eigentlichen Zelle kontaktiert oder wie intel bei 10nm probiert hat, den Schaltkontakt mitten auf die Zelle draufzusetzen aka Contact Over Active Gate, COAG, was natürlich Zellhöhe spart]), die geschalteten Ströme sind also typischerweise größer und die damit aufgebauten Schaltungen schneller (aber gegebenenfalls auch entsprechend stromhungriger). Die Zellhöhe geht linear in die Größe von Logikgattern ein, 9T ist schlicht 50% größer als 6T. Für SRAM basteln die Hersteller sowieso ein eigens optimiertes Design für die Zelle (bzw. sogar mehrere, aus denen man wählen kann), was nicht unbedingt den sonstigen Designrules für Logik entspricht (weswegen die Skalierungsfaktoren für SRAM und Logik durchaus unterschiedlich sein können).

[BoMbY]

Da muss ich glatt an die Meldungen denken, dass Navi 10 mit 20 CUs kommt. Im Endeffekt ist es egal, es zählt ja die Leistung. Aber die kreative Zählweise kann den einen oder anderen stören.

Ein Vorteil bei den WGUs scheint die Möglichkeit von Register-Sharing zu sein. Wenn man irgendwas hat was da kritisch drauf regiert könnte die doppelte Anzahl VGPRs schon etwas helfen.

[robbitop]

Wie immer fundiert und detailliert erklärt! :up: Danke Gipsel!

[mboeller]

Da muss ich glatt an die Meldungen denken, dass Navi 10 mit 20 CUs kommt. Im Endeffekt ist es egal, es zählt ja die Leistung. Aber die kreative Zählweise kann den einen oder anderen stören.


sogar der Die-Shot zeigt nur 20 CU's

[Gipsel]

sogar der Die-Shot zeigt nur 20 CU'sDas ist zuerst maximal ein Floor Plan, zudem wohl noch ein wenig "künstlerisch" bearbeitet. Und man sieht genau 20 "Workgroup Processors" bestehend aus jeweils zwei CUs ;). Die teilen sich ein paar Resourcen (LDS, L0-I$, L0-sD$), aber sind dennoch offenbar keine einzige Einheit (die haben zwei getrennte Sätze von jeweils vier TMUs, die nicht geteilt sind).

[Mandalore]

Gipsel, was hälst du eigentlich von RDNA im Allgemeinen und vor allem in Bezug zu Nvidias Turing bzw. AMDs GCN Architekturen , mit den Infos die wir bisher haben?

[unl34shed]

Das ist zuerst maximal ein Floor Plan, zudem wohl noch ein wenig "künstlerisch" bearbeitet. Und man sieht genau 20 "Workgroup Processors" bestehend aus jeweils zwei CUs ;). Die teilen sich ein paar Resourcen (LDS, L0-1$, L0-sD$), aber sind dennoch offenbar keine einzige Einheit (die haben zwei getrennte Sätze von jeweils vier TMUs, die nicht geteilt sind).

Och ne, dann gehen bestimmt wieder so Diskussionen los, wie bei Bulldozer. Vollwertige Kerne bzw. CUs oder nicht... Bitte nicht :(

[Gipsel]

Gipsel, was hälst du eigentlich von RDNA im Allgemeinen und vor allem in Bezug zu Nvidias Turing bzw. AMDs GCN Architekturen , mit den Infos die wir bisher haben?Das grundlegende Prinzip mit Vektor- und Skalar-Instruktionen bleibt aufgrund der ISA ja identisch (und daß ich das Prinzip mag, ist wohl in der Vergangenheit bereits deutlich geworden). Also ordentliche (Compute-)Shaderprogramme zu schreiben, wird nicht schwieriger und erfordert auch keine große Umstellungen. Im Detail ändert sich natürlich was, aber unter dem Strich dürfte da ein Plus herauskommen (kleinere Wavefronts möglich [wenn nötig]; doppelte Load-Bandbreite; potentiell weniger Waves erforderlich, um GPU zu füllen [kleinere Tasks werden etwas effizienter abgearbeitet]; wahrscheinlich bessere Performance für sehr ressourcenfressende [viele Register oder LDS belegende] Programme, doppelt so viele Register pro SIMD [auch wenn die vALU breiter ist, bleibt da ein positiver Effekt übrig]; eine zusätzliche Stufe in der Cachehierarchie [L0, L1 und L2 statt nur L1 und L2, wobei der neue L0 dem alten L1 entspricht, der neue L2 dem alten L2 und der neue L1 dazwischen geschoben wurde]). Dies waren bisher Punkte, die sowohl Grafik als auch Compute betreffen.

Zu den weiteren Änderungen, die sich auf reines Compute eventuell nicht so stark auswirken (aber wesentlich für Grafiklasten in Spielen sind), sind mir noch zu wenig an Details bekannt (und ganz ehrlich kenne ich mich da auch nicht ganz so gut aus), um da viel zu sagen zu können. Erstmal wirkt es so, als wenn AMD Flaschenhälse erkannt und daran gearbeitet hat (logisch). Aber wie gut das dann am Ende Alles funktioniert, wird man sehen müssen. Und AMD wird auch weiterhin hart an der Erhöhung der Energieeffizienz arbeiten müssen (nV bietet ja kein stehendes Ziel, die basteln auch an den nächsten Verbesserungen).

[Gebrechlichkeit]

Sobald die Super GPUs zu haben sind, hat AMD hoffentlich ein paar 5800, 5900 parat. AMD hat CPU seitig gewaltig aufgeholt, im GPU Sektor .... da fehlt noch ein Rad am Wagen.

[Denniss]

AMD bräuchte eher eine kleine Navi im Brot-und-Butter Bereich als Ersatz für Polaris und gegen die 1660. Wenn dabei noch eine 75W Navi gegen die 1650 abfällt umso besser denn damit könnte man bei OEMs gut landen

[Dino-Fossil]

AMD bräuchte eher eine kleine Navi im Brot-und-Butter Bereich als Ersatz für Polaris und gegen die 1660. Wenn dabei noch eine 75W Navi gegen die 1650 abfällt umso besser denn damit könnte man bei OEMs gut landen

Wobei so ein kleiner Navi vermutlich leider zu schwach ausfällt um Polaris-Besitzern wie mir ein sinnvolles Upgrade zu bieten.
Gehen wir mal von max 28CUs aus (größer dürfte er nicht werden, da sonst wieder zu nah an Navi10(?) dran), komme ich grob auf vielleicht 1,3x Polaris10/20-Performance bei 100-120W TBP.

Damit wäre so ein Chip zwar gut für fullHD in 2019/20, aber eben kein richtig überzeugendes Upgrade für Polaris10/20-Besitzer. Navi10 bietet zwar Performance, ist aber in Punkto Preis (und mMn Verbrauch) zu hoch positioniert.

Aber 1-2 kleinere Navi um das Portfolio nach unten zu modernisieren wären davon unabhängig natürlich trotzdem nett.

[robbitop]

IMO ist N10 ein Polaris Nachfolger. Die Preise werden schon sukzessive in dessen Bereich kommen (wo Polaris 2016/17/18 sich aufhielt).
P20/30 dann zunächst für das Segment darunter. Reicht doch völlig aus und ist nach wie vor ein guter 1080p Chip.

[Denniss]

Die aktuellen Navis tummeln sich im Leistungsbereich der Vega, weit oberhalb von Polaris.

[Der_Korken]

Was ist das denn für ein Argument? Es würde ja auch keiner auf die Idee kommen zu sagen, dass die GTX1060 ein Nachfolger für die GTX980 war, weil die ungefähr gleich schnell sind. Mit jeder Generation steigt die Leistung in jeder Klasse. Es war früher selbstverständlich, dass nach 2 Jahren die Mittelklassekarten die Leistung der alten Highend-Karten geliefert haben.

[Daredevil]

Was ist das denn für ein Argument? Es würde ja auch keiner auf die Idee kommen zu sagen, dass die GTX1060 ein Nachfolger für die GTX980 war, weil die ungefähr gleich schnell sind. Mit jeder Generation steigt die Leistung in jeder Klasse. Es war früher selbstverständlich, dass nach 2 Jahren die Mittelklassekarten die Leistung der alten Highend-Karten geliefert haben.
"Früher" ist aber nun auch mal kein Zeitraum von hunderten von Jahren. Seit einer Gewissen Zeit ging das so, aber das bedeutet ja nicht, nur weil es 30 Jahre so ist, dass es eine Ewigkeit so bleibt.

[Käsetoast]

Aus reiner Kundensicht sieht man halt Polaris->Vega->Navi und 14nm->12nm->7nm. Ich denke der Wunsch Vega Leistung zum Polaris Preis zu bekommen ist da nicht totales Wunschdenken vom Prinzip her...

Natürlich kann man dann noch AMDs Engpass was Gelder für Entwicklungen angeht anführen bzw. den Umstand, dass Vega unterm Strich für den Gamer eher ein Stillstand war, der im Endeffekt nur wegen stromsparendem HBM einigermaßen rund war was das Gesamtpaket angeht. So gesehen ist meine Hauptenttäuschung bei Navi wenn man davon reden will die, dass die rund 100 € zu teuer sind für meinen Geschmack. Ich meine wenn man da an die 4GB Polaris für 199 $ denkt - das war schon eine Ansage. Nachdem man was Vega angeht in dem Preisbereich komplett leer ausgeht tut es ein wenig weh, dass das was wir von Navi hören dann eher im Bereich doppelt so teuer wie die 4GB Polaris spielt...

Vielleicht tut es AMD aber auch ganz gut was mehr auf Marge zu gehen um dann eben wieder mehr Geld für die Entwicklung zu haben...

[Daredevil]

Aus reiner Kundensicht sieht man halt Polaris->Vega->Navi und 14nm->12nm->7nm. Ich denke der Wunsch Vega Leistung zum Polaris Preis zu bekommen ist da nicht totales Wunschdenken vom Prinzip her...

Es ist ja auch Realität.
Günstige Vega 56 gibt es schon gerne mal für 219€ und gute Vega 56 für 249€.
Ein Preispunkt, den eine RX590 abgedeckt hat und die ist aktuell bei 184€ ( Gestartet bei 250€+ ).

Dazu gibt es aktell noch eine Spielbundle im Wert von ~40€.
Man bekam aktuell noch nie mehr Leistung in der Kategorie fürs Geld.

Ich habe Navi ja auch deutlich günstiger getippt, weil es für mich wenig Sinn ergibt, eine Karte in der gleichen Kategorie deutlich teurer anzubieten.
Da Vega aber noch da ist, nimmt die Serie halt aktuell die Bread and Butter Kategorie ein.

[Käsetoast]

Ja, wobei ich die derzeitigen Vega Ramschpreise jetzt nicht weiter in der Gesamtdiskussion einbeziehen würde. Es geht mehr darum, zu welchen Preisen die Karten angedacht sind / waren. Beim Ausverkauf sind natürlich immer Kampfpreise möglich, aber das ist ja mehr ein "solange der Vorrat reicht". Da ist Navi in meinen Augen mehr ein Vega Nachfolger als ein Polaris Nachfolger was die angedachten Preise angeht...

[Daredevil]

Ja, da hast du natürlich auch recht. Aber reale Preise von existierenden Produkten kann man halt auch mit folgenden Vergleichen.
Ich glaube auch, dass Navi ein Vega Nachfolger ist, aber dadurch kann Vega halt auch mittelfristig ein 200€ Polaris Nachfolger sein, während die 200€ Polaris Karten die RX560 ect. ersetzen.

Analog dazu, wie Apple ihr Lineup handhabt.
Vorjahresmodelle werden günstiger und technische Neuerungen nehmen den regulären Platz ein. ( Oder werden teurer :D )

Abverkaufspreis ist ein sehr schwieriges Wort, das hier sehr oft genannt wird.
Ich meine....... aktuell gibts 100+ GTX1060 im Mindstar für 159€, wie lange soll so ein Abverkauf denn gehen? Drei Jahre? Wann beginnt ein "Abverkauf"?
( Komischerweise kauft die auch noch wer.... )

[dildo4u]

V7wwDnp8p6Y

[Leonidas]

Da würde ich sogar drauf wetten, dass der mit 16GB HBM kommt. Alles andere macht Ende 2020 keinen Sinn in dieser Leistungsklasse.


Navi 20 wird sicherlich auch wieder Profi-Gedöns haben, dafür braucht man dann zwingend dick Bandbreite = HBM. Außerdem senkt es in dieser Klasse dann die TDP doch beachtbar ab, was nützlich ist, wenn man nicht die 300-Watt-Grenze knacken will. Navi 20 also ziemlich sicher wieder mit HBM. Speichermengen sind inzwischen ja auch kein Thema mehr mit HBM, wie die Pro Vega II bei Apple zeigt.




ich glaub eher das noch ein kleinerer kommt. das Highend/enthusiast segment ist sowieso das unrentabelste. low end wäre auf 7nm wohl profitabler.


Beides. "Vega 14" steht ja schon in irgendwelchem Code.




AMD bräuchte eher eine kleine Navi im Brot-und-Butter Bereich als Ersatz für Polaris und gegen die 1660. Wenn dabei noch eine 75W Navi gegen die 1650 abfällt umso besser denn damit könnte man bei OEMs gut landen


Also RX570-590 Klasse wird schwer für Navi. Da sind die Straßenpreise so ausgeluscht, das ein neuer Navi dies nicht besser machen könnte. Eher interessant wäre eine echte Mainstream-Lösung, die gegen RX560, 1050Ti und 1650 geht. Da kann AMD mal was gutmachen (was mit 460/560 verbockt wurde) und hat potentiell auch mal wieder einen Chip, denn man sogar zu den Notebook-Herstellern schicken könnte.

[HOT]

https://www.tomshw.de/2019/06/14/leistungsaufnahme-tdp-tbp-und-tgp-bei-nvidia-und-amd-grafikkarten-entmystifiziert-und-nachgerechnet-igorslab/

absolut köstlich.

[SKYNET]

https://www.tomshw.de/2019/06/14/leistungsaufnahme-tdp-tbp-und-tgp-bei-nvidia-und-amd-grafikkarten-entmystifiziert-und-nachgerechnet-igorslab/

absolut köstlich.

ich glaube, er mag NV nicht so richtig :upara: :ulol: nutzt jede gelegeneheit die zu zerlegen ;D

[robbitop]

Die aktuellen Navis tummeln sich im Leistungsbereich der Vega, weit oberhalb von Polaris.


Eine Nachfolgergeneration ist natürlich schneller als die Vorgängergeneration.
Siehe GK104->GM104->GP104->TU104. Jeweils schneller weil neuer. Trotzdem jeweils der Nachfolger.

Man sieht aber, wie selbstverständlich es für viele schon ist, für mehr Leistung mehr Geld zu zahlen - auch wenn es die neue Generation ist und eine ganze Menge Zeit vergangen ist.

Bis zu Kepler galt noch: alle 18 Monate 60...100% mehr Leistung für den gleichen Preis.
Natürlich sind die Fertigungs- und Entwicklungskosten hochgegangen seit ein paar Jahren. Aber die Margen auch. ;)

[dargo]

Navi 20 wird sicherlich auch wieder Profi-Gedöns haben, dafür braucht man dann zwingend dick Bandbreite = HBM. Außerdem senkt es in dieser Klasse dann die TDP doch beachtbar ab, was nützlich ist, wenn man nicht die 300-Watt-Grenze knacken will.
Ich bin mir sogar ziemlich sicher, dass Navi20 wieder an die 300W geht. Navi 10 kommt mit 40 CUs, Navi 20 sicherlich wieder mit 64 CUs. Das wären +60%. So viel sparsamer wird 7nm+ nicht, dass man da wesentlich unter 300W landet.

[Denniss]

ein kleinerer Navi (Abfall?) könnte gegen die 1660(Ti) positioniert werden also etwas über der RX590, zudem sollte der im Stromverbrauch günstiger sein. Ob mit GDDR6 oder GDDR5(+) ist dann die Kostenfrage.
Die RX590 wäre dann obsolet und man könnte Polaris erstmal durch die Bank mit 12nm Versionen ersetzen wenn eine ganz kleine Navi mit 75W noch lange braucht. (RX 600 serie?)

[Leonidas]

Die Frage ist, ob AMD diesen kleinen Navi zu denselben Preisen wie RX570-590 hinbekommt. Sprich Preissegment 110-180 Euro. Technologisch ist dies keine Frage, aber bekommen sie Navi derart günstig? Vermutlich nicht - womit es dort sinnvoller ist, Polaris weiterzuverwenden.

[HOT]

Falls es überhaupt nen kleinen Navi gibt auf absehbare Zeit. Man könnte ja auch einfach Polaris weiterverwerten. Der 5700 ist halt ein kostenreduzierter Vega-Ersatz.

[reaperrr]

Ich bin mir sogar ziemlich sicher, dass Navi20 wieder an die 300W geht. Navi 10 kommt mit 40 CUs, Navi 20 sicherlich wieder mit 64 CUs.
Alles unter 80 CUs für N20 wäre extrem enttäuschend. Wozu einen Chip rausbringen, der auf Vega20 nur ~25-30% Leistung draufpackt?
Ziel muss sein, mindestens auf Augenhöhe mit der 2080 Ti zu landen, dafür braucht es ~5700XTx2.

[=Floi=]

kann man anhand der folien sagen, dass DP 2:1 möglich sein wird?
Es gibt ja das eine schaubild, wo die 2x32bit breiten SP in einem block zu sehen waren.

[dargo]

ein kleinerer Navi (Abfall?) könnte gegen die 1660(Ti) positioniert werden also etwas über der RX590, zudem sollte der im Stromverbrauch günstiger sein. Ob mit GDDR6 oder GDDR5(+) ist dann die Kostenfrage.
Die RX590 wäre dann obsolet und man könnte Polaris erstmal durch die Bank mit 12nm Versionen ersetzen wenn eine ganz kleine Navi mit 75W noch lange braucht. (RX 600 serie?)
Das macht keinen Sinn. Du kannst doch nicht den gleichen 251mm² Die für ~200€ verkloppen. Da ist die Produktion von P30 garantiert günstiger. P30 Ersatz macht nur mit einem kleineren Navi Sinn.

Die Frage ist, ob AMD diesen kleinen Navi zu denselben Preisen wie RX570-590 hinbekommt. Sprich Preissegment 110-180 Euro. Technologisch ist dies keine Frage, aber bekommen sie Navi derart günstig? Vermutlich nicht - womit es dort sinnvoller ist, Polaris weiterzuverwenden.
Warum sollte das nicht gehen? So ein kleiner Navi bei ~130-150mm², dann ein GDDR5 Speicherinterface dran... fertig.

[dildo4u]

Alles unter 80 CUs für N20 wäre extrem enttäuschend. Wozu einen Chip rausbringen, der auf Vega20 nur ~25-30% Leistung draufpackt?
Ziel muss sein, mindestens auf Augenhöhe mit der 2080 Ti zu landen, dafür braucht es ~5700XTx2.
Der große Chip wird RT haben daher kannste 80CU vergessen.

[dargo]

Alles unter 80 CUs für N20 wäre extrem enttäuschend. Wozu einen Chip rausbringen, der auf Vega20 nur ~25-30% Leistung draufpackt?
Ziel muss sein, mindestens auf Augenhöhe mit der 2080 Ti zu landen, dafür braucht es ~5700XTx2.
Deine Rechnung kann ich nicht nachvollziehen.

1. Wenn ich von +60% CUs spreche gehe ich davon aus, dass die Skalierung nach oben in etwa 1:1 durchschlägt. Ergo +50-60% Leistung von Navi 10. Und damit hast du schon praktisch 2080TI Leistung.
2. Ein Navi 20 der doppelt so schnell ist wie Navi 10 passt überhaupt nicht ins Portfolio. Dadurch hättest du eine riesen Lücke zwischen N10 und N20.

Ich sehe auch nicht den Bedarf Nvidia bei der schnellsten Grafikarte zu schlagen. Wir sprechen hier immer noch vom Preissegment >1.000€. Dieser Bereich ist am wenigsten rentabel.

Edit:
Selbst wenn Navi 20 "nur" 60% schneller sein sollte als Navi 10 hast du immer noch eine recht große Lücke. In der Regel ist der Salvage nur 10-15% langsamer. Ich könnte mir aber durchaus einen kleinen Refresh von Navi 10 in 7nm+ mit höheren Taktraten vorstellen. Im Prinzip reichen da schon +10-15% Performance um das eigene Portfolio besser abzustufen.

[SKYNET]

Deine Rechnung kann ich nicht nachvollziehen.

1. Wenn ich von +60% CUs spreche gehe ich davon aus, dass die Skalierung nach oben in etwa 1:1 durchschlägt. Ergo +50-60% Leistung von Navi 10. Und damit hast du schon praktisch 2080TI Leistung.
2. Ein Navi 20 der doppelt so schnell ist wie Navi 10 passt überhaupt nicht ins Portfolio. Dadurch hättest du eine riesen Lücke zwischen N10 und N20.

Ich sehe auch nicht den Bedarf Nvidia bei der schnellsten Grafikarte zu schlagen. Wir sprechen hier immer noch vom Preissegment >1.000€. Dieser Bereich ist am wenigsten rentabel.

aber die daus denken grundsätzlich, wer die schnellste karte hat, ist bei jeder klasse der schnellste... :freak:

[Daredevil]

1. Wenn ich von +60% CUs spreche gehe ich davon aus, dass die Skalierung nach oben in etwa 1:1 durchschlägt. Ergo +50-60% Leistung von Navi 10. Und damit hast du schon praktisch 2080TI Leistung.

Du kannst aber halt nicht auf ner 225w Karte 60% mehr Einheiten draufballern und dann "nur" 33% mehr Verbrauch erwarten, wenn der Speicher auch noch ansteigt.
Wenn AMD z.B. nicht 60% mehr Einheiten gibt, sondern sie halt auf 80 ( oder whatever ) verdoppelt, kann AMD die Leistungsaufnahme durch Taktsenkung deutlich niedriger gestalten und so kommt man dann realistischer auf 300w.

Nvidia macht es bei ihrem Lineup ja nicht anders und ihr Konzept funktioniert.
Kleine Karten haben wenig Einheiten und einen hohen Takt ( So wie ne RX5700XT ) und große Karten haben sehr viel Einheiten und einen niedrigen Takt. ( Wie eine 2080ti )
So bekommt man maximal viel Leistung hin bei einer überschaubaren Verlustleistung. Wer dann als User noch Bock hat, kann halt das 400w Bios aufspielen und den Takt auf über 2Ghz prügeln. :D

Deswegen ist eine Vega56Ref auch die bessere Karte als eine RX590Max OC.
Die Vega hat den niedrigeren Takt, weniger Verbrauch und ist trotzdem schneller.

[=Floi=]

wer die schnellste karte hat, ist bei jeder klasse der schnellste... :freak:

ist ja auch so beim auto quartett so! :ugly:

[dargo]

Du kannst aber halt nicht auf ner 225w Karte 60% mehr Einheiten draufballern und dann "nur" 33% mehr Verbrauch erwarten, wenn der Speicher auch noch ansteigt.

Natürlich kann ich das.

1. Navi 10 = 7nm, Navi 20 = 7nm+
2. Navi 10 = GDDR6, Navi 20 = HBM (mit hoher Wahrscheinlichkeit)

[BlacKi]

1. Wenn ich von +60% CUs spreche gehe ich davon aus, dass die Skalierung nach oben in etwa 1:1 durchschlägt. Ergo +50-60% Leistung von Navi 10. Und damit hast du schon praktisch 2080TI Leistung.
tja, leider geht das nicht 1zu1. eher 1 zu 0.33 siehe vega64 vs 56. deshalb macht es nur bedingt sinn, einfach nen großen chip zu schieben.

[Daredevil]

Gut, wenn du aus Vermutungen Fakten machst, mag das stimmen. :D

Ich glaube noch an Navi20 in 7nm im Winter/Frühjahr, so wie dieses Jahr halt die Radeon VII vorgestellt wurde. AMD agiert gerade so aggressiv in jedem Segment ( Ryzen 3, Threadripper, Navi ), dass sie vermutlich nicht viel Zeit verschwenden möchten, um die Konkurrenz in Ruhe arbeiten zu lassen.

[dargo]

tja, leider geht das nicht 1zu1. eher 1 zu 0.33 siehe vega64 vs 56. deshalb macht es nur bedingt sinn, einfach nen großen chip zu schieben.
Nicht dein ernst oder? Was glaubst du warum AMD die Architektur von Navi geändert hat?

btw.
V64 hat 14% mehr Shader als V56. Bei CB schlagen 13% durch. Sicherlich liegt es auch am etwas höherem Takt von V64. Aber soo miserabel ist die Skalierung von GCN auch nicht. Viel fehlt da nicht zu 1:1.

[Daredevil]

Wenn du die 56 und 64 auf einen gleichen Verbrauch bringst, schlägt das halt weit unter 13% durch. So viel Unterschied ist dort nicht gewesen und und die Unterschiede waren je nach Spiel auch deutlich unterschiedlich.
Bei dem einen Game waren es mal 1-2%, bei dem anderen 4-6%.

[Langlay]

btw.
V64 hat 14% mehr Shader als V56. Bei CB schlagen 13% durch. Sicherlich liegt es auch am etwas höherem Takt von V64. Aber soo miserabel ist die Skalierung von GCN auch nicht. Viel fehlt da nicht zu 1:1.

V64 hat auch 75W mehr ASIC Power. Mit dem gleichen Vega64 Bios auf einer Vega56 und Vega64 biste bei ~4% Unterschied.

Aber das war bei AMD schon immer so. Auch R9 290 vs. R9 290X auf gleichem Takt quasi kein Unterschied. Also nur weil Vega von 56 auf 64 nimmer Skaliert heisst das nicht das von Vega64 auf Navi80 keine Skalierung stattfindet.

[dargo]

@Daredevil
Lese bitte nochmal was ich geschrieben habe bevor du hier wieder alles aus dem Kontext ziehst.

V64 hat auch 75W mehr ASIC Power. Mit dem gleichen Vega64 Bios auf einer Vega56 und Vega64 biste bei ~4% Unterschied.

Langsam wirds lächerlich. Ein Navi 20 wird auch keine 225W verbrauchen. :rolleyes:

btw.
V64 hat wenn schon dann 55W mehr Spielraum beim ASIC. 220W vs. 165W.

[reaperrr]

Der große Chip wird RT haben daher kannste 80CU vergessen.
Wo ist da der Zusammenhang?
AMD wird nicht für so ein Nischenfeature die Konkurrenzfähigkeit in allem anderen opfern.
Entweder sie schlucken die flächenmäßige Kröte oder bekommen es vergleichsweise flächeneffizient hin, aber AMD wird nicht satte 16 CUs und die Chance auf die Leistungskrone opfern, bloß um ein Feature zu unterstützen, welches auf absehbare Zeit eh nur dosiert vorkommen wird.

Deine Rechnung kann ich nicht nachvollziehen.

1. Wenn ich von +60% CUs spreche gehe ich davon aus, dass die Skalierung nach oben in etwa 1:1 durchschlägt. Ergo +50-60% Leistung von Navi 10. Und damit hast du schon praktisch 2080TI Leistung.
Du meinst, so wie die 2080 Ti mit ihren 88% mehr SM immer 75-88% vor der 2070 liegt? :rolleyes:

Selbst wenn Navi/RDNA jetzt so gut mit zusätzlichen CUs skalieren sollte wie NV's Architekturen mit zusätzlichen SM, bräuchte AMD immer noch Minimum 72 CUs bei gleich hohem Takt, um auf ~2080 TI Niveau zu kommen.
Und dafür müssten sie vermutlich so weit über den SweetSpot, dass selbst HBM nicht reichen würde, um in 300W zu bleiben. Mit 80 CUs hätten sie einerseits mehr Reserve bei Leistung/Takt, um näher am SweetSpot operieren zu können, und andererseits genug Redundanz, um auch den Salvage-Part auf starke Performance kriegen zu können.
Idealerweise müsste Navi20 Salvage so schnell wie die 2080Ti, und Navi20 XT etwas schneller als die 2080Ti Super sein.


btw.
V64 hat 14% mehr Shader als V56. Bei CB schlagen 13% durch. Sicherlich liegt es auch am etwas höherem Takt von V64. Aber soo miserabel ist die Skalierung von GCN auch nicht. Viel fehlt da nicht zu 1:1.
"Etwas" sind bei Ref vs. Ref unter Last ca. 10%, außerdem hat die V64 über 16% mehr Speicherbandbreite.
Wie die anderen schon schrieben, von den 13% kommen bestenfalls 3-4% von den 8 CUs.

[dargo]

Du meinst, so wie die 2080 Ti mit ihren 88% mehr SM immer 75-88% vor der 2070 liegt? :rolleyes:

Oh man... :facepalm:

Bitte Kopf einschalten! Hat die 2080TI auch die passende Bandbreite zu den +88% Shadern? Hat sie den gleichen Takt wie die 2070? Natürlich müssen andere Bereiche entsprechend mitskalieren die sich auf Performance ebenso auswirken. Einfachste Basics. :rolleyes:


"Etwas" sind bei Ref vs. Ref unter Last ca. 10%, außerdem hat die V64 über 16% mehr Speicherbandbreite.
Wie die anderen schon schrieben, von den 13% kommen bestenfalls 3-4% von den 8 CUs.
Alter... wie soll ein breiterer Chip nach oben skalieren wenn du den an fehlender Bandbreite "verhungern" lässt? :crazy:


Selbst wenn Navi/RDNA jetzt so gut mit zusätzlichen CUs skalieren sollte wie NV's Architekturen mit zusätzlichen SM, bräuchte AMD immer noch Minimum 72 CUs bei gleich hohem Takt, um auf ~2080 TI Niveau zu kommen.
Und dafür müssten sie vermutlich so weit über den SweetSpot, dass selbst HBM nicht reichen würde, um in 300W zu bleiben. Mit 80 CUs hätten sie einerseits mehr Reserve bei Leistung/Takt, um näher am SweetSpot operieren zu können, und andererseits genug Redundanz, um auch den Salvage-Part auf starke Performance kriegen zu können.

Milchmädchenrechnung... 80 CUs bedeutet +25% Die Size gegenüber 64 CUs. Was glaubst du wofür man sich bei einem teuren 7nm+ Fertigungsprozess entscheidet? Der neuere Prozess sollte auch etwas mehr Spielraum beim Takt geben.

[Daredevil]

@Daredevil
Lese bitte nochmal was ich geschrieben habe bevor du hier wieder alles aus dem Kontext ziehst.

Anscheinend bin ich nicht der einzige, der deinen Satz "missinterpretiert" hat. :D

[w0mbat]

Navi10 XT hat 40CUs und schafft mit dem 8GB GDDR6 eine Bandbreite von 448GB/s. Eine theoretische Navi20 XT mit 80CUs könnte gut mit 16GB HBM2 und 1TB/s Bandbreite kommen.

[Raff]

Oder mit 384 Bit und 16 GT/s (-> 768 GByte/s). Man weiß nicht, ob AMD bei HBM bleibt, wahrscheinlich ist's jedoch. Ich würde daher auch auf 4.096 Bit mit HBM tippen (Mitte 2020 dann mit 2,4 GT/s -> 1,23 TByte/s).

MfG,
Raff

[BoMbY]

New GFX1011 / GFX1012 Targets Appear In AMDGPU LLVM Compiler Backend (https://www.phoronix.com/scan.php?page=news_item&px=GFX1011-GFX1012-AMDGPU-LLVM)

Was er wohl nicht gesehen (https://github.com/llvm-mirror/llvm/commit/eaed96ae3e5c8a17350821ae39318c70200adaf0) hat:


image_bvh_intersect_ray v[4:7], v[9:24], s[4:7]
// GFX10: error:

image_bvh_intersect_ray v[4:7], v[9:16], s[4:7] a16
// GFX10: error:

image_bvh64_intersect_ray v[4:7], v[9:24], s[4:7]
// GFX10: error:

image_bvh64_intersect_ray v[4:7], v[9:24], s[4:7] a16
// GFX10: error:

[reaperrr]

Oh man... :facepalm:

Bitte Kopf einschalten! Hat die 2080TI auch die passende Bandbreite zu den +88% Shadern? Hat sie den gleichen Takt wie die 2070? Natürlich müssen andere Bereiche entsprechend mitskalieren die sich auf Performance ebenso auswirken. Einfachste Basics. :rolleyes:
Und dass das bei Navi20 anders ist wissen wir woher...? :rolleyes:

Es ging mir genau darum, dass Navi20 in 300W eben nicht (vermutlich nicht mal annähernd) so hoch takten können wird wie die 5700XT und man je nach Yield evtl. selbst beim Top-Modell Einheiten deaktivieren muss.
60% mehr CUs bei ziemlich sicher weniger Takt sind schlicht zu wenig, um auf 50-60% mehr Leistung zu kommen.

[dargo]

Das ist echt anstrengend mir dir.

Was wissen wir nicht? Wenn Navi 20 mit HBM kommt (davon gehe ich erstmal aus, in dieser Preisklasse kannst du die höheren Kosten besser unterbringen) kommt das Ding mit mindestens 1TB/s (rein technisch geht auch mehr). Das wäre schon mehr als doppelt so viel wie bei Navi 10. Dann hast du den neueren Prozess 7nm+ wo Verbrauch sinkt oder eben Takt bei gleichen Verbrauch steigt. Was da die bessere Balance ist wird schon AMD wissen. Mit Balance meine ich natürlich Kosten/Nutzen Faktor.

btw.
Wenn es ganz mies läuft wird Navi 20 eben 350W verbrauchen. Vielleicht kannst du damit ruhiger schlafen. Die ~300W sind reine Spekulation.

[AffenJack]

Das ist echt anstrengend mir dir.

Was wissen wir nicht? Wenn Navi 20 mit HBM kommt (davon gehe ich erstmal aus, in dieser Preisklasse kannst du die höheren Kosten besser unterbringen) kommt das Ding mit mindestens 1TB/s (rein technisch geht auch mehr). Das wäre schon mehr als doppelt so viel wie bei Navi 10. Dann hast du den neueren Prozess 7nm+ wo Verbrauch sinkt oder eben Takt bei gleichen Verbrauch steigt. Was da die bessere Balance ist wird schon AMD wissen. Mit Balance meine ich natürlich Kosten/Nutzen Faktor.

btw.
Wenn es ganz mies läuft wird Navi 20 eben 350W verbrauchen. Vielleicht kannst du damit ruhiger schlafen. Die ~300W sind reine Spekulation.

Woher willst du wissen, dass Navi20 mit mehr als 1 Tb/s kommt? Es ist alleine schon gut möglich, dass AMD mit Navi die Trennung HPC/Gaming vollzieht und dann sind für Navi20 2 HBM2e Stacks deutlich realistischer, womit wir bei 820 Gb/s landen.

Hieß es nicht sogar GCN soll für Compute erhalten bleiben und RDNA für Gaming?

[dargo]

Da könnstest du durchaus Recht haben. Eigentlich reichen 2 HBM Stacks für Navi 20 vollkommen aus. Mit 820GB/s wären es immer noch 83% mehr Bandbreite als Navi 10. Ich hatte halt spekuliert bei Navi 20 würde das parallel zu Vega 20 ablaufen. Mehr Richtung HPC und dann fürs Gaming mit kleinen Stückzahlen "missbrauchen".

[Dino-Fossil]

Hieß es nicht sogar GCN soll für Compute erhalten bleiben und RDNA für Gaming?

In einer Übergangszeit, langfristig sollen aber entsprechende RDNA-Produkte kommen.
Könnte mir durchaus vorstellen, dass V20 da von AMD in den nächsten 1-2 Jahren das Maß der Dinge bleibt, wenn nicht länger.

[Ravenhearth]

Hawaii war bei DP für 5 Jahre das Maß der Dinge bei AMD. Ich hoffe das passiert nicht nochmal :freak:

[Langlay]

Langsam wirds lächerlich. Ein Navi 20 wird auch keine 225W verbrauchen. :rolleyes:

Meine Aussage bezog sich nicht auf Navi. Meine Aussage war mit den gleichen Parametern ( Powertarget, HBM Geschwindigkeit, HBM Timings usw.) ist eine Vega64 ~4% schneller als eine Vega56.

Ergo ist diese Aussage :

V64 hat 14% mehr Shader als V56. Bei CB schlagen 13% durch. Sicherlich liegt es auch am etwas höherem Takt von V64.

einfach nur nur oberflächlich und falsch.

[dargo]

Das interessiert im Zusammenhang nicht. Weder wird Navi 20 das gleiche Powerlimit noch die gleiche Bandbreite wie Navi 10 haben. Völlig am Thema vorbei. Ich weiß gar nicht was dieser schwachsinnige Vergleich soll? Fehlt nur noch, dass einer die 2080TI auf das Powertarget der 2080 drückt. Den Speicher so weit untertaktet, dass am Ende 448GB/s Bandbreite rauskommen und sich dann wundert warum die 2080TI keine 28% mehr schneller ist (Performanceschnitt bei CB). :usweet: Oder noch besser man wundert sich warum die 2080TI keine 48% schneller ist (+48% Shader). ;D

[Der Sandmann]

Kommen eigentlich auch noch Navis im 100 und 200€ Bereich? Oder wird das weiterhin von RX570, 580 bis 200€ und Vega 56 200-300€ abgedeckt werden?

[reaperrr]

Alter... wie soll ein breiterer Chip nach oben skalieren wenn du den an fehlender Bandbreite "verhungern" lässt? :crazy:
Ich gehe von 2048bit SI mit HBM2E aus (oder evtl. HBM3, falls von einem der Hersteller bis dahin produktionsreif).
Ist mehr Bandbreite als bei TU102, sollte für 80 CUs reichen.
Abgesehen davon, Bandbreitenlimits sind eigentlich nie 'hart', sondern schwächen die Skalierung nur ab, weil die GPU bei Bedarfsspitzen etwas gebremst wird, aber lange nicht permanent. NV hat TU102 nicht zum Spaß so viele SM spendiert, die Bandbreite ist meistens ausreichend, nur halt nicht immer.


Milchmädchenrechnung... 80 CUs bedeutet +25% Die Size gegenüber 64 CUs.
Milchiger geht's auch nicht ;D
Die CUs machen selbst bei den großen Chips vielleicht 60-70% der Gesamtfläche aus. Ich tippe, dass eine Navi-CU bei um die 3mm² liegen wird, also ca. 50mm² für die 16 CUs. Gegenüber einem 64CU-Navi sind das vielleicht 15% mehr Fläche.
25% mehr CUs sollten bei N20 für mindestens ~15-20% mehr Leistung pro Takt reichen, was ggü. TU102 (und evtl. auch dem 7nm-TU104-Nachfolger) über Sieg oder Niederlage entscheiden könnte.
Außerdem wäre ein 2048-bit HBM-SI vermutlich kleiner als das 256bit-G6-SI von Navi10, selbst mit 80 CUs wäre Navi20 daher mMn maximal 450mm² groß, wahrscheinlich kleiner, da auch diverse andere Dinge nicht mitwachsen.

Wenn AMD schon bei Navi10 etwas über die Polaris10-Fläche geht, sehe ich nicht, warum sie bei Navi20 dann ne halbgare Kompromisslösung machen sollten wofür sie am Ende (womöglich deutlich) weniger Geld verlangen können.

Was glaubst du wofür man sich bei einem teuren 7nm+ Fertigungsprozess entscheidet? Der neuere Prozess sollte auch etwas mehr Spielraum beim Takt geben.
Ich sehe einfach nicht, dass Navi mit 64 CUs so linear skalieren würde, dass es für ne 2080 Ti (geschweige denn die Super Variante) reichen würde. Und das wäre einfach eine verschenkte Gelegenheit.

Außerdem: Wenn N20 nicht mehr als 64 CUs bekommt, ist er im Grunde fast DOA für alles außer Spiele, für die Mischkalkulation und Umsätze wäre es aber besser, wenn man den auch im AI-HPC-Bereich und Workstation-Bereich als Nachfolger von Vega10 bringen könnte, da wären ein paar mehr als 64 CUs schon ganz gut, wenn man in diesen Märkten nicht engültig komplett verdrängt werden will...

[Gipsel]

Tipp ins Blaue für Navi20 (Vergleichswerte von Navi10):
72 CUs in 6 Shaderengines (statt 4) mit jeweils 6 WGPs (also 12 CUs statt 10) in <=400mm².

[Denniss]

Kommen eigentlich auch noch Navis im 100 und 200€ Bereich? Oder wird das weiterhin von RX570, 580 bis 200€ und Vega 56 200-300€ abgedeckt werden?Die Vega 56/64 werden sicherlich dieses Jahr auslaufen da durch die 5700 ersetzt. Ich hoffe ja das im Herbst/Winter wenigstens ein Ersatz für die großen Polaris kommt.

[Langlay]

Ich mein Tipp wäre Navi20 = 2x Navi10 also 80CU allerdings mit HBM. Das sollte immernoch <500mm² Die size geben, also quasi so gross wie Vega10. Mit HBM2E und 2 Stacks hätte das Ding 820GB/s an Bandbreite das sollte ja auch reichen. Navi10 hat ja auch "nur" 448GB/s.

[Ravenhearth]

Falls Navi20 auch als vollständige Ablöse für Vega20 gedacht ist, wird der sicher 4 Stacks bekommen. Aber die muss man für Consumer ja nicht alle bestücken, oder?

[Monsta]

Wenn du die 56 und 64 auf einen gleichen Verbrauch bringst, schlägt das halt weit unter 13% durch. So viel Unterschied ist dort nicht gewesen und und die Unterschiede waren je nach Spiel auch deutlich unterschiedlich.
Bei dem einen Game waren es mal 1-2%, bei dem anderen 4-6%.

Wen interessiert der Verbrauch? Wenn man die Skalierung der CUś überprüfen will nagelt man die Karten ja wohl auf einen festen Takt. Total banane die ins Powerlimit rennen zu lassen.
Ein 3 Liter Dieselmotor auf 7 Liter/100 mit Verbrauchslimit wird auch kaum schneller als ein 2 liter Diesel sein der ebensfalls auf 7 liter begrenzt ist.

[Complicated]

Tipp ins Blaue für Navi20 (Vergleichswerte von Navi10):
72 CUs in 6 Shaderengines (statt 4) mit jeweils 6 WGPs (also 12 CUs statt 10) in <=400mm².
Das halte ich für sehr realistisch. Vor allem wenn man davon ausgeht, dass Navi20 7nm+ sein wird und der Nachfolger 5nm mit noch mehr EUV-Layern.

Der 7nm DUV Prozess für Navi10 ist wohl der teuerste den es für lange Zeit geben wird und für große Chips nicht wirtschaftlich und langlebig genug mit EUV im Nacken und den damit verbundenen stark reduzierten Kosten.Hier verzögert die Big-Chip-First Strategie von Nvidia den Zeitpunkt ab wann die Produkte wirtschaftlich sind, durch die schlechteren Yields. AMD hat mit dem auslassen der 10nm und dem frühen entwickeln auf 7nm für kleine Ryzen Chiplets sicherlich 6 Monate Vorsprung bei der Wirtschaftlichkeit.

Das schnelle weiterentwickeln von 7nm DUV->7nm+ (EUV) und direkt weiter auf 5nm EUV durch AMD senkt die Kosten, da die Tools von 7nm weiter verwendet werden können für die folgenden Prozesse. Damit nimmt AMD den Vorsprung mit und reduziert das wirtschaftliche Fenster für die Konkurrenz enorm. Und das bei immer weiter sinkenden Kosten bis 5nm.

Nimmt man nun diesen Hintergrund und zieht Navi10 einen Shrink weiter und reduziert die Fläche um 15% mit 7nm+, sowie die Kosten durch weniger Layer bei EUV entsteht ein perfekter Nachfolger für Polaris der in 12nm auslaufen kann. Navi20 wird der große <400mm² Chip, der dann zeitgleich mit Nvidias 7nm+ GV104 bereit steht. Und diese können ebenfalls günstig auf 5nm runter gehen. Ich denke das ist der Grund warum Nvidia mit Samsung schneller mehr EUV auf die Chips bringen will, damit die großen Chips schneller wirtschaftlich sind.

https://www.anandtech.com/show/14228/tsmc-reveals-6-nm-process-technology-7-nm-with-higher-transistor-density
TSMC says that it expects N6 to be used for a variety of applications, including mobile SoCs, GPUs, high-performance computing chips, networking, 5G infrastructure, and other products. What remains to be seen is whether chip designers will be inclined to use N6 technology given its miniscule improvements over N7 when it comes to power, performance, and area (PPA). Perhaps, companies with complex N7-based chips will prefer to go directly to N7+, or even 5 nm (CLN5FF, N5), for their next generation parts.
TSMC will start risk production of chips using its N6 fabrication technology in the first quarter of 2020. Keeping in mind that it usually takes companies about a year to start high-volume manufacturing (HVM) after the beginning of risk production, expect N6 to be used for mass products starting from 2021.
Oder Navi10 wird in 6nm überführt wie Polaris von 14 in 12nm wenn es soweit ist
TSMC states that their N6 fabrication technology offers 18% higher logic density when compared to the company’s N7 process (1st Gen 7 nm, DUV-only), yet offers the same performance and power consumption. Furthermore, according to TSMC N6 'leverages new capabilities in extreme ultraviolet lithography (EUVL)' gained from N7+, but does not disclose how exactly it uses EUV for the particular technology. Meanwhile, N6 uses the same design rules as N7 and enables developers of chips to re-use the same design ecosystem (e.g., tools, etc.), which will enable them to lower development costs. Essentially, N6 allows to shrink die sizes of designs developed using N7 design rules by around 15% while using the familiar IP for additional cost savings.
Hier zahlen sich die einmal investierten Kosten in 7nm DUV aus noch während der nächsten shrinks. Sowohl die Designs werden billiger als auch die Wafer deutlich. Daher ist nun auch klar warum AMD mit Navi10 keinen Preisbrecher anbietet, der wird im Anschluss möglich werden.

[unl34shed]

Hat Navi eigentlich noch HBCC, weiß man da schon was drüber?

[hilo]

Sicher nicht, was Du hören willst (geht um die PS5 [also leider Navi 20] und ist nichts Offizielles), aber ich erinnere auch hier noch mal an den öfters gesposteten
Reddit-Beitrag:

Apparently they have analyzed the IO behaviour of current gen games and baked the essence of it into what they call a high bandwidth cache controller, which can then map PS4 IO commands into optimized commands for their new storage solution were appropiate (without having to make changes to the game). And it shows, our unchanged game running on the devkit loads around 32% faster then [sic] our PC build on the PM1725a. But the material further states that in order to take full advantage of it the game will have to be patched, and I can't wait to see how fast our game will load once our software engineers have made source code changes to take full advantage of the fast storage. [meine Hervorhebung, hilo]

https://www.reddit.com/r/PS5/comments/bso1jg/the_storage_solution_in_the_devkit_is_a_real_game/

Wäre also interessant, wenn die RX 5700 (XT) bei HBCC jetzt plötzlich passen würde.

[Der_Korken]

Warum sollte AMD das Konzept des HBCC aufgeben? In Szenarien, wo der VRAM nicht reicht, lief eine V64 mit HBCC on deutlich besser als ohne. Man setzt einfach in Hardware um, was sonst per Hand in Software gemacht werden würde, wenn der VRAM voll ist, nur eben deutlich feingranularer.

[hilo]

Ich glaube ja auch nicht, daß AMD das Konzept aufgibt (die Angabe, daß es in der PS5 womöglich eine überragende Rolle zu spielen scheint, legt das auch nicht nahe), aber es ist nun einmal nichts Offizielles, auf das ich verweise, und bis dahin wissen es wir halt nicht (deshalb die Formulierung "wäre also interessant", dann müßte man sich nämlich fragen warum). Aber wie gesagt, ich wüßte ebenfalls nicht, warum AMD da was ändern sollte.

Edit: Plus die Tatsache, daß ich einfach davon ausging, die Frage von unl34shed bezöge sich wohl eher auf die RX 5700 (XT), und nicht auf die PS5/Navi 20, womit ich geantwortet hatte, daher meine vielleicht zu vorsichtige Formulierung.

[Der_Korken]

Ich meinte eigentlich auch unl34shed, sorry.

Da es bei Navi auch Verbesserungen bei der DCC und der Verarbeitung dieser Daten gibt, habe ich mich gefragt, wie das mit dem HBCC interagiert. Soweit ich weiß, spart die DCC keinen Platz im VRAM ein, da sie keine Garantie für den Kompressionsfaktor garantieren kann und immer genug Platz im VRAM allokiert sein muss, um eine Textur nach Veränderung zurückschreiben zu können. Wenn in der Praxis aber in fast allen Fällen 30% Platz eingespart werden können, würde der HBCC den ungenutzten "Platzhalterspeicher" aus dem VRAM verdrängen, wenn der Platz sonst knapp wird? Damit könnte sich die 8GB-Karte praktisch wie eine 10GB-Karte verhalten. In Software dürfte das sehr aufwändig zu lösen sein.

[hilo]

So wie Du es gerade erklärt hast, hatte ich das auch in Erinnerung (keine Platzersparnis), aber ich stehe deshalb gerade etwas auf dem Schlauch, was Deine 30% betrifft. Wo kommen die her?

Edit: Du meinst die neue Kompression. Stehe wirklich auf dem Schlauch.
Edit 2: Ich schätze mal, daß selbst wenn man keine 100%-Garantie für den Kompressionsfaktor geben kann, dann dennoch die Testerei beginnt, bis zu welchem Level ein riskierter cache miss sich dennoch lohnt.

[AlterSack]

Warum sollte AMD das Konzept des HBCC aufgeben? In Szenarien, wo der VRAM nicht reicht, lief eine V64 mit HBCC on deutlich besser als ohne. Man setzt einfach in Hardware um, was sonst per Hand in Software gemacht werden würde, wenn der VRAM voll ist, nur eben deutlich feingranularer.

Mal so´ne Frage vom DAU. Funktioniert HBCC mit DDR6?
...Nur so wegen der grossen Abstände (Signalwege) der DDR-Chips zur GPU
und evtl. grösseren Latenzen. Ist nur eine dumme Frage...

[Zergra]

Funktionieren tut es garantiert, ob wirklich mehr Performance gibt, ist eine andere Sache.

Grundsätzlich müsste aber PCIe 4.0 das ganze verbessern.

[Der_Korken]

So wie Du es gerade erklärt hast, hatte ich das auch in Erinnerung (keine Platzersparnis), aber ich stehe deshalb gerade etwas auf dem Schlauch, was Deine 30% betrifft. Wo kommen die her?

Edit: Du meinst die neue Kompression. Stehe wirklich auf dem Schlauch.
Edit 2: Ich schätze mal, daß selbst wenn man keine 100%-Garantie für den Kompressionsfaktor geben kann, dann dennoch die Testerei beginnt, bis zu welchem Level ein riskierter cache miss sich dennoch lohnt.

Die 30% sind aus der Luft gegriffen. Afaik wurde von AMD damals bei Einführung ihrer DCC gesagt, dass das in Theorie ca. 30% Bandbreite einspart und deswegen der 256bit-Tonga ähnlich viel effektive Bandbreite wie der alte 384bit-Tahiti hätte.

Mal so´ne Frage vom DAU. Funktioniert HBCC mit DDR6?
...Nur so wegen der grossen Abstände (Signalwege) der DDR-Chips zur GPU
und evtl. grösseren Latenzen. Ist nur eine dumme Frage...

Ich bin eigentlich auch ein halber DAU :tongue:
Funktionieren sollte es, denn die Technik hängt nicht von einer bestimmten Speichertechnologie ab. Extra Performance an sich wird es sehr wahrscheinlich nicht geben, denn im Idealfall sind alle Daten im VRAM. Interessant wird es erst, wenn der VRAM knapp nicht reicht, das Spiel also z.B. 10GB allokiert, aber nur 8GB vorhanden sind. Der HBCC kann relativ feingranular (4kB?) Cache-Zeilen auslagern, d.h. die spannende Frage ist, ob er durch geschicktes auslagern von (fast) nicht benutzten Daten die Performance länger hochhalten kann, als es eine Karte ohne HBCC kann. Dadurch würde sich eine 8GB-Karte dann ähnlich wie eine 10GB-Karte verhalten. Das hängt sicher auch vom Spiel ab. Gerade Spiele, die auf den höchsten Texturdetails einfach nur alles unkomprimiert in den VRAM laden, müssten nach meiner Vorstellung enorm profitieren.

[Spasstiger]

Schade, dass das Preisniveau für Grafikkarten auch bei AMD steigt. Die Mittelklasse etabliert sich bei 300-500 €, Vega 56 dürfte auslaufen.

[Ravenhearth]

Das ganze erinnert mich an den Umstieg auf 28nm/GCN. Dort ging die 7970 für $549 ins Rennen, die 7950 war so teuer wie die GTX 580 und die 7870 sollte $349 kosten. AMD hat also damals das aktuelle Preisniveau direkt übernommen, ohne mehr Perf/€ zu bieten. Das hielt allerdings nicht lange an, und schon ein paar Monate später gabs die Karten deutlich günstiger. ;)

[Gipsel]

Da es bei Navi auch Verbesserungen bei der DCC und der Verarbeitung dieser Daten gibt, habe ich mich gefragt, wie das mit dem HBCC interagiert.
Soweit ich weiß, spart die DCC keinen Platz im VRAM ein, da sie keine Garantie für den Kompressionsfaktor garantieren kann und immer genug Platz im VRAM allokiert sein muss, um eine Textur nach Veränderung zurückschreiben zu können. Wenn in der Praxis aber in fast allen Fällen 30% Platz eingespart werden können, würde der HBCC den ungenutzten "Platzhalterspeicher" aus dem VRAM verdrängen, wenn der Platz sonst knapp wird? Damit könnte sich die 8GB-Karte praktisch wie eine 10GB-Karte verhalten. In Software dürfte das sehr aufwändig zu lösen sein.HBCC kümmert sich erstmal überhaupt nicht um DCC. Da wird nur auf den Speicherzugriff auf der Ebene von ganzen Pages (vermutlich immer noch 64kB) geschaut, also wie lange ist es her, daß es in dem jeweiligen Bereich Speicherzugriffe gab. Liegt das lange zurück, kann die Page offenbar aus dem VRAM geschmissen werden, wenn etwas Anderes benötigt wird. Und DCC schafft extrem wahrscheinlich keine freien Pages (sondern nur teilweise gefüllte). Zudem wirkt DCC ja nur auf das, was die ROPs schreiben (klassischerweise der Framebuffer, heute aber auch etliche andere Buffer [Shadow-Buffer, G-Buffer bei deferred Renderern ...]). Gemeinsamkeit ist, daß dies typischerweise jeden Frame (oder zumindest alle paar Frames) geschieht, die also typischerweise nicht als kaum genutzt klassifiziert werden können und damit sowieso kaum für die Auslagerung per HBCC in Frage kommen.
Achja, daß man eine Textur modifiziert, also eine die von der Platte geladen wurde, ist nicht so häufig. Die Texturen liegen ja meist in einem bereits komprimiertem Format (verlustbehaftet, aber höhere und garantierte Kompression) vor, was die GPU direkt lesen (aber nicht schreiben) kann. Hier spielt DCC also keine Rolle. Allerdings erkennt HBCC ungenutzte Texturen (oder auch Teile davon, z.B. MipMap-Level) auf Page-Basis und kann die in den Hauptspeicher auslagern. Dies dürfte in Spielen der Hauptanwendungsfall sein.
Mal so´ne Frage vom DAU. Funktioniert HBCC mit DDR6?Na klar.
...Nur so wegen der grossen Abstände (Signalwege) der DDR-Chips zur GPU
und evtl. grösseren Latenzen. Ist nur eine dumme Frage...Die Latenz des VRAMs ist für HBCC ziemlich unerheblich. Wichtiger ist die (langsame) Verbindung von der GPU zur CPU (und von der zum Hauptspeicher). Also der Flaschenhals momentan ist eher PCIe3 (16GB/s) oder später dann PCIe4 (32GB/s). ;)

[Daredevil]

Vielleicht habe ich es übersehen, aber waren die Software Features ( Besseres Streaming, der Low Latency Mode ) ect. jetzt eigentlich Navi exklusive Features oder kommen da auch Vega/VII Menschen mit in Kontakt? bzw. sind es überhaupt Software Features? :D

[Linmoum]

Bei Anti-Lag steht auf der Folie "GCN and newer". Ich würde jetzt einfach mal vermuten, dass das auch auf den Rest zutrifft.

[Ravenhearth]

Afaik ist nur das Image Sharpening Navi-exklusiv.

[smalM]

Ich könnte mir aber durchaus einen kleinen Refresh von Navi 10 in 7nm+ mit höheren Taktraten vorstellen.

Der Wechsel von N7 auf N7+ benötigt immer ein Redesign, es gibt da also keinen kleinen Refresh; wirtschaftlich ergibt das wenig Sinn.

Oder Navi10 wird in 6nm überführt wie Polaris von 14 in 12nm wenn es soweit ist
[...]
Hier zahlen sich die einmal investierten Kosten in 7nm DUV aus noch während der nächsten shrinks.

Den Shrink bekommt man bei N6 auch nicht geschenkt, es wird ein "New Tapeout" benötigt, was zwar nichts anderes als ein Redesign mit N6 Bibliotheken ist, aber immer noch deutlich weniger aufwendig (= preiswerter zu haben) ist, als N7+.
Wahrscheinlicher mag ein "Re-Tapeout" in N6 sein, was dann allerdings keinen Shrink mit sich bringt, wohl aber Vorteile in der Produktion, also auch die Stückkosten verringert.

[Der_Korken]

[...]
Und DCC schafft extrem wahrscheinlich keine freien Pages (sondern nur teilweise gefüllte).
[...]


Danke für die ausführliche Erklärung. Ich habe oben mal den für mich entscheidenden Satz stehen lassen. Damit ist mein voriger Beitrag natürlich obsolet.

[Lard]

Vielleicht habe ich es übersehen, aber waren die Software Features ( Besseres Streaming, der Low Latency Mode ) ect. jetzt eigentlich Navi exklusive Features oder kommen da auch Vega/VII Menschen mit in Kontakt? bzw. sind es überhaupt Software Features? :D
Any GPU that previously used Radeon Chill can take advantage of these improvements.
Anti-lag is supported in DX11 on all AMD GPUs. Support for DX9 games is a Navi-only feature. DX12 games are not currently supported due to dramatically different implementation requirements in that API.
RIS is a Navi-only feature and is only supported in DX12 and DX9.
The Contrast Adaptive Sharpening tool can be used on any GPU if developers want to do so.
https://www.extremetech.com/gaming/293205-beyond-hardware-amds-planned-software-improvements-for-navi-gcn

[aufkrawall]

wtf is this fragmentation? :confused:

[nagus]

falls schon vorher gepostet wurde hier, sorry.

https://www.reddit.com/r/realAMD/comments/c1d6u6/revised_rx_5700_xt_and_rx_5700_launch_versus_rx/

da hat sich jemand sehr viel mühe gemacht preise und performance der letzten grafikkarten generationen von amd und nvidia zu vergleichen.

Navi ist auf alle fälle ein Schritt in die richtige Richtung! Trotz extremer Preise bei Nvidia sind bei AMD die Preise gefallen und die Performance gestiegen im Vergleich zu Vega. Und Leute, hört mir bitte auf mit dem Gejammer von wegen Die Größe und dass es in Wirklichkeit ja nur ein Polaris Nachfolger ist. Was am Ende zählt ist die Leistung.

[x-force]

Was am Ende zählt ist die Leistung.

was am ende zählt ist, daß sich genügend idioten finden, die jeden preis bezahlen.

diese zahlesel finden dann auch gründe, warum ein produkt zu ähnlichen fertigungskosten im laufe der zeit einen immer höheren preis rechtfertigt.

[BoMbY]

Ist das ein Talkingpoint der vom zentralen NVidia-Astroturfing-Kommando vorgegeben wurde?

[robbitop]

Den Shrink bekommt man bei N6 auch nicht geschenkt, es wird ein "New Tapeout" benötigt, was zwar nichts anderes als ein Redesign mit N6 Bibliotheken ist, aber immer noch deutlich weniger aufwendig (= preiswerter zu haben) ist, als N7+.
Wahrscheinlicher mag ein "Re-Tapeout" in N6 sein, was dann allerdings keinen Shrink mit sich bringt, wohl aber Vorteile in der Produktion, also auch die Stückkosten verringert.
Bei 14 nm -> 12 nm brauchte man keine neuen Masken. Das war ja das Tolle. Wurde 6nm nicht mit ähnlichem beworben?

[dargo]

Der Wechsel von N7 auf N7+ benötigt immer ein Redesign, es gibt da also keinen kleinen Refresh; wirtschaftlich ergibt das wenig Sinn.

Mit kleinen Refresh meine ich natürlich wenig Mehrleistung. Analog zu RX590 vs. RX580.

[Complicated]

Hier ist es ganz gut zusammengefasst. Man muss aber auf die Begrifflichkeiten achten:
https://www.anandtech.com/show/14290/tsmc-most-7nm-clients-will-transit-to-6nm
Die selben Tools sparen Geld und die selben Designrules sparen Geld und Zeit.

7nm bis zu 5nm sind ja keine wirklichen shrinks am Transistor. Hier geht es lediglich um die Anzahl der EUV Layer im Prozess:
7nm keine
7nm+ 4 Layer
6nm 5 Layer
5nm 14 Layer

Auch gut zu sehen, dass keine großen Performancesprünge zu erwarten sind.

[robbitop]

Man bekommt offenbar ein bisschen Power (~10%) und Density (~15%) bei 7+/6nm. Performance bleibt gleich.
Das könnte man zumindest in Transistoren investieren. -> 10-15% mehr Transistoren -> mehr Performance.
Ggf. kann man sogar noch etwas mehr Transistoren investieren, da Prozesse reifer und günstiger (EUV, Abschreibungen schon etwas weiter fortgeschritten) geworden sein könnten.

[HOT]

AMD wird mMn 6nm nur im GPU-Bereich machen, nicht im CPU-Bereich. Wenn man schon in 7FF+ produziert lässt man das auch bis 5FF laufen.

[iuno]

Kann man fuer 6 nicht dieselben Masken benutzen? EUV wird ja schon mit 7+ eingefuehrt.
Da man jaehrlich Produkte bringt, ob refresh oder neu, ergibt es doch keinen Sinn, dann zu bleiben. Ausser natuerlich, es gibt keine Kapazitaet.

[basix]

5nm 14 Layer

Vermutlich ist das ein Up to?! Weil heutige Chips haben total ca. 12-15 Layer, da kann ich mir nicht vorstellen, dass man sogar die obersten Metal-Layer im Mikrometer Massstab mit EUV behandelt. Das wäre totaler Overkill von Ressourcen.

[y33H@]

Natürlich ist das ein 'up to' für kommende Nodes.

[Complicated]

Das ist der Vierfach Belichtung geschuldet. Daher verringert jeder EUV Layer um 4 DUV-Masken. 12 mal 4 ergibt die hohen Zahlen der Masken und Kosten.

[HOT]

Kann man fuer 6 nicht dieselben Masken benutzen? EUV wird ja schon mit 7+ eingefuehrt.
Da man jaehrlich Produkte bringt, ob refresh oder neu, ergibt es doch keinen Sinn, dann zu bleiben. Ausser natuerlich, es gibt keine Kapazitaet.
Dafür ist 5nm zu nah dran. Vermeer ist sicherlich 7nm+ und Zen4 passt ja gut zum Zeitplan für 5nm. Für APUs und GPUs ist 6nm hingegen sicherlich interessant, wobei grad für GPUs 5nm noch viel interessanter ist.

[Raff]

Zu der hier verlinkten RDNA-Präsentation noch ein paar kleine Anmerkungen:

Falls man der Darstellung da trauen kann, beträgt die Latenz einer arithmetischen vALU-Instruktion jetzt 5 Takte (statt vorher 4). [...]

Um das nochmal aufzugreifen: Wie kommst du denn auf 5 Zyklen? AMD zeigt in den Folien ein konkretes Shader-Beispiel, bei dem Navi schlimmstenfalls zwei Takte braucht (Wave64-Modus) und bestenfallls nur einen (Wave32-Modus). Entsprechend formuliert man eine "Per work item IPC", die doppelt bis viermal so hoch ist wie die von GCN. Das ist doch der Grundgedanke hinter der ganzen "Dual Compute Unit"-Geschichte, bei der quasi alles verdoppelt wurde. Ernstgemeinte Frage an dich als Fachmann, ich raffe deinen Gedankengang nämlich nicht. :)

MfG,
Raff

[Gipsel]

Um das nochmal aufzugreifen: Wie kommst du denn auf 5 Zyklen? AMD zeigt in den Folien ein konkretes Shader-Beispiel, bei dem Navi schlimmstenfalls zwei Takte braucht (Wave64-Modus) und bestenfallls nur einen (Wave32-Modus). Entsprechend formuliert man eine "Per work item IPC", die doppelt bis viermal so hoch ist wie die von GCN. Das ist doch der Grundgedanke hinter der ganzen "Dual Compute Unit"-Geschichte, bei der quasi alles verdoppelt wurde. Ernstgemeinte Frage an dich als Fachmann, ich raffe deinen Gedankengang nämlich nicht. :)Jeder Pipeline der FPU in einer CPU kannst Du auch jeden Takt einen neue Instruktion anbieten, solange die unabhängig ist. Das Wunder des Pipelinings ;).
Die Latenz sagt dagegen aus, wie viele Takte vergehen müssen, bevor man eine abhängige Instruktion (also eine, die das Ergebnis einer vorherigen Instruktion als Eingabewert benutzt) ausführen kann. Und das sind nach dem Beispiel auf Seite 14 nunmal 5 Takte für die Allerwelts-vALU-Instruktion v_mul_f32 bei RDNA (dort gekennzeichnet als "vALU dependency stall on v0").
Bei GCN liegt man da bei 4 Takten, was zusammen mit dem Instruktionsissue über 4 Takte bedeutet, daß es keine Stalls auf einem SIMD wegen der ALU-Latenz gibt (für die gebräuchlichsten Instruktionen). GCN erlaubte also back-to-back-issue abhängiger Instruktionen (apparent latency = 1 Scheduler-Takt), RDNA erlaubt das nicht und benötigt mehrere Waves pro SIMD (oder unabhängige Instruktionen für eine Wave), um keine Bubbles wegen der ALU-Latenz zu produzieren.

Edit:
Maxwell und Pascal liegen übrigens bei 6 Zyklen ALU-Latenz, Turing vermutlich auch (habe aber noch keinen Test dazu gesehen).

[elhomomomo]

RDNA erlaubt das nicht und benötigt mehrere Waves pro SIMD (oder unabhängige Instruktionen für eine Wave), um keine Bubbles wegen der ALU-Latenz zu produzieren.


Ergo ist Treiberarbeit noch essentieller?

[Gipsel]

Ergo ist Treiberarbeit noch essentieller?Nein, das heißt das nicht. Der Shadercompiler muß auf etwas andere Dinge achten, aber das war es dann auch schon bald.
Wie schon mal gesagt, wäre es schön zu wissen, wie genau die Beschränkungen von RDNA bezüglich der Extraktion von ILP aus dem Code aussehen (das können die bisherigen GCN-Karten gar nicht), weil das beeinflußt, was der Compiler optimalerweise tun sollte.

[BlacKi]

mitarbeiter von NV glauben, dass das feature radeon anti lag nicht viel mehr sei als maximum prerendered frames auf 1.:|

https://www.pcgameshardware.de/Radeon-RX-5700-XT-Grafikkarte-274775/News/Nvidia-zuRadeon-Image-Sharpening-undRadeon-Anti-Lag-1284620/

[Brillus]

Bei 14 nm -> 12 nm brauchte man keine neuen Masken. Das war ja das Tolle. Wurde 6nm nicht mit ähnlichem beworben?

Soweit ich weiß kann man die Masken der oberen Layern weiter verwenden unten ist EUV. Die sind ganz neu.

[Ravenhearth]

Man bekommt offenbar ein bisschen Power (~10%) und Density (~15%) bei 7+/6nm. Performance bleibt gleich.
Das könnte man zumindest in Transistoren investieren. -> 10-15% mehr Transistoren -> mehr Performance.
Ggf. kann man sogar noch etwas mehr Transistoren investieren, da Prozesse reifer und günstiger (EUV, Abschreibungen schon etwas weiter fortgeschritten) geworden sein könnten.
Auf der letzten Seite wurde zu 6nm zitiert:
TSMC states that their N6 fabrication technology offers 18% higher logic density when compared to the company’s N7 process (1st Gen 7 nm, DUV-only), yet offers the same performance and power consumption.

[Birdman]

mitarbeiter von NV glauben, dass das feature radeon anti lag nicht viel mehr sei als maximum prerendered frames auf 1.:|
Dies entspräche zumindest genau dem was auch ich mir hierzu gedacht habe.
Wüsste auch nicht was man sonst für eine magic sauce auspacken könnte, um die (input) Latenz auf Stufe Grafik- Karte/Treiber zu senken.

Aber vermutlich ist nVidia etwas angepisst, weil es ihnen nie eingefallen ist dem ganzen Ding einen fancy Marketingbegriff zu verpassen, um es an die eSports Community verkaufen zu können.

[robbitop]

Wobei die Density in der Hauptsache auf Logik und SRAM begrenzt ist. Man sieht ja an Mavi und Vega 7 mit einiges an Interfaceanteil, dass aus 100% Skalierung der Density (theoretisch) nur 70% in der Praxis waren.

[N0Thing]

mitarbeiter von NV glauben, dass das feature radeon anti lag nicht viel mehr sei als maximum prerendered frames auf 1.:|

https://www.pcgameshardware.de/Radeon-RX-5700-XT-Grafikkarte-274775/News/Nvidia-zuRadeon-Image-Sharpening-undRadeon-Anti-Lag-1284620/

Ich dachte, seit der Radeon Software Crimson Edition wäre bei AMD maximum prerendered frames auf 1 der Standard. Falls nicht, ist es natürlich an der Zeit und würde erklären, wie AMD den Sprung bei der Latenz erreichen konnte.

[dargo]

mitarbeiter von NV glauben, dass das feature radeon anti lag nicht viel mehr sei als maximum prerendered frames auf 1.:|

https://www.pcgameshardware.de/Radeon-RX-5700-XT-Grafikkarte-274775/News/Nvidia-zuRadeon-Image-Sharpening-undRadeon-Anti-Lag-1284620/
Glauben ist nicht wissen. Ergibt auch keinen Sinn denn prerenderlimit 1 ist schon lange im Treiber implementiert. Und das kannst du auch nicht ändern.

[Screemer]

Glauben ist nicht wissen. Ergibt auch keinen Sinn denn prerenderlimit 1 ist schon lange im Treiber implementiert. Und das kannst du auch nicht ändern.

Zumindest hieß es das. Gab's da auch Mal was offizielles zu?

[aufkrawall]

Zumindest hieß es das. Gab's da auch Mal was offizielles zu?
1min Googlen:
(...) die Flip Queue Size wurde für einen geringeren Input-Lag reduziert...
https://www.computerbase.de/2015-11/amd-treiber-crimson-test/6/

https://abload.de/img/vc_amd-crimson-driveryvk85.jpg (https://abload.de/image.php?img=vc_amd-crimson-driveryvk85.jpg)

[Birdman]

blubb, hier stand mist

[Screemer]

1min Googlen:

https://www.computerbase.de/2015-11/amd-treiber-crimson-test/6/

https://abload.de/img/vc_amd-crimson-driveryvk85.jpg (https://abload.de/image.php?img=vc_amd-crimson-driveryvk85.jpg)
danke, dass du die investiert hast. ob das allerdings bei den neuen apis (dx12, vulkan) auch so ist, steht da nicht.

[aufkrawall]

danke, dass du die investiert hast. ob das allerdings bei den neuen apis (dx12, vulkan) auch so ist, steht da nicht.
Von AMD werden nur die alten APIs genannt und durch die Presse wie extremetech heißt es, kein DX12 (und somit sicherlich auch kein Vulkan). Ich weiß jetzt nicht, wo da dein Problem ist?

[Gipsel]

Glauben ist nicht wissen. Ergibt auch keinen Sinn denn prerenderlimit 1 ist schon lange im Treiber implementiert. Und das kannst du auch nicht ändern.
Vielleicht ist das anti-Lag ja die Option für Prerenderlimit 0, also gar kein Prerendern. Das nächste Frame wird erst gestartet, nachdem das gerade gerenderte am Monitor erscheint (also zum Bufferflip). Das sollte man aber vermutlich nicht global aktivieren, denn da dürfte die durchschnittliche Framerate schon nach unten gehen. Aber in rein GPU-limitierten Szenarien (oder bei VSync durch Refreshrate des Monitors limitiert) dürfte der Effekt auf die Framerate sehr klein bis nicht vorhanden sein, die Latenz sinkt aber.

[Screemer]

Von AMD werden nur die alten APIs genannt und durch die Presse wie extremetech heißt es, kein DX12 (und somit sicherlich auch kein Vulkan). Ich weiß jetzt nicht, wo da dein Problem ist?
welches problem? es war ne simple frage. ich würde jetzt schlicht folgern, dass antilag das ganze für dx12 und vulkan umsetzt oder prerender gar nicht mehr passiert und schlicht der frame der grad gerendert wurde angezeigt wird und erst dann ein neuer frame gerendert wird.

[aufkrawall]

welches problem? es war ne simple frage. ich würde jetzt schlicht folgern, dass antilag das ganze für dx12 und vulkan umsetzt.
Eben nicht, es geht um eine weitere Verringerung für DX11 und 9:
https://www.extremetech.com/wp-content/uploads/2019/06/Navi-Software-3.jpg

[HarryHirsch]

die frage ist eher warum sie, nach den folien, schon wieder irgendwelchen murks verbreiten

[dargo]

welches problem? es war ne simple frage. ich würde jetzt schlicht folgern, dass antilag das ganze für dx12 und vulkan umsetzt oder prerender gar nicht mehr passiert und schlicht der frame der grad gerendert wurde angezeigt wird und erst dann ein neuer frame gerendert wird.
Bei DX12/Vulkan würde ich davon ausgehen, dass die Applikation das unter Kontrolle hat. Bei Division 2 gibt es bsw. eine extra Option Ingame um den Inputlag @DX12 weiter zu reduzieren.

[Screemer]

Eben nicht, es geht um eine weitere Verringerung für DX11 und 9:
https://www.extremetech.com/wp-content/uploads/2019/06/Navi-Software-3.jpg
thx. das hatte ich nicht gesehen.

[Locuza]

[...]
Edit:
Maxwell und Pascal liegen übrigens bei 6 Zyklen ALU-Latenz, Turing vermutlich auch (habe aber noch keinen Test dazu gesehen).
https://abload.de/img/turing-latency7wjkk.jpg
Seite 40:
https://arxiv.org/pdf/1903.07486.pdf

[BoMbY]

Navi Code incoming:

https://lists.freedesktop.org/archives/amd-gfx/2019-June/035170.html

[aufkrawall]

Hoffentlich erfüllen sich mit Navi endlich die Hoffnungen an vernünftige Energiesparmodi + Video-Fähigkeiten gleichzeitig unter Linux. Das gibts bisher nur mit Intel, halt mit anderweitig schrottigen GPUs. :redface:

[BoMbY]

Immer das (https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next-navi10&id=019d9cdfd8a698762897a856f4c37f6a0b149d00) ist schon mal eine Bestätigung von weiteren Code-Nummern:


+ NV_NAVI10_P_A0 = 1,
+ NV_NAVI12_P_A0 = 10,
+ NV_NAVI14_M_A0 = 20,
+ NV_NAVI21_P_A0 = 40,
+ NV_NAVI10_LITE_P_A0 = 0x80,
+ NV_NAVI10_LITE_P_B0 = 0x81,
+ NV_NAVI12_LITE_P_A0 = 0x82,
+ NV_NAVI21_LITE_P_A0 = 0x90,


Leider hab ich immer noch nicht gesehen was die LITE-Dinger erklärt.

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next-navi10&id=365c63817f874dd337df49c5fb490d9cf1a4052b:

MES takes over the scheduling capability of GFX and SDMA, add MES as a standalone ip.


https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next-navi10&id=d70ba0e38c69feca9d5246a02b8e16b4fe380e15:


MES (Micro Engine Scheduler) is the new on chip hw scheduling microcontroller. It can be used to handle queue scheduling and preemption and priorities.

[Ravenhearth]

Wait, Navi21 statt Navi20?

[Locuza]

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next-navi10&id=b8d7458cdba913abcb43ed18d78d6e0ebe8b226f
adev->gmc.vram_type = amdgpu_atomfirmware_get_vram_type(adev);
+ switch (adev->asic_type) {
+ case CHIP_NAVI10:
+ /*
+ * To fulfill 4-level page support,
+ * vm size is 256TB (48bit), maximum size of Navi10,
+ * block size 512 (9bit)

Vega10 hatte ein 49-Bit Adress Space.

[KodeX]

Ich finde die Navi-Grafikkarten zwar auch etwas teuer, aber der Polaris-Vergleich ist meiner Meinung nach nicht ganz gerechtfertigt. Die RX 480 hatte gerade mal das Performance-Niveau einer R9 390. In der Vorgängergeneration gab es mindestens fünf schnellere Gaming-Grafikkarten (R9 Fury X, R9 Fury, R9 Fury Nano, R9 390X, R9 295X2) und auch zwei gleichschnelle (R9 390, R9 290X). Die Radeon RX 5700 XT und RX 5700 haben eigentlich nur die 650 Euro teure VII vor sich. Ich halte die Preisgestaltung also nicht für unfair.

[Gipsel]

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next-navi10&id=b8d7458cdba913abcb43ed18d78d6e0ebe8b226f
adev->gmc.vram_type = amdgpu_atomfirmware_get_vram_type(adev);
+ switch (adev->asic_type) {
+ case CHIP_NAVI10:
+ /*
+ * To fulfill 4-level page support,
+ * vm size is 256TB (48bit), maximum size of Navi10,
+ * block size 512 (9bit)
+ */
+ amdgpu_vm_adjust_size(adev, 256 * 1024, 9, 3, 48);
+ break;

Vega10 hatte ein 49-Bit Adress Space.
Die gleiche Stelle für Vega:
case CHIP_VEGA10:
case CHIP_VEGA12:
case CHIP_VEGA20:
/*
* To fulfill 4-level page support,
* vm size is 256TB (48bit), maximum size of Vega10,
* block size 512 (9bit)
*/
/* sriov restrict max_pfn below AMDGPU_GMC_HOLE */
if (amdgpu_sriov_vf(adev))
amdgpu_vm_adjust_size(adev, 256 * 1024, 9, 3, 47);
else
amdgpu_vm_adjust_size(adev, 256 * 1024, 9, 3, 48);
break;;)
Das bezieht sich offenbar auf den GPU-internen Speicher. Mit dem Bit 49 geht man ja auf die CPU. Das hier ist identisch für Vega und Navi (GMC9.0 vs GMC 10.0):GMC9:
/* Set the internal MC address mask
* This is the max address of the GPU's
* internal address space.
*/
adev->gmc.mc_mask = 0xffffffffffffULL; /* 48 bit MC */

GMC10:
/*
* Set the internal MC address mask This is the max address of the GPU's
* internal address space.
*/
adev->gmc.mc_mask = 0xffffffffffffULL; /* 48 bit MC */

[Locuza]

Ich nehme an bei Polaris sind es dort auch 48-Bit, aber iirc gibt es dort nur zwei unterschiedliche Page-Größen.

Interessant wären Merkmale bezüglich der HBCC-Funktionalität.
Da habe ich auch nichts Gescheites auf die Schnelle zu Vega12 (Vega 16/20 Pro bisher) gefunden, nur ein paar Texte von heise und anderen das HBCC mit dabei ist, aber pauschal vertrauen tue ich den Seiten definitiv nicht.

[horn 12]

Navi Custom Lösungen nicht vor Mitte August:

https://www.fudzilla.com/news/graphics/48893-custom-radeon-rx-5700-cards-come-in-mid-august

[Taigatrommel]

Wie anzunehmen war, wird es die Jubiläumsausgabe der 5700XT nur in den USA und China geben:
https://videocardz.com/newz/amd-radeon-rx-5700-xt-50th-anniversary-edition-only-for-usa-and-china
Bei der Jubiläumsversion der Radeon VII war es genauso, da diese ausschließlich von AMD selbst bzw. in China über einen großen Vertriebspartner verkauft wurde.

[maximus_hertus]

Ist kein Verlust. Im August kommen die eh dramatisch besseren Customs. AMD kann eh keine vernünftigen (aka keine Turbine) Refdesigns.

[Ravenhearth]

Stimmt auch einfach nicht (https://www.reddit.com/r/Amd/comments/c2ewog/amd_radeon_rx_5700_xt_50th_anniversary_edition/erk4gjd/)

[BlacKi]

Stimmt auch einfach nicht (https://www.reddit.com/r/Amd/comments/c2ewog/amd_radeon_rx_5700_xt_50th_anniversary_edition/erk4gjd/)
ab wann? 6 monate später oder wie? ich verstehe auch nicht, warum man als deutscher nicht in den usa bestellen kann.

[[MK2]Mythos]

ab wann? 6 monate später oder wie? ich verstehe auch nicht, warum man als deutscher nicht in den usa bestellen kann.
Kannst du, sogar (us)steuerfrei. Wenn du den Umweg über Dienstleister wie shipito.com gehst.

[Taigatrommel]

Stimmt auch einfach nicht (https://www.reddit.com/r/Amd/comments/c2ewog/amd_radeon_rx_5700_xt_50th_anniversary_edition/erk4gjd/)

Stimmt, es wurde revidiert. Zu schade das dies nicht für die rote VII gilt

[BlacKi]

Ich bin mir nicht sicher ob der Preis wirklich das große Fragezeichen ist, denn schließlich muss Navi auch in Konsolen verbaut werden und Konsolen haben einen ganz bestimmten Preis.. Ich tippe also so in etwa auf 200€ für die 5700 und 300 € für die 5700XT, mal schauen was dabei rauskommt.
Customs bekommen nochmal nen Fuffi Aufschlag und gut ist.
ganz knapp:biggrin:

auch nicht schlecht:
die erste kaufbare navi, wird die vega64 sehr deutlich hinter sich lassen, versprochen ;)

[Daredevil]

Tjo, so ist das ganze halt recht langweilig. :- )
War dann wohl eher Wunschdenken.

Aber mal schauen, wie sich die Preise so entwickeln bzw. wie viele Spiele dort gebundlet sind.

[BoMbY]

Scheint so als wäre die RX 5700 XT wohl mal eine RX 690 gewesen: https://www.pcgamesn.com/amd/radeon-rx-5700-xt-690-graphics-card-e3

[Ravenhearth]

Ich wünschte sie wären dabei geblieben...

[SKYNET]

ganz knapp:biggrin:

auch nicht schlecht:

was ist an 10% knapp?

[KrisNeme]

Also, wegen 10% wechsel ich nicht von meiner Vega 64. ;-)

[SKYNET]

Also, wegen 10% wechsel ich nicht von meiner Vega 64. ;-)

warte dochmal die customs ab... ;)

[BlacKi]

was ist an 10% knapp?
das ganz knapp ging an an 300$ speku vs 449$ reveal

die 10-15% sind nicht deutlich schneller so wie von dir versprochen.

[r3ptil3]

Ich bin gespannt, ob ich als 1080 TI Besitzer evtl. vielleicht sogar irgendeinen Vorteil hätte bei einem Umstieg.

Ein AMD System (3900X, 5700 XT) wäre schon was reizendes.

[Der_Korken]

Ich bin gespannt, ob ich als 1080 TI Besitzer evtl. vielleicht sogar irgendeinen Vorteil hätte bei einem Umstieg.

Performance-technisch ganz sicher nicht. Im Gegenteil.

[SKYNET]

Ich bin gespannt, ob ich als 1080 TI Besitzer evtl. vielleicht sogar irgendeinen Vorteil hätte bei einem Umstieg.

Ein AMD System (3900X, 5700 XT) wäre schon was reizendes.


ne... 11GB, mehr power...

[Leonidas]

Annahmen zu: AMD Navi 21

- gedacht als HighEnd/Enthusiasten-Cip oberhalb von Navi 10, eine Zweitverwendung im Profi-Segment ist nicht unwahrscheinlich
- Grafikchip-Architektur ist RDNA1 (größere Chance) oder RDNA2 (kleinere Chance)
- Chipfertigung in TSMCs' 7FF oder 7FF+
- geschätzt 380-440mm² Chipfläche
- angenommen 64-80 Shader-Cluster mit 4096-5120 Shader-Einheiten
- Speicherinterface ist entweder 384 Bit GDDR6 oder 2048-4096 Bit HBM2
- Stromverbrauch dürfte nahe an die 300-Watt-Grenze gehen
- Speicherbestückung ist (je nach Speicherinterface) 12 GB GDDR6, 12 GB HBM2 oder 16 GB HBM2
- sollte sich in der Spitze durchaus mit einer GeForce RTX 2080 Ti anlegen können
- Verkaufsname sollte regulär die "Radeon RX 5800" Serie sein, denkbar ist aber auch ein (teilweiser?) Sondername
- Terminlage ist derzeit nur ungenau das Jahr 2020

Quelle:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-2223-juni-2019

[HOT]

Entweder der Chip kommt zeitnah und hat RDNA1 und 7FF oder er kommt nächstes Jahr und hat RDNA2 und 7FF+. Zweiteres ist wahrscheinlich, ersteres tendiert die Wahrscheinlichkeit gegen 0. Warum sollte man was ohne EUV bringen, wenn der Prozess doch gut verfügbar ist? Das macht keinen Sinn. Und 2020 ist bei AMD ganz klar und offiziell RDNA2 angegeben (und 7nm+ übrigens). Da gibts keinen Zweifel.
Auch denke ich, dass N21 was ganz anderes ist und die Chips nächstes Jahr unter anderem Namen laufen werden. N21 kann alles mögliche sein, ein kleiner Grafikchip, ne Custom-APU/GPU oder was weiss ich, das muss kein großer Grafikchip sein. Auch ein reiner Profichip als V20-Ablöse wär denkbar.
12GB HBM halte ich für Unfug, das ist nur bei Salvage denkbar. Ich denke, dass man man HBM verwendet ist 90% zu 10% GDDR6. 16GB sind damit gesetzt. Man wird mMn in jedem Fall seine aufgebaute HBM-Lieferstruktur weiternutzen.

[Linmoum]

RDNA 1.0 würde auch bedeuten kein RT, was aber definitiv nächstes Jahr kommt. Wo ergibt das Sinn wenn nicht bei N21 als (potentieller) High-End-Lösung?

Wenn wir davon ausgehen, dass N21 der bisher spekulierte N20 ist, dann kann man sowieso vom nächsten Jahr ausgehen. Und wie HOT schon sagt sind RDNA 2.0 und 7nm+ dort gesetzt.

[HOT]

Wenn AMD es ernst meint mit der Rückkehr in das Enthusiastensegment, dann wären sogar 2 Chips denkbar. Einer mit 350-400mm² und einer mit 450mm²+, also 64-72CUs und einer mit >=96 CUs oder so. Die jetzigen Navis werden sowieso wieder refresht. Auch Leos Nummernspeku halte ich für falsch.
Die 5000er sind die Initialserie, aber die neuen Chips werden eh 6000. Und N10 bekommt bestimmt aktiviertes "software-"RT und wird in 7nm+ refresht werden, sobald die neuen Spruchreif sind oder kurz danach.
RDNA wird sowieso keine RT-Cores bekommen, wer sich das vorstellt ist mMn eh auf dem Holzweg. Man wird die CUs so optimieren, dass sie möglichst effizient mit RT umgehen können.

[Leonidas]

12GB HBM halte ich für Unfug, das ist nur bei Salvage denkbar.


3072 Bit Interface? HBM ist sehr flexibel, was das angeht.

[nordic_pegasus]

RDNA wird sowieso keine RT-Cores bekommen, wer sich das vorstellt ist mMn eh auf dem Holzweg. Man wird die CUs so optimieren, dass sie möglichst effizient mit RT umgehen können.

beziehst Du die Aussage nur auf PC oder auch auf Konsolen, wo ja RT bereits angekündigt wurde.

[HOT]

Auf beides. RT ist auch mit anderen Implementationen sinnvoll zu machen als mit NVs Variante.

[SKYNET]

3072 Bit Interface? HBM ist sehr flexibel, was das angeht.


denke AMD wird aus dem shitstorm gegen NV(wegen speicher ausstattung der turings) ein paar lektionen für sich selber mitgenommen haben, heisst, der navi der mit der 2080 konkurriert wird 12GB haben, und der big chip dann 16GB, um in jeden fall ein kaufargument zu haben. :)

[gbm31]

Da die VII beerbt werden soll 16GB, drunter ist doof.

[KORE]

Nein drunter ist gut denn sie haben ja von NV gelernt. :)

[Der_Korken]

12GB HBM als Vollausbau würde ich ausschließen, weil man dazu drei Stacks bräuchte und die sich zusammen mit der GPU nicht symmetrisch und rechteckig anordnen lassen. Da würde AMD lieber gleich auf vier Stacks gehen und den Salvage mit drei Stacks bestücken. Da N10 bereits >200W TBP liegt, wird HBM für den großen Chip wohl obligatorisch sein.

[BoMbY]

Ich kann mir beim besten Willen nicht vorstellen dass Navi12 und Navi14 beide noch kleinere Chips als Navi10 sind. Ich würde fast wetten das wenigstens einer davon 64 oder mehr CUs hat, und der andere 20 bis 24 CUs. Weniger braucht man eigentlich für nichts für das nicht auch eine APU reichen würde, zumal da Renoir vermutlich auch ein paar CUs zulegen wird.

[aufkrawall]

RDNA 1.0 würde auch bedeuten kein RT, was aber definitiv nächstes Jahr kommt. Wo ergibt das Sinn wenn nicht bei N21 als (potentieller) High-End-Lösung?
Es ist wohl nun schon so weit, dass HOTs Spekus mehr Sinn ergeben als Leos. :freak:

[HOT]

Auch interessant, N14 und N12 darüber zu sehen. Glaub ich aber nicht. Ich denke, N14, 12 und 21 sind einfach kommende Klein-Lösungen, ob APU oder nicht. Man wird das wieder wie bei Polaris machen, einen 120mm²-Chip und einen 80-90mm²-Chip. Langfristig spart das Kosten. Die Dinger sind ja wieder 5 Jahre am Markt.

[Schnitzl]

Auch interessant, N14 und N12 darüber zu sehen. Glaub ich aber nicht. Ich denke, N14, 12 und 21 sind einfach kommende Klein-Lösungen, ob APU oder nicht. Man wird das wieder wie bei Polaris machen, einen 120mm²-Chip und einen 80-90mm²-Chip. Langfristig spart das Kosten. Die Dinger sind ja wieder 5 Jahre am Markt.
dann wärs echt besser die Grafiksparte direkt zu schliessen.
Evlt. kann ja dann Matrox die Leute aufnehmen und wieder anfangen. Das wär doch mal was.

Nein das ist kein Trolling das ist Resignation.

[HOT]

Navi-Generation ist wie Polaris, nur dass NV diesmal schwächer ist. Die große Frage ist: Stecken die nächstes Jahr viel Arbeit in die High-End und Enthusiastenvarianten oder nicht. Wenn ja wird es mMn 2 Chips geben, wenn nicht gibts nen Navi-Aufguß, der eigentlich nur für Profimarkt ist mit 64CUs, das wars. Die 2 Möglichkeiten gibts. Macht AMD jetzt ernst und lässt die Worten Taten folgen oder gibts das Weiter-so und das waren alles hohle Phrasen. Es ist beides möglich.

[MadPenguin]

Navi-Generation ist wie Polaris, nur dass NV diesmal schwächer ist. Die große Frage ist: Stecken die nächstes Jahr viel Arbeit in die High-End und Enthusiastenvarianten oder nicht. Wenn ja wird es mMn 2 Chips geben, wenn nicht gibts nen Navi-Aufguß mit 64CUs.

AMD wird bei der GPU wieder gross dabei sein. Da sehe ich keinen Zweifel. RDNA in seiner Reinform muss sich jedoch erst behaupten und keiner weiss wie es sein wird :)

[HOT]

Ich spekulier mal für den Fall, dass man es ernst meint:

N12 -> 20CUs, 130mm², 128Bit
N14 -> 12CUs, 80mm², 64Bit, PCIe 4x
N21 -> Custom/Mobile GPU in 7FF+ mit HBM (ähnlich P22/V12)
RDNA2-HE -> 64 CUs, 384 Bit GDDR6 oder 2 HBM mit 2,4GHz, <400mm², 7 FF+ (2080Ti-Leistung)
RDNA2-En -> 96 CUs, 4 HBM-Stapel, >500mm², 7 FF+ (weit über 2080Ti)
Vega30 -> 7FF+/6FF-Variante von V20

Wenn man wie bisher weitermacht:

N12 und N14 gleich
N21 -> (Semi-)Profi-GPU, 64CUs, 500mm², 7FF+, 4HBM, IF -> Hieße V10 Teil2

[JVC]

Man wird die CUs so optimieren, dass sie möglichst effizient mit RT umgehen können.
Darauf spekuliere ich auch.
Lieber mehr CUs die mehr können, als Extra-Hardware die nur RT kann :smile:

M.f.G. JVC

[reaperrr]

Auch interessant, N14 und N12 darüber zu sehen. Glaub ich aber nicht. Ich denke, N14 ist einfach Renoir und N12 eine 100mm²-Variante.
Raven Ridge hat auch keine eigene Vega-Nummer bekommen. Nicht vergessen, N10 & Co sind Codenamen, und die APUs haben ja schon einen, bloß halt aus dem CPU-Bereich. Wäre Quatsch, dem Grafikteil einen eigenen Codenamen zu geben. Eigene Polaris/Vega-Nummern haben bisher immer nur reine GPUs bekommen. Und dass Renoir schon Chiplet ist bezweifle ich, außerdem sagt der aktuelle Gerüchtestand doch eh, dass Renoir noch Vega-Tech sein soll.

Ich persönlich gehe eher davon aus, dass N12 und N14 die Nachfolger von Polaris 11 und 12 sind, jedenfalls was Größe/Specs angeht, also in etwa N12 = 20 CUs in ~130-140mm², N14 = 10 CUs in ~80-100mm² (hängt stark davon ab, ob auch das SI halbiert wird ggü. N12).

[BoMbY]

Jo, die APU GPUs nutzen nicht die GPU-Codenamen. Renoir und Dali sind die nächsten Codennamen nach Raven und Picasso.

Ich würde sagen:

Renoir: 16 CUs
Navi14: 24 CUs GDDR5
Navi10: 40 CUs GDDR6
Navi12: 64 CUs GDDR6
Navi21: 96 CUs (und HBM2 oder HBM3).

So wird ein Schuh daraus.

[Schnitzl]

Ich spekulier mal für den Fall, dass man es ernst meint:

N12 -> 20CUs, 130mm², 128Bit
N14 -> 12CUs, 80mm², 64Bit, PCIe 4x
N21 -> Custom/Mobile GPU in 7FF+ mit HBM (ähnlich P22/V12)
(1) RDNA2-HE -> 64 CUs, 384 Bit GDDR6 oder 2 HBM mit 2,4GHz, <400mm², 7 FF+ (2080Ti-Leistung)
(2) RDNA2-En -> 96 CUs, 4 HBM-Stapel, >500mm², 7 FF+ (weit über 2080Ti)
Vega30 -> 7FF+/6FF-Variante von V20

Wenn man wie bisher weitermacht:

N12 und N14 gleich
N21 -> (Semi-)Profi-GPU, 64CUs, 500mm², 7FF+, 4HBM, IF -> Hieße V10 Teil2
(1) das geht meiner Meinung nach in die Hose. Siehe (2)
(2) das Ding muss sich, wie auch (1) an der 3080Ti messen, deshalb sollte es die 2080Ti weit hinter sich lassen.
2020 ein Monster mit 2080Ti Leistung rauszubringen ist doch nur ein weiterer Fehlschlag.

[Der_Korken]

64 CUs fände ich unpassend. N10 scheint vier Shaderengines mit je 5 Doppel-CUs zu haben. Für den größeren Chip werden die hoffentlich auf sechs Shaderengines aufrüsten, um nicht wieder in Skalierungsprobleme zu rennen. Also entweder 60 CUs (10/SE) oder 72 CUs (12/SE). Allerdings wird es für GDDR6 dann sehr eng, denn ein 1.5facher N10 läge bereits bei 337W TBP ohne weitere Effizienzsteigerungen. Mit weniger Takt würds gehen, aber dann ist man wieder keine 50% schneller als N10. Da würden 2x8GB HBM mit jeweils 1,2Ghz Takt (616GB/s Bandbreite) schon mehr Sinn ergeben und man kriegt vielleicht auch 72CUs in 300W unter.

[Complicated]

Jo, die APU GPUs nutzen nicht die GPU-Codenamen. Renoir und Dali sind die nächsten Codennamen nach Raven und Picasso.

Ich würde sagen:

Renoir: 16 CUs
Navi14: 24 CUs GDDR5
Navi10: 40 CUs GDDR6
Navi12: 64 CUs GDDR6
Navi21: 96 CUs (und HBM2 oder HBM3).

So wird ein Schuh daraus.
Seh ich auch so. Navi21 in 7nm+ und der Rest in 7nm. Ich denke AMD braucht nur einen Chip unter Navi10. Polaris Lowend wird wohl ähnlich lang die 12 nm am leben halten wie die HD5450 die 40nm.

[HOT]

Wenn man annimmt, dass AMD des ernst mein mit der GPU-Sparte (das muss sich eben erweisen), glaub ich da nicht dran. Navi ist mMn nur und ausschließlich RDNA1. Ob 7nm+ oder nicht hängt von der Verfügbarkeit des Prozesses ab mMn. Früher oder später werden die eh auf 7 oder 6 EUV gefertigt werden. Diese Prozesse sind ja technisch gesehen gleichzusetzen, 6 EUV ist ja nur etwas billiger.

RDNA2 wird nen ganz neuen Codenamen erhalten und ist mMn auch noch einiges weg, 2.HJ 2020 wird man schon noch warten müssen mMn.

Und für die Zukunft wäre das auch ein anderes Modell als bisher. Immer die Annahme im ersten Satz dieses Postings im Hinterkopf behalten dabei!

AMDs Strategie für neue Chips müsste man ja ganzheitlich betrachten. Einfach nur die GPUs zu sehen ist zu kurz gesprungen, wenn man die CPUs vergisst.
MMn (falls Annahme erster Satz zutrifft) müsste AMD die GPUs in das eigene Tick-Tock-Modell mit einbauen. Bedeutet im Klartext, man wiederholt die 7nm-Strategie bei 5nm. Will heißen, kickoff für 5 EUV wäre ein RDNA2-Profichip mit 96CUs, IF und HBM mit ca. 350mm². Danach sind die 5nm-Chiplets dran, danach die nächste Mainstreamgeneration in 5nm. Nachfolger für die Enthusiastensparte ist dann erst in 4nm zu erwarten, was auch Sinn macht, da diese wieder sehr groß werden würden und das alles vorher schon totoptimiert sein muss. Zudem würde dann auch ein neues Chiplet mit Architekturupgrade in 4nm fällig werden, was dann Zen5 entspräche, sprich die komplexen Sachen immer nur im optimierten "Refresh"-Prozess.

Launchplan für 2019 wäre dann (nur 7nm):
Vega20
Matisse/Rome
N10 (5700)
N12/14 (5600/5500/5400)
Renoir
N21 (Mobile) (7 EUV)

für 2020

V30 (7 EUV Refresh)
N"20" (Refresh N10) (6700)
RDNA2-HE (6800)
Vermeer (Ryzen4k und Milan)
N"22 und 24" (Refresh N12/14) (6600/6500/6400)
RDNA2-En (6900)

für 2021/22/23
APU für 6 EUV (Renoir Refresh)
RDNA2 Profi in 5 EUV
Zen4 in 5 EUV
RDNA3 Mainstream in 5 EUV, später Refresh in 4 EUV
APU in 5 EUV, später Refresh in 4 EUV
Zen5 in 4 EUV
RDNA3-HE/En in 4 EUV
RDNA3 Profi in 3 GAAF

usw.

Übrigens wäre ein RDNA2-Chip mMn noch nicht im Linux-Treiber, das kann nur RDNA1 sein.

[dildo4u]

5700XT vs 2070 in World War z.Komischerweise in DX11 gebencht vielleicht ein gutes Zeichen für bessere Auslastung ohne Low Level.


https://www.reddit.com/r/Amd/comments/c54hls/amd_ryzen_3900x_5700xt_a_little_faster_than_intel/

[Dural]

Navi-Generation ist wie Polaris, nur dass NV diesmal schwächer ist. Die große Frage ist: Stecken die nächstes Jahr viel Arbeit in die High-End und Enthusiastenvarianten oder nicht. Wenn ja wird es mMn 2 Chips geben, wenn nicht gibts nen Navi-Aufguß, der eigentlich nur für Profimarkt ist mit 64CUs, das wars. Die 2 Möglichkeiten gibts. Macht AMD jetzt ernst und lässt die Worten Taten folgen oder gibts das Weiter-so und das waren alles hohle Phrasen. Es ist beides möglich.

In welcher Welt lebst du? Polaris / Pascal waren 12nm, Turing ist jetzt in 12nm und Navi in 7nm.

In Wahrheit wurde der Abstand zwischen NV/AMD sogar GRÖSSER!

Darauf spekuliere ich auch.
Lieber mehr CUs die mehr können, als Extra-Hardware die nur RT kann :smile:

M.f.G. JVC

Kleiner Tipp, ich würde mal nachlesen wie NV das mit den RT "Einheiten" macht...
Gilt auch für @HOT

Das sind nur Erweiterungen und KEINE extra Einheiten die nur RT können!

[aufkrawall]

In welcher Welt lebst du? Polaris / Pascal waren 12nm, Turing ist jetzt in 12nm und Navi in 7nm.

Du lebst offenbar in einer Welt, in der du deine Fakten nicht in Ordnung hast.

[Ex3cut3r]

@Dural

Polaris (RX 480) war in 14nm gefertigt, Pascal war wiederum in 16nm gefertigt. Und Turing ist in 12nm gefertigt. Radeon 7 und Navi basieren natürlich auf 7nm, wenn man schon Scheiße labert, dann bitte richtig.

[w0mbat]

Polaris30 ist 12nm.

[gravitationsfeld]

@Dural

Polaris (RX 480) war in 14nm gefertigt, Pascal war wiederum in 16nm gefertigt. Und Turing ist in 12nm gefertigt. Radeon 7 und Navi basieren natürlich auf 7nm, wenn man schon Scheiße labert, dann bitte richtig.
16/14/12 sind alles nur Bullshit-Namen fuer die gleiche Node mit minimalen Aenderungen. Vergleichbar mit Intels 14/14+/14++.

[Brillus]

16/14/12 sind alles nur Bullshit-Namen fuer die gleiche Node mit minimalen Aenderungen. Vergleichbar mit Intels 14/14+/14++.
Ja schon weil GF und TSMC den gleichen Prozess verwenden ... nicht.

[N0Thing]

Darum ging es ihm nicht.
Es ist ein neuer Name für kleine Änderungen, der bei TSMC mehr suggeriert als eigentlich drin steckt.

[gravitationsfeld]

Ja schon weil GF und TSMC den gleichen Prozess verwenden ... nicht.
Nein, aber es ist die gleiche Node. Die Performance-Charakteristiken sind auch vergleichbar.

[Brillus]

In welcher Welt lebst du? Polaris / Pascal waren 12nm, Turing ist jetzt in 12nm und Navi in 7nm.

In Wahrheit wurde der Abstand zwischen NV/AMD sogar GRÖSSER

1. Pascal war 16 und Polaris 14.

2. Ist es völlig egal wie gut NV in 7nm wäre sie haben keins und nach aktuellem Stand werden sie die nächsten 6-9 Monate nichhts da haben. Aktueller wissens Stand ist Navi wird ca. Gleiche Effizienz haben als NV.

[BoMbY]

Erste Hinweise auf RX 5800 und RX 5900 Serie:

https://videocardz.com/newz/sapphire-registers-radeon-rx-5950-5900-xt-rx-5850-5800-xt-series-at-eec

[dargo]

WTF? So viele neue SKUs? Wo kommen die denn alle her?

[M4xw0lf]

WTF? So viele neue SKUs? Wo kommen die denn alle her?
Vermutlich nur Platzhalter.

[BoMbY]

Rebrands, NAvi10, Navi12, Navi14.

Edit: Fertig:

AMD Radeon RX 5950XT Navi21 XT Custom Cooling
AMD Radeon RX 5950 Navi21 Pro Custom Cooling
AMD Radeon RX 5900XT Navi21 XT Stock Cooling
AMD Radeon RX 5900 Navi21 Pro Stock Cooling
AMD Radeon RX 5850XT Navi12 XT Custom Cooling
AMD Radeon RX 5850 Navi12 Pro Custom Cooling
AMD Radeon RX 5800XT Navi12 XT Stock Cooling
AMD Radeon RX 5800 Navi12 Pro Stock Cooling
AMD Radeon RX 5750XT Navi10 XT Custom Cooling
AMD Radeon RX 5750 Navi10 Pro Custom Cooling
AMD Radeon RX 5700XT Navi10 XT Stock Cooling
AMD Radeon RX 5700 Navi10 Pro Stock Cooling
AMD Radeon RX 5650XT Navi14 XT Custom Cooling
AMD Radeon RX 5650 Navi14 Pro Custom Cooling
AMD Radeon RX 5600XT Navi14 XT Stock Cooling
AMD Radeon RX 5600 Navi14 Pro Stock Cooling
AMD Radeon RX 5550XT Vega12 XT Custom Cooling
AMD Radeon RX 5550 Vega12 Pro Custom Cooling
AMD Radeon RX 5500XT Vega12 XT Stock Cooling
AMD Radeon RX 5500 Vega12 Pro Stock Cooling


:biggrin:

[iuno]

Im MR zu Navi support fuer radeonsi finden sich fuer Interessierte ggf. interessante Infos: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1173

Ich habe nur grob drauf geschaut (und natuerlich auch nicht viel Ahnung ;) ), aber es wird jetzt zw. merged und multi-part shader unterschieden. Offenbar spart man sich mit Navi mit "NGG" die (Hardware-)VS stage am Ende, die man z.T. gebraucht hat, weil nicht jede stage in position/parameter Caches schreiben konnte.

[mczak]

Im MR zu Navi support fuer radeonsi finden sich fuer Interessierte ggf. interessante Infos: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1173

Ich habe nur grob drauf geschaut (und natuerlich auch nicht viel Ahnung ;) ), aber es wird jetzt zw. merged und multi-part shader unterschieden. Offenbar spart man sich mit Navi mit "NGG" die (Hardware-)VS stage am Ende, die man z.T. gebraucht hat, weil nicht jede stage in position/parameter Caches schreiben konnte.
So sieht's aus. Vega hat ja auch schon shader zusammengefasst, aber brauchte eben (bei aktivem API GS) immer noch den zusätzlichen (HW) VS am Ende für den Parameter-Export.

/*
* API shaders VS | TCS | TES | GS |pass| PS
* are compiled as: | | | |thru|
* | | | | |
* Only VS & PS: VS | | | | | PS
* GFX6 - with GS: ES | | | GS | VS | PS
* - with tess: LS | HS | VS | | | PS
* - with both: LS | HS | ES | GS | VS | PS
* GFX9 - with GS: -> | | | GS | VS | PS
* - with tess: -> | HS | VS | | | PS
* - with both: -> | HS | -> | GS | VS | PS
* | | | | |
* NGG - VS & PS: GS | | | | | PS
* (GFX10+) - with GS: -> | | | GS | | PS
* - with tess: -> | HS | GS | | | PS
* - with both: -> | HS | -> | GS | | PS
*/

[danarcho]

Ich weiß nicht, ob ihr euch mal den LLVM code angeschaut habt, aber anscheinend hat AMD für Navi die alten GCN1 ALUs wieder ausgegraben. Zumindest sind praktisch alle opcodes wieder so wie bei SI :crazy2:

Vielleicht bekommt RDNA3 wieder die GCN3 opcodes :weg:

[Gebrechlichkeit]

https://streamable.com/xe209

[BoMbY]

AMD's Radeon RX 5700 XT appears on 3DMARK Time Spy (https://www.overclock3d.net/news/gpu_displays/amd_s_radeon_rx_5700_xt_appears_on_3dmark_time_spy/1)

Verglichen mit einer Radeon VII (https://www.3dmark.com/spy/7553480) wäre das ein sehr gutes Ergebnis.

[BlacKi]

timestamp zur aussage, das hbm tatsächlich teurer ist/war.
https://youtu.be/OY8qvK5XRgA?t=1405

[gravitationsfeld]

Ich weiß nicht, ob ihr euch mal den LLVM code angeschaut habt, aber anscheinend hat AMD für Navi die alten GCN1 ALUs wieder ausgegraben. Zumindest sind praktisch alle opcodes wieder so wie bei SI :crazy2:
Ich koennte mir vorstellen, dass das fuer Konsolen-Abwaertskompatibilitaet gemacht wurde.

Gleiches Opcode-Encoding hat uebrigens nichts mit der ALU-Implementierung zu tun.

[BoMbY]

"pricing is very volatile" (GDDR6 und HBM)

"and the pricing, as of today, is a little bit better than HBM"

[BlacKi]

die leute von amd sind ganz schöne heuchler. erst wollen sie den spielemarkt mit cores überfluten, mit dem argument, das zuerst die hw da sein muss, aber bei raytracing kommt die 180° drehung und wollen auf den spielemarkt warten, bis er bereit für raytracing ist.:facepalm:

aber was sollen sie denn sonst sagen...

[x-force]

aber was sollen sie denn sonst sagen...

ich kann mir vorstellen, daß erfrischende ehrlichkeit im kontrast zur üblichen marketing verarschung ziemlich gut kommen könnte. aber wahrscheinlich überschätze ich die zielgruppe.

vor allem würden sie mit anständiger selbstkritik sämtlichen kritikern a priori den wind aus den segeln nehmen.

man stelle sich mal vor:
amd bencht zum release absolut fair und transparent alles durch. legt offen wie was selektiert wird und wie die summe der chips über die spannung skalieren usw. dazu gibt es eine ordentliche dokumentation von allen relevanten bios einstellungen.

[Digidi]

So sieht's aus. Vega hat ja auch schon shader zusammengefasst, aber brauchte eben (bei aktivem API GS) immer noch den zusätzlichen (HW) VS am Ende für den Parameter-Export.

/*
* API shaders VS | TCS | TES | GS |pass| PS
* are compiled as: | | | |thru|
* | | | | |
* Only VS & PS: VS | | | | | PS
* GFX6 - with GS: ES | | | GS | VS | PS
* - with tess: LS | HS | VS | | | PS
* - with both: LS | HS | ES | GS | VS | PS
* GFX9 - with GS: -> | | | GS | VS | PS
* - with tess: -> | HS | VS | | | PS
* - with both: -> | HS | -> | GS | VS | PS
* | | | | |
* NGG - VS & PS: GS | | | | | PS
* (GFX10+) - with GS: -> | | | GS | | PS
* - with tess: -> | HS | GS | | | PS
* - with both: -> | HS | -> | GS | | PS
*/


Wie sieht das Frontend eigentlich bei Nvidia aus? Sind Primitive Shaders jetzt immer an? Das wäre ja ein Vorteil zu Nvidia wo die Messhader reinprogramiiert werden müssen.

[Linmoum]

die leute von amd sind ganz schöne heuchler. erst wollen sie den spielemarkt mit cores überfluten, mit dem argument, das zuerst die hw da sein muss, aber bei raytracing kommt die 180° drehung und wollen auf den spielemarkt warten, bis er bereit für raytracing ist.:facepalm:

aber was sollen sie denn sonst sagen...
Ganz einfach: Bei CPUs können sie den Markt von oben bis unten mit einem ganzen Lineup mit mehr Cores fluten. Können sie das auf der anderen Seite genauso mit RT und GPUs? Nein.

Hypothetisch: Wenn AMD jetzt 12C für $500 anbietet, aber bei <$400 nur 6C und weniger, meinst du irgendjemand optimiert da großartig für mehr Kerne? Nein, warum auch. Lohnt sich ja nicht, weil die Verbreitung fehlt.

Deswegen hat AMD in Form von Wang auch gesagt RT von oben bis unten und vorher nicht. Nur etwas am Markt haben reicht nicht, wenn die Leistung fehlt. Dann kann und wird kein User diese Features nutzen und Devs genauso wenig. Was meinst du, wenn Nvidia RT auf 2070 und 2060 beschränkt hätte? Das wäre eine noch größere Totgeburt zum aktuellen Zeitpunkt als ohnehin schon.

Edit: RT-Patent.
TEXTURE PROCESSOR BASED RAY TRACING ACCELERATION METHOD AND SYSTEM
http://www.freepatentsonline.com/20190197761.pdf

[Daredevil]

Immer wieder ganz unterhaltsam, der AMD Youtube Channel. :)

"Software Updates for Radeon RX 5700 Series"

2lCIogAK2iI

[mczak]

Wie sieht das Frontend eigentlich bei Nvidia aus? Sind Primitive Shaders jetzt immer an? Das wäre ja ein Vorteil zu Nvidia wo die Messhader reinprogramiiert werden müssen.
Keine Ahnung (zumindest bei den neuesten Chips), aber würde mich nicht wundern wenn es da auch bloss einen pre- und post-tessellation shader gibt. Die Task- und Meshshader entsprechen ja eigentlich genau dem Modell, bloss hat man halt statt Tessellation dazwischen eben "Mesh Generation". Das ist aber nur eine grobe Vermutung, zitiere mich bloss nicht :biggrin:.