Systemanforderungen

Achtung: Halbwissen

in DMXC3.3 wird die Kommunikation zwischen Kernel und GUI auf gRPC umgebaut. Dies ist deutlich schneller. Kommt drauf an, wie groß für dich groß ist, aber das könnte ein Teil des Problems sein. Oder benutzt du schon die 3.3RC2?

Ich vermute, dass DMXC3 kaum für GPUs direkt optimiert ist. Solange deine CPU bzw deine integrated graphics nicht voll, oder annäherned voll ausgelastet sind, sollte DMXC kaum "entschleunigt" werden. Generell sind die Grafikanforderungen von DMXC aber auch nicht sonderlich hoch. Die Stageview zieht wahrscheinlich am meisten, gerade bei vielen/komplexen Geräten.

Quote from showtechniker

in DMXC3.3 wird die Kommunikation zwischen Kernel und GUI auf gRPC umgebaut. Dies ist deutlich schneller. Kommt drauf an, wie groß für dich groß ist, aber das könnte ein Teil des Problems sein. Oder benutzt du schon die 3.3RC2?

Ja, mittels gRPC ist die Kommunikation zwischen den ganzen Programmteilen deutlich effektiver. Das wichtigste ist hier: die Technologie selbst. Bis einschließlich DMXControl 3.2.3 kam für die Kommunikation das .net Remoting zum Einsatz. Dies ist aber technisch veraltet und auch schon lange abgekündigt. Aber in der Summe hat die Netzwerkkommunikation nicht den großen Einfluss auf die benötigte Systemleistung.

Quote from showtechniker

Ich vermute, dass DMXC3 kaum für GPUs direkt optimiert ist. Solange deine CPU bzw deine integrated graphics nicht voll, oder annäherned voll ausgelastet sind, sollte DMXC kaum "entschleunigt" werden. Generell sind die Grafikanforderungen von DMXC aber auch nicht sonderlich hoch. Die Stageview zieht wahrscheinlich am meisten, gerade bei vielen/komplexen Geräten.

Ganz im Gegenteil: Teile von DMXControl 3 laufen aktuell noch mit einer Gaming Engine - dem XNA-Framework. Das sind mit Stand DMXControl 3.3.0 noch die Stage View, der Programmer, das Input Assignment und der Network Monitor. Wie groß die Anforderungen aber sind, hängt wieder vom Projekt ab. Ein paar wenige Geräte können auch von einem PC / Laptop mit nur mittelmäßiger Hardwareausstattung gut angesteuert werden. Das Problem am XNA ist, dass es zum einen auch abgekündigt ist und nicht mehr weiterentwickelt wird. Zum anderen kann es mehrere einzelne Fenster nicht so gut beschleunigen. Deswegen steht ja hier der große Umbau der Fenster auf WPF auf dem Plan, weil dies hier in der Summe effizienter arbeitet und grundsätzlich besser parallelisieren kann.

Quote from Homer-J-Simpson

Mir ist bewusst, das ihr daran (TCshow) noch schraubt , jedoch wollte ich Mal fragen welche Faktoren relevant sind , mehr Grafikleistung, oder doch die Kerne .. oder oder oder ?

Wenn ich mir jetzt eine andere grafikkarte hole, worauf ich achten sollte , um so gut wie möglich unserem geliebten Lichtprogramm eine gute Basis zu Bieten .

Da sind wir genau bei dem Punkt, den ich eben schon eingeleitet habe: was willst du machen? Und auch wie? Gerade wenn du beim Programmieren eines Projekts mit vielen Geräten auch noch viele Fenster offen hast, brauchst du natürlich mehr Leistung als für das Abfahren einer Show, wo vielleicht nur noch die Executoren in der GUI offen sind. Daran kannst du folgendes Ableiten:

• Kernel: eher CPU-lastig, jedoch werden für ein paar Dinge wie die Gobo-Korrelation auch auf der GPU berechnet
• GUI: eher GPU-lastig, allerdings stark davon abhängig, wie viele Fenster offen sind und wie groß das Projekt ist und wie viele Bildschirme bespielt werden sollen ("Grundlast")

All dies ist natürlich immer noch nicht wirklich greifbar. Ich kann dir aber mal ein paar Erfahrungswerte an die Hand geben:

• York in Kassel: Desktop-PC mit AMD Ryzen 3 3200G, 16GB RAM, nVidea GTX 1650 8GB
• Phoenix Fight Championship und Lightshow "Out of the Box": mein Office-Notebook mit Intel i7-7700HQ, 16GB RAM, Intel HD 630 + nVidia GeForce GT 940MX (2GB RAM)
• DMXC-Jahrestreffen 2024: mein Licht-Notebook mit Intel i7-8850H, 32GB RAM, Intel UHD 630 + NVIDEA Quadro P2000 4GB
• Mein Desktop-PC: AMD Ryzen 7 3700X, 32 GB RAM, NVIDEA RTX 2060 Super 8GB

Mit allen System konnte ich alle Setups so fahren, wie ich es haben wollte. Einzig beim Programmieren der Lichtshow fürs Jahrestreffen 2024 hat sich bei meinem Office-Notebook gezeigt, dass hier die interne Grafikkarte mit mehreren Stage Views auf zwei Full-HD-Monitoren bereits überfordert ist, während es auf meinen Desktop-PC mit einem Display mit einer Auflösung von 5210 x 2560 besser lief.

Also um hier mal ein wenig mit dem Halbwissen aufzuräumen, die Aussagen von LightningBrothers mal auch von Entwicklerseite zu ergänzen und vor allem die ganz unterschiedlichen Einflüsse und Einflussbereiche aufzuzeigen: Hier ein etwas längerer Post, denn es ist kompliziert

Erst einmal allgemein: DMXControl 3.3.0 ist nicht ein Programm sondern im Grunde 3 Programme (genauer 4, wenn man den Launcher mitzählt, aber der hat an dieser Stelle keinen Einfluss). Wie Stefan schon ausgeführt hat, haben Kernel und GUI unterschiedliche Anforderungen, was die Ressourcen angeht. Nur der Umbra ist da etwas genügsamer bzw. braucht eigentlich eine möglichst schnelle Verarbeitung des Netzwerk-Verkehrs. Aber lassen wir diesen erst einmal außen vor. So sind also wirklich vor allem der Kernel und die GUI in der Betrachtung relevant. Allerdings kommt es nun darauf an, was du machen möchtest. Und da rede ich jetzt nicht von der Größe des Projekts wie Stefan, sondern wirklich welche Bereiche du in DMXControl 3 genau berührst und wie du diese nutzt. Beispiel Matrix: DMXControl 3 berechnet Matrizen rein auf der CPU (hier ist bisher keinerlei GPU-Code entwickelt worden). Das hat zur Folge, dass bei sehr großen Matrizen die Updaterate in die Knie geht. Allerdings gibt es hier auch eine optimierte Variante. Wenn man mal in den DDFs genau darauf achtet, fällt bei der Definition von Matrizen auf, dass man dann nur ein eingeschränktes Funktionsset hat, was die einzelnen Pixel einer Matrix können. Das liegt daran, dass dafür ein optimierter und deutlich beschleunigter Rechenpfad eingebaut wurde, der zwar auch noch auf der CPU läuft, aber einige der HAL-Teile umgeht und so selbst bei großen Matrizen halbwegs vernünftige Updateraten bietet.

Nun zur CPU: DMXControl 3 besteht an sich aus mehreren Multi-Core-Applikationen, sie können also mehrere Kerne einer CPU nutzen. Das ist anders als z.B. DMXControl 2, was eine reine Single-Core-Applikation war. So machen wir an vielen Stellen von der Nebenläufigkeit Gebrauch, vor allem in der GUI. Wenn wir z.B. wissen, dass wir auf etwas kurz warten müssen (z.B. auf eine Antwort des Kernels), dann machen wir diese Aufrufe asynchron oder starten für gewisse Dinge eigene Threads, die dann prinzipiell auch auf anderen Kernen laufen können (so eben, wie das heute bei GUI-Programmierung üblich ist). Allerdings ist der Einsatz von mehreren Kernen nicht an allen Stellen sinnvoll. Und da kommen wir jetzt zum Kernel. Beispielsweise ist es bei einem gewissen Teil des HAL nicht sinnvoll, ihn zu parallelisieren. Das liegt daran, dass man sich dann andere Probleme einhandelt (aufwändiges Zusammenführen der Daten, nötige Wartepausen und möglicherweise auch sog. Race-Conditions). Da könnte eine Parallelisierung auch kontraproduktiv sein. Hier kommt es also auf die reine Single-Core-Performance der CPU an. je höher diese ist, desto besser. Und da können manchmal die "fetten" CPUs mit vielen Kernen schlechter als manch kleinere CPU mit wenigen Kernen sein da die "Kleinen" CPUs manchmal mehr Single-Core-Leistung haben als "die Großen". Außerdem ist hier zumindest bisher meist Intel besser als AMD, wobei letztere bei der Single-Core-Performance stark aufgeholt haben.

Kommen wir zur GPU: Diese wird immer wichtiger werden, denn anders als von showtechniker vermutet, läuft in DMXControl 3 doch schon ein bisschen was auf der GPU und das wird in Zukunft immer mehr werden. Erst einmal zum Status Quo. In der GUI von DMXControl 3.3.0 laufen insgesamt 3 Grafik-Frameworks / -Engins: Windows Forms (kurz WinForms), WPF und XNA. Zu letzterem hat Stefan ja schon ein bisschen war gesagt aber hier noch einmal die genauere Ausführung: Bei XNA handelt es sich tatsächlich um eine Game-Engine, ähnlich wie die heute durchaus bekannten Game-Engines Unity und Unreal Engine 5. XNA ist dabei aber auch für 2D Grafiken optimiert, was wir ja bei uns brauchen. Allerdings besteht eben die Problematik, die Stefan schon angerissen hat: XNA ist abgekündigt und wir wollen davon weg. Was Stefan aber nicht angesprochen hat sind WinForms und WPF. Ersteres ist das Fenster-Framework, welches wir bisher nutzen und welches die Steuerelemente anbietet, die man für Windows-Applikationen mit GUI braucht. Allerdings ist WinForms nicht wirklich auf hohe Grafik-Performance optimiert und das war auch der Grund, warum wir damals überhaupt angefangen haben, XNA in DMXControl 3 zu nutzen. Wäre nämlich die Stage View mit WinForms geschrieben, so hätten wir Updateraten von so einem Bild alle 1 bis 3 Sekunden. Hier kommt nun WPF ins Spiel. Dieses bietet ähnlich wie WinForms auch die ganzen Windows-Steuerelemente wie Buttons, Dropdowns etc. an, ist aber auf Grafikperformance optimiert, sprich ein Großteil der Anzeige wird aktiv auf der Grafikkarte gerechnet. Das ist der Grund, warum wir nun überhaupt aufwändigere Fenster wie z.B. die Executoren mit einem recht modernen Design bauen können, ohne uns zu hart zu verbiegen (wie das in XNA nötig ist). Mittel bis langfristig wollen wir daher komplett auf WPF umsteigen. Dadurch versprechen wir uns an manchen Stellen neben vielen anderen Dingen auch Performance-Verbesserungen. Alle neuen Fenster in DMXControl 3.3.0 sind daher bereits in WPF gebaut (u.a. Executoren, der Timecode-Player, die Master, die Projekt Administration und ein paar mehr) und wir werden jetzt Schritt für Schritt alte Fenster in WPF neu schrieben. Alles geht mit WPF aber auch nicht, weshalb Qasi da beim Timecode-Player noch einige Dinge selbst auf der Grafikkarte rechnen muss (und deshalb für den TCP noch einen Teil Shader-Code für die Grafikkartenberechnung geschrieben hat). Das heißt aber eben auch, dass die Grafikkarte für DMXControl 3 (zumindest für die GUI) in Zukunft immer wichtiger werden wird.

Kommen wir zum Arbeitsspeicher: DMXControl 3 ist aktuell größtenteils eine 32bit-Anwendung (nur der Umbra ist schon eine 64bit Anwendung). Das liegt daran, dass in der GUI wie im GPU-Abschnitt schon geschrieben eben XNA werkelt, was leider nur 32bit unterstützt. Im Kernel sind wir auf 32bit beschränkt, weil es eben einige Ausgabeplugins gibt, die 32bit benötigen und welche sich nicht in 64bit laden lassen. All das hat zur Folge, dass DMXControl 3 nur eine beschränkte Menge an Arbeitsspeicher nutzen kann. Das sind zwar theoretisch im Maximum etwa 4GB an RAM, die mit 32bit addressierbar sind. Aber praktisch ist das deutlich weniger und so ist meist schon bei so 1,6 - 1,8GB bei DMXControl 3 Schluss. Dann passt nichts mehr in den nutzbaren Speicher und DMXControl 3 (vor allem der Kernel) wirft OutOfMemory Exceptions und muss neu gestartet werden, obwohl der Arbeitsspeicher vor allem bei den heutigen Größen noch recht leer ist. Mittelfristig werden wir hier komplett auf 64bit umsteigen. So gehören dann auf einmal diese Arbeitsspeicher-Probleme bei größeren Projekten der Vergangenheit an.

Ich hoffe, dieser doch etwas längere Post hat etwas zur Klarheit bei den Zusammenhängen beigetragen

Viele Grüße

JP

Quote from Homer-J-Simpson

Um die Sache komplett zu bekommen, bitte ich nochmal ausführlich darauf einzugehen welche Systemkomponenten für den Netzwerkverkehr in Frage kommen . Und was man speziell dort, Hardwaretechnisch optimieren kann , gibt es da Netzwerkkarten die da besser sind oder fällt da die Last auch zurück auf die CPU ?

Letztendlich brauchst du in DMXControl 3 ähnlich wie auch bei vielen Online-Spielen eine niedrige Latenz. Die reine Netzwerkkarte ist aber vor allem dann relevant, wenn GUI und Kernel auf unterschiedlichen PCs laufen. Da gibt es zwar Netzwerkkarten, die behaupten, für Online-Spiele optimiert zu sein, aber das klingt häufig nach Schlangenöl bzw. um von den Gamern gekauft zu werden. Sind GUI, Umbra und Kernel auf dem selben Rechner, sind aber diese Latenzen eigentlich immer vernachlässigbar. Da bringt eine optimierte und mit geringen Overhead versehene Netzwerkkommunikation in der Applikation mehr als eine spezielle Netzwerkkarte. Deshalb nutzt DMXControl 3.3.0 an dieser Stelle wie schon gesagt auch gRPC, ein von Google entwickeltes Netzwerkprotokoll, was die für den sehr schnellen Datenaustausch zwischen ihren Servern verwenden. Und das merkt man tatsächlich im Vergleich zum alten .Net Remoting. Damit haben wir mal bei unserem Video zu gRPC zwei Verbindungen quer durch Deutschland aufgebaut (Stuttgart <=> Magdeburg <=> Dortmund). Da war dann die GUI zwar ein klein wenig laggy (sprich hat sich bei einzelnen Operationen ein paar 100ms Verarbeitungspause gegönnt, die man wahrgenommen hat). Aber es war erstaunlich, wie gut das schon "out of the box" funktioniert hat, ohne das wir da jetzt schon etwas massiv darauf hin optimiert haben. Deshalb lange Rede, kurzer Sinn: Konzentriere dich da eher auf die anderen Komponenten und verwende eine ganz normale Gigabit (oder schneller) Netzwerkkarte.

Was an Daten durch das Netzwerk geschoben werden, zeigt dir DMXC 3.3.0 ja auch oben rechts an -auch wenn alles lokal läuft.

Insgesamt ist dann das Laden und Speichern des Projekts der Teil, der mit am meisten Datenverkehr generiert. Selbst das Wiedergeben einer Timecode-Show verursacht wieder Datenverkehr, da nämlich die FFT-Darstellung komplett in der GUI verarbeitet und dies nur mit dem Kernel abgeglichen wird, wo sich der Wiedergabemarker befindet.

Daher kann ich die Aussage von JPK nur voll und ganz bestätigen, dass eine Standard-Gigabit-Onboard-Netwerkkarte bereits mehr als ausreichend ist - ich habe nämlich nichts anderes und schnelleres.