News 32+ Kerne für Computerspiele sind kein Problem - Dan Baker Oxide
- Ersteller E555user
- Erstellt am
User-News
Von E555user
Hinweis: Diese "User-News" wurde nicht von der Planet 3DNow! Redaktion veröffentlicht, sondern vom oben genannten Leser, der persönlich für den hier veröffentlichten Inhalt haftet.Dan Baker von Oxide Games hat auf der Khronos-Veranstaltung anlässlich der Siggraph 2018 noch einmal über den Wechsel von alten auf neue APIs für Gameengines rekapituliert (video).
Die Schwierigkeit liegt dabei aus seiner Sicht nicht in der API selbst, sondern darin die alten Konzepte zu verwerfen und asynchrones Multithreading zu denken und umzusetzen. Er gibt viele grundlegende Ratschläge bzw. Dos&Don'ts wie man Multi-CPU Konzepte erfolgreich umsetzt.
Er erläutert dabei wie alte Engines funktionieren und warum diese nicht erfolgreich umgebaut werden können. Man selbst verfolgt dabei recht pragmatische Ansätze.
Deshalb sind alle Komponenten der Engine in eigene Module entkoppelt und es gibt lediglich einen zentrales System für Scheduler und Messaging, alle anderen Services arbeiten dabei so weit wie möglich asynchron parallel. Das Scheduler und Messagingsystem verteilt die Jobs bzw. Tasks auf die zur Verfügung stehenden Threads auf CPUs und GPUs. Synchronisation - gerade unnötige implizite Synchronisation durch die Compiler - wurde weitestgehend abgeschafft.
Sämltliche Shader-Daten werden je Frame komplett neu übertragen, man macht locker 50.000 bis 100.000 Drawcalls, dafür keine Vertex oder Constant Buffers. Dabei werden den etablierten Threads je Frame zwischen 100 bis 500 Jobs verteilt um von der Engine and die Vulkan API übersetzt zu werden. Konstanten werden garnicht zwischen den Frames verwaltet, man hofft auf die treiberseitigen Optimierungen und war bislang von der Performance sehr überzeugt.
Die eigene Engine kann so neben den sonstigen Modulen der Engine für Vulkan bereits sämtliche CPU-Threads nutzen. Die Crux dabei ist, dass für Vulkan selbst im eigenen Fall kaum mehr als 1 oder 2 Kerne für diese "GPU Command" benötigt werden, man ist schon mit einem Kern in bis zu 4ms fertig. Die Cores stehen dann also im Wesentlichen für die anderen Services zur Verfügung.
Interessant ist auch das Statement zu Apple Metal, dass man dort voraussichtlich nicht wirklich mehr als 4 Cores gut nutzen kann.
Sehr schön ist auch im Kontrast der Vortrag im Anschluss von Mikko Strandborg zur Unity-Engine, bei der Vulkan auf die bestehende Konzepte angewendet werden soll, entsprechend berichtet er über wenige Erfolge und viele Probleme im asynchronen Ansatz mit Vulkan.
Man fragt sich letzlich ob für Unity (oder Unreal-Engine) bald eine Zäsur gewagt wird um mit einem Neuanfang den Ballast alter Konzepte abzwerfen und neue Möglichkeiten der Low Level APIs zu nutzen.
Die Schwierigkeit liegt dabei aus seiner Sicht nicht in der API selbst, sondern darin die alten Konzepte zu verwerfen und asynchrones Multithreading zu denken und umzusetzen. Er gibt viele grundlegende Ratschläge bzw. Dos&Don'ts wie man Multi-CPU Konzepte erfolgreich umsetzt.
Er erläutert dabei wie alte Engines funktionieren und warum diese nicht erfolgreich umgebaut werden können. Man selbst verfolgt dabei recht pragmatische Ansätze.
Deshalb sind alle Komponenten der Engine in eigene Module entkoppelt und es gibt lediglich einen zentrales System für Scheduler und Messaging, alle anderen Services arbeiten dabei so weit wie möglich asynchron parallel. Das Scheduler und Messagingsystem verteilt die Jobs bzw. Tasks auf die zur Verfügung stehenden Threads auf CPUs und GPUs. Synchronisation - gerade unnötige implizite Synchronisation durch die Compiler - wurde weitestgehend abgeschafft.
Sämltliche Shader-Daten werden je Frame komplett neu übertragen, man macht locker 50.000 bis 100.000 Drawcalls, dafür keine Vertex oder Constant Buffers. Dabei werden den etablierten Threads je Frame zwischen 100 bis 500 Jobs verteilt um von der Engine and die Vulkan API übersetzt zu werden. Konstanten werden garnicht zwischen den Frames verwaltet, man hofft auf die treiberseitigen Optimierungen und war bislang von der Performance sehr überzeugt.
Die eigene Engine kann so neben den sonstigen Modulen der Engine für Vulkan bereits sämtliche CPU-Threads nutzen. Die Crux dabei ist, dass für Vulkan selbst im eigenen Fall kaum mehr als 1 oder 2 Kerne für diese "GPU Command" benötigt werden, man ist schon mit einem Kern in bis zu 4ms fertig. Die Cores stehen dann also im Wesentlichen für die anderen Services zur Verfügung.
Interessant ist auch das Statement zu Apple Metal, dass man dort voraussichtlich nicht wirklich mehr als 4 Cores gut nutzen kann.
Sehr schön ist auch im Kontrast der Vortrag im Anschluss von Mikko Strandborg zur Unity-Engine, bei der Vulkan auf die bestehende Konzepte angewendet werden soll, entsprechend berichtet er über wenige Erfolge und viele Probleme im asynchronen Ansatz mit Vulkan.
Man fragt sich letzlich ob für Unity (oder Unreal-Engine) bald eine Zäsur gewagt wird um mit einem Neuanfang den Ballast alter Konzepte abzwerfen und neue Möglichkeiten der Low Level APIs zu nutzen.
Zuletzt bearbeitet:
Warum zum Henker ist das heute immer noch ein Thema, das überhaupt den Entwicklern wie sauer Bier nahegebracht werden muss? Es gab schon mit dem Pentium Pro Dual-Boards und damit keine Ausrede, es nicht zu probieren, aber spätestens mit dem Pentium D hätten Spieleentwickler branchenweit anfangen müssen, so ihre NextGen-Engine zu entwerfen. Denn da war klar, dass in Zukunft die Performancezuwächse über mehr Kerne stattfinden.
Ja, man kann einwenden, dass Intel bis heute den Mainstream-PC mit Zweikernern abgespeist hat. Aber der Gamer mit ein bißchen Anspruch hat schon lange einen Vierkerner, und die jetzige Explosion der Kernanzahl kommt auch nicht überraschend. Alles sehr vorhersehbar. Ein Spieleentwickler, der sich jetzt überrascht gibt "oh, wir müssen multithreaded arbeiten" hat irgendwie den Schuß nicht gehört.
Ja, man kann einwenden, dass Intel bis heute den Mainstream-PC mit Zweikernern abgespeist hat. Aber der Gamer mit ein bißchen Anspruch hat schon lange einen Vierkerner, und die jetzige Explosion der Kernanzahl kommt auch nicht überraschend. Alles sehr vorhersehbar. Ein Spieleentwickler, der sich jetzt überrascht gibt "oh, wir müssen multithreaded arbeiten" hat irgendwie den Schuß nicht gehört.
Nosyboy
Grand Admiral Special
Die Technik war der SW schon immer voraus, nix neues. Seit wann gibt es schon 64 Bit Cpu's...
Oder aktuell die Vega GPU von AMD, die kaum ausgelastet wird usw.
Oder aktuell die Vega GPU von AMD, die kaum ausgelastet wird usw.
Stefan Payne
Grand Admiral Special
Because you can get away with that shit!
Und weils in den letzten 15 Jahren ja auch nicht sooo besonders schnell voran ging...
Die Parallelisierung geht erst seit etwas mehr als einem Jahr weiter, davor konnte man irgendwas hinkotzen, so dass 4 Threads halbwegs ausgelastet werden....
Erst seit Ryzen gibt es 8 Kerne im Desktop...
Und du brauchst halt erst mal einen gewissen Leidensdruck, damit sich was ändern kann. Die Baby-Steps von Intel seit Nehalem haben den SW Entwicklern auch nicht gerade Feuer unter dem Hintern gemacht...
Kurz:
Du brauchst erst mal die Hardware im Mainstream, damit sich was an der Software ändern kann.
Früher wars umgekehrt, da hat 'ne Sofware mal eben alle aktuell existierenden Rechner platt gemacht...
Heute wartet man vergebens darauf, dass die Software halbwegs die Hardware ausnutzt...
Ähnliche Themen
