PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Gerüchteküche: AMDs Navi-Chip mit veränderten Shader-Clustern und ...


Leonidas
2019-05-22, 15:21:27
Link zur News:
https://www.3dcenter.org/news/geruechtekueche-amds-navi-chip-mit-veraenderten-shader-clustern-und-insgesamt-2560-shader-einhe

Gast
2019-05-22, 16:09:27
Falschen Monat erwischt :)
Die Computex beginnt Ende Mai, nicht Ende Juni.

Gast Ritis
2019-05-22, 16:29:00
Zur Shader-Performance zu den GTX fehlt dann aber wohl immer noch ein funktionierender Draw Stream Binning Rasterizer.

Mal sehen was AMD von den versprochenen Vega-Features noch umsetzt oder begräbt. Das könnte richtig interessant werden.

Ansonsten - mindestens eine Tonne Salz zu dem Leak ;D

Leonidas
2019-05-22, 16:45:42
Falschen Monat erwischt :)
Die Computex beginnt Ende Mai, nicht Ende Juni.


Logisch. Gefixt.

cat
2019-05-22, 17:06:11
Ich finde, dass sich Gipsels Erklärung sehr danach anhört als ob man dadurch das Latency-Hiding torpediert. Also von 4 auf 2 Takte zu gehen ist echt sportlich.
Außerdem scheint der Ansatz nich bei dem eher nötigen feineren Packen der Wavefronts ansich zu helfen.
Solange die Menge an potenziellem Müll in den Wavefronts nicht weniger wird kann sowas bei der Symptombekämpfung natürlich etwas helfen aber der Weisheit letzter Schluss ist es bestimmt nicht.
Beeindruckend falls good-old-GCN soeinen starken Eingriff erlauben würden.

"Zu viel Salz ist nicht gut für den Blutdruck"

Complicated
2019-05-22, 17:25:50
Also von 4 auf 2 Takte zu gehen ist echt sportlich.

Dazu konnte ich nichts im Artikel finden. Könntest du mal zitieren wo eine Änderung von 4 auf 2 Takte erwähnt wird und wofür?

Gast
2019-05-22, 17:40:11
Breitere SIMDs zu verwenden führt allerdings nicht unbedingt zu mehr Performance/ALU, eher im Gegenteil.

Wieviele ALUs man braucht um die gewünschte Performance zu erreichen ist auch erstmal irrelevant, viel wichtiger ist es wieviele ALUs man verbauen kann und welche Performance dabei rauskommt.

Die Nvidia-Architektur mit der besten Performance/ALU ist immer noch Fermi. Fermi hat allerdings auch viel mehr Tranistoren/ALU gebraucht.

Mit Kepler ging es dann komplett in die andere Richtung, eigentlich wurde Kepler ähnlicher zu GCN, man brauchte pro verbauter ALU deutlich weniger Transistoren, konnte aber dafür deren Anzhahl dramatisch anheben.

Seit dem geht es wieder in die andere Richtung, mit Maxwell stieg die Leistung/ALU (und damit auch der Tranistorenaufwand) wieder an, Pascal blieb annähernd gleich und Turing braucht wieder deutlich mehr Transistoren/ALU und erreicht damit auch bessere Performance.
Wobei der Vergleich mit Turing natürlich nicht ganz einfach ist, da man dort viel mehr spezialisierte Einheiten zusätzlich zu den FP32 ALUs verwendet.

cat
2019-05-22, 23:22:50
Dazu konnte ich nichts im Artikel finden. Könntest du mal zitieren wo eine Änderung von 4 auf 2 Takte erwähnt wird und wofür?

Der untere Link im Artikel verweist auch eine Antwort vom Moderator Gipsel
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12000532#post12000532

In dem erwähnt er, dass: ZITAT
""Dies würde z.B. erklären, warum es jetzt (also ab Navi) Register-Bank-Konflikte geben kann (falls die Registerfiles identische Bandbreite behalten), da man nur noch 2 Takte (statt 4 Takte) Zeit hat, alle Operanden zu lesen.""

Natürlich bräuchte jede Wavefront immernoch 4 Takte zum abarbeiten, aber die Sache mit den Operanden war das was ich meinte.

Complicated
2019-05-23, 05:20:19
Danke. Also keine Taktänderungen, sondern eine Anpassung an die größeren SIMD, derer es nur noch 2 pro CU gäbe anstatt 4.

Gast
2019-05-25, 21:49:05
Danke. Also keine Taktänderungen, sondern eine Anpassung an die größeren SIMD, derer es nur noch 2 pro CU gäbe anstatt 4.

Naja, die koplortierten Änderungen werden sicher nicht die Performance pro Takt und ALU steigern, wenn dann eher das Gegenteil, da damit Pipeline-Bubbles wahrscheinlicher werden.

Wenn diese Änderung wirklich so kommt, dann um evtl. den Energieverbrauch zu verringern und damit höhere Taktraten zu ermöglichen. Oder man hat an dieser Stelle Transistoren gespart um sie an anderer Stelle zu verwenden, und kommt damit im Endeffekt beispielsweise durch größere Caches und der Möglichkeit mehr Wavefronts in der GPU zu halten effektiv zu mehr Performance, bzw. kann die Nachteile durch die größeren SIMDs ausgleichen.

Weil auch immer wieder von Raytracing die Rede ist, zumindest bei der Navi-Basierten PS5.
Ein Grund warum Raytracing auf aktuellen GPUs trotz guter Parallelisierung eher bescheiden läuft ist, das Raytracing stark zum Cache-Trashing neigt.

Nvidia hat dafür beispielsweise alle möglichen Caches in Turing teils massiv vergrößtert, wesbhalb auch die RTX-losen Turings für Raytracing wesentlich besser als Pascal geeignet sind.

Es wäre also durchaus denkbar, dass AMD bei Navi zwar keine direkte RT-Hardware einsetzt, aber generell die GPU so gebaut hat, dass diese für RT besser geeignet ist.