• Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!

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

gartenriese schrieb:
Warum denn nicht? Die Spiele an sich sind ja nicht grafikkartenspezifisch programmiert, sondern benutzen die APIs (DirectX und Vulkan).

Es gibt bis heute keine Vulkan RT API, die Spiele die mit RT und Vulkan hergestellt wurden, unterstützen logischerweise kein DXR sondern basieren auf Nvidias RTX Erweiterungen.

Anders ausgedrückt, es sollten theoretisch alle DXR Spiele auch auf AMD Grafikkarten laufen, wenn der Hersteller nicht einer Abfrage eingebaut hat, es ist aber unwahrscheinlich, dass auch die Vulkan Spiele mit RT einfach so auf AMD Karten funktionieren.
 
Shoryuken94 schrieb:
Was nachdenklich stimmt ist die Raytracing und AI Umsetzung. Das die TMUs zwischen RT und normalen Berechnungen entscheiden müssen, ist schon ein Nachteil, wenn ich das richtig interpretiere.
Sehe ich als Vorteil weil der Entwickler flexibel darin ist wie er die Einheiten nutzt. Bei einem PC wäre ich bei dir weil nicht für eine konkrete Konfiguration entwickelt wird. Auf der Konsole macht das dagegen Sinn.
 
@Glyphus Soweit ich weiß, wird die Struktur immer so aufgebaut, dass man erst ein Polygon in je eine Box steckt, und danach aus mehreren Boxen eine größere zusammenstellt. Wenn also die TMUs nur die Strahldurchquerung der Boxen berechnen, sollte am Ende klar sein, welches Polygon getroffen wird. Dabei können 4 TMUS logischerweise 4 Boxen gleichzeitig durchtesten, also kommt man von 3 möglichen Polygonen direkt in einem Schritt zum richtigen Polygon.

PS: Ein Strahl kann auch durch mehrere Polygone fliegen, wenn ein Teil des Polygons transparent ist. Besonders bei Bäumen eine sehr lästige Sache, da das bedeutet, dass ein neuer Strahl erstellt werden muss, der den Raum hinter dem ersten Polygon durchläuft. Also werden doppelt so viele Strahlen benötigt.
 
Zuletzt bearbeitet: (Falsche Person zitiert)
xexex schrieb:
Es gibt bis heute keine Vulkan RT API, die Spiele die mit RT und Vulkan hergestellt wurden, unterstützen logischerweise kein DXR sondern basieren auf Nvidias RTX Erweiterungen.
Hier geht es um eine Konsolen APU, da interessiert das ohnehin niemanden weil die ihre eigenen APIs mitbringen und die Spiele dafür entwickelt werden.
Wie das nachher auf dem PC ausschaut muss sich dann erst zeigen aber die Vermutung liegt nahe das nvidia die Konkurrenz bei ihrer Vulkan Erweiterung blockt.
 
Taxxor schrieb:
Wie kommst du überhaupt darauf, dass das die Leistung wäre wenn alle TMUs sich mit RT befassen?

Weil das so in der News steht und Microsoft das selber angegeben hat:

Entsprechend gibt Microsoft die RT-Performance mit 380 Gigarays pro Sekunde an (52 CUs * 4 RT * 1,825 GHz).

Sag mal liest du auch den Inhalt (und verstehst ihn) oder pickst du dir immer nur einzelne Elemente heraus um diese dann aus dem Kontext herausgerissen zu kommentieren, mit einem Kommentar der mit der Antwort zuvor nichts zu tun hatte nur um diese Diskussion unendlich am leben zu halten?
 
Wadenbeisser schrieb:
Hier geht es um eine Konsolen APU, da interessiert das ohnehin niemanden weil die ihre eigenen APIs mitbringen und die Spiele dafür entwickelt werden.

Trifft allerdings auch nur auf Sony zu, die Xbox setzt auf DXR, bzw. DirectX Ultimate. Hat aber mit der eigentlichen Behauptung, man könnte alle bereits erhältlichen RT Spiele auch auf den kommenden AMD Karten spielen, nichts zu tun, wobei sich die Anzahl an Vulkan RTX Titeln eh in Grenzen hält.
 
  • Gefällt mir
Reaktionen: gartenriese
@xexex

Wie gesagt, das muss sich auf der PC Plattform erst noch zeigen. Wieviele RT Spiele gibt es denn für Vulkan?
 
@xexex Du hast schon Recht, dass RT bei Vulkan ein Spezialfall ist. Allerdings gibt es schon länger bei neuen Grafikkartentreibern die Meldung, dass weitere Vulkan-RT-Erweiterungen unterstützt werden. Ist halt die Frage, ob die Vulkan-RT-Spiele wirklich nur Nvidias ursprüngliche Erweiterung unterstützen, oder alle bisher erschienenen.
Quelle: https://en.wikipedia.org/wiki/Vulkan_(API)#Real-time_ray_tracing
 
Zuletzt bearbeitet: (Quelle hinzugefügt)
Colindo schrieb:
@Gamefaq Bisher ist mir nur aufgefallen, dass du nach jeder Antwort, die dir gegeben wird, einen neuen Kritikpunkt auspackst.

Von deinem ursprünglichen "AMD hatte zuwenig Zeit" habe ich schon länger nichts gelesen.

Ursprünglich wollte ich hier aus dem Thema schon raus sein. Taxxor zitiert nur ständig aus dem Kontext herausgerissene Inhalte von mir. Weshalb ich jetzt mich wirklich verabschieden werde aus dem Thema, weil bis die neuen Grafikkarten da sind (die Konsolen selbst hier interessieren mich null) gibt es eh nichts mehr zu sagen da nur Spekulation.
 
  • Gefällt mir
Reaktionen: Colindo
Gamefaq schrieb:
Ich werde nicht hier mit Fanboys spekulieren was sein könnte , es zählt nur was ist. Und stand jetzt ist die Art wie es AMD integriert hat mehr eine Alibi Funktion = für die Feature Checkliste gedacht damit man sagen kann, man hat es auch.
Das einzige an "Alibi-Funktion" die ich lese ist die "Fanboy-Karte". Ab dem Moment braucht man den Kommentar meist nicht mehr weiterlesen, weil man weiß, dass nichts kommen wird.
Es ist lächerlich zu glauben, dass NV RT erfunden hat. Aus irgendwelchen Gründen frisst man den Aussagen von NV aus der Hand. Die sind immer schnell mit neuer Technologie und angepassten Chips, leider zeigt sich der Nachteil immer wieder, wesentlich teurer.

Zu glauben AMD Ansatz wäre billig, ist selbst als Aussage billig. Wieso ?
Weil es immer wesentlich schwerer ist, ein Feature in ein bestehendes System hineinfließen zu lassen, als etwas neues ranzuhängen und das wird sich in Zukunft auch nicht ändern.

Wie ich gesagt habe, Bsp FreeSync. Manche kommen immer noch mit dem "technisch" besseren Ansatz für Gsync. Fakt ist, es hat sich nicht so durchgesetzt, weil AMD Ansatz eine Technologie "offen" in das breit ex. Ökosystem einbindet.
Das beste Beispiel ist Tessellation. Da gab es auch unterschiedliche Ansätze, durchgesetzt hat dann jener, den AMD und MS für die XBOX 360 und DX entwickelt haen.

MS hat aber dieses mal frühzeitig dieses Problem darin gelöst, dass sie mit AMD, NV und Intel frühzeitig an einer gemeinsamen API zusammengearbeitet haben. Kurz, von DXR aus werden höchstwahrscheinlich NV, Intel und AMD GPUs gleich arbeiten und ich wage zu behaupten, dass MS hier Extrawürstchen machen wird, sondern maximale Erweiterungen einführen wird, die für alle zugänglich sind.
Und nur zu Info, Intel kommende GPUs können auch RT. Und die haben weit aus früher Hardware mit RT Hardware Funktionen am Markt gehabt als NV. Oder google mal PowerVR Ray Tracing.

Der Grund wieso das Zeug jetzt erst kommt hat aber einen anderen. RT benötigt viel an Shader-Performance. Die Hauptlast, wie in vielen Beitragen zuvor zu lesen gewesen, liegt bei den Shader, weniger bei den RT-Cores.
Die Aufgabe die die RT-Cores übernehme sind für Shader einfach zu ineffizient zu berechnen. Sie ist per Software aber umzusetzen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: yummycandy und Teralios
Gamefaq schrieb:
Aber danke für diesen Lacher aus der Marketingabteilung.
Essen geholt, neue Kraft, also legen wir mal los:

Es gibt hier nur zwei Personen, die hier wirklich für Lacher sorgen, weil sie zeigen, dass sie keine Ahnung von der Materie haben, hier aber meinen eines auf Dickehose zu machen. Das bist du und das ist @xexex der immer noch nicht kapiert, dass seine ganzen Aussagen meiner primären Aussage nicht widersprechen. Er gibt sich aber wenigstens Mühe, das rechne ich ihm hoch an.

Du hingegen versuchst hier einen großen Haufen abzusetzten, kannst es aber nicht und ehrlich gesagt: Es nervt mich langsam gewaltig, dass Leute ohne grundlegende Ahnung von Hardware, Software und Programmierung hier jedes mal meinen andere anzumaulen, sich hier als Oberschlau hinzustellen und am Ende überhaupt nichts drauf haben, weil ihnen grundlegende Kenntnisse fehlen. Hätten sie diese, würden sie 90% ihrer Aussagen schon selbst revidieren können.

Und entschuldige bitte die direkte Wortwahl, aber mich nervt es wirklich, weil fast 100% hier einfach unnötig ist. Ich habe mir Mühe gegeben, sehr genau zu erklären was Sache ist. Wenn du über die RT-Umsetzung von AMD mehr weißt, dann schieß los, ansonsten sage ich dir nun genau das, was du forderst:

Abwarten und Tee trinken, die Tests werden es am Ende zeigen, wie gut oder schlecht AMDs Umsetzung ist. Das hast aber weder du noch Xexex getan, sondern ihr schwadroniert hier rum, dass das alles ja nichts ist, und das NERVT!

Entweder du besuchst nen Informatikstudium die Grundkurse und dann ein Seminar für 3d-Berechnung, dann können wir wirklich sinnvoll diskutieren, ansonsten bringt das nichts, weil ich mich immer und immer weiderholen muss.

Deswegen noch mal:

Gamefaq schrieb:
Ist das nicht genau das was sie nicht wollten?! Ja sie geben die Raytracing Leistung sogar mit 380 Gigarays an wenn alle CU genutzt werden. Ja und was soll dann die restliche Grafik berechnen wenn alle CU nur Raytraycing berechnen? Nochmals das ist Marketing BLABLA der großen Zahlen die als Blender fungieren sollen. Nimm mal die Rosarote Brille ab und sie was real ist.
Und das geht jetzt auch wieder an Xexex:

Beschäftigt euch bitte mit Hardware und Software. Eine CU bei AMD kann aktuell bis zu 2 Threads zur gleichen Zeit aus führen - in der modernen WGP bei RNDA - sind es wie zu GCN-Zeit 4 Threads! Dem entsprechend hat AMD auch das Verhältnis CU zu TMU gewählt: 1:4. Auf eine CU kommen 4 TMUs. Sprich eine CU kann 4 Texel oder nun eben 4 "Rays" anfordern. Das ist hier die Hardwareebene und jetzt kommt es @xexex gut aufpassen, vielleicht erkennst du ja dann dein Denkfehler, gerade zu deiner Beschreibung, dass ja "RT, Tensor und Co zur gleichen Zeit ausgeführt werden": Wir sprechen hier nicht nur von Hardware, sondern auch von Software-Ebene!

Und jetzt kommt es: Auch bei AMD können FP32-Berechnungen, INT32-Berechnungen, RT sowie Texel-Anforderung zur gleichen Zeit stattfinden und wie dass? Hardware-Ebene!

Ich spreche hier aber bei einem Shader von der SOFTWARE-Ebene! Und wieder aufpassen @xexex wichtig, GRUNDLAGEN! Shader sind kleine Programme die aufgerufen werden und dann ihre Berechnungen ausführen, das können FP32, INT32, Texel oder eben RT-Berechnungen sein. Dieser Ablauf im Shader ist SERIELL NICHT PARALLEL! Siehe dazu das vereinfachte Fluss-Diagramm im Turing-Paper.

Im Shader-Programm können aufgrund der seriellen Ausführung - bis auf wenige Ausnahmen - keine voneinander Abhängigen Schritte parallel ausgeführt werden. Hier bedeutet es: Sobald der Shader ein Ergebnis aus dem BVH-Baum braucht um weiter zu rechnen, wartet der Shader bis er das Ergebnis aus dem BVH-Baum hat und rechnet erst dann weiter. Während der Shader auf sein Ergebnis aus dem RT-Aufruf wartet, wird er als "wartend" markiert und andere Shader auf der CU - nun WGP - können dann die restlichen Vec32, SALUs sowie eben auch TMUs nutzen.

Sprich: Der Shader ansich ist in seinem Programmablauf an die imperativen sowie seriellen Paradigmen gefesselt, die CU selbst nicht!

Und jetzt kommt das letzte zu der Thematik: AMDs Ansatz kann in einer GANZ bestimmten Situation nachteilig werden: Wenn mehr als 8 gleichzeitig laufende Shader auf der WGP zur gleichen Zeit sowohl ein Texel als auch ein Ray von der TMU anfordern und DAS ist der Worstcase, der sehr selten auftritt.

Beschäftigt euch nicht nur mit irgendwelchen Marketing-Folien, egal ob NVIDIA oder AMD, sondern eignet euch mal ein paar Grundlagen an, dann erkennt man nämlich, dass beide Firmen gerne zum Schwadronieren neigen, aber vermeintliche "Vorteile" so überhaupt nicht von Bedeutung sind.
 
  • Gefällt mir
Reaktionen: Haldi, jemandanders, bad_sign und 16 andere
Tief durchatmen, @Teralios.
Aber du hast es gut beschrieben: Die Hardware ist eben nicht Single-Thread, sondern kann mehrere Threads pro CU bearbeiten. Deswegen kann zwar mal ein Thread (Shader) warten, der CU rechnet aber gut ausgelastet munter weiter.

Die Wahrscheinlichkeit, dass ein CU tatsächlich einmal wartet, ist so nochmal geringer, als ich ursprünglich angenommen hatte.
 
DJKno schrieb:
Würde ich so noch nicht unterschreiben. XBox One und PS4 basieren auch auf AMD-CPUs.
Intel war in Spielen meist trotzdem schneller.
Da müsste man eine Rechnung machen, die versucht darzustellen, ob der Performance-Rückstand der AMD-Jaguar gegenüber Intel bei Spiele geringer ist als bei andere Software.
z.B.
(Jaguar-Software-Performance / Intel-Software-Performance)
/
(Jaguar-Spiele-Performance / Intel-Spiele-Performance)
 
@voerden Am besten mit Programmen, die den Intel-Compiler und die MKL-Bibliothek benutzen :D

Nee im Ernst, ich denke dadurch, dass damals die IPC bei Intel besser war und bei beiden Herstellern 8 Threads zur Verfügung gestellt wurden, war Intel berechtigerweise in den Spielebenchmarks vorne.
 
  • Gefällt mir
Reaktionen: bad_sign
Colindo schrieb:
Tief durchatmen, @Teralios.
Ich hasse es einfach nur, wenn Leute hier meinen sie wüssten alles besser, nur weil sie ein paar Marketing-Folien und Videos sich angeschaut haben, aber von den Grundlagen, die dahinter stehen Null Ahnung haben.

Statt dann mal zugeben, dass sie keine Ahnung haben, meinen sie dann aber einen Belehren zu müssen, irgendwann greift man dann zu einem Vorschlaghammer und haut auf den Putz. Ich bin ein sehr geduldiger Mensch, nur irgendwann ist diese halt weg. Besonders wenn man dann versucht mich mit ein paar "Ich hab mal bei Google was eingegeben"-Folien und Videos widerlegen will, die aber dem, was ich geschrieben habe, nicht wieder sprechen, sondern teilweise es sogar noch bestätigen.

Colindo schrieb:
Die Wahrscheinlichkeit, dass ein CU tatsächlich einmal wartet, ist so nochmal geringer, als ich ursprünglich angenommen hatte.
AMD hatte bei den großen "GPUs" immer das Problem, dass sie sehr viele Threads brauchen um die CPU aus zulasten, bei Vega64 spricht man von bis zu 256 Threads sprich 4 Threads pro CU.

Jetzt benötigt man pro CU nur noch maximal 2 Threads um diese Auszulasten und ich denke, mit spielen tut hier auch, dass AMD darauf hinarbeitet ihren Shader-Compiler weiter zu verbessern, dass man auf Shader-Ebene noch "OoO" umsetzt, sodass man unabhängige Berechnungen in mehren Vec32-Befehlen verpacken kann. Da bewegen wir uns dann aber auf eine Ebene zu, die wirklich kompliziert wird.

So ein schöner Tag bis jetzt.
 
  • Gefällt mir
Reaktionen: bad_sign und Sephiroth51
xexex schrieb:
Anders ausgedrückt, es sollten theoretisch alle DXR Spiele auch auf AMD Grafikkarten laufen, wenn der Hersteller nicht einer Abfrage eingebaut hat, es ist aber unwahrscheinlich, dass auch die Vulkan Spiele mit RT einfach so auf AMD Karten funktionieren.
Grundsätzlich hast du Recht, aber die offizielle Raytracing-API von Khronos wird sich ja sehr stark decken mit der nvidia-Extension, ich kann mir also gut vorstellen, dass AMD das sogar auf dem Treiber-Level lösen könnte. Wir werden sehen.
Ergänzung ()

Wadenbeisser schrieb:
Wie das nachher auf dem PC ausschaut muss sich dann erst zeigen aber die Vermutung liegt nahe das nvidia die Konkurrenz bei ihrer Vulkan Erweiterung blockt.
Warum sollte nvidia da was blocken? Die arbeiten sogar offiziell in der Khronos-Gruppe mit, um ihr eigene Extension zu standardisieren.
Ergänzung ()

Wadenbeisser schrieb:
Wieviele RT Spiele gibt es denn für Vulkan?
Bisher Quake und Wolfenstein.
 
Ich bin ausgesprochen neugierig auf die RT-Implementation AMDs, und ich denke, dass Echtzeit-Raytracing damit endlich auch dem Massenmarkt zugänglich gemacht werden wird. Nicht zuletzt wird das auch die relevanten Titel, welche diese Technologie überhaupt nutzen, vielleicht zeitnah aus dem niedrigen zweistelligen Bereich katapultieren.
 
Zurück
Oben