AMD Zen 2: Angeblich zwei Dies mit bis zu 16 Kernen

@gausmath, viking und mango : Ich kapiere gerade gar nix mehr!! Drückt euch so aus, dass der gemeine Pöbel (wie ich ;) ) euch folgen kann!:ugly:
 
Die Kurzversion ist: Schaffe hat unrecht... :D:D

Nein, was möchtest du genauer wissen?
 
Kann der Thread bitte verschoben werden?

Ist ja nicht OT^^, geht um Mehrkernnutzung in Unity und um Mehrkernnutzung mit DirectX 11/12 und damit auch um den Anwendungsbereich von Ryzen mit mehr Kernen ;). Wird nur gerade sehr technisch.

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.

Inline ASM ist inline Assembler xD Klar ist der Compiler gut, aber C++ hat auch einen sehr mächtigen und dazu noch den Low-Level Uugriff den C# nur begrenzt hat. :) Geil ist das Ding aber auf jeden. Aber als jemand der beides ganz gut kann: Hat beides seine Vor- und Nachteile. Ich mag sowohl Unreal als auch Unity.

@gausmath, viking und mango : Ich kapiere gerade gar nix mehr!! Drückt euch so aus, dass der gemeine Pöbel (wie ich ;) ) euch folgen kann!:ugly:

Wir Diskutieren gerade auf technischer Ebene über Parallelisierung (also Multithreading) in Spielen. Der Kommentar von Viking hat sich auf eine technische gegebenheit von DirectX 11 bezogen. Es gibt 3 Komponenten in DirectX um die es gerade ging. Die Direct3DDevice, den Direct3DKontext und den Direct3DDeferredContext. Die Device kann man über mehrere Threads ansprechen (also gleichzeitig), den Kontext nicht und der DeferredContext ist ein Spezialfall was dich in DirectX11 vor ein gewisses Problem mit Multithreading (also für Laien jetzt mal Mehrkernprogrammierung, auch wenn das nur halb wahr ist) stellt, nachdem der Context am meisten verwendet wird. So mal die Kurzform.

Die Diskussion mit gaussmath dreht sich um ein Parallelisierungs-Feature der Unity3D Engine was es erlaubt, "recht leicht" gut mit mehr Kernen skalierende Unity Spiele zu Entwickeln. Sprich, Spiele die von Viel-Kern CPUs profitieren können. Das Teil heißt eben Job-System. Jeder Job ist eine parallele Aufgabe für deine CPU.
 
Zuletzt bearbeitet:
Langsam nimmt Zen 2 Formen an.

Das wird sehr spannend. Ich vermute AMD wird dann erstmals in fast allen Belangen überlegen sein.
Ich schätze bei der IPC ist noch einiges drinnen, da sollte man zumindest auf das Level von Skylake kommen. Auch taktmäßig dürfte zumindest ein ähnliches Niveau erreichbar sein. Damit sollte beim einzigen großen Vorteil den Intel noch hat - die Singlethread Performance zumindest Gleichstand herrschen. Überall anders wird AMD deutlich davonziehen, nachdem AMD dann einen weitaus fortschrittlicheren Prozess haben wird zusammen mit einer Architektur die bereits jetzt deutlich besser skaliert.

Ich schätze, dass dann der 12-Kerner bei gleichen Taktraten so viel Energie verbraucht wie der 6 Kern Coffee Lake heute. Da wird auch im Desktop Bereich nicht mehr viel für Intel sprechen. Bei den Servern werden sowieso Welten dazwischen liegen.
Ich denke AMD wird zumindest für 2 Jahre technisch stark überlegen sein, bis Intel seine Prozessprobleme so weit in den Griff bekommen hat um kontern zu können. Trotzdem - vergleicht man den heutigen Umsatz der beiden und zieht die Trägheit vor allem im Data Center Bereich in Betracht wird es wohl gerade für einen Gleichstand im Marktanteil reichen.

Zumindest wird sich dadurch für AMD die Möglichkeit ergeben ihre Entwicklung auf ein ganz anderes Niveau zu heben. Nachdem sie schon mit sehr begrenzten Mitteln viel Innovation zu Wege gebracht haben, kann das dem Fortschritt nur gut tun.

Wie schon gesagt, es wird spannend!
 
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.

Und was kann man deiner Meinung nach nicht parallelisieren? Da müsste es in Spielen ja trotz Directx12 eine ganze Menge sein.
Was ich halt nicht verstehe: Ihr habt ganz offensichtlich Hintergrundwissen, wieso glaubt ihr dann an diese Multithreading-Propaganda?
Egal welchen Fachartikel man liest und ich bin von der Materie schon einige Zeit wieder raus, kommt man doch eigentlich nicht drumherum diese angebliche Entwicklung die da kommen soll, in Zweifel zu ziehen.

Die Kurzversion ist: Schaffe hat unrecht... :D:D

Ich steig durch die Beitrage halbwegs durch, aber dennoch beantworten sie nicht meine Frage, oder haben mir konkret widersprochen.

Wieso soll mit Directx12 abgesehen von der Draw-Call Geschichte und der Overheadreduzierung und bzw wegnehmen des einen stark belasteten Threads, der Profit an FPS aus mehr Kernen steigen und in welchem Titel kann man das begutachten und was bietet Directx12 abgesehen davon denn so besonderes?
Ihr tut so als ob man alles parallelisieren könnte, sry das halte ich einfach nicht für besonders glaubwürdig.
Ihr schiebt es auf die Unfähigkeit der Entwicker, grade bei Dice, die das ganze Thema angestoßen hatten, mhm.

Ich will mich in die technischen Diskussionen hier überhaupt nicht einmischen, ich beobachte schlicht und ergreifen nur und lese desöfteren mal Fachartikel für Halb-Dummies.
Kann ich wie gesagt nicht nachvollziehen.

Also seit ihr Spieleentwickler, um mal direkt zu fragen und hantiert mit der API?

Mango2Go schrieb:
DirectX12 und Vulkan hebt ja nur das CPU-Limit im Bezug auf's Rendern an.

Wenn das alles ist? Wenn das soviel bringt, wieso nutzt es denn dann niemand? Kann es sein, dass die Drawcalls gar nicht wirklich gebraucht werden, weil man sich mit Direct11 arrangiert hat?
Wieso gibt es kein Directx12 auf High Level Basis mit denselben Funktionen bezogen auf Rendering und den Draw Call CPU entlastungen?

Mantle wollte damals schon kaum einer unterstützen und Directx12 fristet ein ähnliches Schicksal.


Die Engine skaliert übrigens auch mit 12 Kernen.... ;)

Ist das nicht graue Theorie?
 
Zuletzt bearbeitet:
Ich steig durch die Beitrage halbwegs durch, aber dennoch beantworten sie nicht meine Frage, oder haben mir konkret widersprochen.

Das war auch nicht ernst gemeint. Deswegen die Smileys. Wie viel Hintergrundwissen zur Programmierung hast du? Man kann das schwer erklären, ohne halt sehr technisch zu werden.
 
Hintergrundwissen, ich würde mal sagen, nichts was über eine Berufsschulausbildung als Anwendungsentwickler/Wirtschaftsinformatikstudent im dritten Semester hinausgeht.
Das ist aber im Prinzip auch nicht das worum es mir hier geht, mir geht es nicht darum jetzt in die Tiefe zu gehen.
Sondern ich möchte abseits des reduzierten Overheads von Directx12 gerne wissen, warum Directx12 als heiliger Gral für Mehrkernoptimierung gefeiert wird.
Ganz einfach deswegen weil man das überall in den Threads liest und ich es eben einfach nicht für voll nehme, vor allem dann nicht wenn immer solche Pauschalisierungen kommen, besonders von dir.:D

Skaliert mit x Threads, unterstützt 12 Kerne usw. usf.
 
Also wenn man das so liest von den drei Usern, die augenscheinlich entsprechendes Fachissen zur Materie haben und dann suggerieren das dies mit DX12 und der MultiCore Ausnutzung 'so easy' ist (so kommt es rüber) wie sie es schreiben, stellt sich mir die Frage: Sind die AAA Spiele- und AAA Engineentwickler da draußen größtenteils inkompetent/unfähig das die das nicht auch drauf haben oder wissen müssten?

Warum hat der äußerst enthusiastische EPYC 7601 32Core oder Xeon Platinum 8180 28Core Gamer, 2018 ... Jahre nach DX12 Veröffentlichung, höchstwahrscheinlich nicht das bessere Spielerlebnis wie ich als 'popliger' 8700K 6Core Besitzer? Nicht mal in allen DX12 Games? (DX12) Spiele (/Engines) auf Multicore zu trimmen ist relativ einfach, wird hier im Forum zumindest der Eindruck erweckt, AMD kommt scheinbar mit 12Kernen im Mainstream, stehen uns doch rosige Zeiten bevor? Oder kommt dann doch wieder die Ernüchterung, wenn mal die eine oder andere Redaktion das Thema genauer beleuchtet, was im praxisnahem Spieleeinsatz eine 12Kern Unterstützung gegen einen 8Core effektiv an Geschwindigkeitsvorteile bringt?!

Was ist eigentlich eines der vorzeige Games mit 12Core-Support Unity Engine?
 
Ich denke über das jetzt zu diskutieren bringt wenig. Die Nutzung von Mehrkernen ist etwas was mehr oder weniger Stiefmütterlich behandelt worden ist.


Nehmen wir doch mal an AMD schmeißt mit ZEN2 wirklich einen 12K/24T oder 16K/32T Ryzen raus. Dann muss man sich die Frage stellen für was? Auch der Otto Normaluser ist nicht so dumm das er nicht weiß dass das ganze kaum eine Software nutz. Das weiß man aber auch bin AMD und INTEL das dem so ist. Gerade für GAMER ist das heute noch kein wirkliches Argument zu sagen so viel Kerne.

Aber sie werben genau mehr oder weniger mit dem.

Wir müssen auch davon ausgehen das sowohl AMD als auch INTEL da viel mehr sehen kann was in Entwicklung ist als wir. Um einiges mehr. Daher könnte es schon sein das da im Hintergrund kräftig daran gearbeitet wird. Was ich im Interesse beider liegen wird. Haben ja auch beide angekündigt das sie das mehr unterstützen wollen.

Frage warum wollen das beide. Ganz einfach beide sind keine Heiligen, die wohlen Kohle machen. CPUs mit mehr Kernen sind ein echtes Verkaufsargument, aber eben nur wenn es dazu die Software gibt. Sollte also AMD wirklich solche Dinger rausschmeißen, dann würde ich davon ausgehen das da so einiges in Entwicklung ist und sich auch bald einiges ändern wird.

Ich sehe da aber noch ein anderes Problem. Die GAMES von heute nutzen "nur" einen Kern. Verteile ich das auf mehr, bringt das auch nur wenig. Da wird im GAME ja nichts besser. Es muss also auch einen Unterschied zwischen den Spielen geben die "nur" 1 Kern nutzen und denen die mehr Nutzen damit das auch Sinn macht und ein Verkaufsargument ist. Fragt sich halt dann ob es die GPUs mit machen oder alle vier von sich strecken.

Aber ich würde das ganze mal entspannt sehen und sagen halten wird die Gaule mal ruhig. Wenn man schon länger dabei ist so wie ich weiß man auch das es immer gleich abläuft. Zu erst muss die Hardware mal zum kaufen sein die es kann. Dann kommt erst die Software die es ausnutzt nach und die kommt immer. Das war bis jetzt jedes mal so und genau so wird es auch wieder kommen. Ist halt immer nur eine Frage wie lange es dauert. Wenn einer die zündete Idee hat dabei kann das so gar sehr schnell gehen.
 
Hintergrundwissen, ich würde mal sagen, nichts was über eine Berufsschulausbildung als Anwendungsentwickler/Wirtschaftsinformatikstudent im dritten Semester hinausgeht.
Das ist aber im Prinzip auch nicht das worum es mir hier geht, mir geht es nicht darum jetzt in die Tiefe zu gehen.
Sondern ich möchte abseits des reduzierten Overheads von Directx12 gerne wissen, warum Directx12 als heiliger Gral für Mehrkernoptimierung gefeiert wird.
Ganz einfach deswegen weil man das überall in den Threads liest und ich es eben einfach nicht für voll nehme, vor allem dann nicht wenn immer solche Pauschalisierungen kommen, besonders von dir.:D

Skaliert mit x Threads, unterstützt 12 Kerne usw. usf.

Wir ham nie gesagt, dass DirectX 12 der heilige Gral der Mehrkernoptimierung ist, sondern nur, dass es hilft. Was du daraus machst ist nicht unsere Baustelle. Draw-Calls sind nicht immer der limitierende Faktor. Auch das hab ich schon klip und klar gesagt mit mehreren Beispielen was man parallelisieren kann, dass auch Einfluss hat. Aber wenn die einzelnen Elemente leichter zu parallelisieren sind und asynchron ausgeführt werden können wird das gesamte Parallelisieren leichter weil man an weniger Stellen eingreifen muss. Ein Beispiel. Nehmen wir an du kannst Physik und Grafik beides Asynchron machen. Dann kannst du einfach deine ganzen Physik und Grafik-Tasks in eine Queue geben, N Threads drauf loslassen und die machen das scho. Wenn du Physik lock-frei parallelisieren kannst, Grafik aber nicht, musst du erst die Physik tasks an die Threads geben, warten bis die durch sind und dann die Grafik machen. Das ist ungleich aufwändiger und Synchronisation kostet Performance und das nicht zu knapp. Also ja, es hat einen Einfluss.

Also wenn man das so liest von den drei Usern, die augenscheinlich entsprechendes Fachissen zur Materie haben und dann suggerieren das dies mit DX12 und der MultiCore Ausnutzung 'so easy' ist (so kommt es rüber) wie sie es schreiben, stellt sich mir die Frage: Sind die AAA Spiele- und AAA Engineentwickler da draußen größtenteils inkompetent/unfähig das die das nicht auch drauf haben oder wissen müssten?

Warum hat der äußerst enthusiastische EPYC 7601 32Core oder Xeon Platinum 8180 28Core Gamer, 2018 ... Jahre nach DX12 Veröffentlichung, höchstwahrscheinlich nicht das bessere Spielerlebnis wie ich als 'popliger' 8700K 6Core Besitzer? Nicht mal in allen DX12 Games? (DX12) Spiele (/Engines) auf Multicore zu trimmen ist relativ einfach, wird hier im Forum zumindest der Eindruck erweckt, AMD kommt scheinbar mit 12Kernen im Mainstream, stehen uns doch rosige Zeiten bevor? Oder kommt dann doch wieder die Ernüchterung, wenn mal die eine oder andere Redaktion das Thema genauer beleuchtet, was im praxisnahem Spieleeinsatz eine 12Kern Unterstützung gegen einen 8Core effektiv an Geschwindigkeitsvorteile bringt?!

Was ist eigentlich eines der vorzeige Games mit 12Core-Support Unity Engine?

Du missverstehst da was. Threading ist nicht leicht. Ganz im Gegenteil, Threading ist sau schwer. Wir Unterhalten uns hier über Grundsätze. Das Unity Job-System unterstützt bis zu 12 Threads. Das heißt nicht optimieren für 12 Kerne ist easy. Das heißt man hat ein zugängliches Feature um das umzusetzen.
Es wird einfacher weil die Möglichkeiten jetzt geschaffen werden mit Vulkan, DirectX 12 oder auch dem Unity Job-System. Das heißt nicht alles wird jetzt super easy, es wechselt nur von völliger abfuck zu machbar. Aber ja, in AAA Studios gibt es sehr viele Entwickler die von Sachen wie Threading keine Ahnung haben. Deshalb werden Dinge wie Job-Systeme Entwickelt. Schau dir das Panel von Nsughty-Dog an und warte auf die Begründung warum die tun was sie tun. Ein Gameplay-Programmierer mus kein Crack sein um Dinge zum laufen zu kriegen. Threading ist aber schwer. Ich kann threading recht gut, das heißt aber nichts. Zaubetn ksnn ich auch nicht. Aber mit dem Unity Job-System hab ich aber hslt ne chance.
 
Also zunächst mal, ich bin kein Experte für 3D APIs. Die anderen beiden kennen sich besser aus damit.

@Schaffe: Wenn du das so verstanden hast, dass DirectX 12 der heilige Gral ist, wäre ich an deiner Stelle auch misstrauisch, denn so ist es nicht. Mal abgesehen davon, dass Low Level Programmierung eine größere Hürde bei der Entwicklung darstellt und somit höhere Kosten verursacht, wird auch der optimale Einsatz keine Wunder vollbringen. Das ist nichts, was den großen Unterschied zwischen einem 6 und 12 Kerner ausmacht, zumindest bei der derzeitgen Performance von Grafikkarten. Es ist eher so, dass es Bremsen löst und die Effizienz verbessert, die Performance natürlich auch, indem Treiberoverhead reduziert wird und die Last besser auf mehere Kerne verteilt wird.

Jenseits des Renderings, was übrigens auf der CPU durchaus gut parallelisiert werden kann, gibt es noch den ganzen Rest. Hier greifen dann die Vorteile eines hochoptimierten Jobsystems in Verbindung mit optimierten Compilern. Siehe das Video, was ich verlinkt habe. Das ist ein Bereich, wo ich mich auskenne. Was die Jungs da auf die Beine gestellt haben, ist fantastisch. Der Code ist leicht lesbar, abstrakt und sicher gegen Raise Conditions durch das eigens entwickelte Security System, was eine riesige Hürde bei der Entwicklung drastisch verringert. Genau das sehe ich das technologische Potential, welches dann den Unterschied zwischen 6 und 12 Kernen ausmachen kann.

Man darf die bisherige Arbeit und Leistung von Programmierern nicht herabwürdigen. Solche Technologien mussten und müssen erst wachsen und sich verbreiten.

Low Level APIs sollten sich eigentlich schon längst in AAA Titeln weit mehr finden lassen als es bisher der Fall ist, denn die Ressourcen sind da. Für kleine Studios macht es einfach keinen Sinn. Ich denke, dass Nividia nicht ganz unbeteiligt ist an diesem Missstand. Beim Marktführer ist alles auf DirectX 11 getrimmt. Warum sollten sie das aufgeben?

Ich kann gerne, was die Jobsystem betrifft, noch weiter ins Detail gehen...
 
Sollte AMD wirklich 12 Kerne für den Mainstream Sockel bringen, halte ich das für reichlich über trieben, zudem wird da auch sicher ein AM4 + Sockel nötigsein.

Vielleicht laufen ja die kleinen 8 Kerner dann noch auf dem alten AM4.

Glaube ich nicht was begründet deine Aussage?.;)
Die Belegung muss nicht geändert werden die, zusätzliche Spannung zufuhr wird auch nicht benötigt.Und der Aufbau wird denke ich mal auch Simultan sein. Wenn der Bios Support passt, wird das wohl auch so gehen. Es ist nur die Frage ob das gehen sollte. "Bis 2020 unterstützt" heißt ja eben auch nicht das alles was kommt darauf läuft
 
Sondern ich möchte abseits des reduzierten Overheads von Directx12 gerne wissen, warum Directx12 als heiliger Gral für Mehrkernoptimierung gefeiert wird.
Weil die Schnittstelle an sich das ganze tatsächlich trivialerweise erlaubt. Die Schwierigkeit besteht eher darin, eine Engine drum herum zu bauen, die a) daraus die entsprechenden Vorteile zieht, b) gleichzeitig noch mit Dx11 halbwegs vernünftig funktioniert, und c) alle unterstützten Schnittstellen zumindest so weit abstrahiert, dass man nicht den kompletten Renderer zwei Mal schreiben muss. Und ich denke, dass es in erster Linie daran hapert, denn das kann einfach nicht gut gehen - dafür sind die APIs und v.a. auch die "Best Practices" für die beiden APIs einfach zu unterschiedlich.

Effizientes Multithreading in einem Spiel umzusetzen ist natürlich nicht einfach, aber Vulkan und Dx12 stehen einem dabei im Gegensatz zu den alten APIs nicht mehr im Weg. Mit nem Vulkan-only-Ansatz müsste man sich auch um Dx11-Support nicht mehr kümmern, das traut sich außer id Software allerdings noch niemand.

A propos id: Da gab es doch zum Wolfenstein 2-Launch irgendwo ein Interview, wo sich ein Entwickler über diverse Tricks auslässt, durch das Entfernen des alten OpenGL-Renderers aus der Engine möglich geworden sind, dass sie sich praktisch nicht mehr um Draw-Batching kümmern müssen etc. - findet das noch jemand?

Warum Dice den Dx12-Renderer von BF1 dermaßen vergeigt haben, wüsste ich auch gerne, das ging in BF4 und Dragon Age Inquisition mit Mantle schon mal deutlich besser. Es ist ja in dem konkreten Fall nicht nur so, dass das Spiel mit Dx11 eine Ecke schneller läuft als mit Dx12, mit Dx12 war es auf meinem alten System praktisch unspielbar.

Schaffe89 schrieb:
Wieso soll mit Directx12 abgesehen von der Draw-Call Geschichte und der Overheadreduzierung und bzw wegnehmen des einen stark belasteten Threads, der Profit an FPS aus mehr Kernen steigen und in welchem Titel kann man das begutachten
Ich weiß zwar jetzt nicht, worauf die doch etwas lang geratene Frage jetzt genau abzielt, aber Rise of the Tomb Raider würde mir generell als Positiv-Beispiel einfallen, das mit Dx11 auf meinem alten Phenom II X6 im Geothermal Valley seine Mühe hatte, 30 FPS zu halten bei vielleicht 50% CPU-Last, mit Dx12 dann aber problemlos mit 50+ FPS im GPU-Limit lief und das bei deutlich höherer CPU-Auslastung als unter Dx11. Auch der Vulkan-Renderer der kürzlich erschienenen Linux-Version ist im CPU-Limit deutlich flotter als Dx11 unter Windows.

Generell ist Dx12 in vielen der wenigen Spiele, die es überhaupt unterstützen, in einem recht traurigen Zustand, das kann man leider nicht leugnen, aber hin und wieder bringt es eben doch die erwünschten Ergebnisse.

Schaffe89 schrieb:
Also seit ihr Spieleentwickler, um mal direkt zu fragen und hantiert mit der API?
Ich bin der Entwickler von DXVK, einem Dx11->Vulkan-Wrapper für Linux.

Sicherlich nicht der heilige Gral der Mehrkern-Optimierung, auch wenn intern durchaus etwas Multithreading existiert, aber da steht mir eben in erster Linie das Dx11-Design im Weg und nicht das von Vulkan.
 
Zuletzt bearbeitet:
Also seit ihr Spieleentwickler, um mal direkt zu fragen und hantiert mit der API?

Ich bin übrigens normaler Softwareentwickler, mach aber viel privat mit Spieleentwicklung und will auch genau da hin, habe aber auch schon im nicht-Spiele-Bereich produktiv auf Arbeit mit DirectX und OpenGL gearbeitet und kenne mich durchaus mit den APIs aus. Ich hab auch mal testweise und zum üben eine eigene Game-Engine gebaut mit Render-Backend. Sehr primitiv aber solide für's Verständnis. (Daher auch das Code-Sample). Mit Unity und Unreal hab ich schon recht viel gemacht.

Nicht so gut wie Viking der das scheinbar auf hohem Niveau macht aber ich weiß durchaus wovon ich rede.
 
Zuletzt bearbeitet:
Zurück