• 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

Denkt ihr wenn man sich einen pc mit der hardware der xbox series x aufbaut also ryzen 3700x und wahrscheinlich rx 6700(xt)
Vergleichbare ssd usw.

Eine bessere optimierung der neuen next gen spiele sehen wird auf diese hadware?

Ich bin jedenfalls gespannt darauf und werde mir genau so einen pc zusammenstellen.
 
CoNk3r schrieb:
Irgendwie schon.

Nicht so flüssige 30fps Minecraft RTX 1080p auf der XSX versus Minecraft RTX auf einer 2080ti in 60fps.

380 << 11 in diesem Fall.
Zeige mir mal bitte den Test! Mir ist einzig das mit 30 fps encodierte Video der Techdemo auf der XSX bekannt.
 
Ich wunder mich echt wie 8k60Hz heute schon ein Thema sein kann. Da sind wir doch in extrem weiter ferne ...
 
  • Gefällt mir
Reaktionen: aklaa
beckenrandschwi schrieb:
Das wäre doch einmal eine APU vom feinsten. 8C 16T; starke Grafik und schneller RAM. Das Teil in ein Notebook und es bäuchte nichts anderes mehr. Wobei der Preis mit Sicherheit auch recht hoch sein wird.


In der Theorie nette Idee, in der Praxis aber leider nicht umsetzbar. Ein Hauptproblem ist der Speicher. Mit normalem DDR4 Speicher wäre das eine ziemlich lahme Gurke.

Man könnte natürlich GDDR6 wie in den Konsolen verwenden, dass hat aber im Notebook einen ganz großen Nachteil. Die Energieeffizienz. Je nach Takt brauchst du da ca. 1,5-2,5 Watt pro Chip. Da sich System und GPU den Speicher ja teilen müssen, sollten es mindestens 32GB sein. Wenn du im Notebook alleine ~60 Watt für den Speicher brauchst, wird es schon ziemlich unschön.

Natürlich kannst du auch einen zweiten Speicherppol (Vram GDDR6) und System Ram DDR4 machen, aber dann ist man auch nicht mehr weit von einer dedizierten Lösung mit extra GPU entfernt.

Du hast aber auch andere Effizienznachteile. Bei getrennten Systemen hast du im Notebook die möglichkeiten zwischen sparsamer mobile GPU und großer GPU umzuschalten, wenn deine einzige GPU aber eine 52 CU GPU ist, dann ist das nicht viel sparsamer als eine Desktop Grafikkarte. Auch Taktmäßig müsste man wohl noch etwas runter, damit das ganze halbwegs gut Kühlbar ist und man nicht zu sehr unter Last Leistung verliert. Eine Moblile 2080 mit 150 Watt kann schon selten wirklich ausgefahren werden in Notebooks.

Also insgesamt doch zu viele Nachteile für eine Notebook APU. Für den Desktop würde es gehen nur da ist die Frage, wer möchte dort verlöteten Ram und eine aufs Mainboard gelötete APU haben und eine Mittelklasse (Ende des Jahres wird das aktuelle Mittelklasseleistung sein) in der CPU?

dermatu schrieb:
Ich wunder mich echt wie 8k60Hz heute schon ein Thema sein kann.
Ist denke ich auch kein Thema. Außer vielleicht irgendwelche 2D Indiegames oder einfacheren Top Down Spielen. Außerhalb davon wird da nichts in 8K drauf laufen. Vielleicht wenn sie es hinbekommen mit AI Upscaler.

8K wird diese Konsolengeneration sicherlich kein wirkliches Thema sein und ich denke im laufe der Generation werden auch viele Spiele nicht mehr in nativem UHD laufen. Es macht bei einer Konsole am Fernseher aber auch wenig Sinn, so viel GPU Leistung nur in die Auflösung zu stecken, wobei man das bei dem Sitzabstand nicht so sehr sieht und es mittlerweile gute Techniken gibt, um z.B. aus 1800p gut wieder ein 2160p Bild zu rekonstruieren.
 
Zuletzt bearbeitet:
Teralios schrieb:
Die CU/SM berechnet den Effekt, während des Effektes kommt es dann zu einer BVH-Abfrage, diese BVH-Abfrage wird dann an den RT-Core oder an die TMU gestellt - hier müssen "Millionen" an Pixel der Szene durchforstet werden, deswegen auch eine "Fixed-Function-Unit". Die CU macht im Endeffekt das gleiche wie die SM bei NVIDIA bei der RT-Berechnung, nur dass eben kein RT-Core den Suchbaum durchstöbert, sondern die TMU. Sobald der Eintrag aus dem BVH-Baum zurückgegeben wird, kann die CU dann weiter rechnen oder eben die SM.

Es werden ja keine Pixel durchforstet, sondern die optimierte Datenstruktur, welche sich aus Bounding Boxes und Dreiecken zusammensetzt. Ich kann mir nach erster, kurzer Überlegung auch nur schwer vorstellen, dass die Bounding Box Evaluierung "fixed-function" ist. Das ist eher speicher- als arithmetik-lastig. Die Triangle Evaluierung ist dann wiederum was anderes. Das ist sehr arithmetik-lastig. Zu sagen, dass die RT-Cores einen Algorithmus abbilden ist schwammig bis falsch (hattest du weiter oben mal erwähnt). Sie führen einen Algorithmus aus. Die RT Cores alleine werden das beschleunigte Hardware-RT nicht ausmachen. Das Konzept müsste eigentlich auch optimierte Speicherzugriffe beeinhalten, also auch Cache-Strukturen.

Ich denke, dass die Marketingfolien stark vereinfacht sind.

1597824476486.png
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: adAstra und .Sentinel.
ZeroStrat schrieb:
Ich denke, dass die Marketingfolien stark vereinfacht sind.
Steht aber auch so im Whitepaper. Ein RT-Core macht den kompletten Vorgang vom Abschuss eines Strahls bis zum Auftritt und gibt das Ergebnis zurück. Also sowohl das Durchforsten der BVH, als auch die Triangle-Intersection. Dafür hat er wahrscheinlich eine eigene Speicheranbindung, dazu gibt es aber keine Informationen, oder kennt jemand eine entsprechend detaillierte Die-Shot-Analyse von Turing?
 
  • Gefällt mir
Reaktionen: Teralios und .Sentinel.
ZeroStrat schrieb:
Die RT Cores alleine werden das beschleunigte Hardware-RT nicht ausmachen. Das Konzept müsste eigentlich auch optimierte Speicherzugriffe beeinhalten, also auch Cache-Strukturen.
Das ist der Punkt. Mit den par Einheiten, die Rays verschiessen ist es eben bei Weitem nicht getan.
Es geht hier um Speicher- und Cache- Management. Diese Einheiten werden von RTRT geradezu zerstört in ihrer Effizienz, was wiederum allen daran angeschlossenen Einheiten an die Performance geht.

Auch ist klar, dass bei der Organisation der RT Einheiten in RDNA2 eine hohe BB- Probing/Intersection- Leistung zu erwarten ist.
Jedoch war die reine Raygen- Verschuss und Auswertungsleistung ja schon bei Turing eher nebensächlich da überdimensioniert. Problematik ist die Belagerung der Shader (in dem Falle physisch gemeint) mit entsprechenden Auswertungs- und den anschließenden Effekt- Aufgaben.

Und wie bereits weiter oben erwähnt haben wir noch den Unterhalt bzw. die Generierung der Beschleunigungsstruktur.
Da beisst sich in gewisser Weise gerade die Katze in den Schwanz. Je mehr Aufwand man in die Beschleunigungsstruktur laufen lässt, umso leichter tut sich der gesamte Raytracingrattenschwanz.

Nur bringt das derzeit wenig, weil eben die Erzeugung und die Pflege dieser Struktur schon ziemlich viel Rechenzeit in Anspruch nimmt.

Den Ansatz für Co- Prozessoren, der hier oftmals per Gerücht rumgeistert finde ich relativ charmant.
Denn wenn man RTRT auf die Hauptaufgaben herunterbricht, handelt es sich hier immer um Spiegelungen/Refractions, Illumination/Shadows/AO.
Diese Techniken greifen ja weitläufig ineinander, sprich man kann viele Effekte an einem Intersection- Ergebnis festmachen.
Wenn man deren Berechnung grundsätzlich in einen Hilfschip gießen würde, könnte das nochmal einen großen Geschwindigkeitsschub liefern und vor allem die Rendereffktnutzung für alle Entwickler vereinfachen und deutlich attraktiver gestalten.

Da man aber derzeit noch so starke Fortschritte macht, was die effiziente Nutzung der neuen Techniken anbelangt, wird man sich das "Zementieren" dieser Effekte noch nicht trauen. Zu groß ist die Wahrscheinlichkeit, dass in ein par Monaten jemand mit einem anderen revolutionären Ansatz zur Berechnung kommt, der aus den Chips von heut auf morgen Hardwareschrott generiert. (z.B. ReSTIR)

Zurück zu RDNA2 in den Konsolen. Ich bin der Überzeugung, dass man auf den neuen Konsolen RTRT Effekte in beschränktem Umfang sehr gut und in erweitertem Umfang (Multieffekt, je nach Effekt) gut nutzen können wird.
Zwar sollte man da keine 4K und 60FPS erwarten, aber in niedrigeren Auflösungen sollte mit Upscaling da was machbar sein, was konstant bei oder über den sonst angestrebten 30FPS liegt.

Und diesbezüglich wird man in einigen Bereichen (z.B. Raytraced Ambient Occlusion und einhergehend Ambient Illumination/Light Bleeding) gerne auf diese Lösungen zurückgreifen, da sie vieles vereinfachen und dabei eine bessere Qualität liefern und schon einen wichtigen Teil der Qualität einer vollständigen GI Lösung ins Bild transferieren.
Zudem kosten z.B. die oben genannte Grafikkniffe im Gegensatz zu seinen kleinen Brüdern durch die Hardwarebeschleunigung eben keine Mehrleistung, sondern könnte mit deutlich höherer Qualität sogar schneller laufen.

Allein das würde den optischen Eindruck von Spielen schon erheblich aufwerten und ist durch die Konsolenhardware sicher leistbar.

Die Frage, die sich mir bei all dem stellt ist, wie langlebig diese Konsolengeneration ob des bevorstehenden Umbruchs der Renderingtechnik sein wird.

Denn gerade Konsolen waren ja immer bekannt dafür, mit vielen Spezialchips und Spezialrecheneinheiten neue Techniken aus Geschwindigkeits- und Kostengründen in Silizium zu gießen (Mode 7 im SNES oder jetzt Kraken in der PS5) und sich damit einen Vorteil gegenüber der PC Hardware zu verschaffen.

Das Hardwarekarussell dreht sich in den nächsten Jahren meines Erachtens wieder deutlich schneller. Endlich...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Maggolos, adAstra, Shoryuken94 und eine weitere Person
Taxxor schrieb:
Oder die PS5 geht auf 599 Disc und 499 digital, während die Xbox 499 kostet, womit man sagen könnte, dass sie mit Disk teurer ist^^

Wann glaubst du weiß man es endlich ?
Dauernd aktualisiere ich News bis man es weiß.
 
ZeroStrat schrieb:
Es werden ja keine Pixel durchforstet, sondern die optimierte Datenstruktur, welche sich aus Bounding Boxes und Dreiecken zusammensetzt.
Ich hab mich an der Stelle auch einfach verschrieben. Gemeint ist an der Stelle die Polygone oder eben der BVH-Baum und das wiederum habe ich mehrfach auch geschrieben, daher ist dein Hinweis auf "Pixel" zwar nett, aber unnötig.

Im Übrigen habe ich nun genug Turing und Co "Folien" und zwar nicht nur den Marketing-Kram angesehen. Und klar ist eine Speicherintensive-Anwendung, das hat NVIDIA jedoch auch von Anfang an kommuniziert, ebenso wie AMD genau diesen Umstand als Begründung nennt, warum die BVH-Funktionen in die TMU wandern. Aber auch das habe ich hier erwähnt: Direkter Zugriff auf die Caches und den Speicher.

... Bitte alles lesen, statt sich auf den erst besten Fehler zu stürzen, bei dem man sich nur verschrieben hat.
 
  • Gefällt mir
Reaktionen: adAstra
Labberlippe schrieb:
Samb zockt hat es in einen Video gut erklärt.
Beispiel Switch.
Handheld oder Dockmode.
Da ist das Spiel quasi auf 2 Konsolen zu programmieren obwohl es für den Kunden ja nur eine Konsole ist.
Nein, das Spiel muss nur einmal programmiert werden und in der Endphase müssen zwei Settings gefunden werden, die auf den jeweiligen Modellen bzw. im jeweiligen Modus (Dockmodus und Handheld-Modus bei der Switch; "Präsentations"-Modus und Performance-Modus z. B. bei diversen PS- und Xbox-Spielen) gut laufen. Alle modernen Spiele-Engines sind auf Skalierung ausgelegt.

Die letztendliche Optimierung auf ein oder zwei oder sogar drei Modelle / Modi dürfte nur einen Bruchteil des Gesamtaufwandes der Spielentwicklung ausmachen.

Bei der Optimierungsphase auf verschiedene Modelle / für verschiedene Modi dürfen die Entwickler natürlich nicht schlampen und sich nur auf ein Modell / einen Modus konzentrieren und das andere trotz offensichtlicher Performance-Mängel durchwinken... eine gewisse Sorgfalt in dieser Optimierungsphase sollte man als Kunde allerdings auch erwarten können.

Hilfreich bei der Optimierung für jedes Modell (Mindestperformance soll nicht unterschritten werden, zusätzliche Kapazitäten der schnelleren Modelle sollten nicht brach liegen) sind natürlich dynamische Optionen (Auflösung, Effekte, usw.)… und der Trend geht ganz stark zu solchen dynamischen Einstellungen, die "Slowdowns" vermeiden.

Und selbst bei der Xbox-Abwärtskompatibilität hat man bereits gesehen, dass viele Xbox360-Spiele auf der Xbox One auch ohne Anpassung des Spiels von der zusätzlichen Performance profitieren und plötzlich an kritischen Stellen keine Slowdowns mehr haben. Viele PS4- und Xbox-One-Spiele mit dynamischer Auflösung werden ohne Anpassung des Spiels auf den Nachfolgekonsolen die Maximalauflösung deutlich länger (wenn nicht sogar durchgängig) halten können.

Auch auf der Switch gibt es viele Spiele mit dynamischer Auflösung und auch hier kann die Bildqualität durch mehr Performance (in diesem Fall Übertaktung) deutlich erhöht werden. Dass eine Switch Pro (oder eine neue Revision mit etwas schnellerem SoC) sinnlos ist, kann ich daher nicht nachvollziehen.
 
Zuletzt bearbeitet:
Teralios schrieb:
... Bitte alles lesen, statt sich auf den erst besten Fehler zu stürzen, bei dem man sich nur verschrieben hat.
Ich glaub das war nicht gemeint, um Dir an den Karren zu fahren. Hast Du ja die letzten Threads wirklich ausführliche Erklärungen dazu abgegeben, sondern eher tatsächlich als Korrektiv.
Denn auch wenn man noch so sorgfältig ist, manchmal hat man eben auch noch Knoten in den Texten.
Ist bei mir ja genau das gleiche.
Wenn Du Dir mal ansiehst, wie lange meine einzelnen beiträge jeweils mit Korrekturen und Änderungen auch lange Zeit nach dem Verfassen belegt werden, dann ist das schon erheblich.

Man strickt halt einen Text vornehmlich mit dem Fokus, die Hauptaussage herauszustellen. Da fallen manchmal "Nebensächlichkeiten" oder unsauber formulierte Passagen unter den Tisch. Dazu noch chronischer Zeitmangel und Kommentare von Usern, die das eh nicht interessiert.

Da korrigierst Du (zum Glück) ja auch gerne mal nach.
Das ist ja nix Schlechtes, da man es ja als Information für die anderen hinterlässt.

Zum Thema- Für mich wäre auch noch interessant, in welchem Format bzw. Datenstrom die Textureinheiten die Informationen erhalten bzw. bearbeiten bzw. in welchen Speichertiers die (welche) Information zur Verarbeitung oder Manipulation gehalten wird.
Wenn man eh schon in der Textureinheit damit liegt, kämme mir nämlich die Idee, eben durch einfache Manipulation über den Texturprozessor (Heatmaps/Raymaps?) vielleicht sogar noch ein Sorting, eine Auswertung oder ein Culling zu integrieren.

Die Verstrickung dieser beiden Einheiten lässt einen da auf allerlei sinnvolle und vielleicht auch blödsinnige Ideen kommen. Da wäre dann wiederum die Frage, wie einfach/schnell sich diese beiden Einheiten (TMU/Intersection) zum miteinander Reden bringen lassen können bzw. ob man die Buffer bei jedem Kontextwechsel leeren muss, oder ob man sie befüllt lassen kann.

Hmmmm....
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: adAstra
Hm, also ich schliesse mich da der Meinung von Tom im folgenden Moore's Law is Dead Video an, da ich auch glaube, dass Navi22 interessant werden koennte (ob nun mit kolportierten 256Bit oder 384 Bit Speicherinterface bleibt abzuwarten), RT-Raytracing fuer die RDNA2 Karten schwer vergleichbar/einzuschaetzen ist durch die zusammen mit Rasterisierung quasi integrierte, multifunktionale Architektur (mit Option auf entweder RT-Raytracing oder Rasterisierung oder einem schnell hin und her-schaltendem Mischmasch, was die bessere Loesung als externe Kerne sein koennte, aber bei der Optimierung durch Entwickler in Spielen zumindest anfaenglich ein deutlich schwieriger Ansatz sein duerfte), nur glaube ich dann doch nicht, dass Microsoft und Sony besser im entwickeln einer Radeon Grafikkarte sind als die Radeon Technologies Group :D:


Gut moeglich, dass nVidia mit den Ti/"Super" Varianten wartet (also nur eine RTX 3080 und RTX 3080, wobei respektive ca. 1000 und 2000 US-Dollar da schon heftige Schaetzungen fuer die Marktstartpreise sind und m.E. etwas hoch gegriffen), um nach AMDs RDNA2 Big Navi Marktstart ggf. deren Produkte (mit einer RTX 3080 Ti/Super und RTX Titan A) auszukontern.

An einen angeblich vorgezogenen Launch schon am 21. August (ja, das waere schon in 2 Tagen) - wie im Video erwaehnt von irgendeiner Quelle - glaube ich eher weniger, denn angeblich soll ja immer noch der 1. September (nicht der 31.August, jedoch natuerlich abhaengig von der Zeitzone) meines Wissens fuer Huang's grossen GeForce Ampere Auftritt samt Lederjacke gelten.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: bad_sign und Onkel Föhn
"Die zusätzlichen Die-Kosten für die Raytracing-Beschleunigung sind laut Microsoft minimal"

Hoffentlich hat diese Aussage bei nVidia jemand zur Kenntnis genommen … ;-)

MfG Föhn.
 
  • Gefällt mir
Reaktionen: bad_sign und Chismon
ZeroStrat schrieb:
Ich habe mich nicht draufgestürzt, das kommt dir nur so vor. @.Sentinel. hat's bereits treffend erläutert.
Kann gut sein, gebe ich offen zu, bin etwas übermüdet. Dann nichts für ungut.
 
  • Gefällt mir
Reaktionen: evilhunter, ZeroStrat und .Sentinel.
Onkel Föhn schrieb:
"Die zusätzlichen Die-Kosten für die Raytracing-Beschleunigung sind laut Microsoft minimal"
...sagen diejenigen, die sich ein durch ein von nvidia groß vorbereitetes Nest setzen...
 
  • Gefällt mir
Reaktionen: evilhunter, Onkel Föhn und adAstra
Was bringt tolle HW wenn die Spiele "fehlen" MS hat in dem Bereich viel Nachholbedarf und das das neue Halo nicht zu release der neuen HW kommt, lässt die Frage aufkommen wofür man sich dieses teure Stück HW zu Release kaufen soll
 
Immer weider die "Märchen", dass der XBox die Spiele fehlen. ;)
Eigenartigerweise ist der Store voll von Spielen, auch mit sehr guter Qualität.

Wenn einem die Spiele nicht zusagen, kein Thema. :)
Aber immer wieder mit der alten Leier "die XBox hat keine Spiele" kommen ist schon recht einfallslos.
 
  • Gefällt mir
Reaktionen: Chismon und Cohen
Onkel Föhn schrieb:
"Die zusätzlichen Die-Kosten für die Raytracing-Beschleunigung sind laut Microsoft minimal"

Entscheidend ist was am Ende dabei rumkommt, aber ich lass mich gerne überraschen.
 
  • Gefällt mir
Reaktionen: Onkel Föhn
.Sentinel. schrieb:
...sagen diejenigen, die sich ein durch ein von nvidia groß vorbereitetes Nest setzen...

Somit ein herzliches DANKESCHÖN an all die RTX Käufer, Danke … :-)

MfG Föhn.
 
  • Gefällt mir
Reaktionen: .Sentinel., Chismon, bad_sign und eine weitere Person
Zurück
Oben