Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Hardware- und Nachrichten-Links des 19. August 2020
Leonidas
2020-08-20, 11:16:29
Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-19-august-2020
Damit kann man dann wohl BN bei RT Heavy Games vergessen, schade.
Das "interessante" an AMDs RT Ansatz ist die Flexibilität. Nutzt ein Spiel wenig RT, müssen auch nur wenige Shader/TMUs abgezogen werden. Bei viel RT Nutzung bleibt dann halt weniger für's klassische Rasterizing übrig. Entsprechend hat man wohl eine relativ gute Auslastung alle Einheiten auf dem Chip. Ob AMDs Ansatz wirklich langsamer als dedizierte Einheiten ist, kann man vermutlich auch nicht pauschal sagen. Ich bin jedenfalls auf erste Tests gespannt.
Aber bisher laufen die Vermutungen ja auch immer gegen Touring, Ampere wird da sicher noch ordentlich was drauf packen. Ich hoffe, AMD wird mit BN zumindest auf 3080 Niveau kommen...
Berniyh
2020-08-20, 12:16:23
Das "interessante" an AMDs RT Ansatz ist die Flexibilität. Nutzt ein Spiel wenig RT, müssen auch nur wenige Shader/TMUs abgezogen werden. Bei viel RT Nutzung bleibt dann halt weniger für's klassische Rasterizing übrig. Entsprechend hat man wohl eine relativ gute Auslastung alle Einheiten auf dem Chip. Ob AMDs Ansatz wirklich langsamer als dedizierte Einheiten ist, kann man vermutlich auch nicht pauschal sagen. Ich bin jedenfalls auf erste Tests gespannt.
Aber bisher laufen die Vermutungen ja auch immer gegen Touring, Ampere wird da sicher noch ordentlich was drauf packen. Ich hoffe, AMD wird mit BN zumindest auf 3080 Niveau kommen...
AMDs Ansatz ist in jedem Fall der pragmatischere, in einer Gamingwelt in der Raytracing nicht sonderlich verbreitet ist.
Troyan
2020-08-20, 12:27:21
Wie genau ist AMDs Ansatz "pragmatischer", wenn das Ding ebenfalls über dedizierte Einheiten läuft, die ohne Raytracing nutzlos rumsitzen?
Berniyh
2020-08-20, 12:34:43
Wie genau ist AMDs Ansatz "pragmatischer", wenn das Ding ebenfalls über dedizierte Einheiten läuft, die ohne Raytracing nutzlos rumsitzen?
Die nehmen weniger Fläche ein und es ist damit kostengünstiger herzustellen und hat weniger Einfluss auf die Leistungsfähigkeit ohne Raytracing (weil man auf gleicher Fläche mehr Rechenpower unterbringen kann).
Ich finde AMDs Ansatz interessant. Er bringt Raytracing kostengünstig in die Konsolenwelt.
Wie performant das ist wird sich zeigen. Bis dahin lese ich amysiert von den Hoffnungen und Wünschen der "Fans".
Troyan
2020-08-20, 12:51:06
TU106 hat 10,7 Mrd. Transistoren und Navi hat 10,3 Mrd. Der Unterschied liegt also bei 3,8% mehr Transistoren (inkl. TensorCores, entkoppelte INTs, mehr Features etc.).
AMDs Ansatz ist daher nicht "kostengünstiger".
TU106 hat 10,7 Mrd. Transistoren und Navi hat 10,3 Mrd. Der Unterschied liegt also bei 3,8% mehr Transistoren (inkl. TensorCores, entkoppelte INTs, mehr Features etc.).
AMDs Ansatz ist daher nicht "kostengünstiger".
Das kannst ja nur bedingt vergleichen. Der TU106 ist über 1,5 mal größer als Navi10, der dazu eben noch keine RT Implementierung hat.
Complicated
2020-08-20, 13:13:14
Gemäß des hierzu vorliegenden Blockdiagramms einer "Dual Compute Unit" (beeinhaltet zwei Shader-Cluster) existiert parallel zu den Textureneinheiten eine "RayTracing Acclerator Unit" mit eben diesem Zweck. Dies bedeutet dann auch, dass RDNA2-Grafikchips zeitgleich nur entweder RayTracing berechnen oder Texturieren können – was aber wohl kaum eine relevante Einschränkung darstellt, sondern vielleicht sogar ganz zweckmäßig ist. AMDs RayTracing-Ansatz verwendet dann desweiteren großzügig die eigentlichen Shader-Einheiten zur RayTracing-Berechnung, dürfte somit nicht ganz so performant wie nVidias RayTracing-Ansatz sein, kommt dafür jedoch vergleichsweise Transistoren-sparend daher.
Ich denke diese Aussage ist falsch. Worauf basiert dein Schluß hier?
Siehe Details in diesem Artikel:
https://www.hardwaretimes.com/xbox-series-x-gpu-architecture-deep-dive-ray-tracing-mesh-shading-sampler-feedback-and-vrs/
Vergleich zu Nvidias Turing:
The actual implementation is identical. The BVH is offloaded to the dedicated hardware while the primary shaders continue to work as normal.
Edit: Like NVIDIA’s RTX, XSX also uses ray-tracing for lighting based effects only such as shadows, reflections, Global Illumination/Ambient Occlusion, etc, while the rest of the rendering is done using standard rasterization.
Auch in diesem Slide ist es explizit bestätigt:
https://www.hardwaretimes.com/wp-content/uploads/2020/08/yTqYSzDr3MGWc2QzhGR4CN-1920-80-1024x576.jpg
https://www.hardwaretimes.com/wp-content/uploads/2020/08/yTqYSzDr3MGWc2QzhGR4CN-1920-80-1024x576.jpg
Ich finde AMDs Ansatz interessant. Er bringt Raytracing kostengünstig in die Konsolenwelt.
Wie performant das ist wird sich zeigen. Bis dahin lese ich amysiert von den Hoffnungen und Wünschen der "Fans".
Es stellt sich am Ende die Frage, ob es einen AMD Ansatz für Raytracing überhaupt gibt. M
Microsoft und Sony dürften die Mindestanforderungen hinsichtlich der Leistungsfähigkeit von AMD's Raytracing schlicht und ergreifend in den ERs festgelegt haben.
Das "interessante" an AMDs RT Ansatz ist die Flexibilität. Nutzt ein Spiel wenig RT, müssen auch nur wenige Shader/TMUs abgezogen werden. Bei viel RT Nutzung bleibt dann halt weniger für's klassische Rasterizing übrig. Entsprechend hat man wohl eine relativ gute Auslastung alle Einheiten auf dem Chip. Ob AMDs Ansatz wirklich langsamer als dedizierte Einheiten ist, kann man vermutlich auch nicht pauschal sagen. Ich bin jedenfalls auf erste Tests gespannt.
Aber bisher laufen die Vermutungen ja auch immer gegen Touring, Ampere wird da sicher noch ordentlich was drauf packen. Ich hoffe, AMD wird mit BN zumindest auf 3080 Niveau kommen...
Das das kein paralleles Tex & Rt möglich ist ist die eine Sache das aber BVH noch durch die Shader muss wird wohl wessentlich härter die Performance treffen.
Booby
2020-08-20, 14:03:24
AMDs RayTracing-Ansatz verwendet dann desweiteren großzügig die eigentlichen Shader-Einheiten zur RayTracing-Berechnung, dürfte somit nicht ganz so performant wie nVidias RayTracing-Ansatz sein
Das ist schlicht falsch, auch bei Turing werden die meisten Raytracing Berechnung im Shader gemacht. Die RT-Cores durchsuchen "nur" den BVH-Tree.
In kurz: Bei NVIDIA sendet der Shader seine Anfrage an den RT-Core, bei AMD an die TMU. Beide warten das Ergebnis ab und der Shader rechnet weiter.
Ich denke diese Aussage ist falsch. Worauf basiert dein Schluß hier?
Siehe Details in diesem Artikel:
https://www.hardwaretimes.com/xbox-series-x-gpu-architecture-deep-dive-ray-tracing-mesh-shading-sampler-feedback-and-vrs/
Vergleich zu Nvidias Turing:
Auch in diesem Slide ist es explizit bestätigt:
https://www.hardwaretimes.com/wp-content/uploads/2020/08/yTqYSzDr3MGWc2QzhGR4CN-1920-80-1024x576.jpg
https://www.hardwaretimes.com/wp-content/uploads/2020/08/yTqYSzDr3MGWc2QzhGR4CN-1920-80-1024x576.jpg
Da steht deutlich drin das BVH trav. über die Shader läuft , ob die das effizienter und schneller als Fixed Funtion Units können kannst du ja mal oraceln.
Lehdro
2020-08-20, 14:22:35
TU106 hat 10,7 Mrd. Transistoren und Navi hat 10,3 Mrd. Der Unterschied liegt also bei 3,8% mehr Transistoren (inkl. TensorCores, entkoppelte INTs, mehr Features etc.).
AMDs Ansatz ist daher nicht "kostengünstiger".
Man vergleicht einfach mal so zwei Chips und stellt dann fest welcher besser ist, einfach aufgrund der Transistoranzahl, den Rest lässt man weg. Vorallem dass man den Vorgänger 1:1 mit dem neuen RDNA2 Design gleichsetzt ist äußerst forsch von dir.
Völlig unabhängig von:
- I/O Ballast (wer braucht mehr Transistoren für das "Drumherum", Decoder, Encoder etc)
- den Taktraten/Kühlung etc
- der erreichten Leistung (https://www.3dcenter.org/artikel/fullhd-ultrahd-performance-ueberblick-2012-bis-2019)
- der erreichten Leistung bei Shader, Bandbreiten und Taktgleichheit (https://www.computerbase.de/2019-07/radeon-rx-5700-xt-test/4/#abschnitt_navi_vs_vega_vs_turing_vs_pascal)
- der Effizienz
- der vielen anderen Dinge die man noch zu beachten hat
Aber sehr interessant, dieser Äpfel <-> Birnen Vergleich, bei dem du alles außer die Transistorenanzahl ausblendest, besonders die Konklusio spricht mich durch ihre bestechende Logik an. :freak:
Troyan
2020-08-20, 14:31:57
Das ist schlicht falsch, auch bei Turing werden die meisten Raytracing Berechnung im Shader gemacht. Die RT-Cores durchsuchen "nur" den BVH-Tree.
In kurz: Bei NVIDIA sendet der Shader seine Anfrage an den RT-Core, bei AMD an die TMU. Beide warten das Ergebnis ab und der Shader rechnet weiter.
Die RT Cores durchaufen das BVH und machen die Intersection-Tests.
pixeljetstream
2020-08-20, 15:16:47
Das ist schlicht falsch, auch bei Turing werden die meisten Raytracing Berechnung im Shader gemacht. Die RT-Cores durchsuchen "nur" den BVH-Tree.
In kurz: Bei NVIDIA sendet der Shader seine Anfrage an den RT-Core, bei AMD an die TMU. Beide warten das Ergebnis ab und der Shader rechnet weiter.
Das “durchsuchen” ist aber der entscheidende Unterschied. Der RT Core kann das, AMD nutzt dafür wieder shader Code. Sprich die TMU lädt und testet immer nur ne fixe anzahl Boxen/triangles pro Anfrage, während der rtcore bis zum finalen Resultat durchläuft.
Leonidas
2020-08-20, 16:35:37
Ich denke diese Aussage ist falsch. Worauf basiert dein Schluß hier?
Siehe Details in diesem Artikel:
Was wird das konkret bestätigt und auf was bezieht sich das "im Ansatz gleich" konkret? Die könnten was ganz anderes meinen. Konkret meinen die wohl eher, wofür RT eingesetzt wird - nicht hingegen die technische Ausführung.
Ich beziehe mich hingegen klar nur auf die technische Ausführung. Die fängt bei NV in den RT-Cores an, bei AMD in der Nähe der TMUs. Dann geht es bei beiden weiter in den Shader-Cores. NVs Ansatz ist auf mehr Performance ausgerichtet, AMDs auf mehr Flexibilität und geringen Xtors-Einsatz. Wo beide am Ende bei der Performance herauskommen, ist natürlich derzeit unklar - aber es würde doch sehr verwundern, wenn der NV-Ansatz real langsamer wäre.
Das ist schlicht falsch, auch bei Turing werden die meisten Raytracing Berechnung im Shader gemacht. Die RT-Cores durchsuchen "nur" den BVH-Tree.
Das will ich überhaupt nicht anzweifeln. Habe ich aber auch nicht in Frage gestellt. Meine Aussage, das NVs Lösung vermutlich performanter sei, war keine direkter Verweis darauf, das NV nicht die Shader-Cores nutzt.
GastII
2020-08-20, 16:37:35
Dedizierte RT-Einheiten (https://www.youtube.com/watch?v=tOdaU0u9c3U&t=18m) haben sogar auf 22mm² Smartphone-GPUs Platz und sind um ein Vielfaches effektiver als Shader (https://www.youtube.com/watch?v=ND96G9UZxxA&t=120).
Complicated
2020-08-20, 17:00:25
Der Satz bleibt dennoch falsch
Dies bedeutet dann auch, dass RDNA2-Grafikchips zeitgleich nur entweder RayTracing berechnen oder Texturieren können
Linmoum
2020-08-20, 17:07:52
Nein, der Satz ist richtig. Entweder oder, beides zeitgleich ist nicht. Vorletzter Punkt.
https://cdn.mos.cms.futurecdn.net/fqvK7bgMNGxQdNKNnHKZHQ-2560-80.jpg
Wie aber bereits gesagt, dass ist mehr theoretischer als praktischer Natur.
Das "oder" bezieht sich auf die CUs, die news schreibt aber RNDA2-Grafikchip.
FrozenPie
2020-08-20, 17:22:52
Nein, der Satz ist richtig. Entweder oder, beides zeitgleich ist nicht. Vorletzter Punkt.
https://cdn.mos.cms.futurecdn.net/fqvK7bgMNGxQdNKNnHKZHQ-2560-80.jpg
Wie aber bereits gesagt, dass ist mehr theoretischer als praktischer Natur.
Nein, der Satz ist falsch, da in dem Satz gesagt wird, dass der gesamte Grafikchip entweder nur Raytracing oder nur Texturierung innerhalb eines Taktes machen kann, was aber nur auf die CU beschränkt ist. Es kann also theoretisch pro Takt 1 Ray Operation und 51 Texture Operationen (Bei 52 CUs) durchgeführt werden oder umgekehrt oder in beliebigem Verhältnis zueinander (je nach dem was mehr gebraucht wird).
Eine CU kann 4 Texture Operationen ausführen, zeitgleich kann eine andere CU 4 Ray Operationen ausführen. So steht es zumindest auf deiner Folie. "4 Texture or Ray ops/clk per CU" und nicht der gesamte Chip kann nur Raytracing oder Texturierung innerhalb eines Taktes ;)
Gemäß des hierzu vorliegenden Blockdiagramms einer "Dual Compute Unit" (beeinhaltet zwei Shader-Cluster) existiert parallel zu den Textureneinheiten eine "RayTracing Acclerator Unit" mit eben diesem Zweck.
Also eigentlich (fast) gleich wie bei Nvidia, auch bei Nvidia sind die RT-Einheiten Co-Prozessoren im Shadercore vergleichbar mit den TMUs.
Dies bedeutet dann auch, dass RDNA2-Grafikchips zeitgleich nur entweder RayTracing berechnen oder Texturieren können – was aber wohl kaum eine relevante Einschränkung darstellt, sondern vielleicht sogar ganz zweckmäßig ist.
Naja, GPUs leben davon, dass tausende Threads parallel ausführen, RT und Texuroperationen dauern beispielsweise vergleichsweise lange, so dass es für eine gute Auslastung unerlässlich ist dass Einheiten parallel arbeiten können, wobei die Einschränkung TMU und RT nicht parallel abarbeiten zu können nicht so groß sein sollte.
AMDs RayTracing-Ansatz verwendet dann desweiteren großzügig die eigentlichen Shader-Einheiten zur RayTracing-Berechnung,
Wie auch bei Nvidia, im Grunde lauft Raytracing komplett im Shader, diese können nur für bestimmte Operationen, nämlich den Intercection Test, die dezidierten Einheiten verwenden. Deshalb bringt es auch nichts großartiges, einfach die RT-Einheiten zu vervielfachen und zu hoffen, dass die Leistung mit Raytracing dann weniger einbricht.
dürfte somit nicht ganz so performant wie nVidias RayTracing-Ansatz sein,
Davon ist hier absolut nichts zu sehen, im high level funktioniert AMDs Raytracing praktisch identisch zu Nvidia. Einzig die Einschränkung TMU und RT nicht gleichzeitig zu können, könnte evtl. ein kleiner Nachteil sein, wobei auch nicht so ganz klar ist wieviel Nvidia hier wirklich gleichzeitig kann, könnte durchaus sein dass es beispielsweise auch bei Nvidia Bandbreitenlimits oder ähnliches geben kann, die eine volle Auslastung aller Einheiten nicht möglich macht.
kommt dafür jedoch vergleichsweise Transistoren-sparend daher.
Nvidias RT-Ansatz braucht ca. 10% Transistoren einer vollen GPU. Es ist kaum vorstellbar, dass AMDs Ansatz hier noch großartig weniger verbraucht.
Eventuell ist es noch ein paar Prozent weniger weil man sich Datenleitungen zwischen TMU und RT-Einheit teilt.
Im Grunde sieht das fast 1:1 wie Nvidias Umsetzung in Turing aus, ob Nvidia bei Ampere hier noch viel ändert wissen wir ja noch nicht.
Complicated
2020-08-20, 19:27:47
Das "oder" bezieht sich auf die CUs, die news schreibt aber RNDA2-Grafikchip.
Richtig.
"4 Texture or Ray ops/clk per CU"
Und selbst das halte ich noch nicht für so klar, denn es könnten ebenso 2xText+2xRay (3+1, 1+3)mit dieser Formulierung gemeint sein. 4 ops pro CU/clk, die Txt oder Ray beinhalten.
Vermutlich sind 2+2 möglich, da die Dual-CU auf dem Schaubild für jede CU (CU0 und CU1) separate Ray+Txt Einheiten eingezeichnet hat, mit jeweils gemeinsamem L0$ pro Pärchen. Daher denke ich, dass da auch 2 verschiedene Ops möglich sind pro Dual-CU, da ansonsten das Aufteilen unnötig wäre und man für jede Dual-CU mit halb so vielen Texture-Einheiten auskommen würde.
Booby
2020-08-20, 20:28:20
Das will ich überhaupt nicht anzweifeln. Habe ich aber auch nicht in Frage gestellt. Meine Aussage, das NVs Lösung vermutlich performanter sei, war keine direkter Verweis darauf, das NV nicht die Shader-Cores nutzt.
Woher kommt diese Annahme?
Die Architekturdiagramme geben diese Schlussfolgerung nicht her.
Und reden wir hier von Turing oder Ampere?
AMD hatte zusammen mit Sony und Microsoft zwei Jahre mehr Zeit.
Da wird was ordentliches dabei herauskommen.
Digidi
2020-08-21, 02:56:13
Das “durchsuchen” ist aber der entscheidende Unterschied. Der RT Core kann das, AMD nutzt dafür wieder shader Code. Sprich die TMU lädt und testet immer nur ne fixe anzahl Boxen/triangles pro Anfrage, während der rtcore bis zum finalen Resultat durchläuft.
Die Entscheidente Frage ist doch wie viele Takte brauchen beide Einheiten um zum Finalen Ergebnis zu kommen und welche der beiden Einheiten braucht weniger Platz. Wenn AMDs Ansat weniger Takte braucht und man auch noch mehr Einheiten auf den Chip bekommt da diese kleiner ausfallen wäre das dann ein Vorteil.
Leonidas
2020-08-21, 04:54:45
Der Satz bleibt dennoch falsch
Das korrigiere ich gern. Wo finde ich dazu handfeste Belege?
Eine CU kann 4 Texture Operationen ausführen, zeitgleich kann eine andere CU 4 Ray Operationen ausführen. So steht es zumindest auf deiner Folie. "4 Texture or Ray ops/clk per CU" und nicht der gesamte Chip kann nur Raytracing oder Texturierung innerhalb eines Taktes ;)
Das würde bedeuten: "Nicht zeitgleich pro CU".
pixeljetstream
2020-08-21, 10:31:09
Die Entscheidente Frage ist doch wie viele Takte brauchen beide Einheiten um zum Finalen Ergebnis zu kommen und welche der beiden Einheiten braucht weniger Platz. Wenn AMDs Ansat weniger Takte braucht und man auch noch mehr Einheiten auf den Chip bekommt da diese kleiner ausfallen wäre das dann ein Vorteil.
IMO ist der Vorteil für die Konsole die Flexibilität, weil die Entwickler die intrinsics für alles mögliche nutzen können, bin gespannt was davon auf dem PC landet. Dort ist die Abstraktion der api so, dass die ganze Traversal Loop und die Organisation des Baums eine Blackbox ist (auch in dxr1.1). (Allerdings hätte NV ja auch intrinsics, nur am PC möchte man sich offenhalten das Design mit der nächsten Generation verändern zu können, bei der Konsole ist das langlebiger).
Der Nachteil ergibt sich nicht wenn man auf die clocks eines traversals guckt, sondern wie sich die gesamte gpu verhält. Und da kann mit dem CU-zentrischen Ansatz einfach nicht so viel andere Arbeit noch in flight sein, weil mit jeder Traversierungsiteration man hin und zurück muss. Das bedeutet mehr wavefronts sind aktiv gehalten die traversieren. Bei NV kann man die warps die auf das Ergebnis warten länger schlafen legen und dadurch den warps, die schon ein Ergebnis haben, mehr Aktivität verpassen. Und da mehr in hw gegossen ist, ist es effizienter. Du kannst davon ausgehen, dass NV sich der unterschiedlichen tradeoffs bewusst ist und auch die Mittel hat das zu simulieren.
Es geht hier IMO eher um was den Herstellern design philosophisch wichtiger war, absolute Performance als Teil einer abstrakten API, oder halt das wissen dass auf Konsolen die Entwickler sowieso mehr rausholen können. Daher ist spannend wie es sich am PC Verhalten wird. Insbesondere auch wo Intel sich dann in dem Spektrum der Lösungen einordnet.
Ich denke AMD wird auf built-in functions (aka Intrinsic) setzen. Warum auch nicht? Schließlich stellt man auch die Konsolen SOCs. Meiner Meinung nach mach dies auch gerade am Anfang sinn, eben weil die GameDeveloper sich daran austoben sollten. Wenn die nächste GPU Generation wirklich inkompatibel zu den built-in functions werden sollte, dann sollten sie so schnell sein um mit DXR (dann ohne die "alten" built-in functions) mithalten zu können.
Zudem wird sich DXR in nächster Zeit sicher noch extrem ändern.
Screemer
2020-09-07, 21:30:37
Das korrigiere ich gern. Wo finde ich dazu handfeste Belege?
ich geh da mit complicateds annahme. geht man nach dem schaubild, dann können die dual-cus jeweils 2x2 operationen gleichzeitig ausführen.
Complicated
2020-09-07, 21:34:04
4+4, da je CU 4 ops/clk. 2xCU= 4+4 ops. pro Dual-CU.
Es könnte aber wie gesagt sogar für jede CU 2+2 sein IMHO, der Formulierung nach.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.