News Xbox Series X: Technische Details zur Zen-2-CPU und RDNA-2-GPU

[Taxxor]

Quelle? Ich sehe zum Beispiel bei der Erklärung zu Quake RTX folgendes.
Anhang anzeigen 956122

Ist für mich schlüssig.
In den grünen Parts stellen die FP32 Cores die Anfragen und die RT Cores geben den gesuchten Pfad zurück, der dann von den FP32 cores als Effekt umgesetzt wird.
Quake 2 ist ja soweit ich weiß 100% Raytraced, also fallen nebenher keine nicht-RT Aufgaben für die Cores an, würde die Berechnung auf den RT Cores laufen, würde man an den Stellen nur Grün sehen.
Bei Pascal ist die ganze Linie länger weil die FP32 Cores sowohl den Pfad suchen als auch den Effekt umsetzen müssen.

 

[Tawheed]

Die APU die fast jeder kaufen wollen würde.
Sieht schonmal sehr vielversprechend aus.

 

[Shoryuken94]

Wundert mich das sie 2 CCX genommen haben und nicht ein einziges wie bei Renoir?

Renoir nutzt auch zwei CCX! Mit Zen 2 lässt sich alles über 4 kerne nur mit mehreren CCX realisieren. Hier wird ein großer Unterschied zu Zen 3 sein. Dort wird ein CCX 8 Kerne umfassen.

Die APU die fast jeder kaufen wollen würde.

Wüsste nicht, warum ich die kaufen wollen würde. Im PC wäre die nicht sinnvoll nutzbar. Denn dort bräuchte man dann auch GDDR6 oder HBM2 als Hauptspeicher. Mit normalen DDR4 Speicher wäre das eine ziemliche Gurke.

 

[nazgul77]

OK, Erscheinungsdatum der Xbox mit AMD APU mit RDNA2 ist wohl Ende des Jahres 2020.

Die Renoir-APU mit Zen 2 erschien Anfang des Jahres mit Vega.
Der Nachfolger Cezanne mit Zen 3 und auch Vega vermutlich Anfang 2021. Frage ich mich, warum dort nicht die Kombination Zen3 mit einer abgespeckten RDNA2 möglich ist? Das Design ist ja für die XBox fertig.

 

[Taxxor]

Frage ich mich, warum dort nicht die Kombination Zen3 mit einer abgespeckten RDNA2 möglich ist? Das Design ist ja für die XBox fertig.

Weil das ein komplettes Custom Design ist, was man nicht mal so einfach in eine 65W PC APU umbauen kann.

 

[xexex]

Wenn ich raten müßte läuft die Strahlenverfolgung bei Pascal auf den normalen Shadern ab, bei Turing ohne RT Cores auf den Tensor Cores und mit RT Cores auf den FFUs.

Nein, die Tensor Kerne haben da keinen Einfluss drauf, der Unterschied zu 1080 ergibt sich aus der gleichzeitiger Abarbeitung von Int und FP Befehlen. Erst mit den RT Kernen wird es dann "schnell".

 

[Colindo]

Ich klopf mir schonmal auf die Schulter, dass ich das AMD-Patent Anfang des Jahres richtig analysiert habe

Also keine extra Einheit für RT sondern die bisherige Textureinheit wird genutzt? Könnte das heißen, dass RT auch auf älteren GPUs möglich sein wird?

Die Textureinheiten wurden erweitert, um diese Fähigkeit zu können. Die alten Designs können das nicht

Weil die 380 Gigarays vmtl ein theoretischer Wert ist, der erreicht wird, wenn sich alle 52 CUs dauerhaft um RT kümmern, was in der Praxis aber nicht funktioniert^^

Der wird nur erreicht, wenn lediglich die Textureinheiten arbeiten. Sobald du die Shader fürs Raytracing brauchst, was immer der Fall ist, können die auch der Bottleneck sein.

Es klingt aber so, als wäre AMD deutlich schneller bei Spielen die rein auf Raytracing basieren, wie die Minecraft-Version (wenn ich mich recht erinnere). Vorausgesetzt die FP32-Shader können die 380 GRays/s der Textureinheiten in der Spitze mitmachen. Oder es muss in FP16 programmiert sein, oder sowas....

 

[menace_one]

Wie du im zweiten Link deutlich Zeigst ist es nix weiter als eine Beta.

YT setzt mittlerweile bei fast allen beliebteren clips bis 1080p auf AV1. Beta ist da schon lange nichts mehr.

Tatsächlich sind die meisten Videos mit denen ich Kontakt habe [..]

Ja das Henne Ei Problem, deshalb ist es so ärgerlich, dass die Konsolen keinen HW support bieten.
Damit hätte die Verbreitung einen dringenden Schub bekommen.
Endlich schluss mit dem Lizenz Wirrwarr und neue mandatorische Features wie "Filmgrain Synthesis", damit solche encoding Katastrophen wie Walking Dead der Vergangenheit angehören.

 

[Wadenbeisser]

@xexex

Dann ginge es dabei aber wohl dennoch "nur" um die arbeitsintensive Strahlenverfolgung die bei Turing etwas effektiver abläuft aber erst durch die FFUs richtig beschleunigt wird. Ich gehe mal davon aus das die Berechnung des Effekts selbst der Ausschlag ganz am Ende ist.

 

[Sa.Lt]

halte ich die Diskussion für hinfällig.

ja, deine war es von Anfang an 🤷‍♀️

 

[Teralios]

@xexex
ist es denn so schwer mal einzusehen, dass man von etwas keine Ahnung hat und dass man dann lieber mal den Mund hält, statt mit dem Nichtwissen hausieren zu gehen! Nein, statt dessen zwingst du mich nun den Vorschlaghammer herauszuholen.

Das Phänomen in der Psychologie, dass Menschen ihre eigene Kompetenz als viel zu hoch einschätzen, je weniger sie Kompetent sind trifft hier mal wieder voll zu.

Na gut, dann würde ich dir empfehlen mal das Architektur-Paper von Turing durchzulesen, dort findest du dann folgendes:

" At the heart of Turing’s hardware-based ray tracing acceleration is the new RT Core included in each SM. RT Cores accelerate Bounding Volume Hierarchy (BVH) traversal and ray/triangle intersection testing (ray casting) functions. (SeeAppendix DRay Tracing Overview on page 68 for more details on how BVH acceleration structures work). RT Cores perform visibility testing on behalf of threads running in the SM."

Und dann solltest du dir die Grafik auf Seite 31 ansehen. ...

Klassisch. ... Eines auf dicken Max machen, aber keine Substanz dahinter.

 

[gartenriese]

DLSS 1 lief ja auch noch auf den Shadern und ist erst später auf die Tensorcores gegangen (mit großen Sprüngen beim Ergebnis).

Hast du da eine Quelle für? Genau darüber habe ich nämlich heute früh schon diskutiert und kam dann zu dem Ergebnis, dass DLSS 1.0 eben schon auf den Tensor-Kernen lief. Hier bei dem Bild bei Metro Exodus ist beschrieben, dass die Tensor-Kerne für DLSS benutzt werden. Und im verlinkten Turing-Whitepaper ist es auch so beschrieben.

 

[Colindo]

Wenn die RT Leistung 38 mal höher als bei einer 2080Ti wäre, dann hätten wir in den bisherigen Konsolendemos wohl nicht solche Kompromisse und Optimierungen beim RT gesehen, wie wir es haben.

Ich denke wir sollten als grundlegende Zahl die 95 GRays/s für die Triangle Intersection nehmen. Die 380 merkt man erst dann, wenn man viele Strahlen verwerfen kann.

Ist denn die Texture-Einheit immer so "ausgelastet" dass sie nicht nebenbei eben auch RT Berechnungen machen kann und somit ausbremst.

Das werden sich die Entwickler als Zeitbudget sehr genau anschauen müssen. Bei den RT-Techdemos der letzten Jahre wurde ja auch immer angegeben, welcher Rechenschritt wieviele ms braucht, und was man beachten muss damit am Ende 16,67ms (60fps) eingehalten werden.

 

[Teralios]

Dann ginge es dabei aber wohl dennoch "nur" um die arbeitsintensive Strahlenverfolgung die bei Turing etwas effektiver abläuft aber erst durch die FFUs richtig beschleunigt wird. Ich gehe mal davon aus das die Berechnung des Effekts selbst der Ausschlag ganz am Ende ist.

Richtig, das Durchsuchen eines Baumes - jetzt unabhängig des BVH-Baums beim RT - ist immer recht arbeitsintensiv, weil man je nach Tiefe und Breite des Baumes viele Möglichkeiten hat, aber immer noch effizienter als einfach so zu suchen.

Die Größe des Baumes wird hier anhand Assetzs und Pixel Polygonen bestimmt. Bei Quake 2 RTX findet aber abseits der "BVH"-Suche kaum Shading statt, weswegen hier die Ausschläge nicht sehr hoch sind. Der eigentliche Effekt wird aber auch hier auf der SM mithilfe der FP/INT-ALUs zusammen gerechnet.

So, ich geh mir mal ein Wasser und eine Melone holen, sonst bekomme ich noch Zustände.

 

[Wadenbeisser]

@Sa.Lt

Weil du komplett auf dem Holzweg warst und am Ende in beiden Fällen weitestgehend gleich abläuft?
So wie ich das sehe werden die Daten von einer FFU aufbereitet und am Ende von den Shadern umgesetzt. Der Unterschied ist lediglich der Ort wo sie aufbereitet werden und weniger wie.

 

[Colindo]

Fordert der SM die Abfrage vom BVH-Tree an, dann muss er in der Regel auf die Daten warten, bevor er zum nächsten Schritt kann.

Wenn sich dann noch die RT-Cores und die Shader um die gleiche Speicherbandbreite kloppen, sind die theoretischen Rays eh egal

Wenn die GPU da selbst Machine Learning Kann dann soll sie aber bestimmt was anderes raus finden als den Upscaling Algorithmus.

Sie soll den Algorithmus ausführen. Ist nicht ganz korrekt formuliert, aber kommt aufs Gleiche raus.

 

[Gamefaq]

380 GigaRays/s klingt erst mal viel, wenn NVidias Flaggschriff auf gerade mal 11 kommt. Aber es ließt sich ja so, als ob bei AMD "entweder-oder" gefahren werden muss, wohingegen die 11 GigaRays (oder wie viel auch immer im jeweiligen Modell) bei NVidia parallel/zusätzlich zur Verfügung stehen (also die regulären Shader/Textureinheiten nicht {so stark} dafür benötigt werden)? Hab ich das richtig verstanden?

Genau. Bei nVidia haste du die Tensor Kerne die nur für Raytracing oder DLSS (oder eben die Kombination so wie benötigt) genutzt werden. Bei der Konsole muss es von den Kernen die eigentlich die Grafik berechnen sollen ein Teil exklusiv dann das Raytracing berechnen.
Das hat 2 Nachteile.
Der erste und direkt Logische ist das weniger Leistung für das Spiel selbst bereit steht je mehr Raytracing genutzt wird.
Der Zweite ist das ein spezialisierter Chip wie die Tensor Kerne das ganze effektiver = schneller berechnen kann.

AMD ist hier pragmatisch vorgegangen. Nvidia hat sie mit Raytracing in Hardware überrascht und an den Tensor Kernen nach eigener Angabe 10 Jahre geforscht. Diese Technik kann man nicht mal eben selbst in 2 Jahren (seit dem gibt es die RTX Karten) entwickeln oder kopieren ohne zu wissen wie sie genau funktioniert. Also musste ein Kompromiss her der das auch kann ohne dabei so effektiv oder schnell zu sein aber man hat auf dem Papier diese Technik (wenn auch in anderer Form erzeugt) auch. Sprich wir werden Raytracing auf Konsolen kaum und nur sehr dezent eingesetzt sehen aber AMD/Sony können sagen es ist in den Konsolen vorhanden. Ebenso wird es AMD bei seiner nächsten PC Grafikkarten sagen können. PC Benchmarks die exzessiv Raytracing nutzen werden zeigen wie groß dieser Leistungsunterschied ist.

 

[Teralios]

Wenn sich dann noch die RT-Cores und die Shader um die gleiche Speicherbandbreite kloppen, sind die theoretischen Rays eh egal

Das sowieso, aber das Problem hat NVIDIA auch.

Deswegen haben ja sowohl AMD als auch NVIDIA den Shadern auch einen direkteren Weg zum Cache mit gegeben, statt wie - bis einschließlich Pascal sowie Vega - über die TMUs abzufragen.

Ergänzung (18. August 2020)

...

Grob Falsch, hab jetzt auch genug Beiträge zu dem Thema geschrieben was RT angeht und ehrlich gesagt keine Lust.

Architektur-Paper ist verlinkt. Die Tensore-Cores haben mit RT nichts am Hut. ...

So, ich klinke mich aus. Viel Spaß euch.

 

[Taxxor]

Diese Technik kann man nicht mal eben selbst in 2 Jahren (seit dem gibt es die RTX Karten) entwickeln oder kopieren ohne zu wissen wie sie genau funktioniert.

Du gehst hier davon aus, dass sich AMD bis zum Release der RTX Karten absolut 0 mit Raytracing beschäftigt hat, woher kommt diese Annahme?

Zu den anderen Ausführungen wurde ja schon genug geschrieben, die TMUs bei AMD machen nicht anderes als die RT Cores bei Nvidia und es wird auch bei Nvidia weniger Leistung für das Spiel selbst bereitstehen, je mehr RT genutzt wird, da deren SMs ebensowenig was anderes machen können, während sie auf die RT Cores warten.
Daher ist es auch egal, dass die TMUs nur entweder oder können, da eine CU sowieso nur entweder Raster oder RT Anfragen stellt.

 

[ghecko]

Wie das wohl mit der Speicherbandbreite bei der APU funktioniert? Damit das Ding nicht aushungert muss das Interface ganz schön breit sein, was wiederum viele Pins->teurer BGA bedeutet.