AMD Zen 2: Angeblich zwei Dies mit bis zu 16 Kernen
- Ersteller PCGH-Redaktion
- Erstellt am
DKK007
PCGH-Community-Veteran(in)
Jetzt macht das mit den hundert Tabs auch mehr Sinn, wenn ich drüber nachdenke.
Allein das PCGH-Forum sind oft 40 Tabs, um mehrere Themen zu verfolgen.
VikingGe
Software-Overclocker(in)
Um mal auf den Gamestar-Artikel zurückzukommen:
Allerdings müsste man dafür Dx11 zur Seite legen und auf moderne APIs setzen, aber das will ja keiner und stattdessen wird lieber rumgenörgelt, dass die Single Core-Leistung eines 5 GHz-i7 nicht ausreicht.
Ja. Auf der GPU müssen sie das. Aber nicht auf der CPU.
Allerdings müsste man dafür Dx11 zur Seite legen und auf moderne APIs setzen, aber das will ja keiner und stattdessen wird lieber rumgenörgelt, dass die Single Core-Leistung eines 5 GHz-i7 nicht ausreicht.
S
Schaffe89
Guest
Wie willst du sonst die Spiele- IPC vergleichen? Prozessoren mit unterschiedlicher Kernzahl?
Latenzen zum Beispiel, sind bei Intel deutlich geringer, Ringbus ruled halt noch.
Da gehts um das Rendering bevor die GPU etwas macht, das Rendering der Welt, die Zeichenbefehle die an die GPU geschickt werden.
Die sind unter Directx11 durchaus etwas limitiert, da die Renderinglast ungleichmäßig verteilt war und ein Thread stärker belastet wurde.
Das hat man jetzt mit Directx12 abgemildert und besser verteilt.
Wieso das aber zu einer besseren Multicore-Skalierung führen soll, würde ich mich schon fragen, eher das Gegenteil ist der Fall, wenn man mal auf BF1 unter Directx12 schielt.
Ashes of the Singularity ist ein Strategiespiel mit sehr vielen Einheiten und fällt unter die paar Spiele in denen noch eine Gewinn durch mehr Cores generiert werden kann.
Directx12 führt nicht per se zu einer Nutzung von mehr CPU Cores, eher entlastet es die CPU Cores und dadurch hängt man auch mit weniger Kernen schon im GPU Limit und braucht eher weniger Kerne/Threads damit es flüssig läuft.
Directx12 bringt einfach viel weniger als man sich das eingestehen will, deshalb wird es in der aktuellen Form auch die nächsten Jahre verschwinden und durch etwas anderes ersetzt werden.
Hat das neue Battlefield überhaupt noch einen Directx12 Modus? Ich glaube nicht.
Zuletzt bearbeitet:
VikingGe
Software-Overclocker(in)
Ein einfacher Forward-Renderer macht ungefähr sowas hier:
Ressourcen-Updates -> Shadow Map 1 -> Shadow Map 2 -> Shadow Map 3 -> Shadow Map 4 -> Depth Pre-Pass -> Color Pass -> Post Processing -> Fertig
In Dx11 muss man das im Grunde wirklich alles auf einem Thread und in der richtigen Reihenfolge machen. Das ist eine Einschränkung im API-Design, du setzt ein paar Zustände auf dem D3D11-Context, die da implizit gespeichert werden, updatest quasi vor jedem Draw Call einen oder mehrere Buffer (absolut dämliche Design-Entscheidung, die letztenendes auch Performance kostet - in D3D 11.1 nicht mehr nötig, aber auch das nutzt kaum jemand), und der Draw Call verwurstet das ganze dann zu GPU-Befehlen, die erstmal intern irgendwo in einem Command Buffer gespeichert werden und dann in mundgerechten Häppchen zur GPU geschickt werden.
In Vulkan/Dx12 bastelst du dir deine Command Buffer selbst (Mehrzahl), die eben nicht von irgendwelchen impliziten Zuständen abhängen, und genau daher kommt auch die Möglichkeit, das Rendering zu parallelisieren¸ allerdings auch ein Teil des höheren Aufwands ggü. Dx11, weil auch Ressourcen keinen impliziten Zustand mehr haben und man sich selbst um Speicherallokation kümmern muss und darum, dass Texturen zum richtigen Zeitpunkt im richtigen "Layout" sind, was treiberseitig beispielsweise Delta Color Compression ermöglicht oder verhindert.
Eine äußerst naive, parallelisierte Implementierung für unseren Forward-Renderer könnte so aussehen:
Thread 1: Shadow Map 1
Thread 2: Shadow Map 2
Thread 3: Shadow Map 3
Thread 4: Shadow Map 4
Thread 5: Depth Pre-Pass
Thread 6: Color Pass
Thread 7: Ressourcen-Updates -> Submit -> Warte auf Thread 1 bis 4 -> Submit -> Warte auf Thread 5 -> Submit -> Warte auf Thread 6 -> Submit -> Post Processing -> Submit -> Fertig.
Thread 1-6 erledigen dabei den überwältigenden Großteil der Arbeit und generieren Command Buffer. Submissions sind relativ billig, weil sie nur der GPU mitteilen, die bereits fertigen Command Buffer abzuarbeiten.
Jetzt könnte man natürlich noch auf die Idee kommen, das gleiche mit D3D11 Deferred Contexts zu machen, die in der Theorie auch etwas Multithreading erlauben, dann müsste man Submit oben durch ExecuteCommandList ersetzen. Aber das ist nicht wirklich vergleichbar, weil Thread 1-6 durch den impliziten Zustand von Ressourcen keine fertigen Command Buffer generieren können und Thread 7 (bzw. eher der implizite Treiber-Thread 8) immer noch einen ganzen Haufen Arbeit zu erledigen hat.
derneuemann
Lötkolbengott/-göttin
Stark Spielabhängig, mal ist ZEN+ Taktbereinigt gleich schnell in Spielen, mal nicht.
derneuemann
Lötkolbengott/-göttin
Der Artikel ist sogar nur die halbe Wahrheit, da in 1080p getestet wurde, was zwar realitätsnäher ist, aber auch schon die Fps im GPU LImit begrenzt. Der Unterschied wäre in 720p, mit weniger Begrenzung durch die GPU Leistung noch deutlicher. Beweisen lässt sich das durch alle anderen CPU Tests, die in 1080p und in 720p testen.
AMD hat höhere Latenzen in der CPU, daher der Unterschied, in den Games, ohne das es tatsächlich größere Unterschiede bei der IPC Leistung gibt.
Borkenpopel1
Software-Overclocker(in)
Und demnächst wird sich Luxemburg und Vietnam zusammenschließen und die Weltherrschaft Militärisch an sich reißen
Ne mal im Ernst, halte ich für zu sehr durch die rote Brille geschaut. ZEN 2 wird wahrscheinlich ein noch größerer Kracher als die 1. Gen, aber deine "Hoffnungen" sind absolut unrealistisch
Jedes und alle sind gefährliche Begriffe bei sowas. Was ist zum Beispiel mit Mad Games Tycoon, Another Brick in the Mall und ähnlichen kleineren Titeln, die im Lategame teilweise abkacken aber kaum mehr als einen Kern nutzen? Außerdem spielt man auch vielleicht mal was von vor 2015.
Und einer "postfaktischen Anhängerschaft" "ewige Lügen" zu unterstellen und die Tatsache, dass du so empfindlich reagierst, zeichnen dich eigentlich mehr als "Boy" aus, als die, denen du es vorwirfst.
Master-Onion
PC-Selbstbauer(in)
OK, ja ne is klarNichteinmal die Blauen oder die Fans von Leder Jacken Jonny würden so einen Unfug verbreiten
G
gaussmath
Guest
Computerbase auch? Alle keine Ahnung außer du?
Das ist doch das gleiche wie bei Gamestar. Ich weiß nicht, ob das Inkompetenz ist oder gezielte Desinformation, damit Intel seine 6 Kerner möglichst gut und lange am Markt platzieren kann.
Natürlich wird es immer sequentielle Teile innerhalb einer Anwendung geben, so auch beim Rendern. Aber es geht nicht um diese Teile, es geht darum, was man beim Rendern parallelisieren kann. Die Aussage bei Gamestar und CB ist total in die Irre führend. Wie kann es sein, dass eine Grafikkarte mit meherern tausend Shadern ausgelastet werden kann? Wie kann es sein, dass Wolfenstein 2 und The Divsion 32 Threads (und mehr!) nutzen?
Ich habe keine Lust, das hier auszuführen. Würde das überhaupt was bringen? Ich werde wohl bald ein Youtube Video dazu machen. Dann kann ich das zukünftig bei Bedarf einfach verlinken.
Ich kann nur sagen: informiert euch. Bitte hiermit anfangen: Unity High performance job system - Go Make Games, multithreaded work
Tatsächlich verbessert DirectX/Vulkan die Mehrkernauslastung nachdem man die DirectX CommandList im Gegensatz zum alten DirectXContext halt ohne Lock ansprechen kann. Wie aber bei der Anwendungsprogrammierung muss man das halt auch gut machen und genau das ist der Knackpunkt.
S
Schaffe89
Guest
Die Artikel bei CB oder GameStar sind weder irreführend noch Desinformation, daran ändert auch ein Directx12 nichts, weil die Punkte die dort geändert werden keine gute Kernskalierung auslösen, sondern den Overhead der vorher bei DirectX x11 ab und zu auf einem Thread lag nun auf etwas mehr besser verteilen, das ist die Quintessenz für FiSi s wie mich. Deswegen bringen aber nicht plötzlich mehr Kerne was, sondern grade auf CPUs mit wenigen hat das den größeren Vorteil. So extrem wie das hier aber dargestellt wird ist es auch nicht, DirectX x11 besitzt durchaus schon ein gutes Multithreading um die GPU vernünftig zu füttern, man hat sich halt damit arrangiert und das was man bisher sehen kann ist, dass die Skalierung mit mehreren Kernen bei jeder DirectX x12 Portierung geringer wird.
Wie VikingGe das schon technisch ausgeführt hat, und man das auch nachlesen kann Stimme ich dem doch völlig zu, das löst aber wie bereits schon mehrfach gesagt keine Abhängigkeiten vom Mainthread oder ist dafür zwingend verantwortlich dass ein Spiel über einen 4 Threads oder 8 Threads Prozessor noch hinaus skaliert. Assassins Creed ist ja kein DirectX x12 Spiel, genauso wenig wie BF1 das unter DirectX x11 besser nach oben skaliert.
Wie kann das sein? Lieblose Portierung?
Oder vielleicht ein gezielter Over Hype von DirectX x12 durch überspitzte Formulierungen und Drawcall Weltmeisterschaften?
Ach komm das bisschen was da im Endeffekt in einem Teil das Prozesses mehr parallelisiert wird.
Ihr verwechselt doch da richtig ordentlich zwei paar Schuhe miteinander.
VikingGe müsste das eigentlich wissen wenn man seine Beiträge zu dem Thema liest.
Wie VikingGe das schon technisch ausgeführt hat, und man das auch nachlesen kann Stimme ich dem doch völlig zu, das löst aber wie bereits schon mehrfach gesagt keine Abhängigkeiten vom Mainthread oder ist dafür zwingend verantwortlich dass ein Spiel über einen 4 Threads oder 8 Threads Prozessor noch hinaus skaliert. Assassins Creed ist ja kein DirectX x12 Spiel, genauso wenig wie BF1 das unter DirectX x11 besser nach oben skaliert.
Wie kann das sein? Lieblose Portierung?
Oder vielleicht ein gezielter Over Hype von DirectX x12 durch überspitzte Formulierungen und Drawcall Weltmeisterschaften?
Ach komm das bisschen was da im Endeffekt in einem Teil das Prozesses mehr parallelisiert wird.
Ihr verwechselt doch da richtig ordentlich zwei paar Schuhe miteinander.
VikingGe müsste das eigentlich wissen wenn man seine Beiträge zu dem Thema liest.
Zuletzt bearbeitet:
G
gaussmath
Guest
Dass an der Software (Engines) was geändert werden muss, ist doch klar. Mangelhafte DX12 Portierungen als Begründung für irgendwas ins Feld zu führen, bringt gar nichts. Der Artikel (darf man eigentlich gar nicht so bezeichnen) bei Gamestar und CP suggeriert, dass 6 Kerne das Optimum darstellen und das auch in Zukunft, weil Rendern grundsätzlich nicht besser parallisiert werden kann. Und das ist Blödsinn.
Schau dir das verlinkte Video an und informiere dich umfassender.
Schau dir das verlinkte Video an und informiere dich umfassender.
Das liegt daran, dass das Draw-Call limit nicht der einzige Faktor ist der CPU gebunden sein kann. Physik kann man parallelisieren, AI-Aktionen wie Wegfindung, die CPU Seite von Partikelsystemen, Sound, Hintergrundtasks, Berechnungen. DirectX12 und Vulkan hebt ja nur das CPU-Limit im Bezug auf's Rendern an. Auf Physik und Co hat ja DirectX keinen Einfluss. bei BF1 im DX12 Modus werden sie alles ganz passabel gemacht haben und dann das Render-Backend versemmelt haben.
Das kann viele Gründe haben. Bescheidene Allokations-Pattern, False Sharing, zu viele Locks, Bugs und mehr. Wenn ein Game gut parallelisiert ist, das Render-Backend aber halt räudig, dann läuft das ganze trotzdem langsam weil einfach bei der CPU-GPU-Kommunikation ein Bottleneck entsteht.
BF1 ist genau daran gescheitert womit viele Teile der Industrie am Anfang zu kämpfen hatten. Fehlendes Know-How im bereich DirectX 12. Die hatten ja wenig Möglichkeiten das zu üben. Das die ersten Spiele auf neuen APIs nicht so super laufen ist nichts neues. Vulkan und DirectX 12 sind wirklich mächtig. Sieht man an Doom und Wolfenstein 2 (sind zwar beide jetzt mal Vulkan, aber selbes Prinzip). Mit DirectX 12 und Vulkan ist es halt wie mit C/C++. Low Level Programmierung hat viele Stolpersteine. Man kann mehr machen aber auch mehr versemmeln. Das ist einer der Gründe warum Java so verbreitet ist und C# sich so schnell ausgebreitet hat.
Höhere Abstraktionsebenen lassen weniger Platz für grobe Schnitzer. DirectX 11 und OpenGL sind einfach deutlich weiter abstrahiert als es DirectX 12 und Vulkan sind. Ein Paradebeispiel mit Vulkan wie man's nicht macht: The Talos Principle. Das ist nicht's anders als ein Vulkan - OpenGL Wrapper. Und so lief der Vulkan Support halt auch. Ein Beispiel für eine relativ gute DirectX 12 Implementierung ist dann z.B. Gears of War 4. Das läuft echt gut.
DirectX 12 wurde nicht overhyped nachdem es in der Theorie einfach ein sehr mächtiges Werkzeug ist, es wird einfach von vielen nicht so optimal eingesetzt.
Das Multithreading von DirectX 11 ist halt leider *******. Man muss da so rumtricksen das parallel zu bekommen. Man hat eine ID3D11DeviceContext und eine ID3D11Device. Der Zugriff auf ersteres kann nicht parallel erfolgen, auf letzteres schon (Quelle: https://msdn.microsoft.com/de-de/library/windows/desktop/ff476891(v=vs.85).aspx ). Einen Synchronisationsmechanismus zu verwenden ist halt scheiß teuer und vor allem können dann Aktionen die den DeviceContext benötigen nur seriell ausgeführt werden. So, ein Großteil der Operationen zur Vorbereitung eines Draw-Calls und dann auch das eigentliche Draw werden mit dem Context gemacht. Sprich in DirectX 11 läuft der Großteil eines Drawcalls seriell ab. Ich hab jetzt einfach mal einen Screenshot angehängt der den Source-Code für einen Draw-Call auf ein einfaches MD5 Mesh zeigt. Auch als nicht Programmierer kann man mal schauen wie oft da die DirectXDevice verwendet wird und wie oft der Context. DirectXDevice nämlich gar nicht. Die Device wird z.B. benutzt um Buffer zu erzeugen, Rasterizer States zu erstellen oder Shader zu kompilieren. Sprich der Großteil eines Draw-Calls läuft seriell ab mit zusätzlich noch den Kosten für einen Lock.
Bei DirectX 12 sieht das anders aus. Der Context ist raus geflogen und es wird eine CommandList zusammengestellt was parallel ohne Locks geht. Die wird dann einfach abgegeben und dann parallel abgearbeitet. Sprich der Parallelisierungsaufwand ist einfach geringer.
Wenn sich jemand über Parallelisierung in Spielen abseits von Grafik informieren will verweise ich gerne nochmal auf Naughty Dog (GDC Vault - Parallelizing the Naughty Dog Engine Using Fibers). In dem Panel erklärt der Kerl wie Naugthy Dog sein Job-System implementiert hat um gute Parallelisierung in ihren Games zu gewährleisten. Kommt z.B. be Uncharted 4 zum Einsatz. Ist aber sehr technisch.
Zuletzt bearbeitet:
G
gaussmath
Guest
Genau das macht die neue Unity Engine auch. Es wird ein hoch optimiertes Job System und eigener JIT Compile verwendet, der sogar C++ schlagen soll. Es geht nicht nur darum, zu parallisieren, sondern auch den Parallelisierungsoverhead zu minimieren. Die Engine skaliert übrigens auch mit 12 Kernen....
VikingGe
Software-Overclocker(in)
Der D3D11DeviceContext selbst ist ja nicht einmal thread-safe und hat dementsprechend kein internes Lock. Würde auch wenig Sinn machen, weil ein internes Lock allein nicht sicherstellen kann, dass die ganzen Befehle auch alle in der richtigen Reihenfolge ankommen.Mango2Go schrieb:
Gibt zwar (seit kurzem) ID3D11Multithread und irgendwas ähnliches in D3D10, aber das sind externe Locks, das kann man auch von Hand implementieren. Sollte man aber nicht, da kann man besser mit Deferred Contexts arbeiten, auch wenn deren Konzept etwas fehlgeleitet ist und die selbst einiges an Overhead mitbringen.
Am besten dürfte es für die Performance nach wie vor sein, den ganzen D3D11-Rendering-Kram in einem Thread zu erledigen und alles andere, was irgendwie indirekt mit Rendering zu tun hat (Sichtbarkeitstests etc.) so weit wie möglich asynchron dazu laufen zu lassen. Witcher 3 wäre so ein Spiel, das tatsächlich nur den Immediate Context verwendet und trotzdem hervorragend läuft.
Den GDC-Talk werde ich mir aber auch mal ansehen, insofern danke für den Link
Zuletzt bearbeitet:
Der D3D11DeviceContext selbst ist ja nicht einmal thread-safe und hat dementsprechend kein internes Lock. Würde auch wenig Sinn machen, weil ein internes Lock allein nicht sicherstellen kann, dass die ganzen Befehle auch alle in der richtigen Reihenfolge ankommen.
Gibt zwar (seit kurzem) ID3D11Multithread und irgendwas ähnliches in D3D10, aber das sind externe Locks, das kann man auch von Hand implementieren. Sollte man aber nicht, da kann man besser mit Deferred Contexts arbeiten, auch wenn deren Konzept etwas fehlgeleitet ist und die selbst einiges an Overhead mitbringen.
Am besten dürfte es für die Performance nach wie vor sein, den ganzen D3D11-Rendering-Kram in einem Thread zu erledigen und alles andere, was irgendwie indirekt mit Rendering zu tun hat (Sichtbarkeitstests etc.) so weit wie möglich asynchron dazu laufen zu lassen. Witcher 3 wäre so ein Spiel, das tatsächlich nur den Immediate Context verwendet und trotzdem hervorragend läuft.
Den GDC-Talk werde ich mir aber auch mal ansehen, insofern danke für den Link
Klar, alles in einem Thread ist besser und der Deferred Context ist eine Option, aber der ist tatsächlich nicht viel schneller oder langsamer als ein normaler Context + Spinlock, nur eben bequemer. Ich würde aber den Lock hier in meinem Beispiel z.B. an den Anfang der Draw-Funktion setzen, dann passt die Reihenfolge, oder man baut nen Wrapper um den Context. Es macht eh keinen Sinn nach jeder Operation einen Lock zu machen. Mit Lock sorgt man dann halt dafür, dass nur ein Draw-Call auf einmal passiert, dann stimmt die Reihenfolge während der Render-Funktion werden ja nur Draw-Calls gemacht (oder sollten zumindest). Dass das Ding keinen internen Lock hat ist klar, das hatte ich auch nicht gemeint
Wäre ja dumm für Single-Thread-Anwendungen den Lock-Overhead mitzuschleppen... Es kommt schon vor das ein Immediate Context mit einem gut gewählten Lock-Typ davor mehr bringt als ein Deferred Context. Aber unterm strich sehe ich das ähnlich. Bei DirectX 11 lässt man das lieber in einem Thread.Genau das macht die neue Unity Engine auch. Es wird ein hoch optimiertes Job System und eigener JIT Compile verwendet, der sogar C++ schlagen soll. Es geht nicht nur darum, zu parallisieren, sondern auch den Parallelisierungsoverhead zu minimieren. Die Engine skaliert übrigens auch mit 12 Kernen....
Jo, genau das macht das Unity System auch, Minus das Coroutinen welche das Scheduling sehr effizient gestalten. Ist echt super nice
Aber ja, mit dem Unity Job-System setz ich mich im Moment auch auseinander Ich find Unity eh ziemlich gut gemacht, ich finde nur das Actor System in Unreal besser gelöst als dieses komplett strikte Entity Component-System in Unity. Aber sonst ist Unity einfach besser mittlerweile. Ich freu mich sehr auf den neuen Shader-Node-Editor! Ich hasse GLSL und HLSL...^^ Allerdings ist *schlägt C++* immer relativ^^ Glaub mir, du kannst in C++ immer anfangen dreckig zu spielen und bekommst es dann nochmal schneller. Geht aber auf kosten der Lesbarkeit oder Einfachheit. Ich wäre immer vorsichtig mit Aussagen wie XY ist schneller C++. C++ kann immer auf C und inline ASM runter. Und auch in der Spieleentwicklung ist Performance nicht alles^^ Lesbarkeit ist bei solchen Projekten umso wichtiger
Zuletzt bearbeitet:
G
gaussmath
Guest
Jo, genau das macht das Unity System auch, Minus das Coroutinen welche das Scheduling sehr effizient gestalten. Ist echt super nice
Die Unreal Fanboys kommen natürlich jetzt mit Destructive Meshes um die Ecke. Es gibt ja immer was...
Es ist schon ziemlich beeindruckend, wie effizient das neue Job System geworden ist. Der Abstraktionsgrad ist hoch, trotzdem läuft alles Low Level ab. Aggressives Inlining geht unter C# übrigens auch und man darf nicht vergessen, dass sie den Compiler massiv aufgebohrt haben.
Zuletzt bearbeitet von einem Moderator:
Ähnliche Themen
