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

[Daredevil]

Ne. :D Ist der Blockchain Treiber.

[dargo]

Achja... da war was. :idea:

[Daredevil]

Ändert aber nichts daran, dass es nicht geht. :D
Muss also nicht unbedingt Modell abhängig sein.

[dargo]

Das Ding ist auch von August, zudem Beta. Wir haben Januar.

[Daredevil]

Ja, sag ich doch.... entweder haben Wattman Leute kein Interesse dadran oder AMD ist zu faul, den Treiber vorran zu bringen.
Beides hat aber nichts mit dem GPU Model zutun.

[Flusher]

Das ist einfach nur Quatsch. Der Markt interessiert sich kaum für W. Die Marke ist viel, viel wichtiger. Danach kommt Verfügbarkeit und was hinten an Leistung rauskommt. Dann ist noch relevant wie leise das Produkt ist. Der Stromverbrauch interessiert hingegen kaum einen, das ist nett, das wars dann aber auch.


Der Markt ist aber nicht nur der Endkunde sondern auch die AIBs. Wie Robitop schon beschrieben hat hat die Perf/W massgeblichen Einfluss auf den Verkaufspreis und die Margen. Wenn da die Margen klein und die Preise hoch sind, dann haben weder Kunden noch AIBs "Bock" auf solche Produkte. Gerade das sehen wir doch bei Vega - die AIBs sind extrem zögerlich was Vega angeht.

Der Schwachsinn geht ja weiter, Fiji hat kaum R&D gekostet, man hat ja nur die damals neuesten GCN-Bausteine genommen und deren Maximalausprägung in eine Marke gepresst. HBM ist keine große Sache gewesen, das einzige, was daran eben schwer ist, ist das billig in ein Package zu packen und billig zu produzieren.

Klar - mal die CUs von Tonga nehmen, ein HBM Speicherinterface dranpappen, nen Interposer schnell in CAD zeichnen und am Ende alles draufpappen. ;D

Mit Verlaub aber hast du überhaupt ein grundlegendes Verständnis von R&D Prozessen, selbst Abseits der Chipfertigung?


Das hat aber weder mit Fiji noch mit Vega als solches was zu tun. Mit Vega hat man wieder einige Entwicklungen mitgenommen, die erst später durchschlagen werden, von daher ist da 0,0 "verschwendet" am R&D-Budget für den Chip. Lasst doch mal diesen polemischen Schwachsinn sein.

Vega zeigt doch gerade das die GCN Architektur, so wie sie heute existiert, an der Grenze ist. Hier muss ordentlich was unter der Haube umgekrempelt werden, was enormen R&D Aufwand bedeutet. Zu behaupten Vega wäre so Nachhaltig entwickelt worden, dass kein Budget unnötig verbraucht wurde ist Unsinn. Alleine der Transfer des Chipdesigns in die Fertigung, die parallel dazu laufende Validierung und nicht zuletzt auch die Entwicklung der Software verschlingen Unmengen an Gelder.


Und wenn 12nm Ampere gegen 7nm Navi antreten muss würd ich da nicht die Hand für ins Feuer legen, dass NV das gewinnen kann, die Prozesse sind doch sehr weit auseinander.

Man kann Fertigungsprozesse mittlerweile nicht nur an dem simplen Marketingbezeichnungen bewerten. "Wer hat den Kleinsten (Transistor)" ist längst nicht mehr maßgebend für Taktbarkeit, Packdichte und Fertigungsaufwand.

[robbitop]

Ich bin wirklich gespannt, ob Navi analog zu Epyc funktioniert. Nur noch ein Die, welches man über dessen Anzahl von Mainstream bis High End über dessen Anzahl skaliert. 1, 2 und 4 dice pro Interposer. Das wäre, wenn das ordentlich skaliert, schon sowas wie der helige Gral. Das würde richtig Kosten sparen in der Entwicklung und time-to-market bringen...

[dargo]

Vega zeigt doch gerade das die GCN Architektur, so wie sie heute existiert, an der Grenze ist.

Oh ja... das sehe ich wunderbar in einem Wolfenstein 2 (welches GCN sogar noch etwas bremst), Doom, BF 2, DoW 3 etc. Es ist mal wieder bezeichnend fürs 3DC wie die Softwareeffizienz komplett unter den Tisch gekehrt wird. :rolleyes: Der gleiche Schwachsinn wie bei Tahiti damals geht jetzt bei Vega wieder los.

[=Floi=]

Ich bin wirklich gespannt, ob Navi analog zu Epyc funktioniert. Nur noch ein Die, welches man über dessen Anzahl von Mainstream bis High End über dessen Anzahl skaliert. 1, 2 und 4 dice pro Interposer. Das wäre, wenn das ordentlich skaliert, schon sowas wie der helige Gral. Das würde richtig Kosten sparen in der Entwicklung und time-to-market bringen...

Der heilige gral ist das sicherlich nicht. Du holst dir ewig viel nachteile mit rein. Pro DIE sind sicherlich nicht unerheblich wenig redundante einheiten nötig welche bei einem monolithischen core nur einmal vorhanden wären. Du brauchst eine sehr gute kommunikationslogik.
Pro DIE brauchst du auch nen speicherchip, weil sonst intern der overhead alles zugrunde richten würde imho. Komplizierteres und teureres package mit bis zu 8 chips.

Die verlustleistung skaliert auch mit! Das wird nicht besser, wenn ich 2 chips mit 200watt oder 4 chips mit 100watt verbaue!
Das ist eine milchmädchenrechnung, weil ich zwar theoretisch schneller als NV werde, aber praktisch an der verlustleistung scheitere.

[dargo]

Pro DIE brauchst du auch nen speicherchip, weil sonst intern der overhead alles zugrunde richten würde imho.
Wie kommst du denn darauf?

[=Floi=]

Wie kommst du denn darauf?

https://www.anandtech.com/show/11551/amds-future-in-servers-new-7000-series-cpus-launched-and-epyc-analysis/2

denke da wäre sicherlich faktor 10-20 nötig um die nächsten jahre das problem zu umgehen.

[dargo]

Wenn du mir jetzt noch verraten könntest was du mit dem Link bezwecken möchtest könnte man darauf eingehen.

[robbitop]

Das wurde bereits bei den mobile GPU Designs (allerdings core intern) so skaliert. Siehe alles aber Series 5 bei IMG Tec. Es gibt sicherlich ein Stück mehr Logik für das Interface, aber das hält sich in Grenzen. Dazu kommen natürlich andere Redundanzen wie der 2D Teil und der Video Teil. Auch das hält sich aber halbwegs in Grenzen. Es kostet unterm Strich sicherlich etwas mehr Silizium. Dafür hast du aber auch kleinere Dice, die zu höheren Yields führen (und die Flächenausnutzung des Wafers ist sogar höher).

Dass jeder Die ein eigenes Speicherinterface und eigenen VRAM hat ist sinnvoll. Das muss aber kein HBM sein. Kann ja auch weiterhin GDDR sein.

Einen Nachteil bei der Skalierung der Leistungsaufnahme wird es sicherlich durch die Offchipkommunikation geben - das kostet sicherlich ein wenig Energie. Jedoch wird die Leistungsaufnahme nicht plump wie im SLI/CF skalieren. Man hat ja nicht doppelten VRAM oder doppelte Spannungsversorgung. Auch wird man redundante Logik sicherlich deaktivieren.

Bei Epyc ist es eigentlich nicht deutlich anders. Unterm Strich kann das sinnvoll sein, mit nur einem Kern viele Markbereiche abzudecken.

NV hat laut ihrem Patent übrigens ähnliches vor.

Wenn du mir jetzt noch verraten könntest was du mit dem Link bezwecken möchtest könnte man darauf eingehen.
Dass es einer sehr hohen Bandbreite für diesen Anwendungszweck (mGPU auf einem Interposer) bedarf. Höher als für CPUs. Die Fabric müsste deutlich schneller sein. Das sollte auf einem SI aber möglich sein. Siehe HBM Anbindung.

[dargo]

Dass es einer sehr hohen Bandbreite für diesen Anwendungszweck (mGPU auf einem Interposer). Höher als für CPUs. Die Fabric müsste deutlich schneller sein. Das sollte auf einem SI aber möglich sein. Siehe HBM Anbindung.
Schon klar. :)

Single-GPU ist langfristig imho eine Sackgasse. Man muss sich nur mal anschauen wie fett ein Volta mittlerweile geworden ist. Sowas kriegst du niemals in den Massenmarkt. Demnächst ist ein Wechsel von 16/14/12nm auf 7nm reif. Was kommt danach? Langsam muss man sich Gedanken machen wie man dieses Problem möglichst günstig umschifft. Ansonsten haben wir Stillstand. Die ganzen Leistungssprünge sind so schon ordentlich gedehnt worden. Vor einigen Jahren gabs eine Leistungsverdoppelung bei GPUs in ca. 12-18 Monaten. Heute musst du schon froh sein wenn du Faktor 2 nach 30-36 Monaten bekommst.

[Flusher]

Oh ja... das sehe ich wunderbar in einem Wolfenstein 2 (welches GCN sogar noch etwas bremst), Doom, BF 2, DoW 3 etc. Es ist mal wieder bezeichnend fürs 3DC wie die Softwareeffizienz komplett unter den Tisch gekehrt wird. :rolleyes: Der gleiche Schwachsinn wie bei Tahiti damals geht jetzt bei Vega wieder los.

Es ist nunmal ein Fakt das AMD Probleme hat breite GCN GPUs ordentlich auszulasten abseits von LL-APIs. NVIDIA hat dieses Problem nicht (zumindest nicht offenkundig). Wieviel Wert hat denn eine Architektur die extrem viel Pflege seitens der Softwareentwickler benötigt?

Das ist doch ein Märchen, dass Entwickler ihre Spiele nicht vernünftig auf die Hardware optimieren. Und wieso rennt AMD mit GCN basierten GPUs nicht davon, obwohl aktuell alle Highend-Konsolen auf GCN basierte GPUs setzen? Glaubst du wirklich, dass die Entwickler hier nicht bereits GCN spezifisch optimieren?

[dargo]

Und wieso rennt AMD mit GCN basierten GPUs nicht davon, obwohl aktuell alle Highend-Konsolen auf GCN basierte GPUs setzen?
Weil du bestimmte Features gar nicht unter der Steinzeit-API abrufen kannst? Auf einer Konsole hast du den Bremsklotz nicht am Bein. Ich sehe auch auf einigen neuen DX11 Games keine schlechte Performance von Vega im Vergleich zur Konkurrenz (1080TI vs. Vega64 oder 1080/1070TI vs. Vega56). Unter low level mit Shader Intrinsic Functions, Async Compute und (zukünftig) RPM geht halt noch X% mehr.

Edit:
Bezüglich Vega FE...
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11594481&postcount=130

Empfehle die FE dem 08/15 Hans, ich freu mich schon auf das Rumgeheule. Ist der aktuelle Stand, muss natürlich nicht heißen, dass es so bleibt.

[Brillus]

Das wurde bereits bei den mobile GPU Designs (allerdings core intern) so skaliert. Siehe alles aber Series 5 bei IMG Tec. Es gibt sicherlich ein Stück mehr Logik für das Interface, aber das hält sich in Grenzen. Dazu kommen natürlich andere Redundanzen wie der 2D Teil und der Video Teil. Auch das hält sich aber halbwegs in Grenzen. Es kostet unterm Strich sicherlich etwas mehr Silizium. Dafür hast du aber auch kleinere Dice, die zu höheren Yields führen (und die Flächenausnutzung des Wafers ist sogar höher).

Dass jeder Die ein eigenes Speicherinterface und eigenen VRAM hat ist sinnvoll. Das muss aber kein HBM sein. Kann ja auch weiterhin GDDR sein.

Einen Nachteil bei der Skalierung der Leistungsaufnahme wird es sicherlich durch die Offchipkommunikation geben - das kostet sicherlich ein wenig Energie. Jedoch wird die Leistungsaufnahme nicht plump wie im SLI/CF skalieren. Man hat ja nicht doppelten VRAM oder doppelte Spannungsversorgung. Auch wird man redundante Logik sicherlich deaktivieren.

Bei Epyc ist es eigentlich nicht deutlich anders. Unterm Strich kann das sinnvoll sein, mit nur einem Kern viele Markbereiche abzudecken.

NV hat laut ihrem Patent übrigens ähnliches vor.


Dass es einer sehr hohen Bandbreite für diesen Anwendungszweck (mGPU auf einem Interposer) bedarf. Höher als für CPUs. Die Fabric müsste deutlich schneller sein. Das sollte auf einem SI aber möglich sein. Siehe HBM Anbindung.
Ich erwarte sogar, das in so einen Fall der ganze 2D-Teil etc. in einen aktiven interposer wandert was nochmal die Flächen Effizienz steigern sollte.

[Pick]

Vega20 und Navi10 in Treiber
https://forum.beyond3d.com/posts/2017313/

[fondness]

Wenn Navi10 jetzt schon im Treiber auftaucht kommt das Ding womöglich früher als erwartet.

[robbitop]

War es nicht immer ca 1 Jahr zwischen ersten Treibereinträgen und Launch?

Was mich nur wundert, dass zwei unterschiedliche Generationen gleichzeitig auftauchen.

[fondness]

Vega20 ist vermutlich HPC-only. Da zählen vor allem ALUs und Bandbreite und da hat eine neue Architektur womöglich gar keine Vorteile wenn Navi zB vor allem was anderes optimiert als die reine Raw-Power. Zumindest ergibt für mich anders der späte Vega20 in 12nm auch keinen Sinn.

Was die Treibereinträge betrifft: Es ist natürlich nur ein Anhaltspunkt, da nach wie vor so einiges schief gehen kann. Aber häufig tauchten Treibereinträge erst deutlich später auf. Zudem wurde Navi ja schon im Juli 2017 in einem Linux Eintrag das erste mal gesichtet. Stichwort gfx10 super secret.

[BoMbY]

Wenn Navi10 jetzt schon im Treiber auftaucht kommt das Ding womöglich früher als erwartet.

Nein, glaube ich nicht. Die Wahrscheinlichkeit ist hoch, dass es noch ein paar Entwicklungsrunden gibt. Neuer Prozess, neue Architektur, usw.

[reaperrr]

Vega20 ist vermutlich HPC-only. Da zählen vor allem ALUs und Bandbreite und da hat eine neue Architektur womöglich gar keine Vorteile wenn Navi zB vor allem was anderes optimiert als die reine Raw-Power. Zumindest ergibt für mich anders der späte Vega20 in 12nm auch keinen Sinn.

Vor allem kann man so bei Navi auf den Strom- und Flächenfresser 1:2 DP verzichten.

Bisher sieht es danach aus, dass diese geleakten Folien zumindest keine Fakes waren, AMD aber (mal wieder...) langsamer als geplant war und wohl auch nicht alles davon umsetzen konnte: https://videocardz.com/65521/amd-vega-10-and-vega-20-slides-revealed

[HOT]

V20 ist sicher nicht nur HPC. Dafür wird der Chip offenbar zu klein. Im HPC vermute ich eher, dass dort 2 auf einem Interposer gekoppelt werden und so 128CUs auf einer Karte bringen werden mit insgesamt 4 HBM-Stacks.
V20 ist ein außerplanmäßiges Produkt, dass den Mainsteammarkt (und als dual-Variante den HPC-Markt abdeckt), also gegen GA102 antreten wird.
V12 wird einfach der geshrinkte V10 sein. V11 gibts nicht, wie schon vermutet.

Vor allem kann man so bei Navi auf den Strom- und Flächenfresser 1:2 DP verzichten.

[...]
Das frisst AFAIK bei GCN keinen Strom, wenns nicht genutzt wird und wenig Fläche... :freak: Hawaii ist auch nicht außergewöhnlich groß und verbraucht nicht wegen DP soviel Saft. Da sind eher die etlichen mem-Controller schuld.

[N0Thing]

War es nicht immer ca 1 Jahr zwischen ersten Treibereinträgen und Launch?

Was mich nur wundert, dass zwei unterschiedliche Generationen gleichzeitig auftauchen.

Falls die Arbeiten an Navi nach Plan verlaufen sind, hat sich durch die lange Geburt von Vega diese Situation ergeben. Laut den aktellen Gerüchten (https://www.pcworld.com/article/3246211/computers/amd-reveals-ryzen-2-threadripper-2-7nm-navi-and-more-in-ces-blockbuster.html) kommt Vega als Refresh in 7nm und nicht in 12nm, also vielleicht als Testlauf, damit Navi weiterhin im Zielfenster bleibt. Die Unterschiede im Treiber zwischen Vega und Vega20 sollten nicht so dramatisch sein, das könnte also alles ganz gut zusammenpassen. Vega 20 war ja eh als HPC-Modell angekündigt, da kann man auch die hohen Preise in der Produktion an den Kunden weiterreichen.

[AMDoderNvidia]

Auf der längerfristigen Roadmap von AMD wurde zu Navi als ein Key-Feature "Scalability" genannt. Das war die Folie der Präsentation dazu:

https://scr.wfcdn.de/14739/AMD-Roadmap-2016-2018-1458068386-0-12.jpg

Kann mir jemand erklären, wie das funktionieren kann? Angenommen, Navi basiert weiterhin auf GCN und zwar konkret auf Vega (wie zuletzt auch hier auf 3dcenter in einer News vermutet) und die Skalierung wird durch das Zusammenschalten mehrerer Vega-Cores erreicht (als Spekulation). Wie sieht sowas dann konkret aus? Und wie spielt dabei Infinity Fabric mit rein? Und warum ist das dann nicht genauso problembehaftet wie Crossfire?

Wäre klasse, wenn da jemand von Euch ein wenig Licht reinbringen könnte :)

[robbitop]

Ich tippe mittlerweile darauf, dass "Scalability" nicht die Skalierung mehrerer dice auf einem Substrat mittels SI meint sondern die Skalierbarkeit der mArch an sich verbessert wird.

GCN (inkl Vega) skaliert verglichen mit halbwegs modernen NV mArchs nur mittelmäßig mit den Ausführungseinheiten.

Cape Verde hatte die höchste pro Flop Leistung der GCN 1.0 Generation (10 CUs). Pitcairn (20 CUs) war schon ein bisschen schlechter in dieser Metrik. Tahitii (32 CUs) noch schlechter. Hawaii (44 CUs) noch ein wenig schlechter. Und die Katastrophe war Fijii (64 CUs).
Vega 64 (64 CUs) scheint rohleistungsnormiert nicht besser als Fijii zu performen.

Auffällig ist, dass Vega M GH (Kaby Lake G) mit 24 CUs hier deutlich besser darsteht und rohleistunsnormiert fast mit Pascal (1060 mobile) mithalten kann.

NV skaliert seit Fermi sehr gut mit den Ausführungseinheiten. Man skaliert so ziemlich alles mit der Anzahl der GPCs. Das scheint hervorragend zu funktionieren. Ich kann mir vorstellen, dass das eine Punkt ist, auf der für Navi relevant ist.

Auch scheint das Cachesystem seit Maxwell ein wichtiger Bestandteil von NVs Bandbreiteneffizenz zu sein. DSBR, DCC und das Cachesystem scheinen Dinge zu sein, die ineinandergreifen und erst im Gesamtzusammenhang richtig, richtig gut funktionieren.

Bspw hat NV seit Fermi schon DCC. DCC scheint allein kaum effektiv zu sein. So dass NV es nicht für nötig erachtete, es schon bei Fermi zu erwähnen. Auch zeigten AMDs GCN 1.3 GPUs nur sehr ernüchternde Resultate in der Hinsicht.

[AMDoderNvidia]

Oh, Deine Interpretation von "Scalability" hier in diesem Kontext gefällt mir :) Nur sehe ich noch nicht, wie man die CUs tatsächlich im Gesamtkontext des Navi-Chips besser skalieren möchte, ohne diesen komplett umbauen zu müssen. Und genau dem stehen zwei Aussagen gegenüber: Zum einen, dass Navi weiterhin auf GCN aufbaut und erst die übernächste Generation im Jahr 2020 was Neues bringen soll und zum anderen GCN in seiner grundsätzlichen Architektur einfach am Ende ist, wie zuletzt hier dargestellt: Hardware- und Nachrichten-Links des 24. Januar 2018 (https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-24-januar-2018), zweiter Abschnitt.

[aufkrawall]

Alles baut irgendwie aufeinander auf. Wartet doch erstmal ab, bis das Kind in den Brunnen gefallen ist. ;)

[robbitop]

Oh, Deine Interpretation von "Scalability" hier in diesem Kontext gefällt mir :) Nur sehe ich noch nicht, wie man die CUs tatsächlich im Gesamtkontext des Navi-Chips besser skalieren möchte, ohne diesen komplett umbauen zu müssen. Und genau dem stehen zwei Aussagen gegenüber: Zum einen, dass Navi weiterhin auf GCN aufbaut und erst die übernächste Generation im Jahr 2020 was Neues bringen soll und zum anderen GCN in seiner grundsätzlichen Architektur einfach am Ende ist, wie zuletzt hier dargestellt: Hardware- und Nachrichten-Links des 24. Januar 2018 (https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-24-januar-2018), zweiter Abschnitt.
Ich glaube nicht, dass man die CUs als solche umbauen muss, sondern die Kontrolllogik (Sheduler, Command Prozessor, Rasterizer, Cachesystem etc) um sie herum.

Wobei eine Anpassung der wavefront size bei den CUs sicherlich auch positiv wäre. Laut gravitationsfeld sind die meisten Spiele relativ schlecht für GPUs optimiert. Mit einer wavefront size von 64 scheint man ggü NVs mArch (32) Nachteile in Bezug auf Verschnitt zu haben. Compute Applikationen haben das Problem seltener. Eine Verbesserung der Granularität wäre somit ggf sinnvoll (kostet aber natürlich Transistoren und sicherlich auch Leistungsaufnahme). Aber viele Entwickler scheinen trotz mehreren Jahren GCN Hardware im PC und auf den Konsolen trotzdem noch Defizite zu haben.

Ergo ist es ggf sinnvoll die HW so auszulegen, dass sie robuster ggü nicht voll optimiertem Code ist. Kostet aber Transistoren. Ich tippe darauf, dass NV vieles per Treiber hinbiegt. Sie bekommen ja (wie auch AMD) frühzeitig Gamecode. Die werden sicherlich via Treiber dann eingreifen und Code substituieren.

[BoMbY]

Man könnte zum Beispiel Virtuelle Register nutzen um eine menge Probleme zu umgehen:


System and method for using virtual vector register files (https://patents.google.com/patent/US20170371654A1/en)

Inventor: Ljubisa Bajic, Michael Mantor, Syed Zohaib M. Gilani, Rajabali M. Koduri

Described is a system and method for using virtual vector register files that may address all of the bottlenecks presented by current register file architecture by yielding lower die area, lower power and faster SIMT units while balancing low latency and register usage.

[robbitop]

Aber hilft das auch bei der Wavefront Größe und dem resultierenden Verschnitt? Das hat ja eher etwas mit der Auslastung und weniger mit der Auslastung der Register zu tun, oder?

[BoMbY]

Die effektive Wavefront-Größe wird IMHO primär durch die Register limitiert. Wie in diesem Beispiel:

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

[Locuza]

Die Thread/Wave-Größe von 64 bleibt immer gleich, die Anzahl an verwendeten Registern limitiert wie viele Waves GCN gleichzeitig verwalten kann, maximal sind es 10 pro SIMD.

Das Register-Patent hat in diesem Bezug nichts mit der Threadgroup-Größe zu tun.

[5CH4CHT3L]

https://youtu.be/AIYI3XnsTTs?t=57m38s
Da bin ich aber mal gespannt

[ndrs]

https://youtu.be/AIYI3XnsTTs?t=57m38s
Da bin ich aber mal gespannt
Ist es so schwer einen Satz dazuzuschreiben, um was es da geht? Der Titel des Videos lautet "Unedited PCMR PAX East Panel (ft. Steve, Bitwit, AMD, Corsair, /r/PCMR)". Aber auch das hilft (zumindest mir) nicht weiter.

[Brillus]

Ist es so schwer einen Satz dazuzuschreiben, um was es da geht? Der Titel des Videos lautet "Unedited PCMR PAX East Panel (ft. Steve, Bitwit, AMD, Corsair, /r/PCMR)". Aber auch das hilft (zumindest mir) nicht weiter.

Ich glaub es geht ihm um dieses NV wir wollen unsere eingenes Gamer label haben. Aber ich habe keine Ahnung wie das zu Navi passt.

[Locuza]

Die Fragestellung dreht sich zuerst um Nvidias GPP-Programm, zusätzlich mit der Frage wann AMD eine GPU veröffentlicht, welche Volta oder eine 1080Ti schlagen kann.

Der AMD-Mitarbeiter antwortet im Prinzip darauf, dass man auf die CES im Januar 2019 warten soll.
Die CES war die Messe, wo AMD Architekturdetails zu Polaris und Vega herausgegeben hat.

[AffenJack]

Die Fragestellung dreht sich zuerst um Nvidias GPP-Programm, zusätzlich mit der Frage wann AMD eine GPU veröffentlicht, welche Volta oder eine 1080Ti schlagen kann.

Der AMD-Mitarbeiter antwortet im Prinzip darauf, dass man auf die CES im Januar 2019 warten soll.
Die CES war die Messe, wo AMD Architekturdetails zu Polaris und Vega herausgegeben hat.

Wo spricht er von der CES 19? Er verweißt nur darauf, dass man auf der CES18 die Timeline präsentiert hat. Daher 0 Newsinhalt.

[Locuza]

Hast recht, er sprach von der Vergangenheit.
Egal 2019, Navi, Zerstörer.

[basix]

Egal 2019, Navi, Zerstörer.

;D;D;D

[Botcruscher]

Nach Failga wohl eher AMD- Zerstörer. Der Rebrand des Rebrand ist lächerlich, dabei hat das Marketing noch extra auf die Skalierbarkeit der Vega- Architektur hingewiesen.
Wo nur der ganze R&D seit Tahiti hingegangen ist... Hoffentlich sehen wir wenigstens ein besseren Prozess.

[vinacis_vivids]

Wo ist Vega ein fail? Die ganze uArch ist gerade dabei sich zu verbreiten und AMD verkauft mehr GPU's als zu Fiji's Zeiten.

[iuno]

Nach Failga wohl eher AMD- Zerstörer. Der Rebrand des Rebrand ist lächerlich, dabei hat das Marketing noch extra auf die Skalierbarkeit der Vega- Architektur hingewiesen.
Naja, es ist schon schwer die Kosten fuer ein komplett neues Lineup zu rechtfertigen, wenn man offenbar eh schon alles verkauft, was man irgendwie produzieren kann.
Mir ist das mit dem Rebranding in der aktuellen Situation voellig egal. Mich bringt eine Karte, die auf P10 Niveau ist aber weniger verbraucht (und das waere ein kleinerer Vega) nicht besonders ins Schwaermen, denn das ist irgendwie halt immer noch nur wenig mehr als Hawaii-Niveau. Was her muss ist was deutlich schnelleres, was nicht gleich 600€+ kostet. Und dabei ist es auch egal, dass der Markt diese Preise macht, weil AMD keinen Direktvertrieb hat.
Man muss sich mal vor Augen fuehren, dass V56 eine UVP um die 400€ hat und aktuell, obwohl es gerade deutlich runter ist, immer noch fuer 650€ verkauft wird. Was bringt dann, eine 300€ UVP GPU zu bringen?
Insofern bleibt doch eh nur das Warten auf Navi.

[=Floi=]

Beim alten chip für die selbe performance spart man eine menge kosten und verkauft es trotzdem.
Das ist mal mitm hirn gedacht. Ein nachfolger chip bräuchte neue treiber/karten/support etc. für die gleiche performance! Das macht wirtschaftlich keinen sinn. Wenn es blöd herging, dann hätte der auch HBM2 und wäre auch in der produktion noch teurer.

[Locuza]

Suzanne Plummer von AMD ist nun (Seit 7 Monaten sogar laut Linkedin) der Corperate Vice President von der Radeon Technologies Group, die gleiche Position hatte Raja Koduri inne, als er von Apple zurück zu AMD gekommen ist.
Suzanne wechselt somit von der CPU-Sparte und ihrer damaligen Zen Microprocessor Design Director Rolle zu der GPU-Sparte, wo Sie angibt das man das Managing Know-How und die Ambitionen von Zen auch auf die GPU-Produkte übertragen möchte, um in der Zukunft größere Fortschritte zu erzielen:
https://youtu.be/iQ_4C2TKHQ0?t=3m3s

[BoMbY]

Häh? Ich glaube da stimmt was nicht?


Graphics Industry Leaders Mike Rayfield and David Wang Join AMD (http://ir.amd.com/news-releases/news-release-details/graphics-industry-leaders-mike-rayfield-and-david-wang-join-amd)

SANTA CLARA, Calif., Jan. 23, 2018 (GLOBE NEWSWIRE) -- AMD (NASDAQ:AMD) today announced the appointment of Mike Rayfield as senior vice president and general manager of AMD Radeon Technologies Group (RTG), and David Wang as senior vice president of engineering for RTG. Both will report to President and CEO Dr. Lisa Su. Rayfield will be responsible for all aspects of strategy and business management for AMD’s graphics business including consumer graphics, professional graphics, and semi-custom products. Wang will be responsible for all aspects of graphics engineering, including the technical strategy, architecture, hardware, and software for AMD graphics products and technologies.

[Screemer]

Das sind doch drei völlig unterschiedliche Posten. Wo soll also das Problem sein? Btw gibt es vor allem bei vice-positionen in us-firmen häufig mehrfache Besetzung bei gleicher Bezeichnung aber anderem Tätigkeitsfeld.

[TheAntitheist]

Das sind doch drei völlig unterschiedliche Posten. Wo soll also das Problem sein? Btw gibt es vor allem bei vice-positionen in us-firmen häufig mehrfache Besetzung bei gleicher Bezeichnung aber anderem Tätigkeitsfeld.
kann ich unterschreiben, die sind dort etwas flexibler.

Wen interessiert denn bitte der Titel

[reaperrr]

Wo nur der ganze R&D seit Tahiti hingegangen ist... Hoffentlich sehen wir wenigstens ein besseren Prozess.
Die wurde halt schon unter dem Interims-CEO Seifert gehörig zusammengestrichen und auch von Read zugunsten von K12 und Zen auf ein Minimum beschränkt.

Wenn die Konkurrenz nicht gerade so träge ist und sich so auf seinen Lorbeeren ausruht wie Intel, macht es sich halt irgendwann bemerkbar, wenn man jahrelang nur einen Bruchteil des Personals und R&D-Budgets der Konkurrenz hatte.

Mit konkurrenzfähigem Budget und Personal hätten wir diverse Chips und Architekturverbesserungen eine ganze Ecke früher bekommen, und Chips wie Pitcairn wären durch bessere ersetzt statt immer wieder aufgewärmt worden.

[HOT]

Die werden schon seit 2 Jahren wieder massiv die Teams der RTG verstärken, jedoch arbeiten die natürlich alle für die neue IP, nicht für den alten Käse.
GCN macht man jetzt auch weiterhin so wenig wie irgend möglich. Wie gesagt, Polais sollte eh bis zum bitteren Ende halten, davon bin ich felsenfest überzeugt. Es gibt 3 Polaris und wird vermutlich 3 Vegas geben insgesamt (ohne semi-Custom) und einen Navi (erinnert an Cayman ein bisschen, aber mit besserer Fertigung).

[gmb]

AMD Navi is no high end GPU (https://www.fudzilla.com/news/graphics/46038-amd-navi-is-not-a-high-end-card?cid=dlvr.it)

Navi 7nm the 2019 chip will not be a high end GPU, it will be a quite powerful performance/mainstream chip.

Think of it as the Radeon RX 580 / 480 replacement. It will be small, and is likely to perform as well as the Vega 14nm that shipped last year. In the Nvidia performance world Navi should perform close to Geforce GTX 1080 which is quite good for the mainstream part but probably on part of the mainstream part planned after the high end part.


Selbst als Mainstream Chip wäre GTX 1080 Level in 7nm nicht berauschend.

[LadyWhirlwind]

AMD Navi is no high end GPU (https://www.fudzilla.com/news/graphics/46038-amd-navi-is-not-a-high-end-card?cid=dlvr.it)



Selbst als Mainstream Chip wäre GTX 1080 Level in 7nm nicht berauschend.

Kommt auf den Preis an...

[N0Thing]

Ich kann mir nicht vorstellen, dass Navi nur ein einziger Chip sein soll. Das wäre ja noch weniger als man mit Polaris oder Vega heraus gebracht hat.

[aufkrawall]

Kommt auf den Preis an...
Müsste ähnlich groß oder etwas kleiner als Polaris sein, also in 7nm nicht gerade geschenkt.

[mboeller]

Ich kann mir nicht vorstellen, dass Navi nur ein einziger Chip sein soll. Das wäre ja noch weniger als man mit Polaris oder Vega heraus gebracht hat.

warum? Ryzen ist auch nur 1 Chip.

alte infos:
http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/News/AMD-letzte-grosse-GPU-Navi-1235463/

https://wccftech.com/amd-navi-gpu-launching-siggraph-2018-monolithic-mcm-die-yields-explored/

[AffenJack]

AMD Navi is no high end GPU (https://www.fudzilla.com/news/graphics/46038-amd-navi-is-not-a-high-end-card?cid=dlvr.it)

Selbst als Mainstream Chip wäre GTX 1080 Level in 7nm nicht berauschend.

Wird sicherlich mehr als 1080 Level, aber viel mehr als 2x Polaris Geschwindigkeit und damit ungefähr 1080TI Territorium würde ich auch nicht erwarten in 2019 von Navi. An was schnelleres glaube ich erst 2020 mit 7nm EUV, 7nm DUV scheint einfach zu teuer zu sein, als dass wir da große Chips sehen werden.

[robbitop]

Wenn man gegen gt106 antreten will ist 1080 performance ok. P10 war dahingehend sehr erfolgreich. Erfolgreicher als V10. Macht schon Sinn. Wenn man erstmal nur 1x gpu bringen will ist das der wichtigste Markt.

[Käsetoast]

Wäre es denn auch denkbar, dass man so einen Polaris Ersatz Navi auch ein wenig mit Konsolen im Hinterkopf entworfen hat? Da also nochmal viel Arbeit reinstecken und es stärker auf Gaming auslegen als bei so einem Compute tauglichem Vega, damit der Chip auf grundsätzlicher Basis dieser Architektur dann 2020 in einer Konsole landen könnte? Die Chipgrößen einer solchen Konsole sollten ja in diesem Bereich liegen...

[Der_Korken]

AMD Navi is no high end GPU (https://www.fudzilla.com/news/graphics/46038-amd-navi-is-not-a-high-end-card?cid=dlvr.it)

Das muss ja erst mal nichts schlechtes heißen. Man könnte jetzt natürlich wieder die Analogie zu Vega=R600 und Navi=RV770 rauskramen, d.h. neue Fertigung, entschlackte Architektur und in gemäßigten Maßstäben entworfen. Allerdings wäre V10-Performance schon relativ wenig, da man in Spielen damit vllt 60% vor der 580 liegt. 100% würden mir definitiv besser gefallen :D.

Ich spinn jetzt mal ein bisschen rum: Wäre es eigentlich denkbar, zwei GPU-Dies auf ein Package zu packen und damit eine non-AFR-MGPU-Lösung zu bauen? Bei TR klappt das ja einigermaßen, außer wenn die Dies viele Daten austauschen müssen. GPUs arbeiten aber ohnehin schon massiv parallel, d.h. der Workload ist für den Ansatz vielleicht angenehmer. Die Latenzen werden nicht schlechter als die des VRAMs sein bzw. man hat vielleicht doppelte Latenzen, wenn GPU A auf den Speicher von GPU B zugreifen will. Problematischer wäre schon eher die Bandbreite, die afaik irgendwo in der Größenordnung von 40GB/s bei TR liegt. Die Daten müssten also z.B. zu 90% aus dem eigenen VRAM kommen und nur zu 10% aus dem VRAM der anderen GPU. Wäre sowas mit Hilfe des HBCCs nicht gut zu realisieren, weil jede GPU dann für sich in Hardware verwaltet welche Daten sie in ihren lokalen VRAM lädt? Alles was angefragt wird, wird in den lokalen VRAM geladen und was nicht gebraucht wird, eben nicht. Daten, die beide GPUs brauchen, werden dann auch in beiden VRAMs liegen bleiben. Man müsste "nur" die Kohärenz sicherstellen (Infinity Fabric?) und die Last so verteilen, dass z.B. bestimmte Texturen möglichst nur auf der einen GPU gebraucht werden, auf der anderen aber nicht. 100%ig klappt letzteres natürlich nicht, aber es sollte zumindest nicht jede Textur in jeden VRAM kopiert werden müssen. Wie es beim Rasterizer aussieht und ob man da verteilt rechnen kann, weiß ich nicht.

[Botcruscher]

Die Multi-GPU Spinnerei ist seit R600 wie Scheiße am Schuh. Das Problem dabei ist und bleibt die gigantische Datenmenge im Vergleich zu den Prozessoren. Selbst 2cm Distanz über einen Interposer sind enorm. Für Chips mit der Fläche ist jede Überlegung verschwendete Zeit.


Die Leistung auf Level der 1080 wiederum kommt absolut hin. Seit Polaris zielt AMD auf das Performance-Segment der Konkurrenz... was zu dem Zeitpunkt dann typisches Mainstream ist. Ohne Mining wäre die ganze Strategie aber schon bei Polaris gescheitert. Seit NV das Highend noch mal mit Performance untersetzt hat, ist AMD strategisch eh am Arsch. Mal sehen was sich dann für den Markt ausgedacht haben.

Wenn man gegen gt106 antreten will ist 1080 performance ok. P10 war dahingehend sehr erfolgreich. Erfolgreicher als V10. Macht schon Sinn. Wenn man erstmal nur 1x gpu bringen will ist das der wichtigste Markt.
Polaris war vor dem Mining auf Steam gegen die 1060 absolut unterlegen. Durch den Miningboom ist die Karte, wie V10, bei Spielern quasi nicht mehr existent. Das ist keine solide Grundlage sondern Glücksspiel. Aktuell sind es bei Steam noch 10,75%! PS: Die 1060 hat alleine 13,9%. Keine Ahnung welche Erfolge ihr da seht.

[Der_Korken]

Die Multi-GPU Spinnerei ist seit R600 wie Scheiße am Schuh. Das Problem dabei ist und bleibt die gigantische Datenmenge im Vergleich zu den Prozessoren. Selbst 2cm Distanz über einen Interposer sind enorm. Für Chips mit der Fläche ist jede Überlegung verschwendete Zeit.

Der VRAM ist auch weit entfernt und wuppt große Bandbreiten. Es ist natürlich klar, dass man nicht einfach zwei GPUs zusammenlötet und alles funktioniert von allein. Da wird zusätzliche Die-Size für ein performantes GPU-to-GPU interface investiert werden müssen, genauso wie für gutes load balancing. Der Vorteil wäre, dass AMD wie bei Ryzen nur einen Die bräuchte, um einen großen Marktbereich abzudecken und dass kleine Chips eine bessere Yield haben als große. Beide Hersteller würden sowas gerne machen, wenn es ohne große Abstriche möglich wäre. Die Frage ist eben, ob AMD mit dem Speichermodell von Vega vielleicht schon nah genug dran ist, es umsetzen zu können. Auch beim Rasterizer sind beide mittlerweile bei einem DSBR angekommen, der externe Bandbreite spart durch starke Lokalität.

[Botcruscher]

Der VRAM ist doch erst das zwote Problem. Den Erfolg beim Verbrauch durch zusätzlichen cache und Komprimierung hat man doch deutlich gesehen. Die ganze interne Kommunikation ist doch viel größer. Mit ein paar Daten im Speicher ist es doch nicht getan.
Multi-GPU ist doch trotz doppelter Hardware nicht ohne Grund tot.

[Der_Korken]

Multi-GPU ist imho deswegen tot, weil AFR zu viele Nachteile hat und mit vielen Titeln gar nicht richtig funktioniert. Die von mir beschriebene Lösung soll natürlich so funktionieren, dass beide GPUs zusammen an einem Frame rechnen. Idealerweise kriegt das Game gar nicht mit, dass da zwei GPUs hinterstecken, sondern das wird alles weg abstrahiert.

Die interne Kommunikation kann ich nicht einschätzen. Allerdings ist es im Allgemeinen (nicht nur für MGPU) eine gute Entwicklung, wenn Chips möglichst lokal arbeiten, d.h. Daten über möglichst kurze Distanzen bewegt werden und lokal vorgehalten werden. Ich erinnere mich da an eine Aussage von Nvidia (afaik zu Fermi-Zeiten), dass das größte Problem für GPUs in Zukunft nicht der Energieverbrauch der Recheneinheiten sondern für die Bewegung der Daten ist (d.h. die Daten zur richtigen Zeit am richtigen Ort zu haben). Das wäre also eine Entwicklung, die auch dem MGPU entgegen kommen würde.

Ich will hier keine Navi-MGPU herbeireden, da es dazu keine belastbaren Hinweise gibt. Mir geht es nur um die Machbarkeit und Wirtschaftlichkeit eines solchen Ansatzes für die nächste GPU-Generation.

Edit: Beitrag ergänzt

[N0Thing]

warum? Ryzen ist auch nur 1 Chip.

alte infos:
http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/News/AMD-letzte-grosse-GPU-Navi-1235463/

https://wccftech.com/amd-navi-gpu-launching-siggraph-2018-monolithic-mcm-die-yields-explored/

Ryzen ist aber eine CPU und keine GPU.
Die Geschichte mit den per Infinity Fabric zusammengelegten Chips ist weiterhin nur eine Spekulation, weil man bis heute nicht weiß, was AMD eigentlich genau mit Scalability auf der Roadmap gemeint hat. Ob das bei GPUs für Spieler überhaupt genauso gut funktionieren würde, weiß man außerhalb von AMD nicht. Für General purpose mag das z.B. funktionieren, bei Spielen wo möglichst gleichmäßige Frametimes gewünscht sind, vielleicht nicht.

[Dino-Fossil]

Naja, wenn es sich denn bewahrheitet - ich kaufe eigentlich nur Midrange und bin mit meiner RX 480 zufrieden.
Entsprechend würde ich auch eine ähnlich positionierte Karte auf Basis von Navi kaufen (solange es keine durchgehend besseren Alternativen gibt).

Problematisch ist dabei natürlich, dass AMD damit wiederum die High-End Strahlkraft fehlt, zusammen mit den möglichen Auswirkungen des GPP werden sie dadurch evtl. noch weniger als gangbare Gaming-Alternative wahrgenommen.

Frage ist dann ein Stück weit - machen sie einen auf Zen, konzentrieren sich also auf die neue Architektur und versorgen den Markt bis dahin nur mit dem nötigsten und relativ leicht machbaren (Navi als letzte GCN-Iteration, gefolgt von einer komplett neuen Arch), oder einen auf Polaris->Vega, um im Folgejahr wieder einen High-End-Chip zu bringen.

[N0Thing]

Man hat schon bei Vega mit einem größeren Schritt bei der Architektur gerechnet und jetzt eigentlich auf Navi gehofft, nachdem Vega gegenüber Fiji nur bei der Taktrate deutlich besser abgeschnitten hat.

[HOT]

Hm ein interessantes Gedankenspiel, wenn Navi Polaris (und V10) ersetzen sollte. Damit wäre ein 250mm²-Chip mit 48-64CUs dann Mainstream und darunter kann man noch 2 weitere Chips positionieren, wie bei Polaris. Und in 2020 wird dann mit der neuen Architektur wieder was für High-End bis Enthusiast fällig.

[robbitop]

Die Multi-GPU Spinnerei ist seit R600 wie Scheiße am Schuh. Das Problem dabei ist und bleibt die gigantische Datenmenge im Vergleich zu den Prozessoren. Selbst 2cm Distanz über einen Interposer sind enorm. Für Chips mit der Fläche ist jede Überlegung verschwendete Zeit.


Die Leistung auf Level der 1080 wiederum kommt absolut hin. Seit Polaris zielt AMD auf das Performance-Segment der Konkurrenz... was zu dem Zeitpunkt dann typisches Mainstream ist. Ohne Mining wäre die ganze Strategie aber schon bei Polaris gescheitert. Seit NV das Highend noch mal mit Performance untersetzt hat, ist AMD strategisch eh am Arsch. Mal sehen was sich dann für den Markt ausgedacht haben.


Polaris war vor dem Mining auf Steam gegen die 1060 absolut unterlegen. Durch den Miningboom ist die Karte, wie V10, bei Spielern quasi nicht mehr existent. Das ist keine solide Grundlage sondern Glücksspiel. Aktuell sind es bei Steam noch 10,75%! PS: Die 1060 hat alleine 13,9%. Keine Ahnung welche Erfolge ihr da seht.
Die Frage ist, wie repräsentativ der Steam Survey ist. AFAIK war Polaris auch vor sem Mining Hype sehr gut verkauft worden.

[Ailuros]

Multi-GPU ist imho deswegen tot, weil AFR zu viele Nachteile hat und mit vielen Titeln gar nicht richtig funktioniert. Die von mir beschriebene Lösung soll natürlich so funktionieren, dass beide GPUs zusammen an einem Frame rechnen. Idealerweise kriegt das Game gar nicht mit, dass da zwei GPUs hinterstecken, sondern das wird alles weg abstrahiert.

Aehnliche Diskussionen fuer mGPU hatten wir hier schon etliche Male in der Vergangenheit. Ich bleibe dabei dass IHVs sich schwer von einer reinen software Loesung wie AFR loesen werden so lange mGPU nicht zum Zwang fuer high end HPC cores u.a. wird. Weder SFR (split frame rendering) noch hardware scheduling dafuer ist irgend ein Hexenwerk, wird aber schon ein kleines Prozentual an zusaetlichen Transistoren und demenstrechendem R&D kosten, welches IHVs wohl nicht investieren werden fuer den ziemich winzigen mGPU Anteil des gaming Markts.

Mal anders: seit DX12 koennte theoretisch jeder erfahrene Entwickler bzw. ISV ein jegliches Spiel fuer SFR/mGPU optimiert entwickeln. Warum keiner den Aufwand wagt liegt eben genau beim gleichen Grund wie oben dass der mGPU Anteil des Markts zu winzig ist.

Die interne Kommunikation kann ich nicht einschätzen. Allerdings ist es im Allgemeinen (nicht nur für MGPU) eine gute Entwicklung, wenn Chips möglichst lokal arbeiten, d.h. Daten über möglichst kurze Distanzen bewegt werden und lokal vorgehalten werden. Ich erinnere mich da an eine Aussage von Nvidia (afaik zu Fermi-Zeiten), dass das größte Problem für GPUs in Zukunft nicht der Energieverbrauch der Recheneinheiten sondern für die Bewegung der Daten ist (d.h. die Daten zur richtigen Zeit am richtigen Ort zu haben). Das wäre also eine Entwicklung, die auch dem MGPU entgegen kommen würde.

Daten-Lokalitaet allgemein war schon seit der Geburt von 3D ein ewiger Kopfschmerz.

Ich will hier keine Navi-MGPU herbeireden, da es dazu keine belastbaren Hinweise gibt. Mir geht es nur um die Machbarkeit und Wirtschaftlichkeit eines solchen Ansatzes für die nächste GPU-Generation.

Edit: Beitrag ergänzt

Fuer ATI bzw. AMD war mGPU bzw. AFR nie ein fremdes Feld. Hardware basierendes load balancing fuer mGPU in Navi waere auf jeden Fall eine sehr wuenschenswerte Entwicklung, wenn AMD sich natuerlich etwas mehr aus dem Fenster lehnen kann, denn bei so feister Konkurrenz wie die von NVIDIA ist das Leben eines hw engineers mit der ewigen Transistoren-Erbsen-Zaehlerei wohl alles andere als leicht....

[Grendizer]

Kam Polaris -> Vega wird der Hammer -> kam Vega --> Navi wird der Hammer .... nun ist Navi schon vor erscheinen nicht mehr der Hammer, was bedeutet das dann für zukünftige AMD Performance Diskussionen ?:confused:

[Achill]

Kam Polaris -> Vega wird der Hammer -> kam Vega --> Navi wird der Hammer .... nun ist Navi schon vor erscheinen nicht mehr der Hammer, was bedeutet das dann für zukünftige AMD Performance Diskussionen ?:confused:

Keine überzogenen Erwartungen und damit Entspannung hier im Forum sowie noch ein paar andere Punkte ...

[Botcruscher]

Die Spannende Frage ist eher ob wir HBM oder GDDR6 sehen werden. Zur Architektur selber kann doch keiner was sagen.

[dildo4u]

AMD muss in jedem Fall die Produktionskosten senken also tippe ich auf GDDR6.Es gibt jetzt endlich ein paar 1070 Ti um 500€ aber keine Vega 56.
Die 580 hat ja im Prinzip auch Fury Pro ersetzt wäre also das selbe Szenario.

[horn 12]

Fehlt noch ca. 90 Euro bis zum Preis von 500 Euro für die RX56 Custom Versionen!
Rechne in 7 - 10 Tagen sind wir dort angelangt.

[BoMbY]

Die Spannende Frage ist eher ob wir HBM oder GDDR6 sehen werden. Zur Architektur selber kann doch keiner was sagen.


https://news.samsung.com/global/samsung-now-mass-producing-industrys-first-2nd-generation-10-nanometer-class-dram:


With these advancements, Samsung is now accelerating its plans for much faster introductions of next-generation DRAM chips and systems, including DDR5, HBM3, LPDDR5 and GDDR6, for use in enterprise servers, mobile devices, supercomputers, HPC systems and high-speed graphics cards.



Wäre jedenfalls die Next Generation von HBM2:

https://i.imgur.com/WQnImAlh.jpg

[danarcho]

Navi als letzte GCN-Iteration, gefolgt von einer komplett neuen Arch
Woher kommt dieses Gerücht? Hab ich jetzt in diesem Thread schon mehrfach gelesen, wunder mich nur (und bezweifel es auch).

[Brillus]

Aehnliche Diskussionen fuer mGPU hatten wir hier schon etliche Male in der Vergangenheit. Ich bleibe dabei dass IHVs sich schwer von einer reinen software Loesung wie AFR loesen werden so lange mGPU nicht zum Zwang fuer high end HPC cores u.a. wird. Weder SFR (split frame rendering) noch hardware scheduling dafuer ist irgend ein Hexenwerk, wird aber schon ein kleines Prozentual an zusaetlichen Transistoren und demenstrechendem R&D kosten, welches IHVs wohl nicht investieren werden fuer den ziemich winzigen mGPU Anteil des gaming Markts.

Mal anders: seit DX12 koennte theoretisch jeder erfahrene Entwickler bzw. ISV ein jegliches Spiel fuer SFR/mGPU optimiert entwickeln. Warum keiner den Aufwand wagt liegt eben genau beim gleichen Grund wie oben dass der mGPU Anteil des Markts zu winzig ist.



Daten-Lokalitaet allgemein war schon seit der Geburt von 3D ein ewiger Kopfschmerz.



Fuer ATI bzw. AMD war mGPU bzw. AFR nie ein fremdes Feld. Hardware basierendes load balancing fuer mGPU in Navi waere auf jeden Fall eine sehr wuenschenswerte Entwicklung, wenn AMD sich natuerlich etwas mehr aus dem Fenster lehnen kann, denn bei so feister Konkurrenz wie die von NVIDIA ist das Leben eines hw engineers mit der ewigen Transistoren-Erbsen-Zaehlerei wohl alles andere als leicht....

Wenn es nur ein kleiner Prozentual an Transistoren wäre hätten wir es schon seit Jahren, bessere Yield, weniger unterschiedliche, weniger Plannungprobleme da man sich nach der Chipfertigung überlegen kann was man braucht, kein festes Belichtingslimit. Ne gut skalierende mgpu ist der feuchte Traum von jeden Herstellern.

[MadPenguin]

Ach kommt schon. Wirklich HBM3? HBM ist bis jetzt doch immer nach hinten losgegangen, oder? Leistung, Verfügbarkeit, Preis, Interposer. Hoffe wirklich nicht, dass sie auf dieser Schiene weiterfahren :(

[=Floi=]

Zurückgehen wird AMD so schnell nicht. Den schleppenden start konnte auch keiner vorhersehen. HBM war der nächste schritt.

[RoughNeck]

Fehlt noch ca. 90 Euro bis zum Preis von 500 Euro für die RX56 Custom Versionen!
Rechne in 7 - 10 Tagen sind wir dort angelangt.

Hier geht es um Navi, nicht um Vega und schon gar nicht um Preise von Vega.
Also bitte, schiebs dir sonst wohin. In jeden Thread muss man den Müll von dir lesen, echt grausam.

[HOT]

Woher kommt dieses Gerücht? Hab ich jetzt in diesem Thread schon mehrfach gelesen, wunder mich nur (und bezweifel es auch).

https://wccftech.com/amd-new-major-gpu-architecture-to-succeed-gcn-by-2020-2021/

Irgendwo kam auch der Spruch her, dass der Sprung nach Navi so groß ausfallen soll, wie von Bulldozer zu Zen. Die CPU-Teams sollen ja jetzt auch massiv die GPU-Teams unterstützen um die Fertigungseffizienz zu verbessern und somit höhere Taktraten zu ermöglichen. Es soll viel Zen-Erfahrung auch auf die GPU-Produkte übergehen.

[AffenJack]

Ach kommt schon. Wirklich HBM3? HBM ist bis jetzt doch immer nach hinten losgegangen, oder? Leistung, Verfügbarkeit, Preis, Interposer. Hoffe wirklich nicht, dass sie auf dieser Schiene weiterfahren :(

Glaube ich auch nicht, Navi dürfte mit GDDR6 kommen. Zumindest hoffe ich das AMD damit plant. HBM3 dürfte für Navi wieder zu spät sein. Mit 512 Gb/s bei 256Bit Interface hat man einen Top Midrangechip. Mehr braucht man dafür auch nicht.

[AMDoderNvidia]

Wirklich HBM3? HBM ist bis jetzt doch immer nach hinten losgegangen, oder? Leistung, Verfügbarkeit, Preis, Interposer. Hoffe wirklich nicht, dass sie auf dieser Schiene weiterfahren :(

Und weil es in der Vergangenheit Probleme gab, gibt es auch in Zukunft Probleme und es ändert sich nix? Nach dem Motto: Gestern hats geregnet, warum sollte dann morgen die Sonne scheinen? :biggrin: Das scheint mir hier ein typisches Psychologie-Phänomen zu sein - die Gegenwart wird einfach in die Zukunft projiziert.

AMD war mit HBM einfach sehr, sehr früh dran. AMD hatte während der Entwicklung von Fiji gar nur einen Partner zur Produktion von HBM-Chips und dort auch ein exklusives Vorkaufsrecht. Inzwischen ist die Situation jedoch anders bzw. wird anders. Problematisch ist doch derzeit, dass die Fabs einfach alle ausgelastet sind und eine Verknappung für NANDs, RAMs, HBMs usw. besteht (die Nennung der verschiedenen Typen war jetzt etwas salopp, sorry).

[MadPenguin]

Und weil es in der Vergangenheit Probleme gab, gibt es auch in Zukunft Probleme und es ändert sich nix? Nach dem Motto: Gestern hats geregnet, warum sollte dann morgen die Sonne scheinen? :biggrin: Das scheint mir hier ein typisches Psychologie-Phänomen zu sein - die Gegenwart wird einfach in die Zukunft projiziert.

AMD war mit HBM einfach sehr, sehr früh dran. AMD hatte während der Entwicklung von Fiji gar nur einen Partner zur Produktion von HBM-Chips und dort auch ein exklusives Vorkaufsrecht. Inzwischen ist die Situation jedoch anders bzw. wird anders. Problematisch ist doch derzeit, dass die Fabs einfach alle ausgelastet sind und eine Verknappung für NANDs, RAMs, HBMs usw. besteht (die Nennung der verschiedenen Typen war jetzt etwas salopp, sorry).

Naja, wir haben 2 HBM Generationen hinter uns, mit genau denselben Problemen bei beiden. Deshalb gehe ich eher davon aus, dass auch HBM3 davon betroffen sein wird. :D Lass mich gerne eines Besseren belehren.

[HOT]

Wenn Navi wieder nur bis upper-Mainstream hochreicht, dann bekommt er GDDR, das sollte glasklar sein.
Für Mobile kann man dann zusätzlich sowas wie Polaris 22 basteln.

Ich tippe mal auf folgendes:

2018
V10
P10
P11
P12

2019
V20
N10
N11
P11
P12

2020
ng10
V20
N10
N11
N12

Das ist also so ne Art Tick-Tock

Neue Fertigung + Mainsteam -> Tick
Neue µArchitektur + HighEnd -> Tock

Nach den neuesten Infos könnte N10 ein 44-CU-Chip mit >200mm² und 256Bit GDDR6-Speicher sein. Das würde mMn auch gut zusammenpassen. Dann würde man statt V10 dann V20 im höhergelegenen Markt erhalten, V10 wird damit ja obsolet, da Navi sicherlich V10-Leistung durchaus erreichen wird. V20 dürfte ja schon >25% mehr Power bringen als V10, erst recht, wenn 3 oder 4 Stapel verbaut werden. 7nm wird nicht nur spürbar mehr Takt erlauben bei normalen FP32-Workloads sondern man dürfte auch noch den ein oder anderen Engpass in der Profivariante aufbohren.

P11 und P12 könnten uns auch noch deutlich länger erhalten bleiben, so wie Oland+CapVerde damals.

GCN wird 2020, wenn die neue µArchitektur kommt, mehr als 8 Jahre auf dem Markt sein. Nur mal so als Gedankenspiel für die post-GCN-Zweifler. K8 war ebenfalls 8 Jahre auf dem Markt (mit Llano fast 9), VLIW war nur 5 Jahre aktiv.

[danarcho]

Das kann man nicht mit CPUs vergleichen. Die benutzen nämlich die ganze Zeit das gleiche Instruction Set. Nvidia hat seit Fermi den Grundaufbau nicht geändert. Warum soll AMD das also zum zweiten Mal in dieser Zeit machen? Und wohin überhaupt? Wieder VLIW? Andere Wavefront-Size?
Also gespannt bin ich schon, ich sag nur not gonna happen.
Was ich mir vorstellen könnte, wäre sowas wie ein Umstieg auf 8er SIMDs mit Veränderung der Pipeline (man hätte ja dann 8 Takte Zeit, könnte also versuchen auf 2,5Ghz+ oder so zu kommen). Auch könnte man die Anzahl der Wavefronts/CU usw. anpassen ohne die ISA überhaupt anzufassen. Ob man das dann neue "Macro-Architecture" (wccftech) nennt oder GCNX 2020 Reboot Next :freak:, es wäre zu dem Schritt Terascale->GCN niemals vergleichbar.

[Dino-Fossil]

Neue Architektur muss ja nicht bedeuten, dass man alle GCN-Konzepte begräbt.
Aber immerhin könnten die Umwälzungen gravierend genug sein, dass man sie mit einer gewissen Berechtigung eben nicht mehr länger als GCN bezeichnet.
Aktuell scheint es ja in der Tat ein paar Probleme in der Architektur zu geben, die einer weiteren Skalierung hin zu schnelleren Chips im Wege stehen.
Auch mit dem Takt alleine kann man da nicht lange arbeiten, irgendwann müssen größere Chips her, die trotzdem effizient skalieren.

[Grendizer]

Könnte es auch einfach sein, das es im Moment ein personellen Engpass bei AMD gibt, da es vieleicht doch viel Fluktuation durch Rajas Weggang gegeben hat ? Und man deshalb die Ziele anpassen mußte.

[AMDoderNvidia]

Ich glaube nicht, dass mit Navi eine komplett neue Architektur kommt. Die Grundzüge von GCN werden erhalten bleiben.

Der Sprung von Terrascale auf GCN war ja bekanntlich darin begründet, dass AMD besser die Verarbeitung von General Purpose Aufgaben ermöglichen wollte, wie es Nvidia seit Fermi kann. Terrascale war gut für Grafikverarbeitung ausgelegt mit der VLIW4/5-basierten Architektur, aber eben nicht für General Purpose.

Das Highlight von Navi, wie es von AMD bereits vor Jahren gezeigt wurde, ist die Scalability - was auch immer das heißt und an welcher Stelle auch immer man die Scalability erreichen möchte. Wäre schon klasse, wenn man das innerhalb des Chips machen könnte wie bei AMDs Zen, sodass man auch BigChips wie den Threadripper einfach aus kleineren Chips zusammenbauen kann.

[HOT]

Es ging nie darum, dass Navi ne komplett neue Architektur ist.


Das kann man nicht mit CPUs vergleichen. Die benutzen nämlich die ganze Zeit das gleiche Instruction Set. Nvidia hat seit Fermi den Grundaufbau nicht geändert. Warum soll AMD das also zum zweiten Mal in dieser Zeit machen? Und wohin überhaupt? Wieder VLIW? Andere Wavefront-Size?
Also gespannt bin ich schon, ich sag nur not gonna happen.
Was ich mir vorstellen könnte, wäre sowas wie ein Umstieg auf 8er SIMDs mit Veränderung der Pipeline (man hätte ja dann 8 Takte Zeit, könnte also versuchen auf 2,5Ghz+ oder so zu kommen). Auch könnte man die Anzahl der Wavefronts/CU usw. anpassen ohne die ISA überhaupt anzufassen. Ob man das dann neue "Macro-Architecture" (wccftech) nennt oder GCNX 2020 Reboot Next :freak:, es wäre zu dem Schritt Terascale->GCN niemals vergleichbar.


Es ist furzegal ob eine GPU oder CPU-Architektur so lange auf dem Markt ist, irgendwann ist einfach was Neues fällig und nein, Maxwell hat nicht mehr viel mit Fermi gemein, das ist Unsinn. Nach 8 Jahren ist eine Komplettrenovierung mehr als nur wahrscheinlich.

[BoMbY]

Ich könnte mir vorstellen woher diese Gerüchte kommen, mit nur Mainstream blabla.

Wenn AMD wirklich endlich auf das Chiplet-Verfahren setzt, und ähnlich wie bei Summit Ridge MCM-Module auf Interposer oder ähnlichem baut, dann könnte es gut sein, dass ein Navi10 z.B. nur 32 CUs und einen HBM-Kanal hat, mit welchem man dann z.B. folgende Optionen hätte:

1x Navi10 (32 CU) + 1x HBM3 (512 GB/s)
2x Navi10 (64 CUs) + 2x HBM3 (1024 GB/s)
3x Navi10 (96 CUs) + 3x HBM (1536 GB/s)
4x Navi10 (128 CUs) + 4x HBM3 (2048 GB/s)

Oder auch als APU:

1x Matisse (Zen2) + 1x Navi10 (32 CUs) + 1x HBM3 (512 GB/s)

Und natürlich sehen die Leute davon erstmal die simple Variante, oder in den Fabs sieht man nur einen Mini-Chip.

[N0Thing]

Neue Architektur muss ja nicht bedeuten, dass man alle GCN-Konzepte begräbt.
Aber immerhin könnten die Umwälzungen gravierend genug sein, dass man sie mit einer gewissen Berechtigung eben nicht mehr länger als GCN bezeichnet.
Aktuell scheint es ja in der Tat ein paar Probleme in der Architektur zu geben, die einer weiteren Skalierung hin zu schnelleren Chips im Wege stehen.
Auch mit dem Takt alleine kann man da nicht lange arbeiten, irgendwann müssen größere Chips her, die trotzdem effizient skalieren.

Deshalb erwarte ich mit Navi auch schon einen größeren Schritt und nicht erst mit der Generation danach. Vega ist von der Anzahl der Ausführungseinheiten auf dem Niveau von Fiji. Von daher würde ich von Navi im Hinblick auf scalability erwarten, dass man mehr Recheneinheiten ohne Flaschenhals ans laufen bekommt. Und auf der anderen Seite ganz wichtig die Effizienz. Es bringt nichts, wenn der Chip 1,8GHz schaffen kann, aber die Leistungsaufnahme dann bei 400W liegt.
Wenn AMD an diesen Stellschrauben für Navi nicht drehen kann, dann könnte Nvidia vermutlich für ein Jahr Betriebsurlaub machen, was ich nicht hoffe.

[cat]

Das Mindeste was an Inter-Die Bandbreite erforderlich ist:

1.
Um kein Stuttering zu bekommen muss in nur einen Framebuffer gerendert werden,
das kann z.B. im L2-Cache sein.
Von der R9 290X hat AMD in Folien 1TB/s L2-BW bestätigt,
geht man davon aus, dass dies mit dem Chiptakt 1:1 ansteigt,
endet man bei 1,6 GHz ca. bei (4,5 TB/s). ** hab mich vertippt, bei 1050MHz einer 290X kämen natürlich mit 1600MHz ca. 1,5 TB/s **

2.
Global Data-Share, das sind nur 64KB aber es muss 1:1 gesynct sein denke ich.

3.
Frontend und die gesammte Kontrolle und das Ballancing.

Ich halte das für machbar, die InfinityFabric macht aktuell im Threadripper 102 GB/s Inter-Die BW bidirektional.

Evtl. käm man mit dem 8-fachen aus, was nicht gänzlich in mehr Leiterbahnen enden muss,
es könnte auch der Takt der Fabric von 1/2 Memory-Speed auf z.B. Quad-Speed gesetzt werden.
Würden dazu die selbe Menge an Bahnen wie im Epic genutzt wäre man nahe an 1,6 TB/s.

Ich denke nicht dass es 100% utopisch ist.

[Hübie]

Ich könnte mir vorstellen woher diese Gerüchte kommen, mit nur Mainstream blabla.

Wenn AMD wirklich endlich auf das Chiplet-Verfahren setzt, und ähnlich wie bei Summit Ridge MCM-Module auf Interposer oder ähnlichem baut, dann könnte es gut sein, dass ein Navi10 z.B. nur 32 CUs und einen HBM-Kanal hat, mit welchem man dann z.B. folgende Optionen hätte:

1x Navi10 (32 CU) + 1x HBM3 (512 GB/s)
2x Navi10 (64 CUs) + 2x HBM3 (1024 GB/s)
3x Navi10 (96 CUs) + 3x HBM (1536 GB/s)
4x Navi10 (128 CUs) + 4x HBM3 (2048 GB/s)

Oder auch als APU:

1x Matisse (Zen2) + 1x Navi10 (32 CUs) + 1x HBM3 (512 GB/s)

Und natürlich sehen die Leute davon erstmal die simple Variante, oder in den Fabs sieht man nur einen Mini-Chip.

Im Kontext der Folie wo man die Skalierbarkeit heraushebt würde diese Variante logisch betrachtet am meisten Sinn ergeben. Kein Sinn ergibt es, dass man das highend-Segment unbespielt lässt.

[Der_Korken]

Das Mindeste was an Inter-Die Bandbreite erforderlich ist:

1.
Um kein Stuttering zu bekommen muss in nur einen Framebuffer gerendert werden,
das kann z.B. im L2-Cache sein.
Von der R9 290X hat AMD in Folien 1TB/s L2-BW bestätigt,
geht man davon aus, dass dies mit dem Chiptakt 1:1 ansteigt,
endet man bei 1,6 GHz ca. bei 4,5 TB/s.

2.
Global Data-Share, das sind nur 64KB aber es muss 1:1 gesynct sein denke ich.

Wie kommen die 4,5TB/s beim L2-Cache zustande? Die 290X hatte ~950Mhz, was auf 1,6Ghz hochgerechnet 1,67TB/s entspräche. Wenn man jetzt noch 1:1 mit SPs skaliert und 64 statt 44 CUs annimmt, wären es knapp 2,5TB/s. Trotzdem extrem viel. Aber braucht der Framebuffer allein wirklich so viel und greift jede CU ständig auf jeden Teil davon zu? Ich frage deshalb, weil bei den CPUs der getrennte L3-Cache und auch mehrere Dies relativ gut funktionieren und ich hätte mit meinem Halbwissen erwartet, dass CPUs beim Thema Latenzen und Synchronisation um Größenordnungen kritischer sind als GPUs.

[LadyWhirlwind]

Im Kontext der Folie wo man die Skalierbarkeit heraushebt würde diese Variante logisch betrachtet am meisten Sinn ergeben. Kein Sinn ergibt es, dass man das highend-Segment unbespielt lässt.

Naja grosse Chips sind teuer und möglicherweise ist es für AMD nicht wirtschaftlich gleich zu beginn der 7nm Produktion grosse Chips zu bringen.

[Ailuros]

Wenn es nur ein kleiner Prozentual an Transistoren wäre hätten wir es schon seit Jahren, bessere Yield, weniger unterschiedliche, weniger Plannungprobleme da man sich nach der Chipfertigung überlegen kann was man braucht, kein festes Belichtingslimit. Ne gut skalierende mgpu ist der feuchte Traum von jeden Herstellern.

Was fuer ein Prozentual an die Flaeche wuerdest Du schaetzen nimmt heute das load balancing zwischen clusters auf einem einzigen chip ein? Mehr oder weniger als die rasterizers selber?


Naja grosse Chips sind teuer und möglicherweise ist es für AMD nicht wirtschaftlich gleich zu beginn der 7nm Produktion grosse Chips zu bringen.

Mit den nochmal um einiges hoeheren Herstellungskosten fuer 7nm werden fuer niemand sehr grosse dies anfangs wirtschaftlich sein ausser man ist NV und verkauft diese mit bei verrueckt hohen Preisen in Profi-Maerkten.

[gravitationsfeld]

Könnte es auch einfach sein, das es im Moment ein personellen Engpass bei AMD gibt, da es vieleicht doch viel Fluktuation durch Rajas Weggang gegeben hat ? Und man deshalb die Ziele anpassen mußte.
Dir ist schon klar, dass Chips die in naher Zukunft erscheinen vor ueber drei Jahren in Planung waren? Rajas Weggang hat praktisch fast keinen Effekt auf Navi.

[Botcruscher]

Wäre jedenfalls die Next Generation von HBM2:

GDDR6 ist auch Next Gen Memory.

[fondness]

Die offizielle Roadmap Folie ist schon relativ alt und seitdem nie mehr gezeigt oder aktualisiert worden. Darauf würde ich ohnehin nicht zu viel geben. Da kann sich vieles längst geändert haben.

Das Mindeste was an Inter-Die Bandbreite erforderlich ist:

1.
Um kein Stuttering zu bekommen muss in nur einen Framebuffer gerendert werden,
das kann z.B. im L2-Cache sein.
Von der R9 290X hat AMD in Folien 1TB/s L2-BW bestätigt,
geht man davon aus, dass dies mit dem Chiptakt 1:1 ansteigt,
endet man bei 1,6 GHz ca. bei 4,5 TB/s.

2.
Global Data-Share, das sind nur 64KB aber es muss 1:1 gesynct sein denke ich.

3.
Frontend und die gesammte Kontrolle und das Ballancing.

Ich halte das für machbar, die InfinityFabric macht aktuell im Threadripper 102 GB/s Inter-Die BW bidirektional.

Evtl. käm man mit dem 8-fachen aus, was nicht gänzlich in mehr Leiterbahnen enden muss,
es könnte auch der Takt der Fabric von 1/2 Memory-Speed auf z.B. Quad-Speed gesetzt werden.
Würden dazu die selbe Menge an Bahnen wie im Epic genutzt wäre man nahe an 1,6 TB/s.

Ich denke nicht dass es 100% utopisch ist.

Ich denke, dass es zu viel Strom brauchen würde und sich AMD wie von robbitop spekuliert auf die Chip-interne Skalierung bezog.

[vinacis_vivids]

GDDR6 ist auch Next Gen Memory.

:rolleyes:

[Botcruscher]

Denk lieber bis drei, so wie der BWLer der die Folie für Aktionäre gemacht hat. Die Frage nach dem "Next Gen Memory" hab ich im Vega thread schon bei Erscheinen gestellt. Wenn es HBM3 wäre, würde HBM3 dort stehen.

[BoMbY]

HBM3 war da IMHO noch nicht spezifiziert. Vom zeitlichen Ablauf sollte HBM3 jedenfalls möglich sein. Würde vermutlich reichen wenn Samsung im Dezember mit der Massenproduktion startet - vor Q2/2019 sehe ich jedenfalls bisher keine Navi-Karte von AMD.

[basix]

Das Mindeste was an Inter-Die Bandbreite erforderlich ist:

.....

SFR geht auch via PCIe, wenn man es richtig macht. Und das sind magere 15 GB/s. Siehe z.B. Civilization 6: https://www.extremetech.com/gaming/192906-investigating-amd-mantles-superb-multi-gpu-scaling-in-civilization-beyond-earth

Klar, dort sind es "nur" ca. +50% Skalierung, aber 100% Skalierung braucht man nicht zwingend. Für einen Multi Chip Ansatz reicht wahrscheinlich 90-95%, solange die Anzahl Chips nicht zu hoch wird. Mit 4 Chips und 90% käme man ca. auf Faktor 3x Skalierung, was sicher schon ordentlich wäre. Mit 95% auf 3.5x oder gar mehr. Bei Chips wo 512 GB/s Speicherbandbreite haben, reicht evtl. ein Viertel zwischen den Chips aus. Das wäre Rohleistungsnormiert auf eine 290X (Civ 6) fast die 10-fache Bandbreite von Chip zu Chip. Das ergäbe bei einem Aufbau nach Epyc Art (oder auch Zen CCX) total 768 GB/s (6 Links) und wäre aus Socket Sicht total etwa das 3-4 fache vom heutigen EPYC. Jeder Navi Chip hat seinen eigenen HBM und Interposer. Das macht die ganze Fertigung des Chips + HBM für alle Segmente einsetzbar. Der Rest wird wie bei Epyc über das Substrat verbunden. Für mich nicht unrealistisch. Ein solches Navi + HBM Modul könnte man dann auch z.B. mit Zen koppeln.

[Digidi]

interessant ist Vegas Design. Da läuft mittlerweile alles über L2 Cache. Das könnte ein Hinweis sein.

Könnte mir vorstellen das man einen Frotend Chip, einen Shader Chip, einen Backend-Chip und einen L2 Cache Chip auflegt und dann über den L2 alles Verbindet. Man kann dann auch ganz gut skalieren.

[gravitationsfeld]

Uebrigens laeuft bei NVIDIA schon seit mindestens Fermi alles durch den L2. Bei AMD wird das in Salami-Taktik seit Jahren in die Richtung umgebaut.

[AMDoderNvidia]

Könnte mir vorstellen das man einen Frotend Chip, einen Shader Chip, einen Backend-Chip und einen L2 Cache Chip auflegt und dann über den L2 alles Verbindet. Man kann dann auch ganz gut skalieren.

Genau, und dann noch einen Rasterizer-Chip und einen Tessellation-Chip :freak:

So langsam denke ich auch, dass die Scalability im Zusammenhang mit Navi darauf bezogen ist, dass man GCN innerhalb des Chips skaliert (und eben kein MCM Design implementiert).

[AffenJack]

interessant ist Vegas Design. Da läuft mittlerweile alles über L2 Cache. Das könnte ein Hinweis sein.

Könnte mir vorstellen das man einen Frotend Chip, einen Shader Chip, einen Backend-Chip und einen L2 Cache Chip auflegt und dann über den L2 alles Verbindet. Man kann dann auch ganz gut skalieren.

Das würde dann eher zu einem 300W Chip führen, der selbst bei 7nm eher mit Polaris kämpfen muss. Off-Die Bandbreite ist das tötlichste was es gibt in Sachen Verbrauch und du willst sonstwieviele Daten hin und her verschieben. Nein, das wird nie jemand machen.

[BoMbY]

Man könnte natürlich auch einfach alle Komponenten mit einem skalierbaren Netzwerk (https://patents.google.com/patent/US20170295111A1/) verbinden.

[AMDoderNvidia]

Off-Die Bandbreite ist das tötlichste was es gibt in Sachen Verbrauch

Hat man beim Hawaii-Chip nicht gerade deshalb ein 512-bit Speicherinterface verbaut, um günstigen VRAM (also niedrig getakteten) anzubinden und trotzdem einen hohen Durchsatz zu haben?

Wenn ich Dich nun richtig verstehe, dann ist der "Preis" Deiner Aussage zufolge eine deutliche Steigerung der Leistungsaufnahme?

[gravitationsfeld]

Man könnte natürlich auch einfach alle Komponenten mit einem skalierbaren Netzwerk (https://patents.google.com/patent/US20170295111A1/) verbinden.
"einfach"

[Botcruscher]

HBM3 war da IMHO noch nicht spezifiziert. Vom zeitlichen Ablauf sollte HBM3 jedenfalls möglich sein. Würde vermutlich reichen wenn Samsung im Dezember mit der Massenproduktion startet - vor Q2/2019 sehe ich jedenfalls bisher keine Navi-Karte von AMD.

Dann würde da trotzdem Next Gen HBM stehen.

"einfach"
Da stellt sich mir die Frage wie schnell die L1 und der L2 überhaupt bei Vega angebunden sind.

[AffenJack]

Hat man beim Hawaii-Chip nicht gerade deshalb ein 512-bit Speicherinterface verbaut, um günstigen VRAM (also niedrig getakteten) anzubinden und trotzdem einen hohen Durchsatz zu haben?

Wenn ich Dich nun richtig verstehe, dann ist der "Preis" Deiner Aussage zufolge eine deutliche Steigerung der Leistungsaufnahme?

Mit Ram hat das nix zutun. Digidi hat vorgeschlagen verschiedene Teile des Chips als einzelne Dies zu fertigen. Somit würden alle Daten z.B. zuerst zum L2, dann wieder über den Interposer zum Frontend, vom Frontend über den Interposer zurück usw. Innerhalb eines Chips Daten zu bewegen ist aber energetisch deutlich effizienter, als diesen zu verlassen und du brauchst ja massive Bandbreiten zwischen L2 und Shader usw. Die Chipinternen Bandbreiten dürften auch deutlich höher sein, als die nach außen zum Ram.

[AMDoderNvidia]

@AffenJack: Der Vergleich mit dem RAM war nur ein Beispiel, um zu zeigen, wie sich Off-Die Zugriffe ungünstig auf die Leistungsaufnahme auswirken können. Bekanntlich ist ja Hawaii ein ziemlicher Hitzkopf (zumindest solange man ihn nicht unter Wasser setzt).

Dass die Bandbreite ab- und die Latenz zunimmt, ich denke, das sollte soweit jedem bekannt sein: Register > L1-Cache > L2-Cache > VRAM > PCIe > DRAM

[OBrian]

ja, aber das ist off-die im Sinne von durchs Package, einen gefühlt halben Kilometer außen rum über die Platine, durchs Speicherpackage, bis man dann irgendwann in der RAM-Zelle angelangt ist. Aber Interposer sind ja Dies, deswegen sind ja auch HBMs so viel günstiger als normaler RAM.

Natürlich wäre ein monolithischer Die noch besser, aber man wird abwägen, ab welcher Größe sich das lohnt bzw, nicht mehr. Ein Chip in Größe von z.B. Polaris 10/20 ist sicher gut machbar, aber fettere Chips leiden dann so an Ausbeuteproblemen, geringen Stückzahlen im Umsatz usw., dass es sinnvoll sein kann, einen großen durch zwei kleine zu ersetzen.

Und man könnte sicher auch einfach vier Chips verbauen, damit viel zu viele Einheiten, aber die dann niedrig takten und effizient betreiben. Siehe Epyc, wo vier Chips drin sind, die aber alle auf niedrigem Takt laufen, oft stark teildeaktiviert sind, trotzdem lohnt sich das, weil es die 0815-Dies aus dem Mainstream sind.

Jetzt nimm mal statt einem riesigen 4096-Shader-Chip, der (um einen bestimmten Nvidia-Chip zu erreichen) auch noch auf Takt geprügelt werden muss und damit entsprechend Strom säuft, vier von z.B. den 1536-Shader-Chips, die auf der Intel-APU sind und bau die zusammen. Ja, die Interconnects machen die Sache etwas ineffizienter als einen großen Chip, aber erstens skaliert der große Chip auch mies (irgendwie hatte GCN ja immer Skalierungsprobs), und zweitens kann man die 6144 Shader dann entsprechend niedriger takten, um auf die gleiche Performance zu kommen. Wird ein fettes Package mit acht Dies, aber Gesamtherstellungskosten könnten sogar niedriger sein, und die Energieeffizienz ist sicher nicht schlechter. Und das fette Package hilft sogar bei der Kühlung, alles ist besser verteilt.

Das Problem ist "nur" die Synchronisierung, wenn ich vier Chips an einem Frame rendern lasse, und die auch noch alle einen unterschiedlichen Takt haben.

[Brillus]

Was fuer ein Prozentual an die Flaeche wuerdest Du schaetzen nimmt heute das load balancing zwischen clusters auf einem einzigen chip ein? Mehr oder weniger als die rasterizers selber?




Ich gehe eher davon aus das Problem liegt an der benötigen Bandbreite zwischen den Chips.

[AMDoderNvidia]

Ja, die Interconnects machen die Sache etwas ineffizienter als einen großen Chip, aber erstens skaliert der große Chip auch mies (irgendwie hatte GCN ja immer Skalierungsprobs), und zweitens kann man die 6144 Shader dann entsprechend niedriger takten, um auf die gleiche Performance zu kommen.

In so einem Design könnte man auch verschiedene Taktdomänen fahren. Die eigentlich Shader, die mit ihrer schieren Anzahl glänzen, takten wie von Dir erwähnt eher gemächlich und der vor ein paar Posts hier erwähnte Rasterizer, der ja oftmals ein Problem* war/sein könnte, taktet deutlich höher.

* Anmerkung: Keine Ahnung, ob Nvidia einfach mehr Polygone pro Takt rastern kann als AMD seit Einführung von Maxwell oder ob es doch an effizientem (frühen!) Culling von Objekten liegt - oder einfach beidem.

[Digidi]

Das würde dann eher zu einem 300W Chip führen, der selbst bei 7nm eher mit Polaris kämpfen muss. Off-Die Bandbreite ist das tötlichste was es gibt in Sachen Verbrauch und du willst sonstwieviele Daten hin und her verschieben. Nein, das wird nie jemand machen.

Milerweile kann man ja Bandbreite durch Kompression sparen. Es kann auch irgendwo Mal der Einwand warum man im Frontend die Daten nicht kompremiert, es sind noch so viele Möglichkeiten offen. Außerdem läuft Multi GPU doch schon jetzt fast Stotterfrei mit dem richtigen Verfahren und das bei relativ kleinen Bandbreiten. Außerdem wäre man bei einem Interposer nicht direkt offchip da dürften sich Höhe Bandbreiten Recht günstig halten lassen.



* Anmerkung: Keine Ahnung, ob Nvidia einfach mehr Polygone pro Takt rastern kann als AMD seit Einführung von Maxwell oder ob es doch an effizientem (frühen!) Culling von Objekten liegt - oder einfach beidem.
Wenn man den Tests aus der Beyond3d Suite bei pcgh vertrauen kann sind beide Rasterizer fast Ebenbürtig bis auf 100% Füllung da will ja AMD mit Primitive Shaders noch nachlegen. Man kann aber auch bei AMD per Prigrammierung über Shader noch zusätzlich Cullen (kommt im Beyond3d Test halt nicht vor). Da die Programmierer aber oft auf Nvidia setzen wird der Rasterizer von AMD schlecht gefüttert.
http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Tests/Benchmark-Preis-Release-1235445/3/

[Grendizer]

Wenn man den Tests aus der Beyond3d Suite bei pcgh vertrauen kann sind beide Rasterizer fast Ebenbürtig bis auf 100% Füllung da will ja AMD mit Primitive Shaders noch nachlegen. Man kann aber auch bei AMD per Prigrammierung über Shader noch zusätzlich Cullen (kommt im Beyond3d Test halt nicht vor). Da die Programmierer aber oft auf Nvidia setzen wird der Rasterizer von AMD schlecht gefüttert.

Glaubt echt noch jemand an die Macht des "Primitive Shaders" ? Das Ding ist doch tot.

[vinacis_vivids]

Primitive Shaders kommen erst unter LL-API richtig zum Vorschein.

[Grendizer]

Primitive Shaders kommen erst unter LL-API richtig zum Vorschein.

Laber doch kein Mist ....es gibt auch im LL keine API dafür.

Seit Ende Januar 2018 ist ja erst bekannt, das es keine implizite Untersützung durch den AMD Treiber geben wird (wie es vorher immer angenommen wurde) sondern, das eine explizite durch den Entwickler selber per API progammierte Unterstützung notwendig ist. Die API gibt es aber Stand 14.4.2018 nach nunmehr 8,5 Monate nach Vega Release noch nicht.

[5CH4CHT3L]

Bis jetzt wird sich kein Entwicklerteam die Arbeit machen und für unter 0,5% der Nutzer (Steam Hardwareumfrage) extra Optimierungen durchführen.
Wenn Navi Polaris ersetzt könnte man sich dies allterdings vorstellen, da man mit Navi einiges an neuen GPUs verkaufen kann und so Marktanteil holt.

[gravitationsfeld]

Bis jetzt kann sich kein Entwickler die Arbeit machen. Es gibt keine API.

[Grendizer]

Bis jetzt kann sich kein Entwickler die Arbeit machen. Es gibt keine API.


Es gab ja auch mal Stimmen, die meinten, das für so eine API Änderungen in Vulkan und DX12 selber notwendig wären und es deshalb noch Jahre dauern kann.

[LadyWhirlwind]

Laber doch kein Mist ....es gibt auch im LL keine API dafür.

Seit Ende Januar 2018 ist ja erst bekannt, das es keine implizite Untersützung durch den AMD Treiber geben wird (wie es vorher immer angenommen wurde) sondern, das eine explizite durch den Entwickler selber per API progammierte Unterstützung notwendig ist. Die API gibt es aber Stand 14.4.2018 nach nunmehr 8,5 Monate nach Vega Release noch nicht.

Ich denke AMD entwickelt die Chips auch auf hinblick auf die NextGen-Konsolen. Da ist es denn auch nicht so wichtig, wenn ein Feature erstmal brach liegt.

[Grendizer]

Ich denke AMD entwickelt die Chips auch auf hinblick auf die NextGen-Konsolen. Da ist es denn auch nicht so wichtig, wenn ein Feature erstmal brach liegt.

Echt jetzt ... und wie erklärt man dann jemanden, der 399-599 Euro für eine Vega für den PC hingelegt hat ? Der Primitive Shader ist schon prominent als Performance Vegafeature hingestellt worden. ist natürlich klasse, wenn dann erst zum Navi Release die APIs bereitstehen um den tatsächlich nutzen zu können.

[maguumo]

Was soll man dem erklären? Hardware kaufe ich nach Performance und Features mit denen ich tatsächlich was anfangen kann. Kann dem Käufer doch egal sein ob da irgendwas brach liegt.

[OBrian]

Das ist doch oft so, dass Sachen erstmal lange brach liegen. Wer hat sich denn CPUs mit 64 bit (Athlon 64 3200+) gekauft und konnte gleich aus der 64bit-Fähigkeit Nutzen ziehen? Selbst die mit der ISA ermöglichte größere Speichermenge war doch jahrelang unwichtig. Jetzt 15 Jahre später sind die CPUs von damals alle alt und gammelig, aber so richtig brauchen wir 64bit immer noch nicht, es ist ganz nett, wenn man es nutzen kann. Bei Grafikkarten ist fast alles in der ersten Generation unnütz, schlicht weil es noch keine Spiele gibt, die das nutzen (abgesehen von einer halben Handvoll Alibititeln)

[gravitationsfeld]

:confused:? Wir brauchen 64 bit nicht? Wat? Die heutigen Spiele verwenden *alle* gut ueber 3GB virtuellen Addressraum. Und nein, das ist nicht die Speichermenge im Task-Manager.

Hier mal FFXV (ohne Grund, hatte ich nur gerade offen):
https://i.imgur.com/6SwAKgt.png

66GB virtueller Addressraum. Und selbst der physikalisch belegte RAM sprengt was man auf einem 32-Bit-System allozieren kann.

Nene, der Zug ob wir 64 bit "brauchen" ist schon vor ~5 Jahren abgefahren.

[HOT]

Seit PS4 und XB1 ist 32Bit tot im PC-Markt. Das ist 2013 einfach gestorben. Davor waren 100% der Spiele 32Bit, weil die alten Konsolen nur 32Bit waren, danach waren 95% der Spiele nur noch 64Bit (von ein paar Indies und Paradox-Titeln mal abgesehen). Davor brauchte man nur für Foto und Videobearbeitung und vllt. für kranke Excel-Tabellen 64Bit. Für Spiele war 64Bit fast 10 Jahre nicht relevant und dann kam der Knall.

[gravitationsfeld]

Ja, wobei die letzte Konsolen-Generation in HW schon auch 64-Bit konnte, es aber nicht benutzt wurde wegen dem bisschen höheren Speicherverbrauch. Bei ~200MB RAM auf der PS3 war jedes Byte ein Problem.

Am PC wurde es eigentlich auch davor schon ziemlich eng, aber es war halt weniger Arbeit damit zu leben.

Anyway, Navi.

[Ailuros]

Ich gehe eher davon aus das Problem liegt an der benötigen Bandbreite zwischen den Chips.

Wenn dedizierte hw die Anteile an Aufgaben gleichmaessig verteilt (und gleichzeitig alle Einheiten bzw. resources so gut wie moeglich auslastet) soll wo genau das Problem bei der Bandbreite liegen? In solch einem Fall wird ein frame zwischen den GPUs ebenbuertig aufgeteilt und jeder einzelne chip bearbeitet seinen Anteil fuer den spezifischen frame. Benutzt man jetzt einen weiteren kleinen quasi Bruecken-chip oder integriert das hw scheduling in einem chip als quasi "master" wobei der zweite dann als quasi "slave" fungiert sind Einzelheiten wie man es wirtschaftlicher realisieren will.

Ich weiss zwar nicht was AMD mit der Skalierung in der Navi Folie meinte, aber eine hw basierende skalierbare Loesung fuer mGPU und dass dann eher fuer Profi-Maerkte wuer mich nicht ueberraschen. Denn einen 815mm2 grossen GV100 dedizierten mords-chip kann ich mir von AMD schwer bis gar nicht vorstellen. Moeglich aus technischer Perspektive schon, aber gute Nacht die Kosten dafuer wieder reinzuholen.

[gravitationsfeld]

Leider wohl nicht so einfach. Es gibt einige Rechenschritte, vor allem im Post-Process, die einen Bildausschnitt lesen, der groesser ist als ein Pixel, also braucht man Daten von der anderen "Haelfte". Dazu kommt, dass Barriers beide Chips leeren muessen und dann hat man zusaetzliche Warte-Zeit um das zu zwischen den Chips zu kommunizieren. Es ist auch nicht garantiert, dass beide Bild-Haelften die gleichen Rechenzeit brauchen, was man nicht vorhersehen kann - es ist also sehr einfach einen der beiden Chips nicht auszulasten.

Was du beschreibst wuerde heute auch schon ueber PCIe gehen. Vulkan KHR_device_group unterstuetzt es sogar explizit.

Wenn man das bauen will, und es effizient sein soll, braucht man schon eine feiner Aufteilung des Bildes. Aber selbst dann bleibt die Latenz ein Problem. On-Chip-Kommunikation ist viel schneller als ueber einen PHY mit dem anderen Chip zu reden.

Ich hab immer wieder mal Hardware-Leute gefragt und bisher klang keiner wirklich besonders begeistert, was die Idee angeht, auch wenn es sehr verlockend ist. Ist nicht so, als wuerde keiner daran arbeiten.

[basix]

Meine Meinung: Wenn es gut funktionieren würde, hätte das schon lange jemand gemacht. Die Vorteile wären einfach zu gross: 1 Chip für ganzes Portfolio, tiefere Entwicklungskosten, günstig herstellbarer Chip (Packaging wäre aber teuerer), sehr gute Skalierbarkeit usw.

Mal einfach so eine wilde Idee:
Könnte man nicht das Bild Schachbrettmässig und mehrstufig rendern? Der eine Chip berechnet auf einem Schachbrettmuster alle weissen Felder, der andere alle schwarzenFelder. Je nach grösse der Tiles muss man pro Stufe nur an den Rändern der Tiles Informationen zwischen den Chips austauschen, falls dies zwingend nötig wäre. Am besten wäre kein Datenaustausch während der Stufe in der Grafik-Pipeline nötig. Da Rendering in mehreren Stufen stattfindet, wird nach jeder Stufe die Information des einen Chips mit dem anderen synchronisiert. Da dies dann nur noch die Resultate beinhaltet, sollte die Bandbreitenanforderung massiv sinken. Oder denke ich da zu einfach?

[SKYNET]

Das ist doch oft so, dass Sachen erstmal lange brach liegen. Wer hat sich denn CPUs mit 64 bit (Athlon 64 3200+) gekauft und konnte gleich aus der 64bit-Fähigkeit Nutzen ziehen? Selbst die mit der ISA ermöglichte größere Speichermenge war doch jahrelang unwichtig. Jetzt 15 Jahre später sind die CPUs von damals alle alt und gammelig, aber so richtig brauchen wir 64bit immer noch nicht, es ist ganz nett, wenn man es nutzen kann. Bei Grafikkarten ist fast alles in der ersten Generation unnütz, schlicht weil es noch keine Spiele gibt, die das nutzen (abgesehen von einer halben Handvoll Alibititeln)


bitte was? :freak: windows 10 selbst mit browser frisst hier grad 3.1GB... und die meisten spiele verlangen bereits seit jahren mehr als 2GB für sich selber, inzwischen je nach game sogar das 5-fache und mehr.

und ich hatte auf meinen A64, ab dem tag wo XP64 rauskam, selbiges am laufen, und war auch ab dort, wo ich nie mehr ein 32bit OS installiert hatte :P

[Botcruscher]

Moeglich aus technischer Perspektive schon, aber gute Nacht die Kosten dafuer wieder reinzuholen.

Im Profibereich gibt es Geld wie Heu. AMDs Mainstream-Strategie ist doch schon vor Jahren voll gescheitert. NV macht derweil mit angepassten Chips einen Rekordgewinn nach dem anderen. Alle Segmente bekommen die optimale Hardware.

[Digidi]

Im Profibereich gibt es Geld wie Heu. AMDs Mainstream-Strategie ist doch schon vor Jahren voll gescheitert. NV macht derweil mit angepassten Chips einen Rekordgewinn nach dem anderen. Alle Segmente bekommen die optimale Hardware.

Gibt es denn überhaupt Zahlen die deine Aussage stützen? Wenn es nicht gerade um AI geht hat AMD sehr gute Karten.

[gravitationsfeld]

CUDA ist ziemlich beliebt.

[Digidi]

CUDA ist ziemlich beliebt.

Gibt es hierzu Zahlen?

[gravitationsfeld]

Ne, aber es ist halt ziemlich offensichtlich von dem was man im Internet so sieht. CUDA dominiert alle Diskussionen ueber HPC-Verwendung von GPUs.

Der Software-Stack ist halt auch einfach polierter. AMD hat entweder nicht die Mittel, oder nicht den Willen da mitzuhalten. Mit CUDA hast du volle Integration in Visual C++ mit vollem Debugger & Profiler. AMD? Nuechts.

Hier gibt's bisschen was dazu:
http://hpcadvisorycouncil.com/pdf/IS360-ISC17-HPC-Market-Update.pdf

Lese ich so, als waeren 75% aller System NVIDIA wenn sie "Accelerators" haben. 20% Xeon Phi. Bleiben <=5% fuer AMD.

[Brillus]

Wenn dedizierte hw die Anteile an Aufgaben gleichmaessig verteilt (und gleichzeitig alle Einheiten bzw. resources so gut wie moeglich auslastet) soll wo genau das Problem bei der Bandbreite liegen? In solch einem Fall wird ein frame zwischen den GPUs ebenbuertig aufgeteilt und jeder einzelne chip bearbeitet seinen Anteil fuer den spezifischen frame. Benutzt man jetzt einen weiteren kleinen quasi Bruecken-chip oder integriert das hw scheduling in einem chip als quasi "master" wobei der zweite dann als quasi "slave" fungiert sind Einzelheiten wie man es wirtschaftlicher realisieren will.

Ich weiss zwar nicht was AMD mit der Skalierung in der Navi Folie meinte, aber eine hw basierende skalierbare Loesung fuer mGPU und dass dann eher fuer Profi-Maerkte wuer mich nicht ueberraschen. Denn einen 815mm2 grossen GV100 dedizierten mords-chip kann ich mir von AMD schwer bis gar nicht vorstellen. Moeglich aus technischer Perspektive schon, aber gute Nacht die Kosten dafuer wieder reinzuholen.

Und ich bezweifle das man es einfach so balancen kann, ich gehe einfach von vielen Daten aus die Synchron gehalten werden müssen. Und ich bleib bei meiner Behauptung, das wenn es so einfach wäre wie du es dir vorstellst hätten wir es schon längst. Von Ryzen haben wir von AMD Aussage das 4*220mm² nur halb soviel kostet wie 1*770 mm². Und unterschiedliche Masken für unterschiedliche Chips ist teuer, und man muss sich oben drauf noch mehrere Monate früher entscheiden was man bauen will (anfang der Chip herstellung vs. Packaging) Die Technik nicht einzusetzen wenn man sie hätte wäre Ökonomischer Wahnsinn.

[HTB|Bladerunner]

Naja 3dfx hatte es doch über Scan Line Interleave vorgemacht. Wobei ich mir nicht mehr sicher bin wie gut das Ganze skalierte.

[robbitop]

Das waren andere Zeiten mit simplen Renderpipelines, wo es nahezu keine Interdependenzen zwischen den Scanlines gab.
Ich denke auch, dass die Anforderungen an die HW in Bezug auf Latenz und Bandbreite für eine transparente Lösung so hoch ist, dass wenn es sinnvoll funktieren würde, längst umgesetzt wäre. Auch ein Vergleich mit der IF und den Multicore Packages von AMD (oder ibm etc) ist nur ein Apfel Birne Vergleich da völlig andere Randbedingungen.
Wenn es sowas jemals geben solle, werden die dice auf dem gleichen Substrat sehr nah beieinander sein.

[Digidi]

Die Problematik ist die Aufteilung der Gebiete die muss flexibel sein. Ein Beispiel mit 2 GPUs. Wenn du oben nur Himmel hast und unten viele Polygonen und deine Grafikkarte bekommt die obere Hälfte und die andere die untere Hälfte, dann hat die GPU für oben nicht viel zu tun. Es müsste dann eine Workbalance geben die ungefähre vorhersagt wo der Schnittpunkt ist das beide ungefähr das gleiche berechnen müssen.

[robbitop]

Damit es 100% transparent funktioniert wird da nix statisch aufgeteilt. Du ziehst die GPU (zB die gpcs) auseinander. Die reguläre Kommunikation zwischen den Einheiten die sonst on chip ist, läuft dann offchip.

[Digidi]

Bei SFR passiert das ja schon und hier sind mikrorukler kaum ein thema.

Erleichtert kommt bei MCM hinzu daß alle auf den selben Vram zugreifen und die Schnittstelle hier um einiges schneller ist als über PCI expres.

Interessant ist ja das der HBM als HBCC also als Cach bezeichnet wird. Ob das ein Wink mit dem Zaunpfahl ist?

[Loeschzwerg]

Leistungssteigerung war bei SFR bisher nur nicht sonderlich gut. Kam deswegen auch nur selten zum Einsatz.
Selbst wenn es mit modernen Techniken möglicherweise besser wird, reicht es aus?

[robbitop]

SFR und auch Supertiling sind für moderne Renderpipelines nicht für die Anwendung transparent umsetzbar.

[Hübie]

Man bräuchte so etwas wie das Schachbrettmuster (SuperTiling), aber eben mit einer gleichmäßigeren Verteilung:

https://abload.de/img/load_balancingyesly.png (http://abload.de/image.php?img=load_balancingyesly.png)

Hab das mal mit 24²=576 Pixel gemacht. In jedem Quadrant rendert die GPU1 288 Pixel und GPU2 288 Pixel. Das bedarf aber einer expliziten Integration in die Engine und ich weiß nicht wie sich das auf die Auslastung auswirken könnte (AMD mal außen vor, da iirc nur Vega raster binned, aber doch kein waschechter TBR zu sein scheint - btw: hatte nicht jemand den Rastertest mit Vega gemacht??).
Wenn man jetzt einen ASIC nur für die Lastverteilung hat und diesen skalierbar vor die eigentliche Recheneinheiten pflanzt, dann kann man die GPU skalieren. Es bräuchte halt ein mesh fabric (Hallo IF) oder besser noch managed network mir RTOS. Von NV weiß man nicht wie deren Interconnect läuft, aber ich weiß noch von Kepler dass es ein RTOS gibt was nicht nur die Metriken für den Boost verwaltet...

Was denkt ihr? Ich mein auf der Folie wird Skalierbarkeit explizit erwähnt und ich schiele mal dezent zu Ryzen bzw. Threadripper deren Teams ja zumindest partiell mit in die RTG gewandert sind. :freak:

[vinacis_vivids]

Im Profibereich gibt es Geld wie Heu. AMDs Mainstream-Strategie ist doch schon vor Jahren voll gescheitert.

:rolleyes:

Schon wieder totaler Unsinn.

[Der_Korken]

Man bräuchte so etwas wie das Schachbrettmuster (SuperTiling), aber eben mit einer gleichmäßigeren Verteilung:

https://abload.de/img/load_balancingyesly.png (http://abload.de/image.php?img=load_balancingyesly.png)

Hab das mal mit 24²=576 Pixel gemacht. In jedem Quadrant rendert die GPU1 288 Pixel und GPU2 288 Pixel. Das bedarf aber einer expliziten Integration in die Engine und ich weiß nicht wie sich das auf die Auslastung auswirken könnte (AMD mal außen vor, da iirc nur Vega raster binned und aber doch kein waschechter TBR zu sein scheint - btw: hatte nicht jemand den Rastertest mit Vega gemacht??).


Rein konzeptionell würde ich bei so einem Ansatz die Last nicht so durchmischt verteilen, sondern eher das Bild vertikal (bzw. horizontal, ist ja wurscht) in zwei Hälften aufteilen und jeder GPU eine Hälfte geben. Die arbeiten das dann kachelweise in Spalten so ab, wie du dargestellt hast. Sobald eine GPU mit ihrem Teil fertig ist, werden die noch nicht gerenderten Spalten der anderen GPU noch mal durch zwei geteilt und jeder GPU zugeteilt, usw. Dadurch minimiert man die Überschneidungen der beiden GPUs bezüglich der Bildbereiche.

Die Frage ist nur, ob die Berechnungen unabhängig genug sind, um ständigen Datenaustausch zu verhindern. Nach meinem laienhaften Verständnis müsste alles, was nach der Verrasterung stattfindet, relativ unkritisch sein. Wenn mal ein paar Ergebnisse von benachbarten Pixeln, die zur anderen GPU gehören, gebraucht werden, sollte das von der Bandbreite her über den Interconnect hoffentlich gehen.

Von der Verrasterung selbst habe ich keine Ahnung. Nvidia arbeitet hier kachelweise, d.h. das Bild wird in Kacheln unterteilt, in denen erstmal alles fertig gerastert wird, bevor die Shader laufen (Vega auch?). Das klingt für mich erstmal ideal für ein MGPU-Konzept, aber meine Vorstellung ist da vermutlich zu einfach.

[Hübie]

Na du hast ja zumindest immer etwas overlapping weshalb die Skalierung nie 1:1 ist. Wenn du jetzt Daten von Ergebnissen austauschst, dann frisst das wahrscheinlich mehr Latenz als wenn du es auf beiden laufen lässt. Wie man es verteilt ist ziemlich Wurscht, man hat immer den Nachteil der Implementierung und der Skalierung.

[fondness]

Mal wieder ein paar vermeidliche AMD Internas:
AMD RX 600 Series GPU Project “Zen” Detailed – Radeon on Steroids to Amp Clock Speeds & Efficiency
https://wccftech.com/amds-secret-radeon-project-zen-to-boost-gpu-clocks-efficiency-in-2018-navi-in-2019-beyond/

[Dino-Fossil]

Mal wieder ein paar vermeidliche AMD Internas:

Im Gegenteil glaube ich, das war früher oder später unvermeidlich...

[Grendizer]

Im Gegenteil glaube ich, das war früher oder später unvermeidlich...


Kann man eigentlich wirklich so einfach CPU Spezialisten an GPUs setzen und die können ihr Wissen dann dort einbringen ?

Ich stell mir das immer so vor, als ob man Motorspezialisten von MAN an die Rennmotoren von F1 Boliden ranläßt.

[Blediator16]

Mal wieder ein paar vermeidliche AMD Internas:
AMD RX 600 Series GPU Project “Zen” Detailed – Radeon on Steroids to Amp Clock Speeds & Efficiency
https://wccftech.com/amds-secret-radeon-project-zen-to-boost-gpu-clocks-efficiency-in-2018-navi-in-2019-beyond/

AMD bemüht sich Takt und Effizienz zu erhöhen.Sie sollte die Leaks schließen und den Maulwurf schnappen :freak:

[Der_Korken]

Selbst wenn das stimmt, wird man in Navi noch nicht viel davon sehen. Die können ja nicht 1,5 Jahre vor dem Launch* nochmal alles mögliche umschmeißen und dann erwarten, dass da was gutes bei rauskommt.

*angenommen 1H19

[fondness]

Das mit Suzanne Plummer ist Fakt:
https://www.youtube.com/watch?v=iQ_4C2TKHQ0&feature=youtu.be&t=3m3s

Laut LinkedIn ist sie vor 7 Monaten von der CPU- in die GPU-Abteilung gewechselt. Sie ist dort immerhin Corperate Vice President Radeon Technologies Group, also nicht gerade unbedeutend.

[AMDoderNvidia]

Der Artikel ist doch mal wieder wie die meisten wccf Artikel: Alles, was drin steht, ist schon bekannt - nur die Aufbereitung ist eben reißerisch. Sie zeigen letztlich die (inzwischen) uralte Architecture Roadmap und darunter noch eine Tabelle mit "dünner Faktenlage".

Interessant wirds erst im letzten Abschnitt:

We’ve been hearing a lot of chatter in private channels about how the company’s post-GCN, all new architecture is going to be Radeon’s Zen so to speak.


LOL - als ob sie eine Quelle hätten und die private channels mithören würden und das dann hier auf noch einfach so publizieren :D

[Dino-Fossil]

Kann man eigentlich wirklich so einfach CPU Spezialisten an GPUs setzen und die können ihr Wissen dann dort einbringen ?

Ich meinte eigentlich, dass wtftech mal wieder vermeindliche Fakten haben und damit einen Clickbait-Artikel zusammenschustern. :ugly: ;)

[horn 12]

AMD bringt die Primitive Shader zum Laufen und lehrt NV das Fürchten, Wetten!
Die Retourkutsche für das NV Programm,- und hoffe AMD lässt die Aussteiger dann wirklich fern vom Boot!

[AMDoderNvidia]

Ich weiß nicht, ob es hier schon im Thread erwähnt wurde, aber eigentlich sollte jeder mal einen Blick reingeworfen und es gelesen haben: Radeon’s next-generation
Vega architecture (http://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf).

Da ist ja sogar von Infinity Fabric die Rede - allerdings scheint mir inzwischen bei AMD jegliche Kommunikation zwischen beliebigen Komponenten als Infinity Fabric bezeichnet zu werden.

[Locuza]

Vom Infinity-Fabric war von Anfang an die Rede.
https://wccftech.com/amds-infinity-fabric-detailed/

AMD unterteilt es auch in ein Scalable Control Fabric (SCF) und Scalable Data Fabric (SDF):
https://abload.de/img/d721b4e1-bc68-43d8-bdj4sny.png
Seite 10:
https://www.hotchips.org/wp-content/uploads/hc_archives/hc29/HC29.21-Monday-Pub/HC29.21.10-GPU-Gaming-Pub/HC29.21.120-Radeon-Vega10-Mantor-AMD-f1.pdf

[Achill]

AMD bringt die Primitive Shader zum Laufen und lehrt NV das Fürchten, Wetten!
Die Retourkutsche für das NV Programm,- und hoffe AMD lässt die Aussteiger dann wirklich fern vom Boot!

Das klingt eher wie der grünen Fraktion etwas Munition zu liefern ...

[reaperrr]

Selbst wenn das stimmt, wird man in Navi noch nicht viel davon sehen. Die können ja nicht 1,5 Jahre vor dem Launch* nochmal alles mögliche umschmeißen und dann erwarten, dass da was gutes bei rauskommt.

*angenommen 1H19
Das ist richtig, zumal es sich für 5-10% mehr Performance bzw. Perf/W nicht lohnt, den Launch um mehrere Monate zu verschieben, da Time-to-Market mMn mindestens genauso wichtig ist (Polaris10 und 11 hätten viel erfolgreicher sein können, wenn sie 2-3 Monate früher und mit besserer Verfügbarkeit erschienen wären).

Das Projekt wird in erster Linie auf die neue Arch nach Navi abzielen, die muss nämlich quasi das Pascal-Niveau überspringen, wenn man den Anschluss wieder herstellen will (mit Vega sind sie zumindest unter DX11 ja noch nichtmal auf Maxwell 2-Niveau angekommen, wenn man das ganze auf den gleichen Prozess normalisieren würde).

Dass sie auf den letzten Drücker noch ein paar Kleinst-Verbesserungen an Navi vornehmen konnten würde ich zwar nicht ausschließen, aber was weltbewegendes sollte man so oder so nicht erwarten.

Wobei Mike Mantor von AMD m.W. gegenüber jemandem von anandtech - ich meine entweder Ian Cutress oder Ryan Smith - schon lange vor dem offiziellen Vega-Release inoffiziell erwähnt hat, dass eben nicht Vega, sondern Navi der nächste größere GCN-Sprung wird (wieviel die Aussage wert ist, muss man natürlich erstmal abwarten, Polaris und Vega waren ja jeweils auch nicht so toll wie angekündigt).
Also zumindest mehr als ein 7nm-Shrink von Vega10, bei dem nur das HBM2-Si durch G6-SI ersetzt wurde, wird Navi wohl schon sein. Ob's reicht um den Rückstand auf NV nicht noch größer werden zu lassen, steht auf einem anderen Blatt.

[Digidi]

WerVom Infinity-Fabric war von Anfang an die Rede.
https://wccftech.com/amds-infinity-fabric-detailed/

AMD unterteilt es auch in ein Scalable Control Fabric (SCF) und Scalable Data Fabric (SDF):
https://abload.de/img/d721b4e1-bc68-43d8-bdj4sny.png
Seite 10:
https://www.hotchips.org/wp-content/uploads/hc_archives/hc29/HC29.21-Monday-Pub/HC29.21.10-GPU-Gaming-Pub/HC29.21.120-Radeon-Vega10-Mantor-AMD-f1.pdf

Viel interessanter ist doch diese Folie:
https://cdn01.hardwareluxx.de/razuna/assets/1/26B50487C56D4E62B04AF098AD0E73B1/img/1C58E0E2475B4742876C81213B3E2930/amd-vega-techday-vega-architecture-pressdeck-09_1C58E0E2475B4742876C81213B3E2930.jpg
https://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/43969-amd-radeon-rx-vega-64-und-rx-vega-56-im-test.html?start=2

Der HBCC ist eigentlich das Tool für den Multi Chip Betrieb. HBM agiert hier als Cache man könnte Ihn super als Austauschpunkt für einen Muly Die Ansatz nutzen. Die Bandbreite und Latenz ist da und die Daten sind jetzt Feinkörnigen für eine Bessere Zuordnung.

[Botcruscher]

Keine Ahnung wie du auf die Idee kommst. HBCC ist eine Speicherverwaltung, da landen wir ja am Ende wieder auf dem VRAM oder schlimmer RAM.
:rolleyes:
Schon wieder totaler Unsinn.
Ja echt ey, Valve manipuliert die Umfragen von Steam.... :freak:

[vinacis_vivids]

Hauptsache erstmal mit Fakten kommen :tongue:

HBCC sieht man bei Doom&WII@5k wo jede 8GB Karte aussteigt außer V10.

[Der_Korken]

Keine Ahnung wie du auf die Idee kommst. HBCC ist eine Speicherverwaltung, da landen wir ja am Ende wieder auf dem VRAM oder schlimmer RAM.

Das Speichermodell von Vega mit dem HBCC könnte einem MGPU-Ansatz aber sehr entgegenkommen:

Die Daten müssten also z.B. zu 90% aus dem eigenen VRAM kommen und nur zu 10% aus dem VRAM der anderen GPU. Wäre sowas mit Hilfe des HBCCs nicht gut zu realisieren, weil jede GPU dann für sich in Hardware verwaltet welche Daten sie in ihren lokalen VRAM lädt? Alles was angefragt wird, wird in den lokalen VRAM geladen und was nicht gebraucht wird, eben nicht. Daten, die beide GPUs brauchen, werden dann auch in beiden VRAMs liegen bleiben. Man müsste "nur" die Kohärenz sicherstellen (Infinity Fabric?) und die Last so verteilen, dass z.B. bestimmte Texturen möglichst nur auf der einen GPU gebraucht werden, auf der anderen aber nicht. 100%ig klappt letzteres natürlich nicht, aber es sollte zumindest nicht jede Textur in jeden VRAM kopiert werden müssen.

Einfach den VRAM beider GPUs als einen großen VRAM betrachten und dann Zugriffe ständig über den schmalen Interconnect der beiden Chips zu schicken, wäre viel zu langsam. Man würde einiges duplizieren und in beiden VRAMs vorhalten müssen, um den Interconnect frei zu halten. Das wäre ein Riesenaufwand das entweder dem Treiber oder den Entwicklern aufzubürden, aber mit dem HBCC könnte man sowas in Hardware lösen. Der Gesamtpool an Speicher existiert nur "virtuell" und die GPUs laden im Sinne eines Caches die xGB, die gerade am meisten gebraucht werden. Das ungenutzte Zeugs liegt dann im RAM oder auf der Platte.

[Hübie]

Also zumindest für AFR müssen z.B. Texturen in beiden Pools resident sein. Bei einer "Verschaltung" beider VRAM Pools hast du das Problem, dass Daten für GPU1 in Pool2 sitzen können und vice versa, da die Speicheradressen keine Tags haben wo der eine endet und der andere beginnt. Also müsste man Daten taggen und darüber ne Liste führen -> overhead(?). NV hat ja einen ähnlichen Ansatz wie HBCC nur glaub ich ohne page migration, aber eben der grundsätzlichen Möglichkeit mehrere physische RAM-Arten zu einem Pool zusammenzufassen (auch über mehrere GPUs hinweg). Ist iirc jedoch nur im compute mode für Tesla und wohl auch Quadro verfügbar. Grid kann dies ebenfalls. Für Spiele sehe ich da noch keinen nennenswerten Vorteil.

[Der_Korken]

AFR will man auf keinen Fall, das wäre kein Fortschritt zu dem, was man schon hat. Den Rest stelle ich mir so vor: Angenommen im RAM würden sich alle Daten befinden, die beide GPUs brauchen, z.B. 12 GB insgesamt. Die beiden GPUs berechnen unterschiedliche Bildbereiche und brauchen daher nicht alle Daten. Jede GPU macht sich über Zugriffe und deren Misses nach einer Einlaufphase ihren 8GB großen lokalen VRAM mit Daten voll. Einige Daten liegen exklusiv bei einer GPU, einige sind geshared. Das müsste man, wie du sagst, tatsächlich irgendwo speichern, damit Writes an alle Leser propagiert werden können. Jetzt sind die 12GB im RAM natürlich Verschwendung, man würde dort eigentlich nur gerne das lagern, was gerade in keiner der beiden GPUs gebraucht wird, also z.B. 2 GB im RAM, 6GB gesharete Daten in beiden GPUs und je 2 GB exklusiv in den GPUs. Das wären quasi zwei getrennte RAMs (=lokale VRAMs) mit gemeinsamen Swap-File (=RAM). Allerdings entsteht natürlich overhead, da die Information, welche GPU gerade welche Pages hat im Prinzip in beiden GPUs vorhanden sein muss.

[Loeschzwerg]

So oder so müsste vermutlich ein neues Renderverfahren her (xyzFR) oder explizit in die Engine gegossen werden. Allzu große Hoffnungen braucht man sich mMn im Hinblick auf Spiele nicht machen.

[basix]

Das Ziel muss SFR sein. Tiling ist ja eigentlich schon eine Variante von SFR, nur halt innerhalb des selben Chips, man prozessiert Tile für Tile (sehr einfach ausgedrückt). Eigentlich sollte man die Tiles ja auf mehrere GPUs verteilen können, solange nicht zu hohe Querabhängigkeiten der Tiles besteht usw. Und Tiling benötigt keine Anpassungen an den Engines und Renderverfahren, Nvidia zeigt es vor.

Das mit dem HBCC sehe ich ähnlich wie andere als Mittel für praktikables MCM für GPUs. Es müssen ja bei weitem nicht alle Daten mit der vollen Bandbreite zur Verfügung stehen. Da über IF auf den RAM der anderen GPUs auf dem MCM zuzugreifen, falls man z.B. Texturen braucht die dort liegen, wäre ja möglich (jede GPU hätte seinen eigenen HBM-Stack). Die schwierigste Frage ist für mich, wie man am effizientesten die Daten auf den gesamten RAM-Pool / auf die mehreren Stacks verteilt, ohne Bottlenecks zu generieren.

[Hübie]

Horizontal hat SFR in den meisten Titeln den Nachteil, dass oben deutlich weniger Rechenlast ist. Vertikal kann es ebenfalls sehr ungleichmäßig sein (man steht z.B. an eine Küste oder am Straßenrand wo rechts der Wald ist.
Das Muster (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11673183&postcount=400), was ich auf Seite 20 gepostet habe, hat dieses Problem eben nicht. Über die Granularität können wir uns ja unterhalten und auch wie man so einen Ansatz implementiert, aber dass hier zumindest das Auslastungsproblem von SFR und Frametime-Problem von AFR umgangen ist, steht doch außer Frage oder habe ich einen Denkfehler gemacht? =)

[Loeschzwerg]

Das Ziel muss SFR sein. Tiling ist ja eigentlich schon eine Variante von SFR, nur halt innerhalb des selben Chips, man prozessiert Tile für Tile (sehr einfach ausgedrückt). Eigentlich sollte man die Tiles ja auf mehrere GPUs verteilen können, solange nicht zu hohe Querabhängigkeiten der Tiles besteht usw. Und Tiling benötigt keine Anpassungen an den Engines und Renderverfahren, Nvidia zeigt es vor.


Wenn das so einfach ist, warum gab es bisher nur so wenige SFR Umsetzungen?

Für Navi sehe ich hier zumindest noch keine Lösung.

[vinacis_vivids]

Frame Pacing und Async Compute sind die Stichwörter und nicht SFR mit irgendwelchen tiled-rendering.
Deus Ex/GoW 4@DX12 zeigen bereits >100% Skalierung mit AMD mGPU.
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11640406&postcount=374

[Digidi]

Horizontal hat SFR in den meisten Titeln den Nachteil, dass oben deutlich weniger Rechenlast ist. Vertikal kann es ebenfalls sehr ungleichmäßig sein (man steht z.B. an eine Küste oder am Straßenrand wo rechts der Wald ist.
Das Muster (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11673183&postcount=400), was ich auf Seite 20 gepostet habe, hat dieses Problem eben nicht. Über die Granularität können wir uns ja unterhalten und auch wie man so einen Ansatz implementiert, aber dass hier zumindest das Auslastungsproblem von SFR und Frametime-Problem von AFR umgangen ist, steht doch außer Frage oder habe ich einen Denkfehler gemacht? =)
SFR verschiebt nun jetzt schon die Bildschirmgrenze so, dass beide Grafikkarten die Selbe Last haben.

[Hübie]

Wie meinst du das? Das es dynamisches load balancing gibt? Hast du dazu mal einen Link?

[robbitop]

Die Aufteilung des Bildes ist doch gar nicht das Kernproblem.

[Hübie]

Die Skalierung ist das Kernproblem. Bei einer 1:1 Skalierung könnte man doppelten Energiebedarf u d doppelte Anschaffungskosten rechtfertigen, da Perf/W konstant bliebe. Die Aufteilung der Rechenarbeit ist somit, zumindest für mein Verständnis, ein ganz dicker Batzen vom Haufen. Dazu kommt eben noch die Implementierung, die sicher nicht ganz trivial sein dürfte.
Es gibt aber halt positive Beispiele für saubere mGPU Anwendungen. In der Menge ist es eben nur nicht haltbar, da 99,99% keine mGPUs berücksichtigen da mindestens das gleiche Prozentual keine verbaut haben.
Mit mGPU kauft man eh nur Zeit ein, da idR die nextgen deren Leistungsspektrum erreicht.

[Botcruscher]

Das mit der Skalierung ist doch eh so eine Sache. Wenn ich mir GP106 gegen GP102 ansehe wird der ganze mGPU Ansatz bei kleinen Chips einfach nur absurd. 200mm² gegen 471 bei grob 3X Hardwareeinheiten und einer Leistung von 2,4. Der Preis skaliert trotz mehr Hardware linear. Für eine Zeit lang hatte die TI dann auch noch das beste P/L.

Vergesst den Mist einfach, baut größere Chips und steckt die Entwicklungskosten in bessere automatische Tools.

Hauptsache erstmal mit Fakten kommen :tongue:
HBCC sieht man bei Doom&WII@5k wo jede 8GB Karte aussteigt außer V10.
Was hat HBCC beim Fail Megatextur mit der nahezu totalen Marginalisierung bei Spieler-Hardware gemein? V10 ist prozentual schlicht nicht existent.

[unl34shed]

Bei den großen Chips ist die yield aber deutlich schlechter. Irgendwann lohnt dass nicht mehr. Die Frage ist eben: wann?

[Der_Korken]

Das mit der Skalierung ist doch eh so eine Sache. Wenn ich mir GP106 gegen GP102 ansehe wird der ganze mGPU Ansatz bei kleinen Chips einfach nur absurd. 200mm² gegen 471 bei grob 3X Hardwareeinheiten und einer Leistung von 2,4.

GP106 ist kein guter Vergleich. GP104 ist 57% größer und hat doppelt so viele Ausführungseinheiten (bei allerdings nur 60% mehr Leistung). Keine Ahnung, warum GP106 so groß ist. GP104 zu GP102 ist dann wieder ungefähr 1:1, genauso wie GM200 vs GM204 vs GM206.

[vinacis_vivids]

GP106 ist auch Schrott was mGPU angeht und Nvidia kommt mit LL-API gar nicht zurecht.
https://www.pcper.com/news/Graphics-Cards/DX12-Multi-GPU-scaling-and-running-Deus-Ex-Mankind-Divided
https://abload.de/img/mankind1080-avgyhphp.png

Hat schon seine Gründe wieso mGPU von Nvidia nicht beworben wird :
- miese Skalierung bei neuen Engines
- besonders im LL-API wo die Speicherkompression (Nvidias Salz in der Suppe) nicht mehr über den Treiber läuft
- kein Framepacing und AC, daher miese frametimes

Ohne eine riesige Änderung an der Grundlegenden uArch hat Nvida keine Chancen was mGPU angeht und muss daher den Weg der monolithsichen GPU bis zum Ende gehen.

Navi dagegen ist auf Skalierung ausgelegt und alles andere als mGPU macht da keinen Sinn.

[vinacis_vivids]

Was hat HBCC beim Fail Megatextur mit der nahezu totalen Marginalisierung bei Spieler-Hardware gemein? V10 ist prozentual schlicht nicht existent.

HBCC ist frisch angekommen und wird bleiben und sich weiter vermehren. Ob du es willst oder nicht. But ok, you tried hard :biggrin:

[iuno]

Navi dagegen ist auf Skalierung ausgelegt und alles andere als mGPU macht da keinen Sinn.
Man koennte auch das exakte Gegenteil interpretieren.

Weiss auch nicht was die Diskussion um das alte Crossfire/SLI soll. Taugt beides genausowenig und daher nicht nur fuer Navi voellig irrelevant.

[Der_Korken]

Hat schon seine Gründe wieso mGPU von Nvidia nicht beworben wird :
- miese Skalierung bei neuen Engines
- besonders im LL-API wo die Speicherkompression (Nvidias Salz in der Suppe) nicht mehr über den Treiber läuft
- kein Framepacing und AC, daher miese frametimes

Ohne eine riesige Änderung an der Grundlegenden uArch hat Nvida keine Chancen was mGPU angeht und muss daher den Weg der monolithsichen GPU bis zum Ende gehen.

Navi dagegen ist auf Skalierung ausgelegt und alles andere als mGPU macht da keinen Sinn.

Was hat dieser Benchmark mit einer hardware-basierten MGPU-Lösung zu tun? Woraus geht hervor, dass Nvidia hardwareseitig hier nicht von zwei GPUs profitiert?
"miese Skalierung bei neuen Engines" -> Pauschalaussage mit Stichprobengröße 1?
"besonders im LL-API wo die Speicherkompression (Nvidias Salz in der Suppe) nicht mehr über den Treiber läuft" -> Bitte was? Speicherkompression ist ein Hardware-Feature ...
"kein Framepacing und AC, daher miese frametimes" -> Was hat AC mit Frametimes zu tun? Wie können die Frametimes bei Nvidia mies sein, wenn MGPU gar nicht funktioniert?

:rolleyes:

[Botcruscher]

Bei den großen Chips ist die yield aber deutlich schlechter. Irgendwann lohnt dass nicht mehr. Die Frage ist eben: wann?
Die Fläche kommt bei GPUs von Recheneinheiten. Davon haben die viele und noch einige mehr als Backup. Das Thema yield dürfte bis zu den typischen 550mm² wahrscheinlich keine Rolle spielen. Der mGPU Ansatz soll überwiegend beim design der Chips sparen.
HBCC ist frisch angekommen und wird bleiben und sich weiter vermehren. Ob du es willst oder nicht. But ok, you tried hard :biggrin:
:confused:
Ich sehe bei Steam keine AMD Karte mit HBCC:
AMD Radeon RX 460
0.36%
AMD Radeon RX 470
0.18%
AMD Radeon RX 480
0.42%
AMD Radeon RX 580
0.19%

Polaris und Vega sind bei dieser Zielgruppe krachend gescheitert.

[Daredevil]

Weiss auch nicht was die Diskussion um das alte Crossfire/SLI soll. Taugt beides genausowenig und daher nicht nur fuer Navi voellig irrelevant.
Die Zeiten haben sich aber nun einmal geändert, es ist nicht mehr alles so wie früher.
Früher empfanden wir Crysis bei ~30-40fps noch als geradezu spielbar ( Hohes empfinden von Mikrorucklern ), heute kotzen viele rum, wenn nicht mal stabil 60fps gehalten werden ( geringeres empfinden von Mikrorucklern ). HighFPS Gamer mit 150fps+ werden von dem ganzen Kram vermutlich nur ein Bruchteil mitbekommen entgegen dessen, wie man es bei LowFPS spürt.

Von daher würde ich nicht sagen, dass alles noch genauso scheiße ist wie früher. Ich habe mal sporadisch ein paar Tests gemacht mit Vega Crossfire und fands beachtlich, wie stromsparend und leiser man viel Leistung rausholen kann, wenn man das PT Limit begrenzt und halt dafür zwei Karten nutzt.

Dark Souls 4k Max Settings:

Stock Voltage - Bios2
Vega 56 Turbo Mode: 31 FPS, 170w GPU, 384w System, 2206RPM, 1310 MHz
Vega 64 Turbo Mode: 34 FPS, 230w GPU, 470w System, 2396RPM, 1386 MHz

Vega 56 + 64 Crossfire @ -50% PT @ Undervolting @ Bios2 @ Power Save Mode
47Fps, 95w GPU ( Vega64 ), 430w System, 1700RPM, 770 MHz

+52% Performance
-9% Stromaufnahme
-23% Umdrehungen pro Minute

[vinacis_vivids]

Was hat dieser Benchmark mit einer hardware-basierten MGPU-Lösung zu tun? Woraus geht hervor, dass Nvidia hardwareseitig hier nicht von zwei GPUs profitiert?
"miese Skalierung bei neuen Engines" -> Pauschalaussage mit Stichprobengröße 1?
"besonders im LL-API wo die Speicherkompression (Nvidias Salz in der Suppe) nicht mehr über den Treiber läuft" -> Bitte was? Speicherkompression ist ein Hardware-Feature ...
"kein Framepacing und AC, daher miese frametimes" -> Was hat AC mit Frametimes zu tun? Wie können die Frametimes bei Nvidia mies sein, wenn MGPU gar nicht funktioniert?

:rolleyes:

Musst dich halt einlesen in DX12 , explicit mGPU, Frame Pacing und AC und unterschiedliche Benches anschauen (neuere Engines).
:biggrin:
https://abload.de/img/bf1mgpudx11ylp8w.png
https://abload.de/img/bf1mgpudx12dgqkb.png
http://gamegpu.com/action-/-fps-/-tps/battlefield-1-vo-imya-tsarya-test-gpu-cpu

[Daredevil]

Einlesen ist ein lustiges Beispiel, wenn man eine russische Seite mit Bildern zeigt und den Text nicht richtig verstehen kann. :D

[Botcruscher]

Ich habe mal sporadisch ein paar Tests gemacht mit Vega Crossfire und fands beachtlich, wie stromsparend und leiser man viel Leistung rausholen kann, wenn man das PT Limit begrenzt und halt dafür zwei Karten nutzt.
Das ist ja nicht schwer. Failga wird auch schneller wenn nur das PT begrenzt wird. Der Chip ist eine Doktorarbeit wert. Soll und Haben liegen da zum Teil Lichtjahre auseinander.

Wenn zwo von zehn Titeln noch CF unterstützen, stellt sich aber die Frage nicht mal.

[robbitop]

Die Skalierung ist das Kernproblem. Bei einer 1:1 Skalierung könnte man doppelten Energiebedarf u d doppelte Anschaffungskosten rechtfertigen, da Perf/W konstant bliebe. Die Aufteilung der Rechenarbeit ist somit, zumindest für mein Verständnis, ein ganz dicker Batzen vom Haufen. Dazu kommt eben noch die Implementierung, die sicher nicht ganz trivial sein dürfte.
Es gibt aber halt positive Beispiele für saubere mGPU Anwendungen. In der Menge ist es eben nur nicht haltbar, da 99,99% keine mGPUs berücksichtigen da mindestens das gleiche Prozentual keine verbaut haben.
Mit mGPU kauft man eh nur Zeit ein, da idR die nextgen deren Leistungsspektrum erreicht.
Eine für die Anwendung transparente Lösung müsste nicht anders aufteilen als es die GPU bereits intern für die GPCs bereits tut. Die Aufteilung ist weniger das Problem als die Bandbreite und Latenz.
Der sheduler verteilt wie gehabt die Aufgaben/wavefronts an die GPCs/CUs. Lesen und Schreiben über den L2, der auf allen GPUs auf dem Träger immer kohärent abgeglichen wird. Das jeweils zuständige Backend schreibt es in den VRAM.
Da muss IMO nichts starr über ein Raster aufgeteilt werden. Nicht wenn es transparent funktionieren soll. Die GPU und deren Kommunikationswege wird entsprechend auseinandergezogen und auf mehrere dice verteilt.

Die og Anforderungen sind aber vermutlich so hoch, dass das zumindest derzeitig schwierig ist und vermutlich sehr viel Energie kostet (Signal über phy aus dem Chip führen kostet mehr Energie - auch wächst das Interface)
Ohne unnötige Redundanz wird man bei einer hypothetischen transparenten Lösung nicht auskommen. Die Leistung wird also nicht linear mit den Transistoren und den Kosten skalieren.

Wenn es der Entwickler explizit für die 3D Anwendung umsetzen würde, könnte man so eine Aufteilung (Raster) machen und somit auch weniger Kommunikationsbedarf zw den GPUs. Dafür ist aber die Zielgruppe zu klein. Also muss es wohl eine nichtstatische, transparente Lösung sein.

[Digidi]

Die Aufteilung des Bildes ist doch gar nicht das Kernproblem.

Ich glaube schon denn mit der Aufteilung bestimmst du maßgeblich was wie im Speicher gehalten werden muss und wo ein Austausch stadt finden muss.

[N0Thing]

Einlesen ist ein lustiges Beispiel, wenn man eine russische Seite mit Bildern zeigt und den Text nicht richtig verstehen kann. :D

Du kannst rechts oben die Sprache auf Englisch stellen.
Mehr als das das übliche cherry picking von vinacis_vivids wirst du aber auch so nicht entdecken können.

mGPU ist vorläufig tot.

[Hübie]

Man koennte auch das exakte Gegenteil interpretieren.

Weiss auch nicht was die Diskussion um das alte Crossfire/SLI soll. Taugt beides genausowenig und daher nicht nur fuer Navi voellig irrelevant.

Die Diskussion entsprang der Idee eine skalierbare Architektur zu basteln, welche nach außen transparent ist und nach innen zwei oder mehr verschaltete GPUs. Sind da wohl etwas abgekommen. :D
So eine Lösung bräuchte einen Arbiter und skalierbaren ASIC nur für das Scheduling. Dazu dann ein, in der Komplexität exponentiell steigenden, interconnect oder ein managed (switched) Network.

@robbitop: Ein transparentes System ist natürlich das bessere aus Anwendungssicht, klar. Bezüglich des Frontends muss man halt auch einen skalierbaren ASIC entwickeln und das backend ebenso entkoppeln.

[robbitop]

Ich glaube schon denn mit der Aufteilung bestimmst du maßgeblich was wie im Speicher gehalten werden muss und wo ein Austausch stadt finden muss.

Wie oben beschrieben aber heutzutage für moderne Renderpipelines von 3D Anwendungen aber nicht transparent möglich. Die Zeiten sind seit 1 Jahrzehnt vorbei.
Wie gesagt: Mit Entwicklerunsetzung möglich aber transparent eher nicht.

Ist bei anderen Aufgaben (gpu compute, encoding etc) mit weniger Interdependenzen viel einfacher. Oder auch bei CPUs.

Auch ist eben bei jeder gpu auch eine Menge Transistoren dabei, die man nicht mehrfach bräuchte (siehe gp106->102). Selbst wenn obige Anforderungen gelöst sind, ist die Skalierung mit der Transisormenge unterproportional. IMO zumindest mittelfristig nicht sinnvoll.

Mit Scalability ist bei Navi IMO eine bessere Skalierbarkeit der mArch gemeint. GCN skaliert ab einer gewissen CU Anzahl immer schlechter. Da wird man sich an NVs mArch sicherlich orientieren, die über die GPCs nahezu alles mitskaliert und auch nahezu unbegrenzt dessen Anzahl hochskalieren kann und die Leistung gleichzeitig mitsteigt.

[Daredevil]

Die Skalierung ist das Kernproblem. Bei einer 1:1 Skalierung könnte man doppelten Energiebedarf u d doppelte Anschaffungskosten rechtfertigen, da Perf/W konstant bliebe.
Die Skalierung kann aber auch anders funktionieren.
Wenn man den Chip nicht bis an die Kotzgrenze hochtakten muss, kann man die Leistung einer einzelnen 300w Karte mit zwei Karten bei 200w hinbekommen. Wenn man das sauber hin bekommt, ist so eine Skalierung schon ganz fein. Vega ist ja ein Negativ Beispiel dafür, dass man im Schnitt mit einer einzelnen Karte viel zu viel Saft zieht für das gebotene und das der Sweet Spot weiter unten liegt im MHz Bereich.
Das ist aber auch bei einer 1080ti der Fall.

MHz sind zwar billig erkaufte Leistung, aber manchmal kommt die einem auch recht teuer. :D

Du kannst rechts oben die Sprache auf Englisch stellen.
Mehr als das das übliche cherry picking von vinacis_vivids wirst du aber auch so nicht entdecken können.

mGPU ist vorläufig tot.
Kampf unter den eisbedeckten Inseln und Schnee bestreuten Schluchten zusammen mit der russischen Armee und seinen legendären Husaren! Ab September 5 bis Halter Battlefield 1 „Revolution“ und Battlefield 1 Premium Pass wird einen zweiwöchige frühen Zugang zum Battlefield Beiblatt 1: „Im Namen des Königs“ erhalten - zu dem größten in der Geschichte von Battlefield. in der letzten gamescom „Die beste Ergänzung des Jahres“ ausgezeichnet, enthält es sechs neue Karten zu Russland gewidmet, neuen Waffen und Fahrzeugen, zwei neue Operationen von epischen Ausmaßen, die neue Regime „Versorgung“ und vieles mehr.
Ja, naja. Bei "gründlichem" recherchieren vertraue ich dann doch Beisätzen vom Reviewer und die werden durch den Übersetzer halt zunichte gemacht.

[N0Thing]

Probier es mit Englisch, das scheint entweder besser mit google translate zu funktionieren, oder wird direkt vom Autor so verfasst. Der deutsche Text ist nur eine Übersetzung der englischen Übersetzung ins Deutsche.

[iuno]

Von daher würde ich nicht sagen, dass alles noch genauso scheiße ist wie früher. Ich habe mal sporadisch ein paar Tests gemacht mit Vega Crossfire
OK, mag sein dass sich die Anforderungen geaendert haben. Aber dass die Situation sich generell verbessert hat, ist ja nicht MGPU spezifisch. Ich nehme mal an, FreeSync funktioniert auch ganz normal mit CF? Ist ja immerhin auch eine mGPU-unspezifische Verbesserung, die es frueher nicht gab, von der man profitiert.
(Auch @Hübie) Ich wollte auch gar keine generelle mGPU Diskussion starten, weiss ja dass das fuer Navi ein Thema fuer Speku ist. Aber die Balkenbildchen aus irgendwelchen Tests mit last Gen Karten und Spielen die wohl noch nicht mal mGPU support haben, sind einfach OT und tragen auch rein gar nichts zur Diskussion bei.

Aber um nochmal aufs Thema zurueckzukommen: das wurde ja schon oefter angesprochen und ich bin gespannt ob und wann man so eine ThreadRipper/Epyc-artige mGPU Konstellation sehen wird. Oft wird ja gesagt, dass die off-chip Kommunikation problematisch ist, aber es gibt ja SI-Interposer oder auch die EMIB. Ich habe immer noch die naive Vorstellung, es koennte irgendwann mal eine "GPU" als aktiver Interposer kommen, mit den basic Sachen wie i/o und eben den control units und dann koennte man HBM und shader cluster oben drauf packen. Denke schon, dass man da noch Interessantes sehen wird, vielleicht nicht mit den aktuellen TSVs/µBumps und noch nicht mit Navi, aber irgendwann... :uponder:

[=Floi=]

Multi GPU wird es wohl eher für den HPC bereich geben. Dort sehtzt NV ja schon die kleineren chips in ihren datacentern ein. Dort könnte es schon kommen. (19" rack modul)
Es gibt für games/consumer einfach zu viele nachteile. Auch von der leistungsabgabe, weil du mit 2 x 150 watt chips schon bei 300 watt bist. 3 chips 450W und 4 chips mit 600w sind utopisch.

zu HBCC
nur braucht das auch system ram welcher auch geld kostet und belastet später den bus. Das thema hatten wir auch schon und zB bei vega gab es für 900€ schon die 16gb version. VRAM ist hier die bessere lösung.

Ich verstehe auch das verlangen nach dem ganzen custom scheiss nicht. Mantle wurde 1 gpu gen supportet!
Ich will die leistung auch noch in 5 jahren haben und da bleibt ein schneller chip immer schnell egal bei welcher api und bei welcher engine. Dort muss AMD hin!

[robbitop]

@Daredevil

Der Betriebspunkt ist bei AMD Karten (außerhalb der Nanos) schon länger ungünstig. Wahrscheinlich weil man das letzte Quäntchen Takt für das Wettbewerbsprodukt unbedingt haben wollte/musste. Radeons können ein paar MHz tiefer mit entsprechend niedriger VCore auch sehr sparsam sein. Das gilt für alle größeren gcns und auch für Vega.
Allerdings sieht man beim Undervolting such für Maxwell und Pascal gutes Potenzial.

[robbitop]

Multi GPU wird es wohl eher für den HPC bereich geben. Dort sehtzt NV ja schon die kleineren chips in ihren datacentern ein. Dort könnte es schon kommen. (19" rack modul)
Es gibt für games/consumer einfach zu viele nachteile. Auch von der leistungsabgabe, weil du mit 2 x 150 watt chips schon bei 300 watt bist. 3 chips 450W und 4 chips mit 600w sind utopisch.

zu HBCC
nur braucht das auch system ram welcher auch geld kostet und belastet später den bus. Das thema hatten wir auch schon und zB bei vega gab es für 900€ schon die 16gb version. VRAM ist hier die bessere lösung.

Ich verstehe auch das verlangen nach dem ganzen custom scheiss nicht. Mantle wurde 1 gpu gen supportet!
Ich will die leistung auch noch in 5 jahren haben und da bleibt ein schneller chip immer schnell egal bei welcher api und bei welcher engine. Dort muss AMD hin!
Für hpc kein so großes Problem weil idR sehr gut parallelisierbar, weniger Interdependenzen und geringerer Kommunikationsbedarf. Im Prinzip hat man das doch mit diesem dedizierten nvlink2 Switch umgesetzt. Entsprechend sollen mehrere gv100 für hpc transparent als eine gpu rechnen können. Ist aber wie gesagt etwas völlig anderes als für 3d Berechnung für Spiele.

——

TSV/Interposer bzw ebmi sind imo dafür Grundvoraussetzung - aber es sind trotzdem extra Schnittstellen mit phys nötig und auch der entsprechend erhöhte Energiebedarf für die Offchip Kommunikation.

[=Floi=]

Das könnte aber bei NAVI unter skalierung zu verstehen sein. Es könnte wirklich die mgpu fähigkeit sein, aber nur im HPC-bereich! Wäre ne option.

[Daredevil]

@Daredevil

Der Betriebspunkt ist bei AMD Karten (außerhalb der Nanos) schon länger ungünstig. Wahrscheinlich weil man das letzte Quäntchen Takt für das Wettbewerbsprodukt unbedingt haben wollte/musste. Radeons können ein paar MHz tiefer mit entsprechend niedriger VCore auch sehr sparsam sein. Das gilt für alle größeren gcns und auch für Vega.
Allerdings sieht man beim Undervolting such für Maxwell und Pascal gutes Potenzial.
Ja, absolut.
Durch meine Mining Experimente bin ich ja überhaupt auf das Thema Effizienz gestoßen, also nicht maximaler Takt bei weniger Volt, sondern echt 10-20% drunter bei 30-50% Ersparnis.
Das können "dicke" Grafikkarten wie eine Vega oder 1080ti aufgrund der Einheiten natürlich viel besser, eine TitanV macht es ja auch vor.

Das Ding ist halt nur, das dass Potential bei beiden natürlich groß ist, AMD aber leider eben nicht die Pole Position mit Vega einnehmen konnte, aus einer total optimierten Vega wird leider eine ~1060/1070, aus einer 1080ti wird eine sehr sparsame 1080. Das sind schon andere Welten, gerade weil man ja noch spielbar sein muss.

Aber die MultiGPU Diskussionen hat man ja immer, nur womit soll AMD denn abliefern, wenn sie die ganze Zeit in der MidRange kleben bleiben und Navi laut letzten Gerüchten da auch haust.

[Hübie]

(Auch @Hübie) Ich wollte auch gar keine generelle mGPU Diskussion starten, weiss ja dass das fuer Navi ein Thema fuer Speku ist. Aber die Balkenbildchen aus irgendwelchen Tests mit last Gen Karten und Spielen die wohl noch nicht mal mGPU support haben, sind einfach OT und tragen auch rein gar nichts zur Diskussion bei.

Ja das ist mir auch klar, ich wollte nur mal einwerfen wie wenig trivial das ganze eigentlich ist. :smile:

Die Beiträge von v_v beachte ich im übrigen gar nicht, sondern amüsiere mich (Speicherkompression per Treiber?!). :D

Aber um nochmal aufs Thema zurueckzukommen: das wurde ja schon oefter angesprochen und ich bin gespannt ob und wann man so eine ThreadRipper/Epyc-artige mGPU Konstellation sehen wird. Oft wird ja gesagt, dass die off-chip Kommunikation problematisch ist, aber es gibt ja SI-Interposer oder auch die EMIB. Ich habe immer noch die naive Vorstellung, es koennte irgendwann mal eine "GPU" als aktiver Interposer kommen, mit den basic Sachen wie i/o und eben den control units und dann koennte man HBM und shader cluster oben drauf packen. Denke schon, dass man da noch Interessantes sehen wird, vielleicht nicht mit den aktuellen TSVs/µBumps und noch nicht mit Navi, aber irgendwann... :uponder:

Kann mir gut vorstellen, dass man daran auch weiterhin forscht, denn ganz neu ist dieses Konzept ja nicht. Beim bonding gibt es auch kontinuierlich Fortschritte. Wenn man sich allerdings Threadripper anschaut ist das doch recht primitiv (aber eben effektiv) gelöst und die interchip communication ist recht lahm im vergleich zu onchip. Das dürfte also merkliche Nachteile in gewissen Anwendungsgebieten geben. Ob man es so bei massiv parallelisierten ASCIs machen kann bezweifel ich erst mal (daher mein hint zu den managed networks).

[robbitop]

@daredevil
Midrange ist doch ok. Da ist der Umsatz sicherlich am höchsten. AMDs Ausflüge in das Highend sind seit r600 alle mehr oder weniger erfolgsarm verglichen mit nv und verglichen mit den Erfolgen im Midrange. Lieber ein sehr gutes und gut verkauftes Midrange Produkt als ein mäßiges, schlecht verkauftes Highend, bei dem man schlimmstenfalls unterm Strich draufzahlen muss. Sich lieber auf die Stärken besinnen. AMDs Grafiksparte ist längst nicht mehr auf dem Stand, überall mit NV mithalten zu können (wie noch vor 10 Jahren). Man muss mit weniger Ressourcen lieber zunächst dort auftreten, wo es die meiste Wirkung hat. In der Hoffnung Stück für Stück durch ökonomische Erfolge wieder die Ressourcen aufzubauen um später sein Portfolio sukzessiv zu erweitern.
Ein exzellenten Widersacher zu GT106 ist für den Markterfolg und von den Chancen das auch umsetzen zu können sicher keine schlechte Idee. So wie bereits Pitcairn, Tonga und zuletzt Polaris.

[Grendizer]

@daredevil
Midrange ist doch ok. Da ist der Umsatz sicherlich am höchsten.

Und trotzdem machte AMD im letzten Quartal deutlich weniger Umsatz mit GPU und CPUs als nvidia. So irgendwie geht die Strategie nicht auf.

Ich denke das man den psychologischen Effekt einer High End Karte nicht vergessen darf. Wenn in der Wahrnehmung des normalen Käufers nVidia für High End Karten und AMD für gute Brot und Butter Karten, aber eben auch nichts besonderes steht, dann wird das irgendwann wirklich gefährlich.

[iuno]

Denke kaum dass es an der Strahlwirkung der schnellen Karten liegt, dass Nvidia so viel mehr Umsatz macht. Die werden schlicht und einfach auch deutlich mehr produzieren (koennen) bei TSMC.
Verkauft wird ja auch alles von AMD, sonst koennten die Haendler nicht solche laecherlichen Preise machen.

[Daredevil]

@daredevil
Midrange ist doch ok. Da ist der Umsatz sicherlich am höchsten. AMDs Ausflüge in das Highend sind seit r600 alle mehr oder weniger erfolgsarm verglichen mit nv und verglichen mit den Erfolgen im Midrange. Lieber ein sehr gutes und gut verkauftes Midrange Produkt als ein mäßiges, schlecht verkauftes Highend, bei dem man schlimmstenfalls unterm Strich draufzahlen muss. Sich lieber auf die Stärken besinnen. AMDs Grafiksparte ist längst nicht mehr auf dem Stand, überall mit NV mithalten zu können (wie noch vor 10 Jahren). Man muss mit weniger Ressourcen lieber zunächst dort auftreten, wo es die meiste Wirkung hat. In der Hoffnung Stück für Stück durch ökonomische Erfolge wieder die Ressourcen aufzubauen um später sein Portfolio sukzessiv zu erweitern.
Ein exzellenten Widersacher zu GT106 ist für den Markterfolg und von den Chancen das auch umsetzen zu können sicher keine schlechte Idee. So wie bereits Pitcairn, Tonga und zuletzt Polaris.
Ja, da hast du recht mit dem Midrange.
Man geht erst das größte Pferd an, bevor man sich an die Kleinigkeiten ranwagt. :)
Polaris war ja auch ein ganz gutes Produkt und die 1060 war in vielerlei Hinsicht ein klein wenig schwächer, da hat Nvidia ja auch kaum mit dem Preis angreifen können.
Deswegen wäre ja vielleicht eine funktionierende Skalierbarkeit im Sinne von MultiChips die Eier legende Wollmilchsau, so wie es Ryzen ja vor macht. Oder das ist eben anders gemeint. ( Eher wahrscheinlich :D )

Verkauft wird ja auch alles von AMD, sonst koennten die Haendler nicht solche laecherlichen Preise machen.

Das ist aber keine Meisterleistung von AMD, da wird lediglich der RAM von Polaris und der Cache von Vega missbraucht und nicht die ganze GPU selber.
Wenn die eine RX560 mit HBM2 raus bringen, kauft für den Mining Zweck keiner mehr Vega.

[Digidi]

Ich weiß nicht was ihr hier mit Transparent und Bandbreite habt. Der Chip muß Dx12.x und Vulkan 1.x regelkonform sein und viel Bandbreite braucht man nicht. Es läuft doch schon heute mit Grottiger PCIe Bandbreite Recht gut wenn die Programmierer sich nur an ein paar Regeln halten. Selbst der Mischbetrieb mit Nvidia und AMD unter Dx12 in Civ läuft schnell und sauber.

[Locuza]

Ein paar Regeln ist gut, über PCIe kannst du eine verdammt große Menge an Rendering-Methoden praktisch gar nicht umsetzen und wenn Entwickler ihre Programme explizit anpassen müssen, dann hat man schon gleich verloren, wenn das keinen Industriestandard darstellt und man als Hersteller nicht alle dazu bewegen kann sich anzupassen.

[Digidi]

Ein paar Regeln ist gut, über PCIe kannst du eine verdammt große Menge an Rendering-Methoden praktisch gar nicht umsetzen und wenn Entwickler ihre Programme explizit anpassen müssen, dann hat man schon gleich verloren, wenn das keinen Industriestandard darstellt und man als Hersteller nicht alle dazu bewegen kann sich anzupassen.

Ich kann Dir sagen wie es ausgeht. AMD wird es umsetzen und Nvidia wird nachziehen und dann macht der Markt erst mit und wir reden hier wieder über fine wine etc... :facepalm:

Vielleicht ist es ja Mal an der Zeit das Rendering an sich zu überdenken. Aber welche Probleme meinst du? Ob Tiled oder Intermediate Render funktioniert doch beides gut über mgpu. Die meisten Spiele nutzen sowieso Intermediate Rendering.

[Locuza]

Ich kann Dir sagen wie es ausgeht. AMD wird es umsetzen und Nvidia wird nachziehen und dann macht der Markt erst mit und wir reden hier wieder über fine wine etc... :facepalm:
Fix lieber deine krude Weltanschauung.

Vielleicht ist es ja Mal an der Zeit das Rendering an sich zu überdenken. Aber welche Probleme meinst du? Ob Tiled oder Intermediate Render funktioniert doch beides gut über mgpu. Die meisten Spiele nutzen sowieso Intermediate Rendering.
In der Realität wird das Rendering überdacht, wenn ein entsprechender Druck vorherrscht.
Die Leistungsskalierung muss schlecht ausfallen, die Perspektive für die Zukunft, möglicher Konkurrenzdruck vorherrschen, es muss ein Nährboden zur Verfügung stehen, um entsprechende Anpassungen zu motivieren, da ohne entsprechenden Absatzmarkt natürlich niemand grundlegend etwas ändern wird.
Und Spiele sind mehrere Jahre in der Entwicklung und an Triple-A Titeln arbeiten im Laufe der Zeit hunderte Entwickler, da wird nichts von Heute auf Morgen umgestellt, völlig unmöglich.

Wenn der Übergang zu neuer Technologie nicht fließend stattfinden kann, dann hat es meist keine Perspektive.

Aktuell sind mGPUs-Lösungen darauf beschränkt die Ressourcen über PCIe zu synchronisieren, heißt alles was Abhängigkeiten besitzt, kopiert und synchronisiert werden muss, zerstört sofort die mögliche Leistungsskalierung.
Du hast gerade mal 8-16GB/s zur Verfügung, dass Chip interne Fabric über hunderte von GB/s.

Deshalb setzt man auch primär auf AFR, weil es am meisten Unabhängigkeit zwischen den GPUs anbietet, weil jede GPU seinen eigenen Frame berechnet, aber hier bricht auch schon das Konzept zusammen, wenn wir von Temporalen Lösungen reden, welche Daten in Historie Puffer ablegen und für Frame-zu-Frame-Abhängigkeiten sorgen.

Deshalb auch die Diskussionen über Transparenz (Entwickler muss sich nicht explizit darum kümmern oder gravierende Änderungen vornehmen) und eine hohe Bandbreite zwischen den GPUs, um Data-Sharing in der Praxis zu ermöglichen.
Sprich so etwas:
http://hexus.net/media/uploaded/2017/7/ab444132-6860-409d-a39b-7c88586b86b6.png
https://www.gizcomputer.com/wp-content/uploads/2017/07/NVIDIA-MCM-GPU-With-GPC-and-DRAM-Dies_3-1030x679.png

[Digidi]

Fix lieber deine krude Weltanschauung.




Meine Weltanschauung ist nicht krude. Bestes Beispiel ist async Computer seit GCN 1.0 dümpelt das bei AMD Rum. Erst jetzt wo Nvidia eine funktionierende Implementierung hat kommt das zum Zuge.

[Locuza]

Cool story mate, ich erinnere mich noch gut an unsere Diskussion bezüglich GameWorks, wie böse HairWorks und die verwendete Tessellation mit hohem Faktor ist und das wir einen Industriestandard brauchen, der völlig an der Realität vorbeigeht, wie fertige Middleware, die irgendwie bestmöglich auf jeder Hardware laufen soll.
Das ganze Rumgereite bezüglich Primitive-Shader fußt auf keiner realistischen Grundlage, da hast du auch ewig herumgepoltert, dass die Journalisten doch endlich mal Druck ausüben sollen und bei vielen weiteren Themen sieht es nicht besser aus.

Async Compute dümpelte deswegen vor sich hin, weil es keine Entwicklerkontrolle darüber gab, die gibt und gab es auch bei Intel und Nvidia bezüglich vieler Features nicht.
Seit Mantle/DX12/Vulkan gibt es die Möglichkeit das Konzept AC auszunutzen und Entwickler haben es auch getan, auch vordem Launch von Pascal.
Ebenso hat auch nicht jeder das Konzept umgesetzt, weil es eben auch zusätzliche Komplexität darstellt, der PC mehrere Konfigurationen besitzt und die Entwicklerkontrolle auch nicht so genau ausfällt, wie unter den Konsolen, ein einfaches 1:1 mapping geht nicht.

[Digidi]

Ach Dude... Du hast den Unterschied immer noch nicht verstanden ob wirklich hilfreiche Features auf eine Chip verbaut sind oder ob willentlich Features zu hauf (ohne das es Sinn macht) auf einen Chip verbaut sind nur um seine Marktmacht ausnutzen zu können.

Los dich Mal von deiner Technischen Seite und betrachte die Wirtschaftlichen Aspekte.

[=Floi=]

Ach Dude... Du hast den Unterschied immer noch nicht verstanden ob wirklich hilfreiche Features auf eine Chip verbaut sind oder ob willentlich Features zu hauf (ohne das es Sinn macht) auf einen Chip verbaut sind nur um seine Marktmacht ausnutzen zu können.

Los dich Mal von deiner Technischen Seite und betrachte die Wirtschaftlichen Aspekte.

Das macht ja amd genau so. Sie sehtzen ihre marktmacht ein, um ihre beschleunigungstechniken durchdrücken zu klönnen.

[Locuza]

Ach Dude... Du hast den Unterschied immer noch nicht verstanden ob wirklich hilfreiche Features auf eine Chip verbaut sind oder ob willentlich Features zu hauf (ohne das es Sinn macht) auf einen Chip verbaut sind nur um seine Marktmacht ausnutzen zu können.

Los dich Mal von deiner Technischen Seite und betrachte die Wirtschaftlichen Aspekte.
Und wer definiert "wirklich hilfreiche Features auf dem Chip"?

Ich habe die wirtschaftlichen Aspekte genauso im Hinterkopf, wie die Technischen.
Oder wie kommt es zu Stande, dass z.B. Tessellation global betrachtet nur sehr moderat in Spielen eingesetzt wird?
Die meisten Spiele verwenden es gar nicht, weil es zusätzlichen Entwicklungsaufwand darstellt, die Content-Pipeline darauf angepasst werden muss und bei hohen Faktoren die Performance bei AMD und den Konsolen nicht mitspielt, entsprechend ist auch die Verbreitung und das Einsatzgebiet davon.
Und die Fälle wo Tessellation Missbrauch vorkommt sind prozentual gesehen verschwindend gering.

Nvidia ist nicht der Nabel der Welt, der vorschreibt was in Spielen verwendet wird und was nicht.

[Digidi]

Nvidia ist nicht der Nabel der Welt, der vorschreibt was in Spielen verwendet wird und was nicht.

Eben Doch! Wer Marktmacht hat um den dreht sich alles. Schau Dir doch an in wievielen Spielen Gameworks ist und wie viele AMD Techniken nutzen....

[Locuza]

Zäune mal das "um den dreht sich alles" extrem ein.
Es gibt deutlich mehr Spiele mit GameWorks, als mit AMD Middleware, aber Beides ist bezogen auf den Spielmarkt als Puderzucker anzusehen, wo Konsolen die technische Grundlage vorschreiben.
Und die Verbreitung von GameWorks ist prozentual gesehen trotzdem klein, wenn du dich nur auf Triple-A Titel beziehen willst dann hat es eine größere Relevanz, aber welche Auswirkungen hat das effektiv auf den Markt und das Kaufverhalten? Vor allem da GameWorks viele Effekte beinhaltet und meist dreht es sich um HBAO+ was praktisch niemanden kümmert.

HairWorks als das Problemkind, jedenfalls was die öffentliche Kritik angeht, hat es effektiv in kaum mehr Spiele geschafft, als TressFX-Technik bzw. darauf basierende Eigenlösungen.

HairWorks gibt es in FF15, The Witcher 3, Monster Hunter Online, Far Cry 4, Call of Duty: Ghosts und King of Wushu.
Na das ist jetzt keine brutale Bilanz.

TressFX gab es zuerst in Tomb Raider (2013), dann in Lichdom, Rise of the Tomb Raider (PureHair), Deus Ex: Mankind Divided (PureHair) und laut AMD Pressemitteilung auch in Monster Hunter Online, wobei da immer nur "Fell" stand und ich keine Ahnung habe, ob das Hairworks und/oder TressFX am Ende wirklich implementiert hat.

[robbitop]

Und trotzdem machte AMD im letzten Quartal deutlich weniger Umsatz mit GPU und CPUs als nvidia. So irgendwie geht die Strategie nicht auf.

Ich denke das man den psychologischen Effekt einer High End Karte nicht vergessen darf. Wenn in der Wahrnehmung des normalen Käufers nVidia für High End Karten und AMD für gute Brot und Butter Karten, aber eben auch nichts besonderes steht, dann wird das irgendwann wirklich gefährlich.

Wie gesagt. Es war auch mit High End Karten bei AMD nicht besser. Siehe fury x und V10. Man braucht zunächst mehr Ressourcen um anständig auf mehreren Hochzeiten tanzen zu können.

[Ailuros]

Und ich bezweifle das man es einfach so balancen kann, ich gehe einfach von vielen Daten aus die Synchron gehalten werden müssen.

Ach es geht heute durch AFR bzw. reiner software wo immer fuer AFR optimiert wird und zusaetzliche dedizierte hw dafuer ***edit: fuer SFR *** soll ein Problem sein? Im Notfall benutzt man einen kleinen Brueckenchip der hoeher taktet um relevante synchronisierte Datenstroeme auf Trab zu halten. Wie gesagt die Realisierung ist nicht das Problem hier.

Das daemlichste aller ist dass es in ULP GPU IP von IMG fuer etliche Jahre realisiert wurde und die Leistung skalierte linear von einem chip bis auf 4 die in Apple's SoCs integriert wurden. Ein chip hatte die extra scheduling hw und fungierte als master und die restlichen als "slaves" und ein jegliches MP config bekam einen noch zusaetzlichen Hydra chip zugesteckt der als Bruecken-/Geometrie-chip dient mit hoeherer Frequenz als eigentlichen GPU chips. Und dabei ist das Bruecken-Konzept auch nicht neu nur wurde es nie realisiert da 3dfx von NV aufgekauft wurde. Rampage und seine Nachfolger hatten relevante Geometrie-/Brueckenchips fuer ihr damaliges SLI. Im Fall von deferred rendering ist es natuerlich leichter mit dem load balancing und relevantem macro tiling (aka "viewports") aber sowohl AMD und NV wenden hierarchical tiling schon seit einer Ewigkeit an und es wird seit neuestem ein Anteil der Geometrie auf GeForces via tile based rasterizing on chip gehalten. Es ist eben NICHT so dass sich keiner damit beschaeftigt hat; noch "schlimmer" Technologie entwickelt sich staendig weiter.

Und ich bleib bei meiner Behauptung, das wenn es so einfach wäre wie du es dir vorstellst hätten wir es schon längst.

mGPU gibt es schon seit der Geburt von 3D. Es war schon immer eine winzige Nische des Markts und wird es wohl auch in absebarer Zeit so bleiben. Nochmal so lange N mGPU Loesungen wie projeziert verkauft werden schuetten IHVs keine resources in eine extravagantere Loesung.

Von Ryzen haben wir von AMD Aussage das 4*220mm² nur halb soviel kostet wie 1*770 mm².

Nicht dass CPUs mit GPUs etwas gemeinsam haetten aber bleiben wir mal dabei....

Und unterschiedliche Masken für unterschiedliche Chips ist teuer, und man muss sich oben drauf noch mehrere Monate früher entscheiden was man bauen will (anfang der Chip herstellung vs. Packaging) Die Technik nicht einzusetzen wenn man sie hätte wäre Ökonomischer Wahnsinn.

NV ist momentan der einzige IHV der fuer GPUs brutal grosse dies entwickelt. Fuer sie ist es momentan immer noch scheissegal was die Herstellung eines >800mm2 GV100 kostet so lange sie den chip so oder so fuer etliche tausend $ loswerden koennen. AMD hat den Luxus nicht.

Eben weil es fuer AMD wirtschaftlicher ist bei kleineren dies halt zu machen (weil sie eben keine dedizierte HPC chips verkaufen koennen und ihre GPU chips gut fuer HPC und 3D sein muessen), macht dedizierte hw fuer mGPU und ueberhaupt fuer HPC fuer AMD mehr Sinn. Der eigentliche und ewige Kopfschmerz mit mGPU ist Geometrie gut zu skalieren und das ist nach wie vor kein Hexenwerk. Noch um einige Meilen besser in einer APU bzw. SoC (ob system oder server on chip).

[AMDoderNvidia]

Ach es geht heute durch AFR bzw. reiner software wo immer fuer AFR optimiert wird und zusaetzliche dedizierte hw dafuer soll ein Problem sein?

AFR hat immer Beschränkungen. Bin ja selbst AMD Crossfire-Nutzer und wenn man die ideale Skalierung auf seinem System herausholen möchte, dann beschäftigt man sich mit den Rendertechniken und wie diese auf AFR skalieren. So ist zum Beispiel temporales AA bei AFR ein Problem, weil hier Abhängigkeiten zwischen den Frames bestehen, was die Skalierung absolut in den Keller fährt.

Wenn mGPU, dann bitte in Zukunft so, dass alle GPUs am selben Frame arbeiten! Alles andere ist Murks. Man sieht das auch schön am AGS-Framework von AMD (AMD GPU Services (AGS) Library (https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK)). Dort ist die DX11-API aufgebohrt für Crossfire (-> DirectX 11 Crossfire API updates), damit man als Entwickler "You can also now specify the transfer engine". Letztlich geht es hierbei darum dem Treiber mitzuteilen, wie Texturen, Framebuffer, usw. zwischen den GPUs ausgetauscht/synchronisiert werden sollen.

[aufkrawall]

Jede Wette, dass mit Raytracing die temporale Komponente auch noch massiv weiter an Bedeutung gewinnen wird.

[Ailuros]

AFR hat immer Beschränkungen. Bin ja selbst AMD Crossfire-Nutzer und wenn man die ideale Skalierung auf seinem System herausholen möchte, dann beschäftigt man sich mit den Rendertechniken und wie diese auf AFR skalieren. So ist zum Beispiel temporales AA bei AFR ein Problem, weil hier Abhängigkeiten zwischen den Frames bestehen, was die Skalierung absolut in den Keller fährt.

Wenn mGPU, dann bitte in Zukunft so, dass alles GPUs am selben Frame arbeiten! Alles andere ist Murks. Man sieht das auch schön am AGS-Framework von AMD (AMD GPU Services (AGS) Library (https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK)). Dort ist die DX11-API aufgebohrt für Crossfire (-> DirectX 11 Crossfire API updates), damit man als Entwickler "You can also now specify the transfer engine". Letztlich geht es hierbei darum dem Treiber mitzuteilen, wie Texturen, Framebuffer, usw. zwischen den GPUs ausgetauscht/synchronisiert werden sollen.

Ich rede schon seit Seiten von hw unterstuetztem SFR. Von AFR halte ich persoenlich nichts, es war nur mangelnd ausgedrueckt in meinem vorigen Post. Im gegebenen Fall "soll" eine hw unterstuetzte SFR Loesung das absolute Hexenwerk sein und nochmal massiv zusaetzliche Bandbreite vorraussetzen.

[SKYNET]

NV ist momentan der einzige IHV der fuer GPUs brutal grosse dies entwickelt. Fuer sie ist es momentan immer noch scheissegal was die Herstellung eines >800mm2 GV100 kostet so lange sie den chip so oder so fuer etliche tausend $ loswerden koennen. AMD hat den Luxus nicht.


nun, möchte auch keinen vega in der grösse sehen, stromverbrauch 500W? :freak: da muss AMD erstmal mit den neuen beweisen das sie auch "stromsparend" können, dann haben sie auch eher den luxus "fettere" GPUs bringen zu können die dann leistungstechnisch auf augenhöhe oder drüber sind, mit den grünen.

würde meine 1080Ti auch sofort gegen eine vega FE 16gb tauschen, wenn das teil nicht mein netzteil und die wärmeabfuhr kapazität von meinem case beidermassen überlasten würde... ;(

[Ailuros]

nun, möchte auch keinen vega in der grösse sehen, stromverbrauch 500W? :freak: da muss AMD erstmal mit den neuen beweisen das sie auch "stromsparend" können, dann haben sie auch eher den luxus "fettere" GPUs bringen zu können die dann leistungstechnisch auf augenhöhe oder drüber sind, mit den grünen.

würde meine 1080Ti auch sofort gegen eine vega FE 16gb tauschen, wenn das teil nicht mein netzteil und die wärmeabfuhr kapazität von meinem case beidermassen überlasten würde... ;(

ΙΜΗΟ nur ein resource Problem. Wenn AMD engineers den Luxus haetten eine Mordsmenge an Transistoren anzupassen um Strom zu sparen waere die Geschichte auch anders. NV hat extravagant hohe Frequenzen mit Pascal erreicht weil sie ziemlich viel zwischen ihren Transistoren "gepolstert" haben. Es ist ueberhaupt ein Wunder dass AMD so weit kommt mit den resources die sie fuer R&D benutzen koennen.

[SKYNET]

ΙΜΗΟ nur ein resource Problem. Wenn AMD engineers den Luxus haetten eine Mordsmenge an Transistoren anzupassen um Strom zu sparen waere die Geschichte auch anders. NV hat extravagant hohe Frequenzen mit Pascal erreicht weil sie ziemlich viel zwischen ihren Transistoren "gepolstert" haben. Es ist ueberhaupt ein Wunder dass AMD so weit kommt mit den resources die sie fuer R&D benutzen koennen.

meinst du nicht, wenn es rein um die recourcen ginge, würden sie zumindest eine professionelle lösung in geringer stückzahl auf dieser basis bringen? :confused:

denke eher liegt an einem "derzeit nicht können" als an einem "nicht wollen weil recourcen knapp bemessen"

[Blediator16]

meinst du nicht, wenn es rein um die recourcen ginge, würden sie zumindest eine professionelle lösung in geringer stückzahl auf dieser basis bringen? :confused:

denke eher liegt an einem "derzeit nicht können" als an einem "nicht wollen weil recourcen knapp bemessen"

Nicht können, weil Ressourcen knapp bemessen ist eher die richtige Ausdrucksweise.

[BoMbY]

Ich bin jetzt kein Experte, aber hört sich das nicht nach einem Rasterizer-Modell an, welches optimal für MCM-GPUs geeignet wäre: Parallel micropolygon rasterizers (http://www.freepatentsonline.com/20180061124.pdf)?

[Ailuros]

meinst du nicht, wenn es rein um die recourcen ginge, würden sie zumindest eine professionelle lösung in geringer stückzahl auf dieser basis bringen? :confused:

....und woher sollen die Kosten dann wieder reinkommen?

denke eher liegt an einem "derzeit nicht können" als an einem "nicht wollen weil recourcen knapp bemessen"

AMD hat genauso hochtalentierte GPU engineers wie NVIDIA. Der Spruch ist zwar nicht neu, gilt aber heute noch: "let AMD develop (gpu) technology and let NVIDIA execute".

Ich bin jetzt kein Experte, aber hört sich das nicht nach einem Rasterizer-Modell an, welches optimal für MCM-GPUs geeignet wäre: Parallel micropolygon rasterizers (http://www.freepatentsonline.com/20180061124.pdf)?

Klingt mir eher nach einer stinknormalen Realisierung von mehreren rasterizers optimiert fuer Tessellation aber lasse mich gerne eines besseren belehren.

[Hübie]

Ich sehe da auch nix besonderes, BoMbY. Aber mag auch an meinem laienhaften Verständnis und dem "Überfliegen" liegen.

[BoMbY]

Alle Arbeit wird in kleinere Pakete gesplittet, welche dann dynamisch an 1 bis n weitere Komponenten geroutet werden, inkl. Berücksichtigung von Latenzen, etc. Von der Terminologie her hört sich das so an wie ein Rasterizer für etwas das aufgebaut ist wie das was in dem schon verlinkten NOC-Patent (http://www.freepatentsonline.com/20170295111.pdf) beschrieben wurde. Der Sprung über z.B. ein Bridge-Chiplet (http://www.freepatentsonline.com/20180102338.pdf) zu einem anderen Chip dürfte dann nur noch ein kleiner sein.

[SKYNET]

....und woher sollen die Kosten dann wieder reinkommen?

AMD hat genauso hochtalentierte GPU engineers wie NVIDIA. Der Spruch ist zwar nicht neu, gilt aber heute noch: "let AMD develop (gpu) technology and let NVIDIA execute".


nun, solche produkte kosten dann ja auch etwas mehr wie ne consumer karte, siehe NV... 4k€ +/-

das ja eh nix neues das AMD technologieträger ist... leider haben sies bis heute nicht gebacken bekommen, das mal als marketing strategie zu nutzen :freak: oder anderes gesagt: deren marketing ist der blanke horror, selbst ein dilletant könnte das besser.

sie könnten ja mal schalten wie "du bist froh mehr als 4GB ram im computer und smartphone zu haben? - wir haben es dir ermöglicht"(A64) gleiches für die grakas... aber neee.... :frown:

[Grendizer]

nun, solche produkte kosten dann ja auch etwas mehr wie ne consumer karte, siehe NV... 4k€ +/-

das ja eh nix neues das AMD technologieträger ist... leider haben sies bis heute nicht gebacken bekommen, das mal als marketing strategie zu nutzen :freak: oder anderes gesagt: deren marketing ist der blanke horror, selbst ein dilletant könnte das besser.

sie könnten ja mal schalten wie "du bist froh mehr als 4GB ram im computer und smartphone zu haben? - wir haben es dir ermöglicht"(A64) gleiches für die grakas... aber neee.... :frown:

64 Bit CPUs hat jetzt aber nicht AMD erfunden. Da waren andere 10 Jahre früher dran :biggrin: . Im Supercomputerbereich wohl sogar 40 Jahre :eek:

[Datarecovery09]

Für's Marketing passt das schon. :D

[SKYNET]

64 Bit CPUs hat jetzt aber nicht AMD erfunden. Da waren andere 10 Jahre früher dran :biggrin: . Im Supercomputerbereich wohl sogar 40 Jahre :eek:

sie habens der breiten masse zugänglich gemacht, ansonsten hätten wir wohl noch immer 32bit bzw. erst seit wenigen jahren(4-5) x64 :freak:

[Grendizer]

OT 64 Bit

So toll ich 64 Bit Prozessoren finde, aber für den gewöhnlichen Anwender gab es doch gar kein Anwendungsvorteil, mangels Betriebsystemunterstützung.

Wer hatte schon ein XP Pro 64 Bit oder gar Vista ? Wirkliche Relevanz für "gewöhnliche Anwender" war erst mit Windows 7 in 2009 gegeben.

Im Serverbereich war es eine Wohltat, sich nicht mehr mit PAE rumschlagen zu müssen, da gebe ich dir vollkommen Recht.

[SKYNET]

Wer hatte schon ein XP Pro 64 Bit



*hand heb* beta version in englisch
:cool:

[AMDoderNvidia]

So, jetzt wurde viel diskutiert die letzten Tage. Gibts bei Navi nun einen tile-based basierten mGPU-Ansatz oder nicht? Ist es wahrscheinlich oder nicht? Oder ist es doch nur ein Aufblähen der GCN-Architektur (diesmal aber richtig und nicht so wie beim Fiji-Chip - also mehr als nur die Shaderzahl erhöhen und eine Prise Deltakompression mit dazu).

[Hübie]

*hand heb* beta version in englisch
:cool:

Dito. XP64 von der ersten Minute an - die Lizenz fliegt hier noch irgendwo herum und wartet darauf ein Retro-System zu beglücken. Die anderen User waren alle b0Bz. Ich hatte sogar Crossfire mit AMD unter XP64. :freak:

[aufkrawall]

Den x64 Blah hatten wir doch erst die Tage. Dass ein besagter User seit einiger Zeit hier fleißig am spammen ist, ist auch ohne Eingehen darauf von anderen schon nervig genug...

[Hübie]

Bist ja auch drauf eingegangen. :P

[unl34shed]

So, jetzt wurde viel diskutiert die letzten Tage. Gibts bei Navi nun einen tile-based basierten mGPU-Ansatz oder nicht? Ist es wahrscheinlich oder nicht? Oder ist es doch nur ein Aufblähen der GCN-Architektur (diesmal aber richtig und nicht so wie beim Fiji-Chip - also mehr als nur die Shaderzahl erhöhen und eine Prise Deltakompression mit dazu).

Kann dir keiner aktuell sagen, aber mMn. hat AMD die letzten Generationen konsequent in Richtung MCM hingearbeitet.
Ob MCM schon mit Navi kommt? Möglicherweise. Langfristig werden AMD und auch Nvidia aber den Weg über MCM-GPUs gehen müssen.

[maximus_hertus]

Ich gehe mal davon aus, das AMD im Sommer irgendwas zu Navi sagen wird. Einfach nur um zumindest im Gespräch zu bleiben, während Turing gelauncht wird.

Ich hoffe, dass Navi ein H1 Produkt ist, sonst könnte es wieder unschön werden.

[Rampage 2]

Ich denke bei Navi immer an zwei Dinge:

1.) Navi = "Vega done right" (offensichtlich scheint mit Vega etwas nicht zu stimmen/Hardware-Bug - soviel Potential, das brach liegt...)

2.) mehr Recheneinheiten als Vega und Fiji, so 96-128 CUs (6-8k Shadereinheiten). Da aller Wahrscheinlichkeit nach der GT102 5000+ Shadereinheiten haben wird, muss auch AMD mit ihrem GPU-Design mehr in die Breite gehen - selbst wenn AMD es endlich schafft, ihre Ausführungseinheiten gut auszulasten, werden sie nur mit 4k Recheneinheiten einem GT102 nicht das Wasser reichen können...

Unsinnig?

R2

[=Floi=]

was wurde eigentlich aus der idee siliziumverbindungen auf dem wafer zu belichen und hinterher nur noch die entsprechenden chips rauszusägen?

mit welchem powerbudget willst du 8000 shadereinheiten betreiben?

[iuno]

Ich gehe mal davon aus, das AMD im Sommer irgendwas zu Navi sagen wird. Einfach nur um zumindest im Gespräch zu bleiben, während Turing gelauncht wird.
Zu Vega haben sie auch fast nichts lange vorher oeffentlich gemacht. Da kam nur Quatsch wie ein Bild zum vermeintlichcen Launch venue. Gut, lag vielleicht daran, dass sie schon wussten, dass es nichts wird. Trotzdem wurde Vega natuerlich wieder ueberhypt, insofern waere es vielleicht schon sinnvoll, wenigstens mal irgendwas zu sagen.