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

[Unicous]

Ich höre "we'll" heraus das zugegebenermaßen sehr nach will klingt.:wink:

Ich denke Refresh ist das was wir traditionell unter Refresh verstehen und es gibt auch RDNA2 als neue Architektur bzw. Chip. Es macht so auch mehr Sinn mit dem Ende des Satzes, dass RDNA2 Teil des Produktportfolios sein wird.

[iuno]

Ich hatte auch mehrmals hingehört, nachdem das von AT ja hier zuvor schon verlinkt war. Aber was die geschrieben haben, ist da beim besten Willen nicht zu verstehen. Deswegen ist es immer schön bei sowas, auch den Originalton bzw. exakten Wortlaut zu haben.

Das was du aufgeschrieben hast, ist kein korrekter Satz. Und selbst wenn das gesagt worden wäre (ich habe jetzt night reingehört), würde ich es sinngemäß so deuten wie die andere Variante, weshalb es dort ggf. auch "korrigiert" wurde. Oder was soll genau der Unterschied in der Bedeutung sein? Ob RDNA2 noch "Navi" heißt?

[TheAntitheist]

na RDNA2 wird die neue Arch sein und Navi die alte

[BlacKi]

wenn da steht:

"You should expect that those will be refreshed in 2020 and will have next generation RDNA architecture that will be part of our 2020 lineup."

das bedeutet wird teil des portfolios sein, aber nicht ausschließlich. es sagt klipp und klar aus, das es nicht komplett aus rdna2 bestehen wird.

wie kann man das anders rauslesen?

[Screemer]

Das istbganz klar ein "we'll". Anders ergibt der Satz überhaupt keinen Sinn. Imho ist die transcription von linmoum nicht richtig.

Ergo Navi als refresh (evtl. 7p oder 7+) und dazu neue rdna2 Karte/n. Wobei letzteres nicht Mal gesichert, denn das kann sich auch nur auf nextgen konsolensocs beziehen.

[basix]

Vermutlich kommt N7P für den RDNA1 Refresh. Ist 100% Designkompatibel und gibt +7% Performance. Wäre eine Verbesserung mit minimalem Aufwand. AMD hat mit RDNA2, Konsolen, Zen 3+4, NextGen APU, Arcturus und der Spezial-SKU für Frontier momentan mehr als genug zu tun.

[Brillus]

Vermutlich kommt N7P für den RDNA1 Refresh. Ist 100% Designkompatibel und gibt +7% Performance. Wäre eine Verbesserung mit minimalem Aufwand. AMD hat mit RDNA2, Konsolen, Zen 3+4, NextGen APU, Arcturus und der Spezial-SKU für Frontier momentan mehr als genug zu tun.

Wenn überhaupt, refereshed kann da auch heißen neuer Name drauf ung 1-2 MHz mehr. Dann ist es formal schon neues Produkt.

[Berniyh]

Wenn überhaupt, refereshed kann da auch heißen neuer Name drauf ung 1-2 MHz mehr. Dann ist es formal schon neues Produkt.
Wenn man N7P ohne Aufwand mitnehmen kann, dann wird man das sicherlich machen.

[Sunrise]

Ich bin mir ziemlich sicher, dass Lisa einfach nur meinte, dass die Navi-GPUs vom letzten Jahr ab diesem Jahr 2020 um RDNA2-GPUs „erweitert“ werden. Damit sind mehrere RDNA2-Produkte gemeint, welche die aktuellen RDNA1-GPUs „ergänzen“. Es fehlen diverse GPUs für alle Marktsegmente und AMD hat nun wieder genug Geld um zusammen mit RDNA2 und N7+ eine Chance zu nutzen.

Denn wenn wir mal zurückgehen, dann rechnete man mit einer High-End Navi-GPU auf RDNA1-Basis, nur hat AMD dem wohl früh genug einen Riegel vorgeschoben (Verbrauch) und hat scheinbar vor, nicht nur RDNA2 einzuführen (Architektur-Anpassung), sondern auch grundlegende Verbesserungen der Energieeffizienz (optimierte Design-Anpassungen) und schließlich die deutlich bessere Transistor-Performance von N7+ zu nutzen, welche zusammen erst einen lohnenswerten und „disruptiven“ Unterschied ausmachen.

Da AMD neuerdings (Einfluss von Zen) wieder auf Performance unter starker Berücksichtigung der Effizienz (nicht nur Energie, sondern auch Fläche) bei RDNA insgesamt verfolgt, erwarte ich von Ihnen nicht weniger als das.

Vorstellbar wäre noch ein Navi10-Nachfolger, auch im Hinblick auf NV, damit man hier konkurrenzfähig bleibt (bis min. 2021). Alles andere sollte sich auf RDNA2 und die größeren GPUs konzentrieren.

Sobald NV mit Ampere kommt sieht selbst RDNA1 eher alt dagegen aus und Lisa hat mehrfach gezeigt, dass sie Konkurrenz liebt. Die Aussagen von AMD deuten das IMHO auch an.

[basix]

Wenn überhaupt, refereshed kann da auch heißen neuer Name drauf ung 1-2 MHz mehr. Dann ist es formal schon neues Produkt.

Wie gesagt, N7P benötigt soweit ich verstanden habe nicht mal eine neue Maske. Einfacher gehts nimmer.

Und +10% würden reichen, damit eine 5700er eine 2060 Super überflügelt und eine 5700 XT mit einer 2070 Super gleichzieht. Und es gäbe wieder etwas mehr Abstand von der 5600 XT zur "6700". Bei der 5600 XT kann man noch die Navi 10 auf Lager abverkaufen und bei einer potentiellen 6700er Serie kommt Navi 10 in N7P.

Das einzig ungewisse ist: Was macht Nvidia? Welche neuen Gegener wird es geben? Ich vermute, dass alles was heute 2060er Reihe und darunter ist wird bleiben / heruntergestuft und es kommen erst mal die High End Ableger.

[HOT]

Der bessere Prozess und ein Metalspin, gepaart mit schnellerem RAM und schon hat man nen guten Refresh. Wie ich die kenne bleibt man aber bei 14GT, bei Polaris blieb man ja auch immer auf dem gleichen RAM hängen.

[mboeller]

Wie gesagt, N7P benötigt soweit ich verstanden habe nicht mal eine neue Maske. Einfacher gehts nimmer.

Und +10% würden reichen,

es sind aber "nur" 7% was ich gelesen habe

[Smee]

Ist halt die Frage ob neue Maske oder nicht für den Refresh.
Für den Polaris Refresh hat man auch keine neue Maske genommen oder erinnere ich mich da falsch:confused:

[basix]

es sind aber "nur" 7% was ich gelesen habe

Jepp, die 3% hat man mit dee Reife von 7nm wohl drin ;) Und sonst: 3% ist nichts, was man mit etwas mwhr Saft erreichen könnte.

[N0Thing]

Ist halt die Frage ob neue Maske oder nicht für den Refresh.
Für den Polaris Refresh hat man auch keine neue Maske genommen oder erinnere ich mich da falsch:confused:

Habe auch so in Erinnerung, wobei da Golem.de und Computerbase sehr lange an jeweils unterschiedlichen Ansichten festgehalten haben. Ich weiß aber nicht mehr, welche Seite auf welcher Seite stand.

[Screemer]

es sind aber "nur" 7% was ich gelesen habe
falls es noch jemanden interessiert: https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/

[Complicated]

Eigentlich wäre der N6P der richtige Refresh-Prozess für Navi, wenn der Refresh nach Big Navi im Sommer mit 7nm+ erst Q4/2020 kommen sollte - N10 könnte bis Ende des Jahres problemlos den Unterbau zu Big Navi bilden. Die RX 5600 ist ja auch erst erschienen:

Link von Screemer:

N6 is the EUV equivalent of N7. It is planned to use more EUV layers than N7+. It is both design rule and IP-compatible with N7 and is intended to be the main migration path for most customers. N7 designs may be taped out again on N6 leveraging EUV masks and the fidelity improvements or re-implemented to take advantage of the poly over diffusion edge (PODE) and continuous diffusion (CNOD) standard cell abutment rules which are said to provide an additional 18% density improvement. It’s worth highlighting that N6 is unique in that it will actually enter risk production early next year and ramp by the end of the year 2020. This means it will ramp after N5. For that reason, TSMC says that N6 builds on both N7+ and N5 EUV learnings.
DUV-EUV Transit mit dem selben Design und langfristig sehr günstige Fertigung.
https://www.tsmc.com/english/dedicatedFoundry/technology/7nm.htm
Meanwhile, TSMC has announced 6-nanometer (N6) process in the second quarter of 2019, which provides a significant enhancement of its industry-leading N7 technology and offers customers a highly competitive performance-to-cost advantage as well as fast time-to-market with direct migration from N7-based designs. By leveraging the new capabilities in extreme ultraviolet (EUV) lithography gained from the N7+ technology currently in risk production, TSMC's N6 process delivers 18% higher logic density over the N7 process. At the same time, its design rules are fully compatible with TSMC's proven N7 technology, allowing its comprehensive design ecosystem to be reused. As a result, it offers a seamless migration path with a fast design cycle time with very limited engineering resources for customers to achieve the product benefits from the new technology offering.
Bisher ist nur die 18% Flächenersparnis bekannt gegenüber 7nm DUV. Würde aber auch 18% (der GPU-Wafer) mehr 7nm-Wafer für Zen2 bedeuten.

[HOT]

Eigentlich wäre der N6P der richtige Refresh-Prozess für Navi, wenn der Refresh nach Big Navi im Sommer mit 7nm+ erst Q4/2020 kommen sollte - N10 könnte bis Ende des Jahres problemlos den Unterbau zu Big Navi bilden. Die RX 5600 ist ja auch erst erschienen:

Link von Screemer:

DUV-EUV Transit mit dem selben Design und langfristig sehr günstige Fertigung.
https://www.tsmc.com/english/dedicatedFoundry/technology/7nm.htm

Bisher ist nur die 18% Flächenersparnis bekannt gegenüber 7nm DUV. Würde aber auch 18% (der GPU-Wafer) mehr 7nm-Wafer für Zen2 bedeuten.
Bei gleicher maske gibts keine Flächenersparnis. Die gibt's nur nei neuen chips.

[Piefkee]

Leute ihr meint doch nicht ernsthaft das irgendwas von AMD in N7P kommt. Es steht klar auf der Roadmap 7nm +

AMD muss mindestens +1Jahr vorher Process Resourcen auswählen.

Zu N7P da brauchst du sehr wohl nen neuen Satz Masken. Das einzige was du dir sparst, du darfst die selben Design-Rules verwenden. Das geht bei 7nm + nicht da man auf QSAP teilweise verzichtet (EUV). Kann das aber mal gerne genauer erläutern falls gewünscht.

Rein aus Process Ressouren Sicht wählt AMD einen Process für die künftigen Produkte aus. Darum steht das ja auch auf der Roadmap. Man wechselt jetzt komplett auf 7nm+. Zen 3 und RDNA2.

Was die meisten hier nicht sehen ist das man nicht so einfach ohne Erfahrung von DUV auf EUV wechseln mag. Darum N7+ weil es nur wenige Layer EUV nutzt und man so besser auf N5 wechseln kann.

[basix]

Es geht ja nicht um die 7nm+ NextGen Chips. Sondern Navi+ à la Polaris 20/30. Leicht verbessert, aber nicht wirklich neu. Deswegen N7P.

Wenn man für N7P neue Masken braucht (wo findet man Infos dazu?), spart man sich dennoch viel Designaufwand um das Portfolio gegen unten abzurunden. Ging bei Polaris ja auch. Alles über Navi 10 wird RDNA2 und 7nm+.

[HOT]

Es geht ja nicht um die 7nm+ NextGen Chips. Sondern Navi+ à la Polaris 20/30. Leicht verbessert, aber nicht wirklich neu. Deswegen N7P.

Wenn man für N7P neue Masken braucht (wo findet man Infos dazu?), spart man sich dennoch viel Designaufwand um das Portfolio gegen unten abzurunden. Ging bei Polaris ja auch. Alles über Navi 10 wird RDNA2 und 7nm+.

Wenn die Designrules kompatibel sind werden keine neuen Masken benötigt, das wäre absurd. Dafür macht man das ja kompatibel.

Und N6, das fand ja mal Erwähnung, brächte keinen Fortschritt sondern wäre nur billiger. 2021 wird N1x aber eh aussortiert, N6 lohnt also sowieso net dafür.

[Smee]

Ne neue Maske kostet halt auch ordentlich $, daher ja meine Frage^^

[amdfanuwe]

Die Masken nutzen sich aber auch ab und müssen je nach Produktionsmenge eh erneuert werden. Wenns passt, kann man da auch direkt für einen besseren Prozess die Masken erstellen.

[Piefkee]

Wenn die Designrules kompatibel sind werden keine neuen Masken benötigt, das wäre absurd. Dafür macht man das ja kompatibel.

Und N6, das fand ja mal Erwähnung, brächte keinen Fortschritt sondern wäre nur billiger. 2021 wird N1x aber eh aussortiert, N6 lohnt also sowieso net dafür.


Das gilt aber nur wenn die keine Selbstverkleinerung haben magst. Daher wird es mM keine N7P von AMD geben. Steht ja nix auf der Roadmap. Und ich kann mich nicht errinnern das sie AMD in den letzten Jahr nicht daran gehalten hat.

[Brillus]

Die Masken nutzen sich aber auch ab und müssen je nach Produktionsmenge eh erneuert werden. Wenns passt, kann man da auch direkt für einen besseren Prozess die Masken erstellen.

Dachte das gilt nur für die EUV Masken.

[HOT]

Das gilt aber nur wenn die keine Selbstverkleinerung haben magst. Daher wird es mM keine N7P von AMD geben. Steht ja nix auf der Roadmap. Und ich kann mich nicht errinnern das sie AMD in den letzten Jahr nicht daran gehalten hat.
Polaris wurde auch nicht verkleinert, Zen+ auch nicht. Klar ist das problemlos möglich N10 in N7P aufzulegen. Bleibt halt bei 251mm².
Und ich sag ja, das könnte einfach N12 sein. Ne Nummer findet sich dafür schon.

[Piefkee]

Polaris wurde auch nicht verkleinert, Zen+ auch nicht. Klar ist das problemlos möglich N10 in N7P aufzulegen. Bleibt halt bei 251mm².
Und ich sag ja, das könnte einfach N12 sein. Ne Nummer findet sich dafür schon.


Dann wäre es aber auf der Roadmap und da ist es nicht drauf.

Zu 14nm vs 12nm GloFo
14LPP (HP) 12LP (HP, HD) Δ
Fin Pitch 48 nm 48 nm 1.0x
Poly Pitch 84 nm 84 nm 1.0x
Metal 2 64 nm 64 nm 1.0x

https://fuse.wikichip.org/news/1497/vlsi-2018-globalfoundries-12nm-leading-performance-12lp/

[reaperrr]

Dann wäre es aber auf der Roadmap und da ist es nicht drauf.
Die RX 590 war auch auf keiner Roadmap, mal ganz abgesehen davon, dass AMD gerade die öffentlichen GPU-Roadmaps zuletzt extrem schwammig und unverbindlich gehalten hat. Das sagt mMn nichts aus. Aus Publicity-Gründen liegt der Roadmap-Fokus eh immer auf den Produkten, die neuere und modernere Technologie verwenden.

[Complicated]

Und N6, das fand ja mal Erwähnung, brächte keinen Fortschritt sondern wäre nur billiger. 2021 wird N1x aber eh aussortiert, N6 lohnt also sowieso net dafür.Was wäre derzeit ein besserer Grund als 18% der Wafer für andere Produkte frei zu machen? Ein Refresh der billiger wird und weniger Platz benötigt. Und das bei kompatiblen Designrules. Gibt es überhaupt einen anderen Grund für einen Navi-Refresh? Ein Refresh muss keinen Fortschritt mehr bringen und kann ebenso wie der 14->12nm Transit bei Polaris in einer Sackgasse der optimierten Fertigung enden. N2x sind die Desings die den Fortschritt bringen. N10 wird den günstigsten Weg des Refreshes gehen.

[reaperrr]

Was wäre derzeit ein besserer Grund als 18% der Wafer für andere Produkte frei zu machen? Ein Refresh der billiger wird und weniger Platz benötigt. Und das bei kompatiblen Designrules. Gibt es überhaupt einen anderen Grund für einen Navi-Refresh? Ein Refresh muss keinen Fortschritt mehr bringen und kann ebenso wie der 14->12nm Transit bei Polaris in einer Sackgasse der optimierten Fertigung enden. N2x sind die Desings die den Fortschritt bringen. N10 wird den günstigsten Weg des Refreshes gehen.
Der Chip wird von allein nicht kleiner, du müsstest das Layout anpassen da Dinge wie die Speicherinterfaces eben nicht schrumpfen.

Dann würde es sogar mehr Sinn machen, einen RDNA2-Chip mit N10-Specs in N7+ zu machen, der bringt nämlich quasi genauso viel Platzersparnis (bis zu 17%), dafür aber zusätzlich noch 10% mehr Performance.

N6 ist nur was für wirklich kleine Billigchips, wie Mainstream-Smartphone SoCs mit ~100mm² oder weniger Fläche, da bringt die Platzersparnis dann über die Menge auch genug Vorteil.

Für sowas wie GPUs ist es sinnvoller, N7P zu nehmen um stattdessen leicht höhere Preise für die etwas bessere Performance verlangen zu können, oder wie gesagt was in N7+ machen.

[HOT]

Was wäre derzeit ein besserer Grund als 18% der Wafer für andere Produkte frei zu machen? Ein Refresh der billiger wird und weniger Platz benötigt. Und das bei kompatiblen Designrules. Gibt es überhaupt einen anderen Grund für einen Navi-Refresh? Ein Refresh muss keinen Fortschritt mehr bringen und kann ebenso wie der 14->12nm Transit bei Polaris in einer Sackgasse der optimierten Fertigung enden. N2x sind die Desings die den Fortschritt bringen. N10 wird den günstigsten Weg des Refreshes gehen.

Es würde sicherlich eben lohnen N10 in N7P zu refreshen, weil das nix kostet und man den Maskensatz einfach weiterverwenden kann und dann in 2021 durch einen RDNA2-Mainstream-Chip in N6 oder N5 zu ersetzen. Ein Re-refresh würde ich bei der RDNA-Generation nicht mehr erwarten, ich glaub, die Zeiten sind vorbei.

[Sunrise]

Der Chip wird von allein nicht kleiner, du müsstest das Layout anpassen da Dinge wie die Speicherinterfaces eben nicht schrumpfen.

Dann würde es sogar mehr Sinn machen, einen RDNA2-Chip mit N10-Specs in N7+ zu machen, der bringt nämlich quasi genauso viel Platzersparnis (bis zu 17%), dafür aber zusätzlich noch 10% mehr Performance
Eben, denn RDNA2 kommt von AMD ohnehin auf N7+, AMD kann das Design also einfach skalieren in jede Richtung. Und um gegen NV besser konkurrieren zu können (N10 ist ein extrem wichtiger Chip in AMDs Lineup) kann man den ebenso anpassen und alle anderen Vorteile ebenso mitnehmen. 30% mehr Performance sollten hier dann möglich sein.

Denkbare Gründe dagegen:
- RDNA2 ist zwar effizienter und schneller, benötigt dafür aber ggü. RDNA1 aufgrund Raytracing usw. deutlich mehr Fläche, sodass N10 noch im Lineup bleibt und dann doch kostengünstig erneuert wird mit neuem Namen (allerdings wäre es eigenartig/verwirrend die Chip-Generationen im neuen Lineup zu mischen)
- evtl. zuwenig Kapazität für EUV bei TSMC

[Leonidas]

allerdings wäre es eigenartig/verwirrend die Chip-Generationen im neuen Lineup zu mischen


Wir reden hier über AMD. Das Einmischen von mehreren Chip-Generationen ins selbe Lineup ist da quasi Firmen-DNA.

[robbitop]

Das war praktisch schon fast immer so (bzw schon sehr lange).

[HOT]

Radeon 8500 (Pro) -> Radeon 9000 (Pro)

Jo das gibts schon ein paar Tage :D.

[BlacKi]

bei p10 gabs wenigstens ein prozessupgrade. aber zb. pitcairn musste wirklich sehr lange herhalten.
https://videocardz.net/gpu/amd-pitcairn/

[dildo4u]

Die RTX 2060 kam ja erst Anfang 2019 gut möglich das Nvidia erst mal nix Neues gegen Navi 10 hat,würde mich wundern wenn es sofort Ampere Dies unter 300mm² geben wird.

[Eldoran]

Bei den 7nm und kleiner benannten Prozessen ist bei TSMC die Nomenklatur etwas unübersichtlich, es kommt noch hinzu, dass die Angaben zu was Nachfolger zu was ist auch noch verwirrend ist.

Klar ist dass N7 (DUV) zu N6 (EUV) "kompatibel" ist insofern als die Design Rules gleich bleiben. Die Masken etc. sind natürlich völlig verschieden. Die dafür notwendigen Änderungen sollen aber aus den Design für N7 direkt ableitbar sein.
N7 zu N7+ hingegen hat andere Design Rules, da braucht man ein völlig neues Design.
Was der Unterschied N7 zu N7P ist, habe ich bisher nicht wirklich verstanden.

Jedenfalls bei GlobalFoundries war 14nm und 12nm effektiv der selbe Prozess, daher war es sogar möglich mit den selben Satz Masken von 14nm in 12nm zu produzieren. Das liegt aber eher daran, dass die Flächenersparnis bei 12nm eher nominal war. 12nm bei GlobalFoundries ist einfach 14nm mit leistungsfähigeren Transistoren (die Form der Fins sind gegenüber 14nm verbessert). Die beworbene Flächenersparnis kommt aber nur dadurch zustande, dass man durch die besseren Transistoren eine andere Library mit kompakterem Design nutzen kann, der dadurch entstehende Leistungsverlust wird durch die besseren Transistoren aufgefangen.

[unl34shed]

N7 zu N7P ist wie 14 zu 12nm bei GloFo. Im Prinzip der selbe Prozess mit neusten Kenntnissen und Optimierungen. Gab einen netten Artikel dazu auf der letzten Seite:

falls es noch jemanden interessiert: https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/

[horn 12]

BIG Navi schneller Releast als erwartet.
September/ Oktober 09 und Release April 20 wäre schon eine Hausnummer
Am 05 März solte AMD ja Genaueres verraten dürfen!

https://www.overclock3d.net/news/gpu_displays/new_amd_certification_hints_at_soon-to-be-released_radeon_big_navi_graphics_card/1

[Ravenhearth]

Woher wissen wir, dass sich der Eintrag auf Big Navi bezieht? Könnte das nicht auch irgendwas anderes sein?

[[MK2]Mythos]

Woher wissen wir, dass sich der Eintrag auf Big Navi bezieht? Könnte das nicht auch irgendwas anderes sein?
Reicht dir horn als Quelle etwa nicht?

[horn 12]

Siehe weiter unten im Link "RX 5500 XT und 5600XT"

AMD hat alles Releast, fehlt noch Big Navi
Cossfire ist Tod,- und machbar in 8 Monaten wäre ein Release allemal, auch wenn da wirklich alles optimal laufen musste!
In gut einem Monat wissen wir mehr.




@edit
Guru3d.com


Why RDNA 2 matters

AMD's next-generation RDNA 2 graphics architecture is due to offer gamers new features and further IPC and/or power efficiency improvements over today's RDNA/Navi architecture.
These changed will help Radeon become more competitive with Nvidia, and bring PC gaming in-line with the feature set of the next-generation consoles from Sony and Microsoft.

RDNA 2 is due to bring support for hardware-accelerated raytracing and variable rate shading (VRS) to AMD's Radeon graphics lineup, securing the future of real-time raytracing into the PC gaming landscape.

If AMD released a "Big Navi" graphics card, Nvidia would be forced to respond. That said, it is unknown how close Nvidia's next-generation RTX graphics are to market,
or it AMD's next-generation Radeon graphics cards are strong enough to worry team Geforce.

Soon we will have frirst 3Dmark leaks -> then we will know for sure to hype Moar


Meine Prognose:
Kleine Schwester auf RTX 2080TI Level plus 5 bis 10% für 579 Dollar mit 12GB
BIG Navi RTX 2080TI plus 30% für 799 Dollar mit 16GB

Damit würde man Nvidia keine Luft zum Atmen lassen,- und der 7+nm Prozess dürfte AMD dies ermöglichen.
Sieht man ja an Zen 2 was alles möglich ist bei Guter Lieferbarkeit, unter 500 Euro (3900X) und gute 700+ Euro (3950X)

Zudem wird Navi 10 wohl angepasst werden und im Preis leicht gesenkt.

[davidzo]

Bei den 7nm und kleiner benannten Prozessen ist bei TSMC die Nomenklatur etwas unübersichtlich, es kommt noch hinzu, dass die Angaben zu was Nachfolger zu was ist auch noch verwirrend ist.

Klar ist dass N7 (DUV) zu N6 (EUV) "kompatibel" ist insofern als die Design Rules gleich bleiben. Die Masken etc. sind natürlich völlig verschieden. Die dafür notwendigen Änderungen sollen aber aus den Design für N7 direkt ableitbar sein.
N7 zu N7+ hingegen hat andere Design Rules, da braucht man ein völlig neues Design.
Was der Unterschied N7 zu N7P ist, habe ich bisher nicht wirklich verstanden.


Die Masken können natürlich für viele Schritte weiter verwendet werden. Die meisten Layer sind ja nicht EUV, höchstens 3-4 Stück bei denen man dann neue Masken braucht, das fabric und die ganzen interconnects sind ziemlich grober DUV Kram...

[Leonidas]

Eigentlich widerspricht sich die Meldung selber: RRA-Zertifizierungen kommen üblicherweise einen Monat vor Release. Das wäre für Big Navi noch deutlich zu früh - davon abgesehen würde es dann mehr Leaks hierzu geben.


Am 05 März solte AMD ja Genaueres verraten dürfen!


An dem Tag wird es weitere Teaser geben (es ist ja nur ein FAD). Passt schlecht zu einer bereits spruchreifen Karte. Jene Zertifizierung bezieht sich vermutlich auf etwas ganz anderes als Big Navi.

[Denniss]

Horns Glaskugel sagt Big Navi, meine dagegen behauptet steif und fest es wird ein Chip aus der Vega-Familie für den Profibereich.
Mal schauen wer recht behält.

[horn 12]

Könnte ebenso gut möglich sein.
Aber in 7 Monaten wäre schon Hammer,- wenn auch nicht unmöglich.

[Linmoum]

So wie sich die Presse direkt auf Big Navi stürzt, scheinen manche noch nicht einmal etwas von Arcturus zu wissen. Das passt wunderbar analog zu V20 damals, Für Navi in N7+ für den Consumer-Markt ist es einfach noch zu früh, für eine HPC-GPU nicht.

[Berniyh]

Ja, Arcturus dürfte ziemlich sicher die nächste GPU von AMD sein.
Hatten ja eigentlich schon erwartet zur CES was davon zu hören, aber war da evtl. nicht das richtige Publikum.

[robbitop]

Eigentlich widerspricht sich die Meldung selber: RRA-Zertifizierungen kommen üblicherweise einen Monat vor Release. Das wäre für Big Navi noch deutlich zu früh - davon abgesehen würde es dann mehr Leaks hierzu geben.

Gab es denn signifikante Leaks vor der 5700XT 1x Monat vorher? (ehrliche Frage)
Ich habe das Gefühl, dass AMD/NV die internen Leaks und die der Lieferkette einigermaßen im Griff haben (im Gegensatz zu vor 10 Jahren). Sicher gibt es auch immer mal wieder Ausnahmen. Löchrig wird's, wenn die Testsamples versendet werden. Das ist idR jedoch erst ~1 Woche vor Launch der Fall. Wenn überhaupt. Manchmal sind es ja nur wenige Tage - im E-Fall über das Wochenende...

Und warum sollte es für Big Navi noch zu früh sein? Gibt es da handfeste Indizien, die dagegen sprechen?

Zur Klarstellung: ich plädiere weder dafür noch dagegen - sehe aber keine richtigen Anhaltspunkte - weder dafür noch dagegen. :)

[Berniyh]

Und warum sollte es für Big Navi noch zu früh sein? Gibt es da handfeste Indizien, die dagegen sprechen?
Tape-Out war laut Spekulationen zwischen Ende-September und Anfang November.
Das wäre dann doch ein bisschen kurz.

Abgesehen davon bin ich mir ziemlich sicher, dass Lisa Su nicht gesagt hätte "you will see big Navi in 2020", wenn der Release bald anstehen würde, sondern eher "you will see big Navi soon™".

Und zudem … es gibt ja eine bald erwartete GPU von seiten AMD, nämlich Arcturus.
Macht einfach viel mehr Sinn als Navi.

[HOT]

Na ja, welches Tapeout das war ist bislang ja total offen.

[robbitop]

Tape-Out war laut Spekulationen zwischen Ende-September und Anfang November.
Das wäre dann doch ein bisschen kurz.
Ja - aber die Basis ist nur eine Spekulation. Das läßt zumindest die Möglichkeit zu, dass diese nicht zutrifft. Und es gibt ja sicherlich nicht nur 1x Tapeout bzw 1 Produkt.

Abgesehen davon bin ich mir ziemlich sicher, dass Lisa Su nicht gesagt hätte "you will see big Navi in 2020", wenn der Release bald anstehen würde, sondern eher "you will see big Navi soon™".
Das ist richtig. Es sei denn, sie wollte vage bleiben.


Und zudem … es gibt ja eine bald erwartete GPU von seiten AMD, nämlich Arcturus.
Macht einfach viel mehr Sinn als Navi.
Ist natürlich eine Möglichkeit.

[JVC]

Das wäre für Big Navi noch deutlich zu früh -

Anders gesehen muss man aber auch eingestehen, das bereits 56(60)CU in den X-Box Entwickler-Kits ausgeliefert werden...

Ich hoffe und denke noch immer, das "Little-Big-Navi(60CU 12Gb)" ~April-Mai aufschlagen wird.

M.f.G. JVC

[HOT]

Lt. PCGH sind 6 Karten gemeldet worden, das wird wohl kein Profiding sein, sondern sicher das 6000er Refreshpaket. Vielleicht gibts ja bald mal Infos zu den großen Karten, denn wenn die den Refresh schon im März/April bringen, werden dei großen nicht weit davon weg sein. Ich tip mal auf Mai.

Wie gesagt muss das erwähnte Tapeout nicht der High-End-Navi gewesen sein, 7nm+ ist schon erheblich früher fertig gewesen, Tapeouts von Zen3 gabs ja lt. AMDs Folien im Mai/Juni in 7nm+ (+ 5 Q wäre dann September 2020 Release, was gut passt), ab dem Datum könnte der ein oder andere Grafikchip ebenfalls Tapeout gefeiert haben.

[Leonidas]

Gab es denn signifikante Leaks vor der 5700XT 1x Monat vorher? (ehrliche Frage)


Naja, ist nicht vergleichbar, weil von AMD Ewigkeiten vorher angeteasert.

Launch am 7. Juli 2019 (https://www.3dcenter.org/artikel/launch-analyse-amd-radeon-rx-5700-5700-xt)
Vorstellung konkreter Grafikkarten am 11. Juni 2019 (https://www.3dcenter.org/news/amd-stellt-die-navi-grafikkarten-radeon-rx-5700-radeon-rx-5700-xt-vor)
Vorstellung der Serie am 27. Mai 2019 (https://www.3dcenter.org/news/amd-kuendigt-navi-basierte-radeon-rx-5000-serie-mit-rdna-architektur-fuer-den-juli)


Leaks vorher (habe reine Termin-Spekulationen weggelassen):
6. Mai 2019: Neue (angebliche) Navi-Spezifikationen mit einem umfangreicheren Navi-Produktportfolio aufgetaucht (https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-6-mai-2019)
28. April 2019: Navi 10 scheint eine Chipfläche von ~260-280mm² aufzuweisen (https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-2728-april-2019)
28. April 2019: Gerüchteküche: Angebliche Navi-Platine zeigt 256 Bit GDDR6-Speicherinterface und dicke Stromversorgung (https://www.3dcenter.org/news/geruechtekueche-angebliche-navi-platine-zeigt-256-bit-gddr6-speicherinterface-und-dicke-stromve)
16. April 2019: Gerüchteküche: AMDs Navi 10 tritt am 7. Juli mit einer höheren Performance als bei der Radeon RX Vega 64 an (https://www.3dcenter.org/news/geruechtekueche-amds-navi-10-tritt-am-7-juli-mit-einer-hoeheren-performance-als-bei-der-radeon-)
22. Februar 2019: Neues AMD-Grafikdevice "7310:00" beim GFXBench könnte eine erste Navi-Grafikkarte sein (https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-2122-februar-2019)
20. November 2018: Gerüchteküche: AMDs Navi 12 soll mit 40 Shader-Clustern auf neuer Grafikchip-Architektur antreten (https://www.3dcenter.org/news/geruechtekueche-amds-navi-12-soll-mit-40-shader-clustern-auf-neuer-grafikchip-architektur-antre)

Wie zu sehen, gibt es da lange vorher viele Infos. Wir hatten lustigerweise seit November 2018 bereits die korrekten Hardware-Daten - mit der falschen Chip-Bezeichnung.




Lt. PCGH sind 6 Karten gemeldet worden


IMO ist die Auflistung mit den 6 Karten eine Aufstellung früherer RRA-Leaks. Damit man sehen kann, wieviel Zeit jeweils zwischen Leak und Release liegt. Neu ist aber IMO nur eine Karte.

[robbitop]

Naja aber die Spekulationen sehen im Nachhinein eher ein wenig wackelig/vage aus.

[Dino-Fossil]

Auf jeden Fall war die Spekulation von AdoredTV (in letzter Zeit hab ich von dem nicht mehr viel gehört) auch zu Navi ziemlich daneben.

[Linmoum]

Lt. PCGH sind 6 Karten gemeldet worden
... und der Nachweis für diese Behauptung fehlt. Wie immer bei PCGH. Typisch verpeilter und inhaltlich falscher Artikel von Herrn Link.

Bei Hardware-"News" sollte man alles tun, nur nicht PCGH anführen.

Ich bleibe weiterhin dabei, dass das Arcturus wird und sie mehr auf dem FDA Anfang März dazu sagen und zeigen werden.

[HOT]

Arcturus ist AFAIK gar kein Chip, sondern irgendwas in Software. Es soll aber einen doppelten Vega-HPC-Chip geben, also 2x 64CUs auf einem Chip. Wenn du das Teil meinst, das ist völlig offen, wann der kommt. Das Produkt ist auch sehr speziell, es wird sich sehr sicher nicht darum handeln.

[Dino-Fossil]

Arcturus wurde im Linux-Treiber und von AMD-Mitarbeitern auf Reddit aber als Chip-Codename geführt.

[Berniyh]

Arcturus ist AFAIK gar kein Chip, sondern irgendwas in Software.
Hast du dafür irgendeine Basis?
Alles was ich bislang gesehen ist, dass Arcturus der nächste HPC Chip ist.

[HOT]

War nur ne Erinnerung, wenns falsch ist, ists falsch, dann ist es halt ein Chipcodename. Ich hab aber ebenfalls noch in Erinnerung, dass AMD nicht nur Codenamen für Chips verteilt.

Brillus danke fürs Klarstellen :D

[Brillus]

War nur ne Erinnerung, wenns falsch ist, ists falsch, dann ist es halt ein Chipcodename. Ich hab aber ebenfalls noch in Erinnerung, dass AMD nicht nur Codenamen für Chips verteilt.

Bei Arctus war die Ansage das sie auf explizite Chipcodenamen gehen anstelle von Familie +Nummer wegen der Vega10 Verwirrung( und das war nach Navi10/14) bekannt war.

[gravitationsfeld]

Arcturus ist def. ein Chip, sonst würde man keine andere Architektur im compiler haben.

[Berniyh]

Es gibt zu Arcturus bekannte PCI IDs, insofern …
»···{0x1002, 0x738C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ARCTURUS},
»···{0x1002, 0x7388, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ARCTURUS},
»···{0x1002, 0x738E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ARCTURUS},
»···{0x1002, 0x7390, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ARCTURUS},

[LasterCluster]

https://www.notebookcheck.com/Die-ma....453127.0.html

Ich habe es mal aus dem Zen2 Thread rüberkopiert, da auch hier relevant. macOS 10.15.4 Beta Einträge von Navi12 und Navi21 (+APUs). Vielleicht ist Navi12 tatsächlich ne Applevariante von Navi10

[HOT]

Halte ich für Quatsch. Der ist ja schon voll aktiviert gewesen. N12 ist höchstens ein N7P-Refresh von N10.

[Agent117]

Wenn N21 wirklich mit 5120 SP kommt macht dieser Refresh mMn wenig Sinn. Dann sollte es auch noch einen Chip mit 3200 SP und RDNA 2 Featureset geben, damit die Lücke nicht zu groß ist. N10 würde ich dann ähnlich wie die 5600XT auf Effizienz getrimmt gegen Ampere unterhalb der mutmaßlichen 3060 stellen gegen eine 3050 oder wie Nvidia die dann nennt.

Aber vlt hat N21 ja auch nur 4090SP, dann macht N10+ ggf. Sinn.

[Sunrise]

RDNA nochmal dieses Jahr zu bringen wäre unklug, ein N10-Nachfolger sollte ordentlich schneller sein, um das LineUp auf den bald aktuellen Stand von AMDs Technik zu bringen und gegenüber NV eine bessere Position zu haben. N10 wird ansonsten wohl regelrecht zersägt und die Margen wären aufgrund von notwendigen Preissenkungen dann sehr sehr dünn. Das kann nicht AMDs Ziel sein.

NV wird voraussichtlich sowohl durch Architektur, neuem Node, besserem Speicher und neuer IP deutlich (50% Minimum, bei HPC eher mehr) zulegen können, das zieht sich dann durch deren komplettes LineUp nach und nach.

[horn 12]

Doch womöglich nur Arcturus zum 05.03.2020 - Tech Day

https://twitter.com/KOMACHI_ENSAKA/status/1225808917252337664?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1225808 917252337664&ref_url=https%3A%2F%2Fwccftech.com%2Famd-radeon-instinct-mi100-arcturus-gpu-32-gb-hbm2-200w-tdp-rumor%2F

[Berniyh]

Sagen wir doch schon die ganze Zeit. ;)

[robbitop]

Es könnte auch sein, dass Ampere/Hopper analog zu Pascal ggü Maxwell wenig Neues (inkl wenig IPC Steigerung) bringt und den Großteil der Mehrleistung aus Takt und Einheiten bringt.
N10 wird dann vermute ich mal vom Performance Segment ins Mainstreamsegment absinken. Ähnliche Positiinierung wie Polaris. Das ist aber für die Chipgröße schon noch relativ üblich.

[BlacKi]

Doch womöglich nur Arcturus zum 05.03.2020 - Tech Day

ich bin schockiert... not

[Ghost1nTh3GPU]

Es könnte auch sein, dass Ampere/Hopper analog zu Pascal ggü Maxwell wenig Neues (inkl wenig IPC Steigerung) bringt und den Großteil der Mehrleistung aus Takt und Einheiten bringt.

Eine praktikable GPU-MCM-Architektur benötigt sicherlich einiges an Entwicklungsaufwand und Basis sollte wohl erstmal eine bekannte Architektur sein.

[y33H@]

Zumal es kein Tech Day ist, sondern Financial Analyst Day ...

[robbitop]

Eine praktikable GPU-MCM-Architektur benötigt sicherlich einiges an Entwicklungsaufwand und Basis sollte wohl erstmal eine bekannte Architektur sein.
MCM Architektur? Ist da soetwas verlautbart worden? Ich sehe aktuell keine Anhaltspunkte, dass die Hürden in sinnvollem Maße überwunden worden sind, so dass es nicht nur praktikabel sondern auch sinnvoll und vorteilhaft sein wird. Zumindest im 3D Grafik Bereich. HPC ist da von den Amforderungen deutlich anders gelagert...

[Ghost1nTh3GPU]

MCM Architektur? Ist da soetwas verlautbart worden? Ich sehe aktuell keine Anhaltspunkte, dass die Hürden in sinnvollem Maße überwunden worden sind, so dass es nicht nur praktikabel sondern auch sinnvoll und vorteilhaft sein wird. Zumindest im 3D Grafik Bereich. HPC ist da von den Amforderungen deutlich anders gelagert...
Wie würdest du das CFR-Experiment (https://www.3dcenter.org/news/nvidia-wiederbelebt-multigpu-rendering-mittels-neuem-cfr-modus) einordnen?
Mit einem 1TB/s EMIB oder vergleichbaren zwischen zwei 400mm² Dies wäre da sicherlich ein interessantes High-End-Produkt möglich, wenn das Verfahren weiterentwickelt wird. Bei HPC sind die Vorteile natürlich noch schneller realisierbar. Fragt sich nur ob das schon mit Ampere passiert oder mit Hopper danach.

Zumal es kein Tech Day ist, sondern Financial Analyst Day ...
Die HPC-Krone (auf FP64 bezogen) für ein paar Monate wäre ein wichtiges Zeichen an die Investoren.

[BlacKi]

MCM Architektur? Ist da soetwas verlautbart worden? Ich sehe aktuell keine Anhaltspunkte, dass die Hürden in sinnvollem Maße überwunden worden sind, so dass es nicht nur praktikabel sondern auch sinnvoll und vorteilhaft sein wird. Zumindest im 3D Grafik Bereich. HPC ist da von den Amforderungen deutlich anders gelagert...
*hust* hier, ist aber OT

macht wohl zuerst im HPC bereich sinn bevor mcm das gaming segment erreicht. deshalb wird hopper wohl HPC exclusive bleiben.
https://www.tweaktown.com/news/69186/nvidia-next-gen-hopper-gpu-arrives-ampere-smash-intel-amd/index.html

[robbitop]

Wie würdest du das CFR-Experiment (https://www.3dcenter.org/news/nvidia-wiederbelebt-multigpu-rendering-mittels-neuem-cfr-modus) einordnen?
Mit einem 1TB/s EMIB oder vergleichbaren zwischen zwei 400mm² Dies wäre da sicherlich ein interessantes High-End-Produkt möglich, wenn das Verfahren weiterentwickelt wird. Bei HPC sind die Vorteile natürlich noch schneller realisierbar. Fragt sich nur ob das schon mit Ampere passiert oder mit Hopper danach.

CFR ist nicht der richtige Weg, da nicht transparent zur Anwendung. CFR, Supertiling, AFR, Scanline interleaving. Das ist alles alter Kram, der in simplen 3D Enginepipelines noch funktioniert hat (im Sinne von Überstülpen in nicht dafür explizit vorgesehenen Spielen). Zumal CFR auch nicht besonders toll war in Bezug auf Auslastung.

Damit mehrere GPUs transparent zur Anwendung arbeiten, müssen sie nach außen wie eine GPU funktionieren. Entsprechend hoch sind die Anforderungen zur Anbindung in Bezug auf Latenz und Bandbreite. Einfach zwei GPUs auf einen Träger mit EMIB oder Silicon Interposer: damit ist es nicht getan.

Zumal es auch ökonomische und Perf/W und Perf/mm² Nachteile gäbe:

1. braucht jedes Chiplet dann entsprechendes I/O: PHY, SersDes, entsprechende Anbindung zum Rest
2. Jedes Signal was off chip gehen soll kostet deutlich mehr Joules pro Bit als on Chip - insbesondere wenn es schnell gehen soll

Damit so niedrige Latenzen und so hohe Bandbreiten überhaupt möglich wären, wären das zwei ordentliche Mali. In Bezug auf Chipfläche und Leistungsaufnahme. Dazu kommen noch die erhöhten Kosten für das Packaging.

Ich bezweifle, dass so etwas in mittelfristigem Zeitrahmen ökonomisch und technisch im Rahmen von 3D Grafik für Spiele sinnvoll und vorteilhaft ist.

@Blacki
Die Zeichnungen in dem Artikel entstammen IIRC einem relativ alten Patent / einer relativ alten Studie von NV, oder? (mit relativ alt meine ich >1-2 Jahre).
Gibt es denn konkrete Hinweise, die auf eine 3D Grafik uArch mit MCM hinweisen? Ich sehe keine.

[Linmoum]

@robbitop

Es gab bzgl. MCM 2018 von Scott Herkelmann und David Wang einige Aussagen zum Thema MCM. Ob das jetzt "konkrete Hinweise" genug sind, darüber kann man sich streiten. Zeigt aber mMn, wo die Reise (erstmal?) hingehen wird.

“We are looking at the MCM type of approach,” says Wang, “but we’ve yet to conclude that this is something that can be used for traditional gaming graphics type of application.”

[...]

It seems, however, that the MCM approach is only an issue in the gaming world, with the professional space more accepting of multi-GPU and potential MCM designs.

“That’s gaming” AMD’s Scott Herkelman tells us. “In professional and Instinct workloads multi-GPU is considerably different, we are all in on that side. Even in blockchain applications we are all in on multi-GPU. Gaming on the other hand has to be enabled by the ISVs. And ISVs see it as a tremendous burden.”

Does that mean we might end up seeing diverging GPU architectures for the professional and consumer spaces to enable MCM on one side and not the other?

“Yeah, I can definitely see that,” says Wang, “because of one reason we just talked about, one workload is a lot more scalable, and has different sensitivity on multi-GPU or multi-die communication. Versus the other workload or applications that are much less scalable on that standpoint. So yes, I can definitely see the possibility that architectures will start diverging.”
https://www.pcgamesn.com/amd-navi-monolithic-gpu-design

[robbitop]

Danke. :) Ja, die Studie meinte ich. Es ist eben nur eine Studie. Mit konkreten Hinweisen meine ich, ob es kürzlich neue konkrete Hinweise gibt, dass ausgerechnet die kommende NV uArch (so klang es nämlich für mich) für 3D Grafik auf eine MCM setzt.
Eine Studie ist nur eine Studie. Ggf. kommt das auch irgendwann in ein 3D Grafikprodukt. Aber dazu muss man zunächst Lösungen finden, die die Nachteile so stark verringern, dass der Vorteil überwiegt. Dazu bräuchte es schon einen kleinen Durchbruch im Bereich Interfaces und Packaging.

Wie bereits beschrieben: für HPC wäre das um Größenordnungen einfacher zu realisieren (bzw die Anforderungen geringer in Bezug auf die Anbindung), da einfacher skalierbar und idR weniger Interdependenzen.

[HOT]

Da wird man denke ich Frontend und Backend trennen müssen, wenn überhaupt. Das ganze auf nem Interposer miteinander verbinden, dann könnte man sogar 2 Backend-Chips oder Chips in 7 und 5nm bringen. Bei EUV jenseits der 7nm wird das ja sogar notwendig sein, diese zu trennen aufgrund der 420mm²-Limitierung.

Wenn AMD das jetzt schon machen würde, könnte man 3 Chips planen, einen 40CUs Backend-Chip in N7+, einen I/O+Frontend-Chip in irgendwas zwischen 12nm und 7nm und zusätzlich noch ein 5nm-Chiplet mit 60CUs planen. Produkte wären dann modular darauf aufbaubar. Das ist zwar für diese Generaiton unwahrscheinlich, aber doch denkbar.
Jetzt wo klar ist, dass der große (505mm²) Chip sehr sicher Acturus ist, ist ja weiterhin alles offen.

[mironicus]

Wie schnell wäre wohl ein Big Navi mit 128 CU (inspiriert vom Arcturus-Thread)? Könnte der dann mit einer vermeintlichen RTX 3080 Ti mithalten?

[Lehdro]

Wie schnell wäre wohl ein Big Navi mit 128 CU (inspiriert vom Arcturus-Thread)? Könnte der dann mit einer vermeintlichen RTX 3080 Ti mithalten?
Kommt auf hauptsächlich auf 3 Sachen an:

- wie skalieren die 128CUs? Potenzielle Bottlenecks beim Sheduling und der Datenversorgung (Cache + HBM)?
- wie hoch kommt man mit dem Takt?
- was macht NV mit der RTX 3080 Ti?

Also: Weiß noch niemand.

[Sunrise]

Wie schnell wäre wohl ein Big Navi mit 128 CU (inspiriert vom Arcturus-Thread)? Könnte der dann mit einer vermeintlichen RTX 3080 Ti mithalten?
Das Hauptproblem wird Bandbreite sein, zusätzlich wohl deutlich größere Caches und das Teil wird zu groß und frisst zuviel, zusätzlich wäre es nicht bezahlbar. Bei 80 CUs hast du auf 7nm+ wohl das Optimum (relativ zu Navi10) bei 100 CUs mit weniger Takt etwa (das 2,5fache von Navi10) das Maximum. Da RDNA2 sicher aber wieder komplexer wird, ist das mit Vorsicht zu genießen.

Bis wir 128 CUs bei RDNA(2, 3 oder wie auch immer) sehen, kannst du dich bis frühestens 5nm (2021/2022) erstmal ausruhen, denn nur weil Arcturus (GCN) mit HBM2 und sehr niedrigem Takt Sinn ergibt, ergibt das bei RDNA im Prinzip garkeinen, weil RDNA insbesondere auf hohen Takt/Performance auf geringer Fläche ausgelegt wurde.

[reaperrr]

Wie schnell wäre wohl ein Big Navi mit 128 CU (inspiriert vom Arcturus-Thread)? Könnte der dann mit einer vermeintlichen RTX 3080 Ti mithalten?
Nicht viel schneller als einer mit 80 CUs, mMn.

Mit HBM wären die Kosten für den Speicher und die Assembly (Interposer, alles fehlerfrei zusammenpacken) wieder deutlich höher, zusätzlich zum riesigen Chip, deswegen klammer ich das mal aus, auch wenn es in 7nm wahrscheinlich die einzige technisch machbare Lösung wäre.

Erstmal ist mehr als 512bit SI mit GDDR aus Platz-Gründen nicht drin.

Damit einher geht, dass man vmtl. auch ROPs und L2$, die seit Vega ans SI gekoppelt sind, ggü. N10 nur verdoppeln könnte, weil die einzige Alternative - Vervierfachung - zuviel Platz und Saft kosten würde.

Damit hätte man im Backend schonmal null Vorteile je MHz ggü. einem 80CU-Navi und durch niedrigeren Takt sogar weniger Durchsatz.

Denn damit kommen wir zum nächsten Problem:
Mit 128 CUs wäre der Stromverbrauch durch die CUs je MHz über 50% höher als bei einem 80CU-Navi, weshalb man deutlich niedrigere Taktraten fahren müsste.

Im Endeffekt bliebe vllt. ein wenig mehr Shader-/TMU-Leistung, bei dafür durch den schlappen Takt schwächerer Front- und Backend-Leistung.

Summa Summarum: vor 3nm sinnfrei, da in 7nm und wahrscheinlich auch noch 5nm nicht auf akzeptable Taktraten zu bringen und dann auch noch irre teuer in der Fertigung.

[Korvaun]

@robbitop

Es gab bzgl. MCM 2018 von Scott Herkelmann und David Wang einige Aussagen zum Thema MCM. Ob das jetzt "konkrete Hinweise" genug sind, darüber kann man sich streiten. Zeigt aber mMn, wo die Reise (erstmal?) hingehen wird....



Ich denke MCM ist mit Ryzen soweit etabliert das es keine Probleme geben sollte sofern Kosten/Nutzen es rechtfertigen. Ist nur fraglich ob das dann wie bisher üblich ohne Heatspreader verbaut wird (worauf wohl die Anspielung auf die ISVs sich bezog, die MCM nicht mögen sollen).

[reaperrr]

Ich denke MCM ist mit Ryzen soweit etabliert das es keine Probleme geben sollte sofern Kosten/Nutzen es rechtfertigen. Ist nur fraglich ob das dann wie bisher üblich ohne Heatspreader verbaut wird (worauf wohl die Anspielung auf die ISVs sich bezog, die MCM nicht mögen sollen).
ISV steht für Independent Software Vendor, das hat nichts mit dem Heatspreader zu tun...

Und MCM für CPUs ist eben nicht vergleichbar mit MCM für GPUs. Um GPU-Chiplets so miteinander zu verbinden, dass sich das MCM wie eine einzelne GPU verhält (also kein AFR, SFR o.ä.), was eben nötig wäre damit die Software-Entwickler sich nicht quer stellen, müsste die Bandbreite zwischen den Chiplets das zigfache von Ryzen-Chiplets betragen, weil viel mehr Daten parallel bearbeitet werden, was dann aber auch das zigfache an PHYs auf dem Chip und Stromverbrauch bedeutet.
Für HPC kommt es sicher irgendwann in Frage, für herkömmliche Grafiksoftware, ganz besonders auch Spiele, macht es aktuell und bis auf weiteres noch keinen Sinn.
Das einzige, was man eventuell schon einigermaßen effizient auf Chiplets auslagern könnte, wäre "Uncore"-Kram wie die Video-Encode/Decode-Einheiten, Audio-DSPs (wenn welche verbaut sind), aber nichts was die Grafikberechnungen selbst betrifft.
Und so richtig scheint sich das bisher weder für NV als auch AMD gelohnt zu haben, sonst hätten sie schon damit angefangen.

[basix]

@reaperr:
Bei reduziertem Takt hast du fast automatisch ^3 Scaling der Energieeffizienz. -10% Takt = -30% Power

[Brillus]

@reaperr:
Bei reduziertem Takt hast du fast automatisch ^3 Scaling der Energieeffizienz. -10% Takt = -30% Power
-27%, sonst hätte man bei -33% Takt ein Perpetomobile.

[reaperrr]

@reaperr:
Bei reduziertem Takt hast du fast automatisch ^3 Scaling der Energieeffizienz. -10% Takt = -30% Power
Der springende Punkt ist für mich, dass a) die Performance-Skalierung je MHz mit den zusätzlichen CUs gegenüber einem 80CU-Navi nicht annähernd linear wäre wegen Frontend/Backend/Bandbreiten-Limitierungen, und du b) einen solchen Chip in 300W schwer auf einen Gameclock von mehr als 1350-1400 MHz kriegen wirst, weil du dafür gegenüber einer 5700 um ca. 15-20% mit dem Takt runter musst, während man den 80CU-Navi dank einfacherem Binning (da bessere Yields) vielleich gerade so noch knapp unter 5700-Takt in die 300W bekommt.
Von den 60% mehr CUs (wenn die Yieldraten es überhaupt zulassen, eine Graka mit vollen 128 CUs zu bringen) bleiben am Ende vielleicht 20% mehr Leistung gegenüber einem deutlich kleineren Chip mit 80 CUs.

Dass die 2080 Ti in vielen Spielen (auch solchen, wo kein CPU-Limit besteht) nur ~30% vor der 2080 liegt kommt ja auch nicht von ungefähr, das liegt nahezu komplett am ~100-150 MHz niedrigeren Takt, weil manche Dinge nach wie vor besser mit mehr Takt skalieren als mit mehr Shader-/Textur-Einheiten, und ein niedrigerer Takt deshalb doppelt reinhaut.
Ein 80CU-Navi würde in 300W locker 200 MHz mehr unter Last schaffen als ein 128CU-Navi, und wenn wir bei beiden 512bit GDDR6 und 128 ROPs annehmen, ist der IPC-Unterschied am Ende noch geringer als bei TU102 vs. TU104.

[horn 12]

https://www.pcgamesn.com/amd/big-navi-release-date

[Berniyh]

https://www.pcgamesn.com/amd/big-navi-release-date
Das ist doch längst debunked.

[Linmoum]

Wie kann etwas "längst debunked" sein, wenn der (neue) Eintrag erst vom 19.02 - ergo heute - ist? ;)

Davon ab, dass dieses reflexartige Geschreie nach Big Navi irgendwann nur noch ermüdend ist. Egal was, alles wird damit in Verbindung gebracht, ohne großartig zu überlegen. Vor allem seitens der Medien irgendwie erschütternd. Artikel bei PCGH wird natürlich morgen folgen mit Schlussfolgerung Big Navi. Muss es ja schließlich sein, andere GPUs und Marktsegmente existieren bei und für AMD schließlich nicht.

[Berniyh]

Wie kann etwas "längst debunked" sein, wenn der (neue) Eintrag erst vom 19.02 - ergo heute - ist? ;)
Weil es ähnliche Berichte schon von anderen Seiten gab und wir damals schon breit erläutert haben (und andere Seiten auch schon erkannt haben), dass die nächste "GPU" von AMD nicht Big Navi, sondern Arcturus sein sollte.
Auch hier dürfte es sich wieder um Arcturus handeln.

Ok, evtl. ist es hier ein Eintrag in einer anderen Datenbank, aber das spielt ja nicht wirklich eine Rolle.

[Leonidas]

Naja, was wirklich demnächst kommt, ist noch nicht raus. Im Teststatus dürfte derzeit beides sein, wenn Big Navi noch dieses Jahr herauskommen soll.

Aber natürlich denke ich auch eher an Arcturus bei diesen Einträgen. Einfach, weil der Datacenter-Chip für AMD momentan Priorität genießen dürfte, in diesem Feld lockt einfach die Rendite.

[Berniyh]

Naja, was wirklich demnächst kommt, ist noch nicht raus. Im Teststatus dürfte derzeit beides sein, wenn Big Navi noch dieses Jahr herauskommen soll.
Das stimmt, aber Big Navi dürfte noch ein Stück von der Veröffentlichung entfernt sein und ein halbes Jahr vorher werden die Eintragungen ja eher nicht gemacht.
Aber natürlich denke ich auch eher an Arcturus bei diesen Einträgen. Einfach, weil der Datacenter-Chip für AMD momentan Priorität genießen dürfte, in diesem Feld lockt einfach die Rendite.
Ich glaube um die Rendite geht es dabei gar nicht so sehr, denn im Umsatz machen die HPC Chips ja einen verschwindet geringen Anteil aus.
Mit Big Navi dürfte AMD deutlich mehr Profit machen. Nicht pro Karte, aber insgesamt.
Und das obwohl die Absatzzahlen für Big Navi vermutlich auch nicht groß sein werden.

Letztendlich ist aber RDNA2 wohl einfach noch nicht so weit, dass man da Karten releasen könnte.
Sonst wüssten wir schon viel mehr darüber. Über andere AMD Produkte waren zumindest ganz grobe Details schon mehere Monate im vorraus halbwegs klar.
Zu Big Navi wissen wir nach wie vor so gut wie gar nichts (außer, dass es RDNA2 und 7nm+ sein wird).

[Leonidas]

Vielleicht ist die einfachste Erklärung am Ende die zutreffende: Arcturus wird einfach etwas früher fertig als Navi 21.

[Berniyh]

Vielleicht ist die einfachste Erklärung am Ende die zutreffende: Arcturus wird einfach etwas früher fertig als Navi 21.
Genau das wollte ich mit dem letzten Abschnitt aussagen. ;)

[Piefkee]

https://twitter.com/CyberCatPunk/status/1231762449994371073

https://pbs.twimg.com/media/ERgZZ28UUAAA2Wf?format=jpg&name=large


Big Navi von SKHynix geleakt?
-Shading units: 5120
-TMUs: 320
-ROPs: 96
-Compute units: 80
-L2 cache: 12MB
-Memory: 24GB (4 x HBM2e, 3 die)
-Memory bus: 4096 bits
-BandWidth: 2048 GB/s

That would be Big Navi if true. Hynix showed a 4Gb/s HBM2e stack last week at ISSCC-2020.

That's 512 GB/s for the die stack which would be 3 high in this case.

[dargo]

Mit 24GB HBM2 sicherlich kein Gaming-Chip.

[Piefkee]

Mit 24GB HBM2 sicherlich kein Gaming-Chip.


Wenn das wirklich alles so stimmt wie es steht. Dann ist das wie im Foto eine 5950XT. Übrigens dieser 5750, 5850 5950 Namen wurden von AMD registriert. Finde gerade die Quelle nicht aber ist schon 6 Monate her.

[Kehaar]

Wenn das wirklich alles so stimmt wie es steht. Dann ist das wie im Foto eine 5950XT. Übrigens dieser 5750, 5850 5950 Namen wurden von AMD registriert. Finde gerade die Quelle nicht aber ist schon 6 Monate her.
Ich bin der Meinung, AMD sollte über eine neue Nummerierung nachdenken. Die 5000-Reihe halte ich für nicht mehr zugkräftig genug, um die neuen Navi-GPUs mit Raytracing zu repräsentieren. Also vielleicht eher 6800 bzw. 6900 für Big-Navi?

[HOT]

Das wird ne 5850 oder gleich ne 6800 sein. Die 24GB dienen hier als Demo, was geht. Da werden sicherlich auch 6 oder 8GB pro Stapel gehen, das ist aber eher weniger beeindruckend :D.

[Berniyh]

Wenn das wirklich alles so stimmt wie es steht. Dann ist das wie im Foto eine 5950XT. Übrigens dieser 5750, 5850 5950 Namen wurden von AMD registriert. Finde gerade die Quelle nicht aber ist schon 6 Monate her.
Das war doch diese zweifelhafte russische Datenbank.

Würde mich aber massivst wundern, wenn AMD eine 5950XT bringt.
Eigentlich würdem an doch denken, dass es jetzt dann mit der 6000er Serie weiter geht.

Aber evtl. handelt es sich dabei ja um Navi12 in Workstation-Ausführung.
Wobei die 4096 Bit Speicherinterface gegen Navi12 sprechen würden.
Der sollte 2048 Bit (bei HBM2) oder 256 Bit (bei GDDR6) haben.

[HOT]

Navi12 ist nur ein N10 reloaded, da bin ich mir sehr sicher.
Und WS oder nicht ist für ne SKHynix-Demo irrelevant. Die werden einen N21 genommen haben und den mit 2 maximal dicken Stapeln bedacht haben (2x12GB 3,2GT). In der Praxis wird AMD eher kostengünstigere Varianten verkaufen, auch bei den Radeon Pro-Varianten ;).

[BoMbY]

D32310 ist jedenfalls eine von den Nummern auf der Liste kürzlich.

[Der_Korken]

Entweder sind die 5120SPs zu mickrig oder die 2TB/s völlig übertrieben. Das Ding soll doppelt so viel Rechenleistung aber mehr als vier mal so viel Bandbreite wie eine 5700XT haben, bei der die Bandbreite sowieso schon nicht knapp ist wie man an der 5600XT gesehen hat. Soll das ein HPC-Chip sein? Wozu baut AMD dann parallel noch Arcturus, der angeblich 8192SPs haben soll und die Bandbreite viel eher gebrauchen könnte? Und dann noch 24GB (sind 6GB pro Stack überhaupt möglich?), ebenfalls zu viel für einen Gaming-Chip, aber die Hälfte davon (12GB) wäre wieder etwas wenig für eine doppelte 5700XT.

Ergibt für mich gar keinen Sinn diese Konstellation.

Edit: Achso, und 96 ROPs. Wie will man die verteilen? 24 pro HBM-Stack oder 12 pro Shader Array (ich gehe mal davon aus, dass es davon 8 gibt und nicht 4 und einfach nur doppelt so viele CUs drangepappt wie bei Fiji)? Auch merkwürdig, da nimmt man doch gleich 128 um im alten Schema zu bleiben; so groß können die im Vergleich zu den ganzen Shadern nicht sein.

[JVC]

https://twitter.com/CyberCatPunk/status/1231762449994371073

https://pbs.twimg.com/media/ERgZZ28UUAAA2Wf?format=jpg&name=large


Big Navi von SKHynix geleakt?
-Shading units: 5120
-TMUs: 320
-ROPs: 96
-Compute units: 80
-L2 cache: 12MB
-Memory: 24GB (4 x HBM2e, 3 die)
-Memory bus: 4096 bits
-BandWidth: 2048 GB/s

Wenn es wahr ist ... immer her damit :smile:
999.- für die 12Gb und 1249.- für die 24Gb ?
(ich nehm die 24Gb ;), mit HDMI 2.1 Bitte! mehr brauch ich nicht wissen^^)
Shut up and take my Money!

Ach ja, und am besten schon Gestern !

Das ist vermutlich die letzte "altegen"
N22-N23 dann die "neugen" :confused:
(oder waren das immer nur die ConsolenSocs ?)

M.f.G. JVC

[HOT]

Der_Korken
Wenn man RT und auch die neuen Konsolen ernst nimmt ist das glaube ich nicht übertrieben, ich denke aber dennoch, dass das, wenn das wahr sein sollte, eine SKHynix-Demo ist und keine AMD-Demo.


Edit: fällt mir ja beim genauen angucken auf, das Ding ist ein absoluter Picasso. MMn genau so ein Fake wie der AM100 Schwachsinn.

[Berniyh]

Navi12 ist nur ein N10 reloaded, da bin ich mir sehr sicher.
Schön für dich. Faktisch betrachtet ist das allerdings ziemlich offen.

[Der_Korken]

Der_Korken
Wenn man RT und auch die neuen Konsolen ernst nimmt ist das glaube ich nicht übertrieben, ich denke aber dennoch, dass das, wenn das wahr sein sollte, eine SKHynix-Demo ist und keine AMD-Demo.

Warum sollte RT plötzlich mehr als doppelt so viel Bandbreite pro FLOPs/s für den ganzen Chip brauchen? Zum Vergleich: Eine 5700XT würde bei dem Verhältnis 1TB/s bekommen, also so viel wie eine R7 und ähnlich teuer würde sie vermutlich auch werden - für in normalen Spielen vielleicht 10% Mehrleistung.

HBM2e kann gerne für den Big Navi kommen, aber 1TB/s und 16GB reichen da dicke aus, alles andere machts nur unnötig teurer.

[Unicous]

4 Stacks und dann 24GB. Also 6GB pro Stack. Warum nicht 8? Warum veröffentlicht hynix den (bereits bekannten) Board?-Namen einer unveröffentlichten GPU. Warum wird 5950XT als Produktname genannt, obwohl es keine Anzeichen dafür gibt, dass AMD den Namen verwendet. Sorry, aber das ist alles etwas fishy. Die ROPs sind auch weird für so einen großen Chip.:confused:

[basix]

Ach kommt jetzt. Evtl. sind es 5120 FP64 Units, welche via Rapid Packed Math in FP32 / FP16 / INT8 rechnen können. Dazu 2 TB/s Bandbreite @ HBMe High Bandwidth Cache. Hohe Bandbreite und tiefe Latenzen sind zudem für Raytracing wichtig. Und das ganze für sagenhafte 595.0$ ;D

[reaperrr]

Die ROPs sind auch weird für so einen großen Chip.:confused:
Nicht nur weird, sondern mit der Konfig eigentlich unmöglich.

Seit Vega sind bei AMD die ROPs, der L2 und eben das SI nämlich eigentlich genauso aneinander gekoppelt wie bei Nvidia.

Heißt: Entweder hat der Chip nur ein 3072 bit SI (was auch besser zu den 24GB und dem Rest außer der Bandbreite passen würde), oder (wesentlich wahrscheinlicher) das ganze Ding ist einfach nur Fake und der Ersteller hatte zu wenig Ahnung, um was durchweg schlüssiges hinzukriegen.

[BoMbY]

Okay, bei Navi10 hat AMD 4 RBs (== 16 ROPs?) pro Shader Engine:

https://i.imgur.com/gsNamJD.png

Mit 96 ROPs käme man so auf 6 Shader Arrays (== 3 Shader Engines?), welche mit 80 CUs dann jeweils 13,3 CUs hätten? Das geht irgendwie nicht auf ...

Edit: Das Whitepaper (https://www.amd.com/system/files/documents/rdna-whitepaper.pdf)sagt:


To scale performance from the low-end to the high-end, different GPUs can increase the number of shader arrays and also alter the balance of resources within each shader array.


Also maximal 2 Shader Engines, aber andere Anzahl Shader Array und RB ist theoretisch möglich.

Wie Teil man 80 CUs auf Arrays auf?

4 Arrays x 20 CUs mit je 6 RBs == 24 ROPs

oder

8 Arrays x 10 CUs mit je 3 RBs == 12 ROPs?

[unl34shed]

Sitzen die ROPs denn in den RB Blöcken?

Die 96 würde zu der Anzahl des L2 Caches passen
Navi 14 hat 2 MB = 32 ROPs
Navi 10 hat 4 MB = 64 ROPs
Wenn man für "Big Navi" mit doppelter Cache * 1,5 rechnet -> 96

Nur mal so eine Überlegung.


3 High Stacks klingen zwar komisch, aber warum nicht? Spart bestimmt etwas kosten und hilft bei den hohen Taktraten.

[mczak]

Sitzen die ROPs denn in den RB Blöcken?

RB ist dasselbe wie ROP. Nvidia spricht von ROPs (Render Output Unit oder Raster Operations, da scheint's mehrere Interpretationen der Abkürzung zu geben), AMD von RB (Render Backend).

[reaperrr]

RB ist dasselbe wie ROP. Nvidia spricht von ROPs (Render Output Unit oder Raster Operations, da scheint's mehrere Interpretationen der Abkürzung zu geben), AMD von RB (Render Backend).
Jein. Es sind bei AMD immer 4 Color ROPs und 16 Z/Stencil ROPs (jedenfalls bis Vega, kA ob's bei Navi noch 16 sind) zu einem Block zusammengefasst, AMD nennt diesen Block RB. Ist bei NV vermutlich ähnlich aufgebaut (bloß mit doppelt so viel Z/Stencil ROPs), aber Nvidia spart sich einen Oberbegriff und nennt einfach nur die Zahl der (Color) ROPs.

[Digidi]

Hmm 5000 shader waren zu wenig für die neuen ampere Karten von NVIDIA. Wenn NVIDIA 4600 hat und dann 50% mehr Einheiten bekommt ist man dann bei ca. 7000 shader. Das waren dann mal 25% unterschied.

[HOT]

Glaskugel FTW!
Mal im ernst: Was NV im Consumer macht ist vollkommen unklar. Ob da mehr Takt forciert wird oder es weiter in die Breite geht ist vollkommen unbekannt.

Es wird sicherlich schwer für AMD aber mal sehen, was da noch so kommt.

[Badesalz]

Nehme an irgendwelche "Kronen" interessieren auch mit BigNavi noch nicht. Polaris war recht erfolgreich ohne Pascal mit der Leistung angreifen zu können.

Es geht erstmal weiterhin darum die Wettbewerbsfähigkeit zu erhöhen. P/L also. Dazu gehört noch ne Weile nicht sich bei 4k auf Ultra mit RT zu duellieren.

[HOT]

UHD ok, RT wird sich zeigen. Kann ja sein, dass AMD mit dem eigenen Konzept für RT hier einen erheblich besseren Start hat als NV.

[Bucklew]

Kann ja sein, dass AMD mit dem eigenen Konzept für RT hier einen erheblich besseren Start hat als NV.
Die Frage ist eher, ob AMD überhaupt ein eigenes/anderes Konzept hat oder nicht einfach nur CopyCat spielt.

[Badesalz]

Ja Bucklew, wird wahrscheinlich auch so sein, daß AMD für RT auch eigene Einheiten (Cores) verbaut. Diese Diebe...

[Complicated]

Soweit bisher bekannt wird AMDs Ansatz ein anderer. https://www.pcgameshardware.de/Raytracing-Hardware-255905/News/AMD-patentiert-eigene-Texturprozessor-Loesung-1293305/amp/

[Badesalz]

Ok. Stand jetzt kann das für mich niemals effizienter sein. Wobei das auch kein echter anderer Ansatz ist. Nur bisschen hin&her Gemauschel.

Aber gut, ihre coreflood bringt das vielleicht brauchbar über die Runden. Daß der Treiber die CPU stärker auslastet als bie NV wäre jetzt nicht neu...
Die Gameengines selbst kommen eigentlich mit 8 Threads aus. Mehr, bringt noch bisschen mehr, aber eine gute Auslastung hat man dann eher nur in wenigen Spezialfällen.

Ob sowas hybrides technisch sinnig ist, lass ich mal so im Raum stehen. Blöd ist das aber nicht von denen. Wenn du mehr FPS mit RT haben willst, rüste auch die CPU auf. Ja natürlich hauts am meisten ab Zen2 rein :ulol:

[Complicated]

Wie kommst du auf CPU? In meinem Link steht nichts davon...

[Badesalz]

"Bei AMDs Lösung handelt es sich offenbar um einen "hybriden Ansatz" zur Berechnung von Raytracing. Der Kern wäre damit kein eigener Raytracing-Prozessor, sondern eine Kombination aus Software- und Hardware-Lösung"

Die Software, die läuft natürlich rein auf den CUs? Was wäre daran "hybrid"? Auf NVs RT-Cores läuft auch "Software". RT entsteht ja nicht durch Magie. Da sagt man aber nicht "hybrid" zu.

Oder was soll da wie passieren? Normale CUs teils damit zu beschäftigen... Ich weiß nicht, ob sie so viele davon jeweils über haben (FPS) Wenn sie CUs haben die dafür dediziert sind, würde das eigentlich zu RT-Cores gehören. Nur eben vielleicht nicht auf dem Blockschaltbild der GPU.
An sich aber Jacke wie Hose oder?

Was ist "ermöglicht besseres Raytracing"? Schon bei NV meckerte man schnell, daß man eigentlich keine Effekthascherei haben will. Man kann also wohl auch übertreiben. Jetzt schon. Wenn man jetzt schon mit der ersten Generation übertreiben kann, wo kann sowas noch "besser" sein?
Weniger Leistungsverlust durch RT, bestens, aber "besseres RT ermöglichen"? Also für mich ist das schon gut genug. Kostet momentan nur bisschen zuviel FPS und bisschen zuviel Geld ;)

Aktuell (immer mitbeachten ;)) kann ich mir nicht vorstellen was und warum man da noch "besser" machen soll.

edit:
Ja, mir ist klar, daß RT nicht nur Spiegelungen sind.

[Der_Korken]

Ich würde den Ansatz eher so verstehen, dass man keine dedizierten Einheiten verbauen möchte, die ausschließlich für Raytracing verwendet werden und sonst gar nicht. Stattdessen sollen die bestehenden Einheiten (SIMD Units und TMUs) erweitert werden, sodass diese entsprechende Raytracing-Operationen effizient berechnen können (so wie TMUs eine bilineare Filterung fest verdrahtet haben könnte man dort auch die Schnittpunktberechnung einer Geraden mit einer Ebene fest verdrahten). Dadurch wird die bestehende Speicherhierachie mitbenutzt. Und falls diese aufgebohrt werden muss, weil Raytracing da höhere Anforderungen hat, dann profitieren auch non-raytracing-Anwendungen davon.

Ob das ganze in der Praxis aufgeht, wird man dann sehen müssen. Im schlechtesten Fall floppt es und die RT-Performance wird extrem mies, im besten Fall funktioniert sie so gut wie bei Nvidia, aber man hat viel Chipfläche eingespart. Oder man hat die Situation wie damals bei Tesselation, dass die Nvidia-Lösung zwar in synthetischen Benchmarks alles zerlegt, in der Praxis aber AMD kaum Nachteile hat, weil der Rechenaufwand für "normales Shading" in Spielen dominiert (so wie 64x Tesselation in Spielen keine Relevanz hatte und man zu 16x praktisch keinen Unterschied gesehen hat, dieser aber auf AMD ausreichend schnell war).

[Badesalz]

Vielleicht nah dran, aber nicht genau ausformuliert für "Software" ;) (imho)
(so wie TMUs eine bilineare Filterung fest verdrahtet haben könnte man dort auch die Schnittpunktberechnung einer Geraden mit einer Ebene fest verdrahten)Könnte man die Filterung dann als eine "hybride" Lösung bezeichnen? Eher nicht oder?

Die RT Leistung wird schon nicht mies sein auf den Konsolen. Auf dem PC also auch nicht. Welchen Sinn würde das denn ergeben, ausser sich lächerlich zu machen?

Die Frage ist wie gesagt wieviel der drivercore, ergo die CPU, damit beim Zubereiten zu tun hat.

[Felixxz2]

Software bedeutet in dem Fall CU, sind ja General Purpose.

[Badesalz]

Ist klar eine Möglichkeit. Mal sehen ob eine gute. Da bin ich diesmal aber wirklich gespannt auf die GPU :)

Und wie sie das nicht nur für Vulkan, sondern auch für DX verheiratet bekommen. Wobei ich annehme, daß es mit der neuen Xbox auch ein DX Update für Windows geben wird :) Sonst wäre das ein Bärendienst an AMD. Denke das ist schon entsprechend abgesprochen werden.

Bis denne.

[unl34shed]

Da muss man auch nicht viel rumrätseln, das Patent ist verfügbar http://www.freepatentsonline.com/20190197761.pdf

[HOT]

Ich würde den Ansatz eher so verstehen, dass man keine dedizierten Einheiten verbauen möchte, die ausschließlich für Raytracing verwendet werden und sonst gar nicht. Stattdessen sollen die bestehenden Einheiten (SIMD Units und TMUs) erweitert werden, sodass diese entsprechende Raytracing-Operationen effizient berechnen können (so wie TMUs eine bilineare Filterung fest verdrahtet haben könnte man dort auch die Schnittpunktberechnung einer Geraden mit einer Ebene fest verdrahten). Dadurch wird die bestehende Speicherhierachie mitbenutzt. Und falls diese aufgebohrt werden muss, weil Raytracing da höhere Anforderungen hat, dann profitieren auch non-raytracing-Anwendungen davon.

Ob das ganze in der Praxis aufgeht, wird man dann sehen müssen. Im schlechtesten Fall floppt es und die RT-Performance wird extrem mies, im besten Fall funktioniert sie so gut wie bei Nvidia, aber man hat viel Chipfläche eingespart. Oder man hat die Situation wie damals bei Tesselation, dass die Nvidia-Lösung zwar in synthetischen Benchmarks alles zerlegt, in der Praxis aber AMD kaum Nachteile hat, weil der Rechenaufwand für "normales Shading" in Spielen dominiert (so wie 64x Tesselation in Spielen keine Relevanz hatte und man zu 16x praktisch keinen Unterschied gesehen hat, dieser aber auf AMD ausreichend schnell war).

Die werden das ja nach Anforderungen von M$ und Sony gemacht haben. Und das ist auch der Punkt: Die Spiele werden genau auf diesen (!) Ansatz hin optimiert werden.
Von daher kann man das als "Gut" oder "schlecht" bewerten, es ist der Ansatz der gemacht wird und fertig. Ich meinte da ja auch gar nicht, dass AMD hier viel schneller ist in der Theorie, sondern, dass die Optimierungen in der Praxis greifen werden und die Konsolen liefern die Grundlage dafür.
Davon abgesehen kann es ja auch sein, dass bei NV die RT-Cores wieder verschwinden werden und man einen ähnlichen Ansatz mit der nächsten Generaton verfolgen könnte. Ich hatte ja sowieso den Verdacht, dass Turing noch sehr nah an Volta ist und man entsprechend erweitert hat, wie Maxwell damals um DX12 erweitert wurde.

[Berniyh]

Die Spiele werden genau auf diesen (!) Ansatz hin optimiert werden.
Zumindest die Spiele, welche auf den Konsolen veröffentlicht werden.
(was ja längst nicht bei allen der Fall sein wird)

Ist aber trotzdem ein wichtiger Punkt, denn am Ende könnte es sein, dass Nvidia da für wenig Gewinn ordentlich Fläche verschenkt.

[Felixxz2]

Erinnert ein wenig an die Frage ob man für DP eigene Cores benutzt. Ich denke aber auch, dass AMD da was sehr rundes abliefern wird, eben weil das sicher durch einiges an Input von Sony/MS garniert wurde. Und wenn es nur so ist, dass man eben massiv Fläche spart, was für die Konsolen mega wichtig ist.

[Bucklew]

Die werden das ja nach Anforderungen von M$ und Sony gemacht haben. Und das ist auch der Punkt: Die Spiele werden genau auf diesen (!) Ansatz hin optimiert werden.
Das behauptet ihr jetzt seit dem PS4/XBoxOne Launch vor 6 Jahren. Wirklich erkennen kann man es nicht. Dafür ist NVIDIA auch viel zu verbreitet am PC, als dass man ihre Architektur einfach so ignorieren könnte. Gerade bei RT natürlich erst Recht. Die aufgebaute Basis von RTX muss AMD erstmal rein kriegen, egal ob Konsole oder PC.

[dildo4u]

Was auch logisch ist da am PC fast alles durch zusätzliche API Layer geht,ohne Vulkan/DX12 kann AMD den Vorteil nicht ausspielen.

Outer Worlds DX11 1070=5600XT

World War Z Vulkan 5600XT 27% schneller als 1070.

F1 2019 DX12 + 29% für den 5600XT

https://www.techspot.com/review/1982-radeon-5600xt-vs-geforce-gtx-1060-vs-gtx-1070/

[Complicated]

Vielleicht nah dran, aber nicht genau ausformuliert für "Software" ;) (imho)

Nvidias RTCores sind auch keine reine Hardwarelösung. Ohne Anpassungen in der Software werden die RTCores nicht genutzt. Deswegen kommt noch lange nicht die CPU zum Einsatz. Textureprocessing ist AMDs Ansatz. Auch das sind Hardwareeinheiten. Wie beschrieben werden aber keine zusätzlichen Buffern benötigt bei AMDs Ansatz da schon vorhandene Einheiten dafür angepasst werden. Das spart in jedem Fall schon mal Platz auf dem Chip.

Der Unterschied zu den letzten 6 Jahren ist hier Nvidias proprietärer Ansatz, der eben zusätzliche Arbeit beim portieren auf PC extra für Nvidia bedeutet. Nvidia kann da sicherlich, wie für PhysX und anderes Gameworx, Entwickler abstellen.

Nur wird AMD Hardware eben nicht links liegen gelassen, wie bisher, wenn die Portierung auf PC erfolgt.

[HOT]

Das behauptet ihr jetzt seit dem PS4/XBoxOne Launch vor 6 Jahren. Wirklich erkennen kann man es nicht. Dafür ist NVIDIA auch viel zu verbreitet am PC, als dass man ihre Architektur einfach so ignorieren könnte. Gerade bei RT natürlich erst Recht. Die aufgebaute Basis von RTX muss AMD erstmal rein kriegen, egal ob Konsole oder PC.

Das ist ja auch so passiert, nur dass die PC-Umsetzungen von anderen Studios übernommen wurden und die jeweils oft alte PC-Technik eingesetzt haben. Gute Beispiel ist Skyrim - auf der Konsole war es ein aktueller Renderer, für die PC-Version hat man Oblivion recycelt, mit allen Nachteilen. Man fixte das zwar, aber das Beispiel gilt ja für vieles.
Das ist heute etwas anders, da diese von dir genannten Konsolen die LowLevel-APIs erst zum Durchbruch verhelfen konnten. Der Prozess ist ja fließend, das ist ja nicht vor 6 Jahren und BÄM, insbesondere bei Microsoft. Das hat sich suksessive entwickelt und man sieht es an BF5 und RDR2, was da mit moderner Grafiktechnologie in Software geht und wie die AMDs heute dabei abschneiden, übrigens auch altes GCN alias Polaris. Und bei RT wird das eh nicht gelten, da die Techniken ja einfach übernommen werden können. Die XBX setzt ebenfalls auf DXR.

Konsolen und PC wächst dank Microsoft zusammen, die XB1 war der Startschuss, wir sind jetzt aber 6 Jahre weiter.


Complicated
RT ist bei den Konsolen ein integriertes Feature, wie PP- und Umgebungsverdeckungstechniken jetzt. Das wird einfach überall für Beleuchtung und Verschattung (und Spieglungen, wobei das sicherlich eher selektiv eingesetzt wird) zum Einsatz kommen in der nächsten Generation. Genau für diesen Einsatz ist RDNA2 gedacht.

[Bucklew]

auf der Konsole war es ein aktueller Renderer, für die PC-Version hat man Oblivion recycelt, mit allen Nachteilen.
Eine Schwalbe macht keinen Sommer.

Als Gegenbeispiel kann man ja zum Beispiel Control nennen, dessen dyn. Lighting praktisch nur mit RTX-Karten funktioniert.

Grundsätzlich wird jeder Entwickler von Anfang an den PC genauso beachten, wie die Konsolen.

[HOT]

Control ist in der Tat ein gutes Beispiel aber pre-Konsole. Das ist halt rein auf die NV-Technik angepasst und ein echtes Leuchtturmprojekt dafür. Eine Schwalbe macht keinen Sommer, das gilt hierfür wie kein weiteres Spiel. Im Gegensatz zu meinem Beispiel, von denen es 100e gibt. Allein die AC Serie...

[robbitop]

Ggf. macht es AMD wie Caustic zu IMG Zeiten und binnt die Rays. Das könnte aufgrund Divergenz der bandbreitenfreundlichere Ansatz sein. Kann mir auch gut vorstellen, dass NV das zu ihrer nextgen auch tut.

[basix]

Ggf. macht es AMD wie Caustic zu IMG Zeiten und binnt die Rays. Das könnte aufgrund Divergenz der bandbreitenfreundlichere Ansatz sein. Kann mir auch gut vorstellen, dass NV das zu ihrer nextgen auch tut.

Frostbite und Unity machen Ray Binning bereits in SW. Kann aber sein, dass ein HW Ansatz beschleunigt.

[y33H@]

Gute Beispiel ist Skyrim - auf der Konsole war es ein aktueller Renderer, für die PC-Version hat man Oblivion recycelt, mit allen Nachteilen.
Hab ich was verpasst?

[robbitop]

Frostbite und Unity machen Ray Binning bereits in SW. Kann aber sein, dass ein HW Ansatz beschleunigt.
Wenn du sagst „SW“ ist aber sicherlich auf der GPU gemeint? Sollte über HW schneller sein.

[Felixxz2]

Hab ich was verpasst?

Würde mich auch interessieren!

[Dino-Fossil]

Kann mich nur erinnern, dass Bethesda damals vergessen hatte, für die PC-Version diverse Optimierungs-Flags im Compiler anzuwerfen. Das wurde dann in einem der Patches nach ein paar Wochen nachgereicht.

[Unicous]

Kann mich nur erinnern, dass Bethesda damals vergessen hatte, für die PC-Version diverse Optimierungs-Flags im Compiler anzuwerfen. Das wurde dann in einem der Patches nach ein paar Wochen nachgereicht.

A.k.a. komplett anderer Renderer.:freak:

[basix]

Wenn du sagst „SW“ ist aber sicherlich auf der GPU gemeint? Sollte über HW schneller sein.

Compute Shader, ja.

[BoMbY]

Auf der GDC in drei Wochen wird man vielleicht etwas mehr zum Thema Raytracing hören. Bei dem Vulkan RT Vortrag (https://schedule.gdconf.com/session/ray-tracing-in-vulkan-presented-by-khronos-group/873839) wird auch ein Sprecher von AMD erwähnt.

[Fragman]

Auf der GDC in drei Wochen wird man vielleicht etwas mehr zum Thema Raytracing hören. Bei dem Vulkan RT Vortrag (https://schedule.gdconf.com/session/ray-tracing-in-vulkan-presented-by-khronos-group/873839) wird auch ein Sprecher von AMD erwähnt.

da gab es doch vor kurzem schon einen Vortrag.

https://www.youtube.com/watch?v=xpxVAoXaVgg

[Berniyh]

Ich hab noch mal ein bisschen im Linux Kernel rumgegraben ob sich noch was interessantes zu Navi12 finden lässt:
/*
* Due to DF Cstate management centralized to PMFW, the firmware
* loading sequence will be updated as below:
* - Load KDB
* - Load SYS_DRV
* - Load tOS
* - Load PMFW
* - Setup TMR
* - Load other non-psp fw
* - Load ASD
* - Load XGMI/RAS/HDCP/DTM TA if any
*
* This new sequence is required for
* - Arcturus
* - Navi12 and onwards
*/
static void psp_check_pmfw_centralized_cstate_management(struct psp_context *psp)
{
»···struct amdgpu_device *adev = psp->adev;

»···psp->pmfw_centralized_cstate_management = false;

»···if (amdgpu_sriov_vf(adev))
»···»···return;

»···if (adev->flags & AMD_IS_APU)
»···»···return;

»···if ((adev->asic_type == CHIP_ARCTURUS) ||
»··· (adev->asic_type >= CHIP_NAVI12))
»···»···psp->pmfw_centralized_cstate_management = true;
}

"Navi12 and onwards" bezieht sich hier vermutlich auf Navi12 und Navi2x.
Navi10/14 sind explizit nicht enthalten.

Das spricht erst mal natürlich überhaupt nicht gegen die Theorie Navi12 = Navi10 + HBM2, kann sich ja auch um eine leicht geänderte Revision handeln.

Was mich aber etwas verwundert ist dieser ganze Code hier:
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c?h=amd-staging-drm-next#n3318

Das ist irgendwie verdammt viel extra Code für einen Chip der "quasi" gleich sein soll?

Außerdem noch der Code hier (gleiche Datei, Zeile 3774):
»···// IF NV12, set PG function pointer to NULL. It's not that
»···// PG isn't supported for NV12, it's that we don't want to
»···// program the registers because that will cause more power
»···// to be consumed. We could have created dcn20_init_hw to get
»···// the same effect by checking ASIC rev, but there was a
»···// request at some point to not check ASIC rev on hw sequencer.
»···if (ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev))
»···»···dc->hwseq->funcs.enable_power_gating_plane = NULL;
oooookaaay?

Warum ist es jetzt speziell bei Navi12 so wichtig nicht extra Energie zu ziehen?

Das zusammen mit der Info, dass die "Peak" Taktfrequenz von Navi12 angeblich 1100 MHz ist lässt eigentlich nur den Schluss zu, dass es sich um einen Navi Chip handelt der auf Effizienz getrimmt wurde.
Zu welchem Zweck auch immer?
In jedem Fall scheint mir die Annahme Navi12 = Navi10 + HBM inzwischen irgendwie zu billig. Da steckt mehr dahinter.

[horn 12]

Navi 21 entspricht 2 x Navi 12
Also Navi 21 12GB HBM und weitere Version mit 24GB HBM

Navi 21 ist gleich 2 x 1

[Berniyh]

oO

[basix]

Warum ist es jetzt speziell bei Navi12 so wichtig nicht extra Energie zu ziehen?

Das zusammen mit der Info, dass die "Peak" Taktfrequenz von Navi12 angeblich 1100 MHz ist lässt eigentlich nur den Schluss zu, dass es sich um einen Navi Chip handelt der auf Effizienz getrimmt wurde.
Zu welchem Zweck auch immer?
In jedem Fall scheint mir die Annahme Navi12 = Navi10 + HBM inzwischen irgendwie zu billig. Da steckt mehr dahinter.

Mobile Chip? Matisse-G à la KabyLake-G?

[BoMbY]

da gab es doch vor kurzem schon einen Vortrag.

https://www.youtube.com/watch?v=xpxVAoXaVgg

Das bezieht sich nur auf die NVidia-Extension soweit ich das sehen kann, nicht auf den offiziellen Support.

[Berniyh]

Mobile Chip? Matisse-G à la KabyLake-G?
Ja, hab ich auch überlegt, aber warum macht man das dann nicht auch bei Navi14 (5300M, 5500M)?

Es scheint halt so zu sein, dass Navi12 ein niedrig taktender (1100 MHz), mittelgroßer bis großer Chip (Interfaces ähnlich breit wie bei Navi10) zu sein der auf Effizienz getrimmt wurde.
Sowas gibt es bei AMD doch eigentlich sonst nicht?

[basix]

Bei einem reinen Mobile Chip bin ich auch eher skeptisch, da es ja noch eine 5700M gibt.

Wenn es "Matisse-G" wird, dann hat der Chip ganz andere Anforderungen. 65W TDP für CPU (3700X alike) und 40W für die GPU, um in den 105W TDP zu bleiben. 1100MHz würden ziemlich gut passen: 180W Chip Power @ 1.8 GHz für die 5700XT --> 1.6x Taktunterschied --> 1.6^3 = 4x --> 180W / 4 = 45W. Noch ein paar weitere Optimierungen und das passt schon.

"Matisse-G" mit Navi-GPU passt aber leider nicht auf AM4, da zu wenig Platz auf dem Träger.

Edit:
Es gibt doch eine Möglichkeit für AM4. Man schiebt den I/O Die nach oben neben das eine Chiplet, dann wird die untere Hälfte des Trägers frei. Hier würde eine GPU von der Klasse eines Navi 10 von der Grösse her knapp hinpassen. Was aber das Killer-Kriterium wäre: Man müsste den HBM auf die GPU 3D stacken. Der starke Fokus auf reduzierte Stromaufnahme könnte zumindest auch ein Indiz dafür sein (Wärmeableitung und so). Ausserdem wäre das ein schöner Pipe Cleaner für "HBM-direct-on-die-Stacking" :D

Edit 2:
Auf ein 200mm2 Die würden ausserdem 2x HBM Stacks passen (8GByte, 2-Hi oder 4-Hi Stacks). Diese mit niedrigen 1-1.2 GT/s laufen lassen (Stromverbrauch) und das ist extrem effizient.

[Der_Korken]

Mal was ganz abstruses: Ist N12 eventuell ein eigener Die, der in einem Mobile-Prozess gefertigt wird? Würde zumindest die niedrigen Taktraten erklären, denn 1100Mhz ist bei N10 schon fast unterhalb des Sweetspots, d.h. man spart keine Spannung mehr ein.

[HOT]

Wird wohl wie V12 ein low-profile-Package sein für Notebooks, insbesondere für Apple.

[Leonidas]

Die bisherigen Navi-Mobile-Lösungen zeichnen sich nicht gerade dadurch aus, die Performance möglichst hochzuhalten und dafür trotzdem mit dem Stromverbrauch stark runterzugehen (wie es nVidia kann).

Insofern könnte ein extra auf Mobile angepasster Chip schon Sinn machen - gerade wenn man vielleicht Apple überzeugen will/muß.

[robbitop]

Der AMD Klassiker. Unnötig schlechte Betriebspunkte. Das ist unabhängig von der uArch.

[Unicous]

Krass, hynix hat eine PM wegen dem fake screen shot veröffentlicht:

https://news.skhynix.com/official-statement-on-the-correction-of-false-news/

[JVC]

Bin auch grad drüber gestolpert...
https://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/52413-geruechte-um-big-navi-mit-24-gb-hbm2e.html
"Update: SK Hynix widerspricht Gerüchten"

M.f.G. JVC

[Linmoum]

Ist auch einfach nur noch absurd, was bei den Medien abgeht.

"das sieht ja eigentlich wenig glaubwürdig aus aber hey machen wir trotzdem newz daraus!!"

[LasterCluster]

Bei einem reinen Mobile Chip bin ich auch eher skeptisch, da es ja noch eine 5700M gibt.

Wenn es "Matisse-G" wird, dann hat der Chip ganz andere Anforderungen. 65W TDP für CPU (3700X alike) und 40W für die GPU, um in den 105W TDP zu bleiben. 1100MHz würden ziemlich gut passen: 180W Chip Power @ 1.8 GHz für die 5700XT --> 1.6x Taktunterschied --> 1.6^3 = 4x --> 180W / 4 = 45W. Noch ein paar weitere Optimierungen und das passt schon.

"Matisse-G" mit Navi-GPU passt aber leider nicht auf AM4, da zu wenig Platz auf dem Träger.

Edit:
Es gibt doch eine Möglichkeit für AM4. Man schiebt den I/O Die nach oben neben das eine Chiplet, dann wird die untere Hälfte des Trägers frei. Hier würde eine GPU von der Klasse eines Navi 10 von der Grösse her knapp hinpassen. Was aber das Killer-Kriterium wäre: Man müsste den HBM auf die GPU 3D stacken. Der starke Fokus auf reduzierte Stromaufnahme könnte zumindest auch ein Indiz dafür sein (Wärmeableitung und so). Ausserdem wäre das ein schöner Pipe Cleaner für "HBM-direct-on-die-Stacking" :D

Edit 2:
Auf ein 200mm2 Die würden ausserdem 2x HBM Stacks passen (8GByte, 2-Hi oder 4-Hi Stacks). Diese mit niedrigen 1-1.2 GT/s laufen lassen (Stromverbrauch) und das ist extrem effizient.

Für AM4 ergibt so ein Chip eh keinen Sinn. Da nimmt man einfach ne dGPU. Potentielle Märkte wären mobile oder semi-custom. Dann wäre ein Renoir-G sinnvoller, da man die GPU dann teilweise komplett abschalten könnte.

[Complicated]

Ist auch einfach nur noch absurd, was bei den Medien abgeht.

"das sieht ja eigentlich wenig glaubwürdig aus aber hey machen wir trotzdem newz daraus!!"

+1

[Berniyh]

Wenn es "Matisse-G" wird, dann hat der Chip ganz andere Anforderungen. 65W TDP für CPU (3700X alike) und 40W für die GPU, um in den 105W TDP zu bleiben. 1100MHz würden ziemlich gut passen: 180W Chip Power @ 1.8 GHz für die 5700XT --> 1.6x Taktunterschied --> 1.6^3 = 4x --> 180W / 4 = 45W. Noch ein paar weitere Optimierungen und das passt schon.

"Matisse-G" mit Navi-GPU passt aber leider nicht auf AM4, da zu wenig Platz auf dem Träger.
Also so ohne Weiteres macht Navi12 als Chiplet auf AM4 keinen Sinn.
Die bisherigen APUs haben 2 SPD Interfaces, entsprechend dem Dual Channel.
16 würden nur mit HBM2 Sinn machen und auch nur für exakt 2 Stacks.

So wirklich mag ich das aber ehrlich gesagt nicht glauben.

[Locuza]

Also so ohne Weiteres macht Navi12 als Chiplet auf AM4 keinen Sinn.
Die bisherigen APUs haben 2 SPD Interfaces, entsprechend dem Dual Channel.
16 würden nur mit HBM2 Sinn machen und auch nur für exakt 2 Stacks.

So wirklich mag ich das aber ehrlich gesagt nicht glauben.
Aus AMDs GPU Firmware:
https://pbs.twimg.com/media/ERUFq2fW4AAgY6e?format=jpg&name=large

Dazu:

For Navi12 dram_channel_width_bytes is 16, i.e., 128 bits per channel, while for Navi10 it's 2, i.e., 16 bits per channel. num_chans is 16 for both, resulting in a total dram width of 2048 bits for Navi12 (and 256 bits for Navi10). This is another hint towards HBM.

Quelle:
https://www.reddit.com/r/Amd/comments/ef0zjq/navi12_arcturus_renoir_gpu_firmware_info_shader/

Ebenso wie Vega20 und Navi14 unterstützt Navi12 mehrere dot-instructions:
https://pbs.twimg.com/media/EQsiOD0XkAAJUqN?format=jpg&name=medium
https://llvm.org/docs/AMDGPU/AMDGPUAsmGFX1011.html

Wurde an anderer Stelle auch als Navi_DL (DeepLearning) bezeichnet.

[Berniyh]

Ebenso wie Vega20 und Navi14 unterstützt Navi12 mehrere dot-instructions
Irgendwas hab ich gestern auch gesehen was dazu passen könnte, hab das aber als unwichtig abgetan, weil es mir irgendwie unlogisch erschien (bzgl. der Einordnung von Navi14 vs. Navi10).

Aber generell erscheint mir die Einordnung von Navi12 als Spezialvariante von Navi1x für Datacenter-Anwendungen angesichts der Eckdaten logischer als die Annahme es handle sich um eine HBM2-Variante für Apple.

Von einem derartig benannten Produkt hat man aber – im Gegensatz zu Arcturus aka MI100 – aber nach wie vor überhaupt nichts gehört obwohl der Code dazu schon sehr lange im Linux Kernel ist (im Gegensatz zu dem zu Arcturus).

[basix]

Und wenn Navi 14 kein Produkt ist sondern nur irgendein Testvehikel? Vielleicht um ein GPU-Chiplet Ansatz auszuprobieren? Da wären niedrige Taktraten zumindest logisch, da nicht maximale Frequenz gefordert ist, sondern stabiler Betrieb mit minimalem Kühlaufwand. Dabei würde man sich zudem viel auf Systemtests und SW-Entwicklung fokussieren, was ebenfalls keine hohen Taktraten erfordert.

[Brillus]

Wie sieht es eigentlich mit Google Stadia aus soll das nicht was SemiCustom sein und da würde auch Linux Treiber passen.

[Berniyh]

Laut Komachi gibt es jetzt auch noch den Codenamen "draco".
Da draco ein Stern(system) ist handelt es sich wahrscheinlich um eine GPU.
Also entweder Nachfolger von Navi oder Arcturus. Vermutlich aber eher letzteres, ich hätte jetzt erwartet, dass noch Navi3x kommt, da man hier ja gerade einen (doch eher positiv gesehenen) Codenamen aufgebaut hat.

Für mich amüsant, denn mein Spiele-PC heißt schon seit 10 Jahren draco. ^^

[HOT]

Draco dürfte RDNA3 ab irgendwann 22 sein. Die sicherlich 21 erscheinende N1x-Ablöse dürfte mMn weiterhin RDNA2 sein.

Locuza
Dann ist klar, dass N12 eine N10-Variante für Mobil/Profi ist, aber dennoch ein neuer Chip.

[Berniyh]

Draco dürfte RDNA3 ab irgendwann 22 sein. Die sicherlich 21 erscheinende N1x-Ablöse dürfte mMn weiterhin RDNA2 sein.
Will ich nicht ausschließen, aber warum sollte man RDNA3 nicht mehr Navi nennen, wenn man den Namen für RDNA2 beibehalten hat?

[Complicated]

Warum sollte man Codenamen nach Marketingkriterien auswählen?
Welcher Kunde weiss denn was Navi ist, nimmt man alle Forenbesucher hier mal aus? Im Mediamarkt werden dir selbst die meisten Verkäufer das nicht erklären können.

Dass ein Refresh die 2x Nomenklatur erhält bei einer Verbesserung des Chips ist ja eines, warum eine ganze neue Generation den Namen weiter tragen sollte ist eher hinderlich für den internen Gebrauch und ermöglicht nur mehr Fehler durch zu viele ähnliche Namen.

Die ISA signalisiert durch Iterationen Kontinuität und Kompatibilität - das sollte doch ausreichen. GCN1...5 und RDNA1/2
Bei Chips kommt dann eher so etwas wie Intels 14nm+++++ bei raus.

[robbitop]

Wobei die ISA ja eigentlich bis heute noch ziemlich GCN geblieben ist. Die Implementierung der uArch ist hauptsächlich stark verändert. Der Name GCN schien aber zu stark verbrannt gewesen zu sein.

[Complicated]

AMD RDNA 1.0 Instruction Set Architecture (https://gpuopen.com/compute-product/amd-rdna-1-0-instruction-set-architecture/)
Alleine dies ist eine gravierende Ändeurng unter vielen anderen:
Previously the shader hardware was grouped into "compute units" ("CUs") which containedALU, LDS and memory access. Now the "workgroup processor" ("WGP") replaces thecompute unit as the basic unit of computing. This allows significantly more compute powerand memory bandwidth to be directed at a single workgroup.
Wieso soll GCN verbrannt sein? APU (Renoir) und Datacenter Vega (MI50/60) sind erfolgreiche Implementierungen die derzeit stark nachgefragt werden.

[Berniyh]

Warum sollte man Codenamen nach Marketingkriterien auswählen?
Welcher Kunde weiss denn was Navi ist, nimmt man alle Forenbesucher hier mal aus? Im Mediamarkt werden dir selbst die meisten Verkäufer das nicht erklären können.
Das stimmt natürlich, aber dennoch wird der Codename von AMD selbst auch z.B. in Vorträgen häufig genutzt.
Letztendlich ist aber natürlich Radeon der eigentliche Marketingname, das ist völlig richtig.
(Ob der dann wichtig ist sei mal dahin gestellt.)
Dass ein Refresh die 2x Nomenklatur erhält bei einer Verbesserung des Chips ist ja eines, warum eine ganze neue Generation den Namen weiter tragen sollte ist eher hinderlich für den internen Gebrauch und ermöglicht nur mehr Fehler durch zu viele ähnliche Namen.
Klar, es gibt Argumente dafür und dagegen.
Letztendlich kann ich dir auch nicht sagen ob Draco wirklich als Codename existiert und ob es sich auf die HPC- oder die Gaming-Linie bezieht.
Ich hatte nur angemerkt, dass AMD offensichtlich für RDNA2 den gleichen Codenamen nutzt wie für RDNA1. Wenn es also RDNA3 gibt (wovon ich jetzt ausgehen würde), dann liegt es eben nahe, dass man das dann als Navi3x bezeichnet.
Kann aber natürlich auch sein, dass man für RDNA3 einen neuen Codename wählt, das will ich überhaupt nicht bestreiten.
Gründe für und wider finden sich auf jeden Fall.

[robbitop]

AMD RDNA 1.0 Instruction Set Architecture (https://gpuopen.com/compute-product/amd-rdna-1-0-instruction-set-architecture/)
Alleine dies ist eine gravierende Ändeurng unter vielen anderen:

Wieso soll GCN verbrannt sein? APU (Renoir) und Datacenter Vega (MI50/60) sind erfolgreiche Implementierungen die derzeit stark nachgefragt werden.
Architektur =/ Instructionset.

Ja es gab auch ganz gute Umsetzungen. Aber die meisten waren einfach (insbesondere in der Öffentlichen Wahrnehmung) den Produkten von NV zu sehr unterlegen.
Polaris war IMO eine Ausnahme.

[Complicated]

Ich hatte nur angemerkt, dass AMD offensichtlich für RDNA2 den gleichen Codenamen nutzt wie für RDNA1. Wenn es also RDNA3 gibt (wovon ich jetzt ausgehen würde), dann liegt es eben nahe, dass man das dann als Navi3x bezeichnet.

Der Vergleich hinkt doch.
RDNA ist das Äquivalent zu GCN.
Navi ist das Äquivalent zu Polaris oder Vega.
Edit: Wobei es ja tatsächlich ein Polaris 30 gab für die RX 590. Allerdings wird das beim Transit von RDNA ->RDNA2 wohl eher ein neuer Codename, IMHO.

Architektur =/ Instructionset.

Ähm, Wie bitte?
https://de.wikipedia.org/wiki/Befehlssatzarchitektur
Eine Befehlssatzarchitektur (englisch (https://de.wikipedia.org/wiki/Englische_Sprache) Instruction Set Architecture, kurz: ISA) ist die abstrakte Beschreibung der Verhaltensweise eines Rechners (https://de.wikipedia.org/wiki/Computer) in Bezug auf seinen Befehlssatz (https://de.wikipedia.org/wiki/Befehlssatz). Dabei wird die Befehlssatzarchitektur so formuliert, dass sie unabhängig von einer bestimmten Implementierung ist. Die ISA ist zudem Teil von Prozessorarchitekturen wie z. B. x86 (https://de.wikipedia.org/wiki/X86-Prozessor), ARM (https://de.wikipedia.org/wiki/ARM-Architektur) oder PowerPC (https://de.wikipedia.org/wiki/PowerPC) und trägt in der Regel deren Namen (z. B. x86-Befehlssatz).
Was ist denn die ISA sonst deiner Meinung nach?

[Locuza]

Die Konsolen haben zuerst damit geworben, auf Navi zu basieren und zumindest bei der Xbox Series X ist es nun offiziell RDNA"2".
Wird AMD am PC den Ausdruck Navi auch für RDNA2 verwenden oder was Neues?
Das Marketing kann allerdings mit Bezeichnungen um sich werfen, wie es lustig ist.

Bei GCN ist es teils verwirrend, da AMD die ISA und Implementierung davon so benannt hat.
Bei RDNA ist aber hauptsächlich nur die Implementierung bzw. Mikroarchitektur eine andere.
Man könnte das so sehen:

ISA: GCN, Mirkoarchitektur: GCN2, GCN4(Polaris), RDNA1 (Navi)

Die GCN ISA definiert hauptsächlich die Maschinensprache, nicht wie eine Compute-Unit aufgebaut wird.

[Complicated]

Nur hat AMD Dokumente sowohl unter dem Namen GCN-ISA als auch GCN3-ISA veröffentlicht.
z.B.: https://gpuopen.com/compute-product/amd-gcn3-isa-architecture-manual/
Ich würde das ungefähr so wie den Unterschied zwischen x86-ISA und x86-64-ISA sehen.
Als Erweiterung/Iteration der ISA.

Eben habe ich sogar zufällig eine Vega-ISA gefunden. Dort sind die Unterschied sogar explizit benannt zu der vorherigen ISA:
http://developer.amd.com/wordpress/media/2017/08/Vega_Shader_ISA_28July2017.pdf
Wird allerdings im Dokument "The figure below shows a block diagram of the AMD GCN Vega Generation series processors" benannt. Was allgemein überall als GCN5 kursiert. (https://de.wikipedia.org/wiki/AMD-Radeon-Vega-Serie)
Die GCN ISA definiert die Maschinensprache, nicht wie eine Compute-Unit aufgebaut wird.
Und definiert in diesen Dokumenten genau das.

[Berniyh]

Allerdings wird das beim Transit von RDNA ->RDNA2 wohl eher ein neuer Codename, IMHO.
Nein, RDNA2 wird auch als Navi (genauer Navi21/22/23) bezeichent, das ist praktisch gesichert, da es schon in diversen Treibern entsprechende Erwähnungen gab.
(außer AMD macht hier in letzter Sekunde noch eine Kehrtwendung)

Selbst Lisa Su hat von "Big Navi" gesprochen und das wird RDNA2 sein, da es außer Navi12 ziemlich sicher keine weiteren Navi1x Chips mehr geben wird und Navi12 wird es nach den bisherigen Erkenntnissen nicht sein.

[Locuza]

Nur hat AMD Dokumente sowohl unter dem Namen GCN-ISA als auch GCN3-ISA veröffentlicht.
z.B.: https://gpuopen.com/compute-product/amd-gcn3-isa-architecture-manual/
Ich würde das ungefähr so wie den Unterschied zwischen x86-ISA und x86-64-ISA sehen.
Als Erweiterung/Iteration der ISA.

Eben habe ich sogar zufällig eine Vega-ISA gefunden. Dort sind die Unterschied sogar explizit benannt zu der vorherigen ISA:
http://developer.amd.com/wordpress/media/2017/08/Vega_Shader_ISA_28July2017.pdf
Wird allerdings im Dokument "The figure below shows a block diagram of the AMD GCN Vega Generation series processors" benannt. Was allgemein überall als GCN5 kursiert. (https://de.wikipedia.org/wiki/AMD-Radeon-Vega-Serie)

Und definiert in diesen Dokumenten genau das.
Die Dokumente trennen das nicht direkt auf.
Es werden sowohl Eigenschaften der Mikroarchitektur beschrieben, als auch die zugrundeliegende Maschinensprache.
Würde man ein Dokument in ähnlicher Art und Weise für CPUs schreiben, dann würde es z.B. "Zen2 ISA document" heißen, wo sowohl Kernaspekte der Mikroarchitektur dokumentiert sind, als auch die verwendete x86_64-Maschinesprache.
Die meisten Aspekte einer Mikroarchitektur definiert die ISA aber nicht, wie eine CU/WGP aufgebaut ist, wie groß die Caches, Register oder Scratchpad-Memories sind etc.

Das sieht man intern laut einem AMD-Mitarbeiter so:
[...] we think about GCN as an ISA, but it seems that most people outside AMD think of GCN as a micro-architecture instead (ie an implementation of the ISA). RDNA is GCN-ish ISA but not what you think of as GCN micro-architecture.
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1103202-amd-is-aiming-for-radeon-rx-5700-navi-support-in-linux-5-3-mesa-19-2?p=1103266#post1103266

[horn 12]

Big Navi Launch doch im März
Mit geriner Verfügbarkeit und ab Ende Anfang April bessere Verfügbarkeit.

[y33H@]

Aha ... Quelle?

[Linmoum]

Du weißt schon, wen du da fragst, oder? ;)

Er lässt mal wieder seine feuchten Träume spielen. Auch, wenn ich nie kapiere, wie man zu solch absurden kommt.

[crux2005]

Aha ... Quelle?

Horn 12

[horn 12]

Quelle
Insider bei Fdx, AMD Software Tester.

User welcher schon bei Navi 10 Recht hatte...

[Berniyh]

Wenn Big Navi im März gelauncht würde hätten wir schon wesentlich mehr Informationen dazu.
Zumal AMD dann auch schon längst ordentlich die Werbetrommel bemühen würde.
Nur mal zum Vergleich: bei der vermutlich sehr spontan aufgelegten 5600 XT wusste man trotzdem grob 2 Monate vorher, dass da bald was kommt, bei der 5500 sogar schon etwa 3 Monate vorher (wobei sich da der Release ja bekanntlich hinaus gezögert hat).
Und die Karten ziehen mit Sicherheit deutlich weniger Aufmerksamkeit und Neugierde auf sich als ein potentieller Big Navi Release.

Insofern ist das doch arg unwahrscheinlich.

[robbitop]

Ähm, Wie bitte?
https://de.wikipedia.org/wiki/Befehlssatzarchitektur

Was ist denn die ISA sonst deiner Meinung nach?
Als Beispiel: x86 ist eine ISA. Und die Implementierung der uArch zB Ryzen oder Core. So wie Locuza es sagt. Das sind absolute Basics.

[Complicated]

Das sieht man intern laut einem AMD-Mitarbeiter so:

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1103202-amd-is-aiming-for-radeon-rx-5700-navi-support-in-linux-5-3-mesa-19-2?p=1103266#post1103266Der das selbe schreibt wie ich. Ich sehe es so wie der Mitarbeiter. GCN ist ISA und nicht Mikroarchitektur, wie du schreibst. Du zitierst ja den Satz.

Sag mal robbitop, ich schrieb x86 ist eine ISA und GCN ebenfalls. Welches Argument konntest du hier bisher anbieten um zu belegen GCN sei keine ISA? Es ist genauso ein Instructionset wie x86. Und das Dokument von AMD, das es als ISA beschreibt habe ich ebenfalls verlinkt. Aus der Originalquelle. Der Wikipedia-Eintrag definiert ISA genauso wie AMD und ich ebenfalls.

Locuza zitiert brigdman der das selbe sagt.

[robbitop]

Ich schrieb mehrfach GCN ist eine ISA. RDNA setzt prinzipiell weiter auf diese und ist keine neue ISA sondern nur eine neue uArch.

[horn 12]

@Update:


Karten (100 bis 150) in Europa eingetroffen …
Launch innerhalb 2 bis 3 Wochen

RTX 2080TI wird übertroffen, oft nur gering,- teilweise im 20 bis 25% Mehrbereich.
RDNA 2 ist nicht komplett schnell,- dies braucht alles seine Zeit.

Launch soll aus dem "Nichts" kommen, wie damals die Radeon VII zur CES und am 07.02.2019 Launchtag.
So "wirklich gut" wird RDNA 2 wohl wirklich nicht und dies weiss wohl AMD selbst …
NV wird da mt der RTX 3080 schon besser dastehen können....

Preislich 799 Dollar/ 729 Euro wird wohl in etwa angestrebt.

[erlgrey]

Wann kommt der horntreiber für rdna2?

[horn 12]

1-ter April

[Unicous]

Warum gibt es eigentlich keine Sanktionen wenn horn diese Falschmeldungen verbreitet?
Er kann hier schalten und walten, man kann den Quatsch melden und es tut sich rein gar nichts.:mad:

Das geht jetzt seit Jahren so. Er spammt die Threads mit Blödsinn voll und das wird einfach so toleriert.

[horn 12]

Abwarten!
Aber bin Raus hier...

[BiZiNiZz]

Selbst wenn an diesem "Horn" Gerücht was dran sein sollte, was will man mit 100-150 Karten für ganz Europa? Das ist noch nicht einmal der berühmte Mückenschiss.... das ist nichts. Wenn höchstens für die Hardware Tester und wann wäre dann der Hardlaunch? in 2 Monaten wenn genug da sind?

[Kehaar]

Warum gibt es eigentlich keine Sanktionen wenn horn diese Falschmeldungen verbreitet?
Er kann hier schalten und walten, man kann den Quatsch melden und es tut sich rein gar nichts.:mad:

Das geht jetzt seit Jahren so. Er spammt die Threads mit Blödsinn voll und das wird einfach so toleriert.
Dir fehlt etwas Toleranz. Wir sind hier im Speku-Bereich. Ich finde, da kann er seine (wilden) Gedanken auch mal äußern. Andere "richtige" Fachleute liegen hier mit ihren Vorhersagen auch nicht immer besser. Du kannst also seine Beiträge "überspringen", ihn auf Ignorieren stellen oder ihn als Humorelement akzeptieren. Für mich ist er jedenfalls ein interessantes, die Stimmung auflockerndes Element.

[Unicous]

Gibt einen neuen Windows-Treiber, der unter anderem Strings für Navi21 Lite enthält.


AMD 27.XX.XXXX.XXXX.
VAN GOGH = GFX1033.
(GFX1032 → GFX1033).
NAVI 21LITE = GFX1020.
NAVI 22 = GFX1031.
https://twitter.com/KOMACHI_ENSAKA/status/1233128311007535104

Außerdem Van Gogh Lite

VANGOGHLITE = GFX1040.
https://twitter.com/KOMACHI_ENSAKA/status/1233129072227520512

[gravitationsfeld]

GCN ist definitiv keine ISA im Sinne von x86, sonst haette sich das Instruction-Encoding zwischen Tahiti und Navi nicht rund fuenf mal geaendert.

Der Assembly-Code sieht aehnlich aus zwischen den verschiedenen Chips aber das war's auch schon. Man kann nicht mal Tahiti-Code auf Polaris laufen lassen. Voellig anderes und inkompatibles Encoding. Selbst Instructions werden zwischen den Chips entfernt oder gaendert.

[Locuza]

Der das selbe schreibt wie ich. Ich sehe es so wie der Mitarbeiter. GCN ist ISA und nicht Mikroarchitektur, wie du schreibst. Du zitierst ja den Satz.

Sag mal robbitop, ich schrieb x86 ist eine ISA und GCN ebenfalls. Welches Argument konntest du hier bisher anbieten um zu belegen GCN sei keine ISA? Es ist genauso ein Instructionset wie x86. Und das Dokument von AMD, das es als ISA beschreibt habe ich ebenfalls verlinkt. Aus der Originalquelle. Der Wikipedia-Eintrag definiert ISA genauso wie AMD und ich ebenfalls.

Locuza zitiert brigdman der das selbe sagt.
Ich fasse man den Kontext zusammen, den ich bisher gesehen habe bzw. wie ich ihn interpretiert habe:

------
[...]
Die ISA signalisiert durch Iterationen Kontinuität und Kompatibilität - das sollte doch ausreichen. GCN1...5 und RDNA1/2
Bei Chips kommt dann eher so etwas wie Intels 14nm+++++ bei raus.
Wobei die ISA ja eigentlich bis heute noch ziemlich GCN geblieben ist. Die Implementierung der uArch ist hauptsächlich stark verändert. Der Name GCN schien aber zu stark verbrannt gewesen zu sein.
AMD RDNA 1.0 Instruction Set Architecture (https://gpuopen.com/compute-product/amd-rdna-1-0-instruction-set-architecture/)
Alleine dies ist eine gravierende Ändeurng unter vielen anderen:
"Previously the shader hardware was grouped into "compute units" ("CUs") which containedALU, LDS and memory access. Now the "workgroup processor" ("WGP") replaces thecompute unit as the basic unit of computing. This allows significantly more compute powerand memory bandwidth to be directed at a single workgroup. "
[...]
Architektur =/ Instructionset.
[...]
------------

Der zitierte Absatz vom RDNA-ISA document hat im Prinzip nur Änderungen an der Mikroarchitektur beschrieben und das Ganze hat den Eindruck erweckt, als ob das Änderungen an der ISA wären bzw. bedingt durch die ISA.
Offensichtlich hat es auch so robbitop aufgefasst, daher der Einwand Architektur =/ ISA.
Darauf folgte noch deine Antwort, dass die ISA ja eine Befehlsarchitektur sei.
Was ja auch richtig ist, nur befinden sich die Dinge die gemeint sind, auf zwei unterschiedlichen Ebenen, die im Detail nicht 100% losgelöst sind, aber meistens getrennt aufgefasst werden.
Die Befehlssatzarchitektur (ISA) ist die eine Ebene, die Mikroarchitektur eine Ebene darüber, welche die ISA implementiert.
RDNA verwendet hauptsächlich die GCN-ISA und keine neue oder stark unterschiedliche RDNA-ISA.
Das ist zumindest das, was scheinbar robbitop und auch ich zum Ausdruck bringen wollten.

Gibt einen neuen Windows-Treiber, der unter anderem Strings für Navi21 Lite enthält.


https://twitter.com/KOMACHI_ENSAKA/status/1233128311007535104

Außerdem Van Gogh Lite


https://twitter.com/KOMACHI_ENSAKA/status/1233129072227520512
Das Lustige bisher ist, dass man immer noch nicht weiß, was das "Lite"-Label bedeuten soll.
Bei Vega-GPUs mit HBCC hat es getrennte GFX-IDs je nachdem, ob es an oder aus ist (GFX900 oder GFX901 für Vega10), aber bei dem Lite-Zeug ist es extrem.
Van Gogh = 1033
Van Gogh Lite = 1041

Navi21 = 1030
Navi21 Lite = 1020

Navi12= 1011
Navi12 Lite = 1011

Eine Logik kann ich dahinter noch nicht erkennen.

GCN ist definitiv keine ISA im Sinne von x86, sonst haette sich das Instruction-Encoding zwischen Tahiti und Navi nicht rund fuenf mal geaendert.

Der Assembly-Code sieht aehnlich aus zwischen den verschiedenen Chips aber das war's auch schon. Man kann nicht mal Tahiti-Code auf Polaris laufen lassen. Voellig anderes und inkompatibles Encoding. Selbst Instructions werden zwischen den Chips entfernt oder gaendert.
Wirklich "fünf mal"?
GCN1-2 sind irrc gleich und danach GCN3-5.

[Unicous]

Ja, das macht mich auch verrückt. Ich glaube eine Theorie war, dass Navi10 Lite eine Konsolen-GPU ist, man ging von der PS5 aus(36 CUs). Aber das macht nicht so wirklich Sinn, da ja RDNA2 so gut wie bestätigt ist für beide Konsolen.

Van Gogh wird ja auch als semi-custom gehandelt, aber das war es auch schon.

Jedenfalls wird man nicht schlauer, je mehr Codenamen auftauchen, zumal ja sicherlich auch Projekte darunter sind, die gecancelt wurden. Dazu kommen noch zig Codenamen für die Konsolen-Projekte, die SoCs, die Plattformen...:uexplode:

Komachi meint auch, dass Navi 10 den Codenamen Fighter trägt und Arcturus wohl auch Phantom heißt.:freak:

Moonshot war wohl Vega20 und Greenland Vega10.

[Locuza]

Immerhin hat man etwas zum grübeln.

Lite impliziert etwas Abgespecktes und die gleiche Kennnummer nachdem Namen verleitet zur Annahme, dass z.B. Navi10 und Navi10 Lite sehr ähnlich ausfallen.
Allerdings gibt es mehrere Lite-Einträge und wenn die Chips so ähnlich wären, würden sich das wohl kaum rentieren und dann eben die Frage, was soll Lite abspecken oder konkret darstellen, sodass man zig Projekte am laufen hätte?
Die GFX-IDs machen es auch kompliziert, einmal ist sie gleich und mehrmals stark unterschiedlich, was im Gegenzug darauf hinweisen könnte, dass die Dinger intern doch mehrere Unterschiede haben.

Unter Umständen ist das aber auch nur absichtliches Wirrwarr und die Einträge werden als Decknamen verwendet für unterschiedliche Projekte.

-----

Greenland habe ich in Erinnerung als Teil von Arctic Islands, als Next-Gen-Line Up, zusammen mit Baffin und Ellesmere.
https://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/News/Arctic-Islands-Greenland-14-nm-LPP-Globalfoundries-Samsung-1181708/

Baffin und Ellesmere wurden später in Polaris11 und Polaris10 umbenannt.

Greenland wurde auch früh als Codename geleaked, zusammen mit Zeppelin (Zen):
https://www.hardwareluxx.de/images/stories/newsbilder/mhaber/2015/amd_gpu_greenland.jpg

Ursprünglich geplant war Half-Rate FP64-Leistung und ECC-Protection.
https://www.fudzilla.com/media/k2/items/cache/84cbc506429ede06026d76e6de6651b2_XL.jpg

Die Pläne, zusammen mit dem HPC-APU-Projekt, hat man (vorerst) begraben.
Ich dachte lange Zeit das Vega10 nur eine Umbenennung wie bei Baffin/Ellesmere darstellt und mehr oder weniger ist es das auch, aber man hat Half-Rate FP64 und ECC gestrichen und stattdessen ein weiteres Projekt mit Vega20 für die entsprechenden Märkte gestartet.

IIRC hat Komachi auch irgendwo eine Liste für GPU-Codenamen, wo einige bei gestrichenen Projekten wieder für andere verwendet worden sind.

Auf einer ganz alten Roadmap hatte AMD Oland als Sea Islands Ableger (GCN2) geführt, ein wenig über Cape Verde.
Am Ende war Oland ein weiterer Southern Islands Chip (GCN1) deutlich unterhalb von Cape Verde (384 Shader vs. 640).
https://www.semiaccurate.com/wp-content/uploads/2013/05/AMD_roadmap_tiran.jpg

Auch interessant da einen Überblick zu bewahren und alle unterschiedlichen Codenamen zu kennen und was wirklich mal hinter Projekt X stand und wie und warum es sich verändert hat.

[Unicous]

Ja, Greenland wurde, wie viele andere Codenamen über die Jahre, recycled. Macht es natürlich nochmals schwieriger nachzuvollziehen, was AMD vorhat. Aber wie du schon sagst, immerhin hat man etwas zum Grübeln, bei Nvidia ist ja vollkommen tote Hose.:frown:

Irgendein Codename aus der Bulldozer-Zeit der wiederverwendet wurde ist letztens auch noch mal aufgetaucht, ich glaube da ging es um eine APU/CPU.

[HOT]

Ich fasse man den Kontext zusammen, den ich bisher gesehen habe bzw. wie ich ihn interpretiert habe:

------




------------

Der zitierte Absatz vom RDNA-ISA document hat im Prinzip nur Änderungen an der Mikroarchitektur beschrieben und das Ganze hat den Eindruck erweckt, als ob das Änderungen an der ISA wären bzw. bedingt durch die ISA.
Offensichtlich hat es auch so robbitop aufgefasst, daher der Einwand Architektur =/ ISA.
Darauf folgte noch deine Antwort, dass die ISA ja eine Befehlsarchitektur sei.
Was ja auch richtig ist, nur befinden sich die Dinge die gemeint sind, auf zwei unterschiedlichen Ebenen, die im Detail nicht 100% losgelöst sind, aber meistens getrennt aufgefasst werden.
Die Befehlssatzarchitektur (ISA) ist die eine Ebene, die Mikroarchitektur eine Ebene darüber, welche die ISA implementiert.
RDNA verwendet hauptsächlich die GCN-ISA und keine neue oder stark unterschiedliche RDNA-ISA.
Das ist zumindest das, was scheinbar robbitop und auch ich zum Ausdruck bringen wollten.


Das Lustige bisher ist, dass man immer noch nicht weiß, was das "Lite"-Label bedeuten soll.
Bei Vega-GPUs mit HBCC hat es getrennte GFX-IDs je nachdem, ob es an oder aus ist (GFX900 oder GFX901 für Vega10), aber bei dem Lite-Zeug ist es extrem.
Van Gogh = 1033
Van Gogh Lite = 1041

Navi21 = 1030
Navi21 Lite = 1020

Navi12= 1011
Navi12 Lite = 1011

Eine Logik kann ich dahinter noch nicht erkennen.


Wirklich "fünf mal"?
GCN1-2 sind irrc gleich und danach GCN3-5.

Hm... Verschiedene Chiplets?!

[gravitationsfeld]

Wirklich "fünf mal"?
GCN1-2 sind irrc gleich und danach GCN3-5.
Gab zwischen allen Revisionen zumindest kleinere Aenderungen.

Aber ja, auch sonst: Southern Islands, Sea Islands, Volcanic Islands, GFX9 (Vega), GFX10 (Navi). Okay, es wurde vier Mal geaendert, wenn man die erste Revision nicht mit zaehlt.

[Complicated]

Ich schrieb mehrfach GCN ist eine ISA. RDNA setzt prinzipiell weiter auf diese und ist keine neue ISA sondern nur eine neue uArch.
Deswegen veröffentlicht AMD ein Dokument mit dem Titel "RDNA Insctruction Set Architecture". Können wir bei den Angaben von AMD bleiben und die eigenen Meinungen an die Realität anpassen? Die Diskussion dreht sich im Kreis, da du keinerlei Argument hast für diese Sichtweise.

Was ja auch richtig ist, nur befinden sich die Dinge die gemeint sind, auf zwei unterschiedlichen Ebenen, die im Detail nicht 100% losgelöst sind, aber meistens getrennt aufgefasst werden.
Die Befehlssatzarchitektur (ISA) ist die eine Ebene, die Mikroarchitektur eine Ebene darüber, welche die ISA implementiert.
RDNA verwendet hauptsächlich die GCN-ISA und keine neue oder stark unterschiedliche RDNA-ISA.
Das ist zumindest das, was scheinbar robbitop und auch ich zum Ausdruck bringen wollten.

Nun jemand muss ja definieren wie es genannt wird. IMHO ist das AMD und daran kann man sich orientieren. Eine bessere Alternatvie sehe ich hier nicht. Und ich sagte ja bereit es sind Iterationen und Erweiterungen.

Ist etwas sowohl ISA als auch Microarchitektur, dann sehe ich keinen Grund zu sagen es sei keine ISA weil es beides ist. Das "Entweder, Oder" muss man ja nicht auf die Spitze treiben. Schon gar nicht in dem Abstraktionlevel auf dem wir hier im Forum damit umgehen wollen.

Eine RDAN ISA wurde definiert - wollen wir diese nun ignorieren, weil sie der GCN-ISA zu 90% ähnelt? Wie viel Ähnlichkeit hat x64 mit x86? Es wird dennoch alles mit x86 bezeichnet.

[gravitationsfeld]

AMD64 ist vollstaendig Abwaertskompatibel und eine Erweiterung von x86. GCN-Generationen haben nicht die selbe ISA. Es ist inkompatibel.

[Berniyh]

Gibt einen neuen Windows-Treiber, der unter anderem Strings für Navi21 Lite enthält.
Spannend.
Wenn man danach gehen würde wäre Navi21 Lite ein neu aufgelegter RDNA1 Chip (Navi10 reloaded?)?
Außerdem Van Gogh Lite
Und das dann RDNA3?!?
Da soll einer durchblicken. ^^
iirc ist das übrigens die erste Erwähnung von gfx104x, d.h. RDNA3.

Edit: ich sehe gerade, dass es ja gfx102x heißt. RDNA1 ist aber gfx101x.
RDNA2 belegt also evtl. gfx102x und gfx103x. Müsste ich noch mal nachprüfen.
Evtl. gehört dann gfx104x auch zu RDNA2?
Ziemliches Chaos jedenfalls.

Edit2: am Logischsten erscheint mir ehrlich gesagt:
gfx101x: RDNA1
gfx102x: RDNA1 Refresh (LITE?)
gfx103x: RDNA2
gfx104x: RDNA2 Refresh (LITE?)

Warum man für einen Refresh eine neue Eingruppierung benötigen würde ist mir aber aktuell noch nicht klar.

IDas Lustige bisher ist, dass man immer noch nicht weiß, was das "Lite"-Label bedeuten soll.
Das ist wohl wahr.
Dachte ursprünglich, dass es sich um mobile Varianten handelt, aber die Navi1x Chips untermauern das nicht unbedingt. Wobei es bei Navi1x glaube ich auch keine Lite Labels gab?
Könnte aber auch sein, dass man bei Navi1x keine derartigen Änderungen zwischen den Desktop- und Mobile-Chips hat, als dass man Code-Branches (und damit ein dediziertes Label) brauchte.
Absurd fand ich ja damals, dass in pal von Navi2x teils nur non-lite, teils nur lite Labels auftauchten. Da war auch überhaupt keine Logik drin.
Andererseits ist der Code inzwischen auch wieder verschwunden, war wohl nur ein Versehen bzw. unvollständig.

[HOT]

Navi ist kein RDNA3. Und 1020 ist kein RDNA1. N12 ist der N10-Refresh mit HBM und sicherlich die letzte RDNA1-Auskopplung, das sollte mittlerweile klar sein. Noch ein Refresh kommt auch nicht.

[Berniyh]

Navi ist kein RDNA3. Und 1020 ist kein RDNA1. N12 ist der N10-Refresh mit HBM und sicherlich die letzte RDNA1-Auskopplung, das sollte mittlerweile klar sein. Noch ein Refresh kommt auch nicht.
Nur weil du Dinge mit Bestimmtheit beständig wiederholst werden sie noch lange nicht zu Fakten … :rolleyes:

[HOT]

Ich wiederhol das, weil das vollkommen unlogisch ist.
N1x ist RDNA1 und N2x ist RDNA2, punkt aus ende. Das ist mittlerweile bekannt, weil alle RDNA1-Auskopplungen bekannt sind und N21 offensichtlich der erste RDNA2-Chip ist. Was darüber hinaus geht ist schwer zu sagen.
Die Befehlssätze entsprechen den jeweiligen Chips. Guck dir das mal für Vega an.

[Berniyh]

Ich wiederhol das, weil das vollkommen unlogisch ist.
N1x ist RDNA1 und N2x ist RDNA2, punkt aus ende. Das ist mittlerweile bekannt, weil alle RDNA1-Auskopplungen bekannt sind und N21 offensichtlich der erste RDNA2-Chip ist.
Dass Navi21 der erste RDNA2 Chip ist auch nicht gesichert. Leo gibt das gerne so an, aber letztendlich wissen wir nur, dass es eben (mind.) 3 dedizierte Chips gibt, nämlich Navi21, 22 und 23.
Weder Navi21=Big Navi ist gesichert noch, dass Navi21 vor Navi23 released wird.

Ich will das was ich oben schrieb auch klar als Spekulation verstanden wissen. Muss nicht so kommen und kannst du selbstverständlich als unlogisch ansehen.
Ich habe mich lediglich darüber gewundert, weshalb AMD für Navi1x nur gfx101x verwendet, für RDNA2 aber potentiell bis zu 3 Bezeichnungen (gfx102x bis gfx104x).
Ich erinnere mich daran, dass ich mich auch früher schon mal über die Zuordnung gfx103x = RDNA2 im Code gewundert hatte, aber damals ist mir nicht aufgefallen, dass gfx102x auch als Navi2x geführt wird (bzw. war evtl. auch nicht ersichtlich, da bin ich mir nicht mehr sicher).
Was darüber hinaus geht ist schwer zu sagen.
Ja, warum behauptest du dann Dinge die wir nicht wissen?
Aktuell wissen wir zu RDNA3 nichts, noch nicht mal gesichert, dass es das wirklich gibt.
evtl. kommt nach RDNA2 ja auch LMAA1? :freak:

Alle Roadmaps die ich bislang gesehen habe, jeglicher Code und jegliche Gerüchte hören aktuell bei RDNA2 auf.

[danarcho]

Gab zwischen allen Revisionen zumindest kleinere Aenderungen.

Aber ja, auch sonst: Southern Islands, Sea Islands, Volcanic Islands, GFX9 (Vega), GFX10 (Navi). Okay, es wurde vier Mal geaendert, wenn man die erste Revision nicht mit zaehlt.
Das Witzige ist doch, dass die RDNA ISA wieder näher and SI ist als an Vega, was das Encoding angeht :)
Man könnte also sagen, die ISA dreht sich genauso im Kreis wie die Diskussion hier :P

[Locuza]

Hm... Verschiedene Chiplets?!
Ich denke nicht das AMD z.B. Multi-GPU Chiplets bauen würde, zumindest nicht mit RDNA1 und RDNA2.
Ebenso denke ich nicht an eine 3-Chip-Lösung, wie I/O-die, GPU-die und CPU-die miteinander auf einem Package.
Eine weitere Möglichkeit wäre GPU und IO auf einem die zu haben und CPU-Chiplets auf einem anderem, was ich vorerst aber auch nicht wahrscheinlich halten würde.
Wenn Van Gogh eine APU ist, dann gibt es davon auch eine Lite-Variante, was soll das dann genau sein?

Deswegen veröffentlicht AMD ein Dokument mit dem Titel "RDNA Insctruction Set Architecture". Können wir bei den Angaben von AMD bleiben und die eigenen Meinungen an die Realität anpassen? Die Diskussion dreht sich im Kreis, da du keinerlei Argument hast für diese Sichtweise.


Nun jemand muss ja definieren wie es genannt wird. IMHO ist das AMD und daran kann man sich orientieren. Eine bessere Alternatvie sehe ich hier nicht. Und ich sagte ja bereit es sind Iterationen und Erweiterungen.

Ist etwas sowohl ISA als auch Microarchitektur, dann sehe ich keinen Grund zu sagen es sei keine ISA weil es beides ist. Das "Entweder, Oder" muss man ja nicht auf die Spitze treiben. Schon gar nicht in dem Abstraktionlevel auf dem wir hier im Forum damit umgehen wollen.

Eine RDAN ISA wurde definiert - wollen wir diese nun ignorieren, weil sie der GCN-ISA zu 90% ähnelt? Wie viel Ähnlichkeit hat x64 mit x86? Es wird dennoch alles mit x86 bezeichnet.
Wie gesagt, würde man in ähnlicher Art und Weise für Zen2 dokumentieren, hätte man es "Zen2 ISA" genannt.
Aber praktisch ist schon relativ klar, was die ISA an sich definiert und was sie nicht tut.
Bridgman von AMD hat in der Hinsicht selber gesagt, dass man RDNA eher als Mikroarchitektur versteht, welche eine GCN artige ISA verwendet.
Allerdings abseits der Mikroarchitektur-Änderungen, die die wirklich unabhängig von der ISA sind, kann man auch deiner Argumentation folgen, in Hinsicht des Namens.
Wenn man das RDNA-ISA nennen möchte, dann passt es auch.


[...]
Das ist wohl wahr.
Dachte ursprünglich, dass es sich um mobile Varianten handelt, aber die Navi1x Chips untermauern das nicht unbedingt. Wobei es bei Navi1x glaube ich auch keine Lite Labels gab?
Könnte aber auch sein, dass man bei Navi1x keine derartigen Änderungen zwischen den Desktop- und Mobile-Chips hat, als dass man Code-Branches (und damit ein dediziertes Label) brauchte.
[...]
Es wurde früher auch Navi10 Lite gelistet.
Navi12 Lite, mit der gleichen GFX-ID 1011 wie Navi12, wird noch angezeigt.

Und bei Van Gogh hat man die Nummerierung gegenüber früher geändert:
"VAN GOGH = GFX1033.
(GFX1032 → GFX1033)."


Gab zwischen allen Revisionen zumindest kleinere Aenderungen.

Aber ja, auch sonst: Southern Islands, Sea Islands, Volcanic Islands, GFX9 (Vega), GFX10 (Navi). Okay, es wurde vier Mal geaendert, wenn man die erste Revision nicht mit zaehlt.
Das Witzige ist doch, dass die RDNA ISA wieder näher and SI ist als an Vega, was das Encoding angeht :)
Man könnte also sagen, die ISA dreht sich genauso im Kreis wie die Diskussion hier :P
Jetzt mal abseits von neuen oder entfernten Instruktionen, aber GCN2 (Sea Islands) sollte doch völlig abwärtskompatibel mit GCN1-Code (Southern Islands) sein?
Es gab nur ein neues FLAT-Format, mehrere neue Instruktionen und vier hat man entfernt.
GCN3/Volcanic Islands dagegen hat weitreichend Dinge umgestaltet:
Modified many of the microcode formats: VOP3A, VOP3B, LDS, GDS, MUBUF, MTBUF, MIMG, and EXP.
SMRD microcode format is replaced with SMEM, now supporting reads and writes.
Dabei wurden auch mehr Instruktionen entfernt.
Da ist es dann auch eindeutig, dass keine weitreichende Abwärtskompatibilität mehr besteht.
GCN4/Polaris verwendet die gleiche ISA.
Mit GCN5/Vega gab es mehrere Änderungen, erscheinen aber relativ klein:
MIMG Microcode format: removed the R128 bit.
•FLAT Microcode format: added an offset field.
•Removed V_MOVEREL instructions.
•Added control over arithmetic overflow for FP16 VALU operations.
•Modified bit packing of surface descriptors and samplers:
◦T#: removed heap, elem_size, last_array, interlaced, uservm_mode bits.
◦V#: removed mtype.
◦S#: removed astc_hdr field.

Deswegen hatte ich im Kopf, dass GCN1-2 weitgehend identisch ausfallen und dann GCN3-5 (wobei 5 ein paar Dinge geändert hat).

Bei RDNA klingt es erneut nach einem stärkeren Bruch:
Programming Model Changes
•FLAT_SCRATCH and XNACK_MASK are no longer in SGPRsThey are in dedicated hardware registers accessed via S_GETREG_B32 andS_SETREG_B32
•Added a scalar source enum: NULL (reads zero and writes nothing).
•Image operations add a DIMension field
•Memory operations gain DLC bit (Device Level Coherence) to control level-1 caching
•Buffer clamping rules in MUBUF/MTBUF is explicitly controlled by the buffer resource
•Separated dependency counters for vector memory loads from stores
•Moved POPS_PACKER from mode to a hardware register accessed via S_GETREG_B32and S_SETREG_B32
•SGPRs are no longer allocated: every wave gets a fixed number of SGPRs

Instruction Changes
•DS_PERMUTE/DS_BPERMUTE are limited to 32-lane permutation
•DPP (renamed to DPP16) is limited to 16-lane access
•VALU ops can use two SGPR inputs instead of just one
•VALU VOP3 format can use a literal constant
•VALU V_CMPX writes only EXEC, not also an SGPR
•VALU Add & Sub instructions have change names to clarify carry-in and carry-out
•VALU all float-16 math uses FMA instead of MAD
•T# and V# (resource constants) have some bit changes
•Added SALU ops to quickly set float round & denormal modes
•Removed:◦S_SET_GPR_IDX family of instructions (use V_MOVREL for GPR indexing)◦CBRANCH_FORK and CBRANCH_JOIN◦All non-reverse VALU V_SHIFT opcodes◦VSKIP◦Removed non-volatile instruction control

@danarcho

Das hast du schon mehrmals erwähnt, wo ist das Encoding wieder näher bei der v6/7 ISA, gegenüber den späteren?
Hat das in dem Fall überhaupt eine signifikante Bedeutung?

[gravitationsfeld]

Ich vermute immer noch, dass das naehere Encoding an Southern Islands ein Beiprodukt der Abwaertskompatibilitaet der neuen Konsolen ist. Aber das ist reine Spekulation

[danarcho]

@danarcho

Das hast du schon mehrmals erwähnt, wo ist das Encoding wieder näher bei der v6/7 ISA, gegenüber den späteren?
Hat das in dem Fall überhaupt eine signifikante Bedeutung?
Zunächst: keine Generation ist 100% abwärtskompatibel. In jeder Generation gab es Änderungen, die das unmöglich machen. Es kann zwischen SI und CI sowie VI und Vega sein, dass einzelne shader funktionieren, aber nicht im allgemeinen.

Soll ich jetzt die einzelnen Formate aufzählen?
Modified many of the microcode formats: VOP3A, VOP3B, LDS, GDS, MUBUF, MTBUF, MIMG, and EXPDas ist halt nicht die einzige Änderung. Zusätzlich wurden die Opcodes der meisten Instruktionen leicht verändert und Navi macht einen großen Teil davon wieder Rückgängig. Eine Übersicht über alle Opcodes findest du zB hier (https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/amd/compiler/aco_opcodes.py).

Ich vermute immer noch, dass das naehere Encoding an Southern Islands ein Beiprodukt der Abwaertskompatibilitaet der neuen Konsolen ist. Aber das ist reine Spekulation
Entweder das oder sie haben aus Versehen das falsche Repo geforkt :tongue:

[2Ms]

GCN ist definitiv keine ISA im Sinne von x86, sonst haette sich das Instruction-Encoding zwischen Tahiti und Navi nicht rund fuenf mal geaendert.

Der Assembly-Code sieht aehnlich aus zwischen den verschiedenen Chips aber das war's auch schon. Man kann nicht mal Tahiti-Code auf Polaris laufen lassen. Voellig anderes und inkompatibles Encoding. Selbst Instructions werden zwischen den Chips entfernt oder gaendert.
Ahhh !!!

Nun wird mir klar, warum Wolfenstein The Old Blood auf Tahiti tadellos lief, aber auf Polaris total versagte, Ruckeln und Stocker zeigte. Das Spiel wurde demnach nie an Polaris angepasst.

[aufkrawall]

Die Spiele sind noch OpenGL, ist wahrscheinlich hauptsächlich auf Nvidia bzw. deren Treiber optimiert und der AMD OpenGL-Treiber für Windows der letzte Müll.

[Screemer]

Mal folgendes mit ob und No getestet?

https://steamcommunity.com/app/350080/discussions/0/154644928858134876/

[robbitop]

Ahhh !!!

Nun wird mir klar, warum Wolfenstein The Old Blood auf Tahiti tadellos lief, aber auf Polaris total versagte, Ruckeln und Stocker zeigte. Das Spiel wurde demnach nie an Polaris angepasst.

Da sitzt doch aber noch eine High Level API und ein Shadercompiler dazwischen. ;)

[Locuza]

Zunächst: keine Generation ist 100% abwärtskompatibel. In jeder Generation gab es Änderungen, die das unmöglich machen. Es kann zwischen SI und CI sowie VI und Vega sein, dass einzelne shader funktionieren, aber nicht im allgemeinen.

Soll ich jetzt die einzelnen Formate aufzählen?
Das ist halt nicht die einzige Änderung. Zusätzlich wurden die Opcodes der meisten Instruktionen leicht verändert und Navi macht einen großen Teil davon wieder Rückgängig. Eine Übersicht über alle Opcodes findest du zB hier (https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/amd/compiler/aco_opcodes.py).
[...]
Jetzt mal spezieller, nur eine kurze Darstellung, warum nicht der meiste SI-Code auch direkt unter CI laufen sollte?
Instruction formats und opcodes sind nahezu alle gleich?


Ahhh !!!

Nun wird mir klar, warum Wolfenstein The Old Blood auf Tahiti tadellos lief, aber auf Polaris total versagte, Ruckeln und Stocker zeigte. Das Spiel wurde demnach nie an Polaris angepasst.
Das Spiel lief (läuft noch?) völlig miserabel auf einer Tonga (GCN3).
Lustigerweise aber nicht bei der Fury X bzw. Fiji (GCN3) mit prinzipiell gleicher Technologiestufe.
Bei Polaris(GCN4) lief es auch richtig schlecht, aber bei der PCGH war der "Übeltäter" das Skylake-System, mit Haswell gab es zumindest Tahiti-Performance und nicht die Hälfte davon:
https://www.pcgameshardware.de/AMD-Catalyst-Crimson-Grafikkarte-255517/News/RSCE-1681-1682-Bug-Wolfenstein-Skylake-Polaris-1204234/

Da kann das Spiel aber wenig machen, denn wir redeten von der internen Maschinensprache der GPUs, als Spielentwickler auf dem PC kann man die gar nicht direkt verwendet.
Man verwendet eine API wie DX11/12, OpenGL/Vulkan und eine High-Level-Shader Sprache wie HLSL oder GLSL.
Der Plattform- oder Treibercompiler übersetzt dann den High-Level-Code zur nativen Maschinensprache.

Das einzige was man als Spielentwickler machen könnte, ist mit Glück das Problem zu identifizieren und mit ein paar Code-Anpassungen könnte man möglicherweise die Treiber/Compiler-Probleme umgehen, wenn nicht, dann hat man eben ultimativ Pech gehabt.

[danarcho]

Jetzt mal spezieller, nur eine kurze Darstellung, warum nicht der meiste SI-Code auch direkt unter CI laufen sollte?
Instruction formats und opcodes sind nahezu alle gleich?
Würde wohl, aber who cares? Die 3 opcodes, die entfernt wurden, sind recht selten. Aber der shader compiler 'weiß' eh für welche Hardware er gerade kompiliert. Wir haben zB außer FLAT und 1-2 workarounds keinen speziellen Code für SI im Compiler. Die allermeisten shader sind also für SI und CI 100% identisch.

[pixeljetstream]

Der Plattform- oder Treibercompiler übersetzt dann den High-Level-Code zur nativen Maschinensprache.

Das einzige was man als Spielentwickler machen könnte, ist mit Glück das Problem zu identifizieren und mit ein paar Code-Anpassungen könnte man möglicherweise die Treiber/Compiler-Probleme umgehen, wenn nicht, dann hat man eben ultimativ Pech gehabt.
Selbst die low-level sprachen wie dxil oder spir-v werden übersetzt. Am PC gibt es nix was nicht vom Treiber abhängt. Afaik kann man nur cuda "legal" binary shippen, was dann aber auf neuerer HW nicht laufen wird, weswegen das nur im Enterprise oder HPC Bereich gemacht wird.

[danarcho]

Afaik kann man nur cuda "legal" binary shippen, was dann aber auf neuerer HW nicht laufen wird, weswegen das nur im Enterprise oder HPC Bereich gemacht wird.
OpenCL auch schon seit Ewigkeiten, gibt auch einen Haufen offline Compiler, aber gleiches Problem.

Edit: Bei AMD kann man sogar assembly kernel schreiben, was auch für etherium und konsorten gemacht wurde :P

[gravitationsfeld]

Ahhh !!!

Nun wird mir klar, warum Wolfenstein The Old Blood auf Tahiti tadellos lief, aber auf Polaris total versagte, Ruckeln und Stocker zeigte. Das Spiel wurde demnach nie an Polaris angepasst.
:facepalm:

[pixeljetstream]

OpenCL auch schon seit Ewigkeiten, gibt auch einen Haufen offline Compiler, aber gleiches Problem.

Edit: Bei AMD kann man sogar assembly kernel schreiben, was auch für etherium und konsorten gemacht wurde :P

Okay. Allerdings auch nur offiziell dann für CL oder? Mir fällt bei Grafik nur das inoffizielle "Hacking GCN via OpenGL" ein.
http://h3.gd/

[horn 12]

Leistung soll duchwachsen sein,- Ähnlich Vega - Radeon VII
Stromverbrauch zwar besser aber so wirklich gut soll auch RDNA 2 nicht sein.

Preis aber wirklich Top und wird NVIDIA das halbe Jahr zum Handeln zwingen.
Erste Karten sind ab 18.ten März im Handel zu finden.

Infos kommen am 05 März.

[danarcho]

Okay. Allerdings auch nur offiziell dann für CL oder? Mir fällt bei Grafik nur das inoffizielle "Hacking GCN via OpenGL" ein.
http://h3.gd/
Naja, man braucht clEnqueueNativeKernel oder etwas entsprechendes in der API, und das haben halt nur die compute APIs. Da bei Nvidia die ISA ja größtenteils reverse-engineered wurde, müsste es eigentlich auch easy sein einen Assembler dafür zu schreiben. Aber keine Ahnung, ob der Treiber noch eine Signatur checkt oder so.

[Screemer]

Leistung soll duchwachsen sein,- Ähnlich Vega - Radeon VII
Stromverbrauch zwar besser aber so wirklich gut soll auch RDNA 2 nicht sein.

Preis aber wirklich Top und wird NVIDIA das halbe Jahr zum Handeln zwingen.
Erste Karten sind ab 18.ten März im Handel zu finden.

Infos kommen am 05 März.
Da verarscht dich jemand hart.

[Linmoum]

Hat ja lange gehalten, nichts mehr schreiben zu wollen.

[reaperrr]

Leistung soll duchwachsen sein,- Ähnlich Vega - Radeon VII
Stromverbrauch zwar besser aber so wirklich gut soll auch RDNA 2 nicht sein.

Preis aber wirklich Top und wird NVIDIA das halbe Jahr zum Handeln zwingen.
Erste Karten sind ab 18.ten März im Handel zu finden.

Infos kommen am 05 März.
Völlig unabhängig davon, ob da jetzt was von stimmt:
Wenn die Unterschiede zwischen RDNA1 und 2 größer wären als 1-2 neue Features und leichte Effizienz-/IPC-Optimierungen (und 7nm+), würden die kommenden Chips nicht mehr Navi heißen.

Das Verbrauchs-Optimierungs-Team um Suzan Plummer ist erst Ende 2017 nach Raja's Abgang vom Ryzen-Team zur RTG gewechselt. Um zwischen Navi1x und 2x noch gravierende Verbesserungen vorzunehmen dürfte es da schon zu spät gewesen sein, man darf nicht unterschätzen, wie lang die Vorlaufzeiten für sowas sind.
Die Früchte der Arbeit werden wir IMO frühestens mit RDNA3 sehen, weil das die erste Ausbaustufe sein dürfte, bei der sie genug Zeit hatten, um tiefgreifendere Optimierungen vorzunehmen.

Außerdem scheint Navi21 der internen ID nach zu urteilen eher RDNA1.8 oder so zu sein, denn das ist der einzige Navi2x mit einer gfx102x ID. Navi1x sind alle gfx101x, die anderen Navi2x und kommende Navi-APUs sind schon gfx103x (bzw. eine APU sogar schon gfx1040), was weitere Verbesserungen impliziert (mglw. noch mehr Optimierungen durch Plummer&Team, die Aussage "Nvidia-Killer" fiel ja auch mal im Zusammenhang mit Navi23, nicht 21).

[Berniyh]

Außerdem scheint Navi21 der internen ID nach zu urteilen eher RDNA1.8 oder so zu sein, denn das ist der einzige Navi2x mit einer gfx102x ID. Navi1x sind alle gfx101x, die anderen Navi2x und kommende Navi-APUs sind schon gfx103x (bzw. eine APU sogar schon gfx1040), was weitere Verbesserungen impliziert (mglw. noch mehr Optimierungen durch Plummer&Team, die Aussage "Nvidia-Killer" fiel ja auch mal im Zusammenhang mit Navi23, nicht 21).
Nein. Navi21 Lite ist gfx102x. Navi21 (ohne Lite) ist gfx1030.
Zumindest laut Komachi.

[reaperrr]

Nein. Navi21 Lite ist gfx102x. Navi21 (ohne Lite) ist gfx1030.
Zumindest laut Komachi.
Ah, ok. Hab ich überlesen, danke für die Klarstellung.

[Der_Korken]

Für VII-Leistung legt AMD keinen neuen Chip auf, solange noch andere Marktbereiche komplett offen sind. Für VII-Leistung würde eine durch 7nm+ gepimpte 5750XT mit schnellerem VRAM reichen, wenn man sich genötigt sieht hier noch 10% rauskratzen zu wollen.

[Linmoum]

Jetzt fangt doch nicht damit an, über Beiträge von horn zu diskutieren. :freak:

[horn 12]

Meinte dass Big Navi die Problem von Vega , Vega VII teilweise noch mitschleppen wird, zwar nicht in dem Ausmaß,- aber immerhin bemerkbar bleiben wird.

[Pick]

Meinte dass Big Navi die Problem von Vega , Vega VII teilweise noch mitschleppen wird, zwar nicht in dem Ausmaß,- aber immerhin bemerkbar bleiben wird.

Zum Beispiel?
Ist alles so schlimm?

[Sunrise]

Meinte dass Big Navi die Problem von Vega , Vega VII teilweise noch mitschleppen wird, zwar nicht in dem Ausmaß,- aber immerhin bemerkbar bleiben wird.
Du meinst das Problem, dass du eine Karte gekauft hast, die in nicht allzu ferner Zukunft durch RDNA2 in den Boden gestampft wird?

Navi2 hat in etwa ebensoviel mit einer Vega VII zu tun, wie ein Wasserkocher mit einem Herd von 1950.

[wolik]

wie ein Wasserkocher mit einem Herd von 1950.
:confused:

[gedi]

Meinte dass Big Navi die Problem von Vega , Vega VII teilweise noch mitschleppen wird, zwar nicht in dem Ausmaß,- aber immerhin bemerkbar bleiben wird.

Horn, du erzählst Blödsinn. Ich gehe doch stark davon aus, dass der kolportierte VR-Bench Navi 2x zuzuordnen ist. Und hier liegt Navi 30% über einer 2080TI. Ausgehend von V64 wäre das ein Aufschlag von 250% und da es performancewise mit RDNA 1 in VR nicht viel besser aussieht, denke ich der große Navi ist ein ziemliches Brett.

[Ravenhearth]

30% über der 2080 Ti passen auch ziemlich genau zu 80 CUs: Die 2080 Ti ist im 4K-Index von 3DC rund 46% schneller als die 5700XT, eine verdoppelte 5700XT läge im Idealfall also ~37% über einer 2080 Ti.

[Kehaar]

Kommt schon. Bis zum 5. März ist es doch nicht mehr so lang hin. Vielleicht liegt horn ja mal richtig :ulol:

PS: Ich glaube jedenfalls nicht daran.

[Berniyh]

Kommt schon. Bis zum 5. März ist es doch nicht mehr so lang hin. Vielleicht liegt horn ja mal richtig :ulol:

PS: Ich glaube jedenfalls nicht daran.
Ich zitiere mal:
Erste Karten sind ab 18.ten März im Handel zu finden.

Infos kommen am 05 März.
Bis zum 5. März sind es noch 4 Tage, bis zum 18. noch 17 Tage (also weniger als 3 Wochen).
Letzteres Datum soll auch nicht das Datum der Vorstellung sein, sondern ab dann sollen die Karten im Handel zu finden sein.
Also: weniger als 3 Wochen vor Release des neuen GPU Flaggschiffs einer Branchengröße und keiner weiß davon?
Wann gab es sowas zum letzten Mal in dem Bereich? Gab es da schon das Internet?
Zumal ja auch AMD Interesse daran hat vor Release darauf aufmerksam zu machen.

Also ganz ehrlich: wenn man sich schon so einen Schmarrn ausdenkt, dann sollte man es wenigstens mit realistischen Eckdaten machen.
So ist ziemlich klar dass das Blödsinn ist.

Wir wissen aktuell praktisch gar nichts über Big Navi, außer, dass es den Chip geben wird, da die CEO von AMD ihn selbst so bezeichnet hat.
Aber das war es dann auch. Wir wissen nicht mal, ob es sich um Navi21, 22 oder 23 handelt.
Folglich ist ein naher Release extrem unwahrscheinlich und der tatsächlich Release dürfte noch mehrere Monate weg sein (wahrscheinlich grob ein halbes Jahr).