Nachladeschluckauf, Direct3D lost & High-DPI

Moin!

Ich wollte mal nachfragen was sich so an Erkenntnissen in den letzten Jahren gesammelt hat bezüglich des leidigen OMSI-Nachladens, verbunden mit dem rausfliegen von Direct3D. Ich halte für gewöhnlich meine AI- und Parklisten sparsam so weit es geht, definiere dort (vor allem in der AI List) wenige Modelle mit größerer Häufigkeit, und ein paar wenige zur Abwechslung mit geringer Häufigkeit. Zusammen mit einem guten Kompromiss bei den Einstellungen erreiche ich wirklich für OMSI-Verhältnisse gute Frameraten: meist liege ich um die 40fps und mehr in unkritischen Bereichen, in kritischen Bereichen geht's bei gutem Wetter kaum unter 25. Natürlich je nach Karte, aber das ist so der grobe Schnitt, z.B. in Bad Hügelsdorf. Im Vanilla-Spandau ist das noch mehr. Also also eigentlich fein. Im groben fahre ich mit einer Nachbarkachel, ökonomischem Reflexionsmodus für Spiegel (und ich modifiziere mir alle Busse so, dass der linke Spiegel immer 100% refresht, Rest in den anderen Sichten ist öko und inaktiv wenn man sie nicht sieht), 400m Sichtweite, max 80 KI-Autos/Menschen @ 100%.

Doch beim Nachladen bleibe ich nicht verschont von Rucklern und Freezes, gerade in "kritischen" Bereichen, bis hin zum Freeze mit dem Abdanken und Wiederherstellen vom Direct3D Device. Nur irgendwie erkenne ich hier kein System: auf gleicher Karte mit gleichen Einstellungen zur gleichen Tageszeit im gleichen Bus an gleicher Stelle kann es auch mal richtig angenehm sein zu fahren, völlig ohne Probleme, trotz gleicher Last. Das was ich aber erkenne ist wenns hackt geht die Auslastung eines einzigen CPU-Threads auf 100% und OMSI scheint sich totzurechnen, während die anderen Threads runter gehen auf 0. Im Normalfall habe ich meist durch OMSI 4-6 Threads unter Last, zwei mit vielleicht 70% und die anderen unter 50. Nun könnte ich annehmen dass irgendwo ein Hitzeproblem oder ähnliches besteht, dem ist aber nicht so. Einen Prime95-Durchlauf mit 100% auf allen Kernen und Threads schafft der Rechner über eine halbe Stunde (noch längeren Test eine Weile nicht gemacht, da dieser sowieso ein Horrorszenario ist fern jeder Praxis, und bei Hitzeproblemen oder CPU/Speicherfehlern schon nach wenigen Minuten ein Crash kommen würde). Nun denn... Also auch DirectX neu installiert, und schon vor Wochen OMSI von SweetFX befreit. Aber irgendwo muss da der Wurm sitzen? Ich glaube mittlerweile nicht mal dass es das Nachladen selbst ist, eher dass in der Situation an Kachelgrenzen OMSI in die Knie geht weil ihn irgendwas im System behindert und es als letztes Mittel das Direct3D-Device neustartet, was manchmal eben fehlschlägt. Irgendwo meinte ich gelesen zu haben dass sogar Spotify dazwischenfunken kann. Kann ich mir ehrlich gesagt nicht vorstellen, und ist bei mir eh vom Autostart ausgeschlossen. Chrome ist bekannt dass es Leistung klaut und vor allem Speicher, auch im Hintergrund. Aber was würde Chrome mit Direct3D wollen?

Mich würde es jetzt mal vor allem interessieren wer denn halbwegs erfolgreich dieses Phänomen beseitigt hat, es also definitiv hatte und dann durch irgendeine Maßnahme, sei es durch vor dem OMSI Start 3 mal im Kreis um den Stuhl laufen, los wurde. Denn wie erwähnt, es gibt auch Sessions da taucht dies garnicht auf, geht also auch ohne.

Vollständigkeitshalber das System: ASUS X350 Prime Pro, Ryzen 7 1700X @3,8 GHz, 32GB RAM DDR4-3000, 512GB M.2 SSD, 512GB SATA SSD, 1TB SATA SSD, Geforce GTX 1080, ASUS Essence STX II Sound, Win 10 Pro.

Achja, als Virenschutz hatte ich früher Norton Security genutzt und die OMSI-Folder exkludiert, heute nutze ich den Windows Defender, ebenfalls mit Ausnahmen für OMSI. Unter Norton wars aber nicht anders, dennoch können ja auch Virenscanner ihren Beitrag zu sowas leisten.

Daran hab ich ehrlich gesagt nie gedacht... Eben nachgeschaut, bei mir läuft OMSI im "normalen" Modus. Werd ich jetzt mal ändern, und testen, danke!

Was mir aber noch einfällt beim Durchgucken der Optionen im Reiter "Kompatibilität" ist der Punkt "Vollbildoptimierungen deaktivieren". Dunkel erinnere ich mich an einige Spiele wo es empfohlen wurde auch da Häkchen zu setzen. Könnte auch eine Rolle spielen, allerdings könnte es auch sein dass es hier wurscht ist, weil im echten Vollbild läuft OMSI ja nicht wirklich, eher als rahmenloses Fenster.

So, ich habe gestern mal den Windows 7 Kompatibilitätsmodus mit Adminrechten ausprobiert und ebenfalls die Sklaierung verboten. WObei letzteres bei mir sicher irrelevant ist, da ich auf dem Desktop auch nicht skaliere sondern 2560x1440 in 100% betreibe. Seit dem hatte ich keinen Device-Verlust gehabt, allerdings schon einen Hänger bis zum Stillstand. Glaube aber dass es insgesamt sich gebessert hat.

Hab auch ein wenig das Ladeverhalten mal im Ressourcenmonitor beobachtet. Dazu vorher meine Vehicles auf eine andere SSD (E:) ausgelagert, und auf eine andere SSD (F:) wiederum SceneryObjects und Splines. Von der M.2 (C) lief also der Rest. Das ganze mit NTFS-Link verknüpft. Interessant war dass bei Fahrt fast nur die das Laufwerk C beansprucht wurde, ganz selten hab ich Spikes auf E und F gesehen. Interessant deshalb weil ich mehr Zugriffe auf die SceneryObjects erwartet hätte beziehungsweise Vehicles, aber beide Laufwerke haben ziemlich viel Däumchen gedreht. An der Performance hat diese Umleitung rein garnix geändert, weder zum positiven noch zum negativem. Hatte noch kleine Hoffnung gehabt dass dadurch dass OMSI so parallel auch über verschiedene Busse zugreifen kann (ein mal PCI Express M.2 mit ca. 1,6 GB/s und dann SATA zusammen 500 MB/s), aber das bestätigt mich mal wieder dass bei OMSI 2 der Flaschenhals im Programm ist. War übrigens bei OMSI 1 nicht so, da hab ich bis zu meiner ersten SSD eine RAM-Disk benutzt und kaum bis gar keine Nachladeruckler. Hab ich dann aber aufgegeben, da die SSD sich nur unwesentlich schlechter verhalten hat. Während der 2.1 Beta zu OMSI 2 gabs kurz ein Build der ebenso geil lief, dafür aber paar andere Böcke gehabt. Nun ja, wir haben nun den Build den wir haben und versuchen das beste draus zu machen. Als nächstes löse ich glaub ich aber wieder den Umleitungskonstrukt auf und werd wohl OMSi auch von der M.2 auf eine der SATAS verschieben, denn großen Unterschied macht das nicht. Vielleicht hätte es sogar den Vorteil dass OMSI dann nicht da drauf wäre wo Windows ist während Phasen wo Windows irgendwas im Hintergrund werkelt. Da aber OMSI kaum die Bandbreite zu nutzen scheint glaube ich dass es keinen Unterschied machen wird.

Ebenfalls keinen Unterschied machte das Hinterfragen und Umstellen von Grafikeinstellungen im Treiber. Ob kein AA, 4x AA, SGSAA oder Transparenz-Supersampling ist Jacke wie Hose für die Frames wie für das Laden. Hatte aber gedacht dass vielleicht durch irgendeine Eigenheit irgendeiner Einstellung da vielleicht irgendwo auch eine Bremse entstehen würde, die vor allem an den Kachelgrenzen eine Rolle spielt, Shadercache oder sowas.

Jetzt mal nach etwas länger:

Direct3D Device Lost kam nicht mehr vor. Denke das wird am Kompatibilitätsmodus liegen. Längere Freezes gab es schon, ich meine aber dass die KI-Autos hier die Übeltäter waren. Ich hatte in den AI Listen vereinzelte Halycon AI-Pack-Autos drin, aber eigentlich recht sparsam. Sie scheinen aber wirklich zu heavy zu sein für den AI-Betrieb. Die Kombination aus Spandau-Autos und Hamburg-Autos flutscht besser als auch wenn nur ein einziges Halycon-Auto in der Liste ist. Ohne diese kann ich fast die Menge verdoppeln. An manchen Stellen drückte eine Häufung dieser Autos sogar auf die fps um gut ein Drittel, was für mich nicht akzeptabel ist.

Sorgen machen mir noch einige Busse von denen es keine KI-Versionen gibt und Repaints die ganz wild png, jpg oder tga als Format nutzen, obwohl schon seit Jahren bekannt ist dass OMSI einzig und allein das dds Format liebt. Das wird nämlich auch die Engine überlasten, und genau diese Kandidaten sind dann mal eben schwarz aus der Entfernung. Möglicherweise verschluckt sich OMSI beim Laden manchmal auch daran.

Btw: "maximale Anzahl von Bussen" in den Optionen bezieht sich doch im Gegensatz zu den anderen AI Einstellungen auf den gesamten Verkehr auf der ganzen Karte, oder? Wenn ich z.B. 50 einstelle, fährt eben auch nur auf der ganzen Karte max 50 Solo bzw. 25 Gelenkbusse rum? Das ist schon wichtig für flächenmässig große Karten.

Der Unterschied BMP - DDS ist eigentlich nur dass DDS komprimiert ist, und auch komprimiert im Speicher gehalten wird. BMP macht auch keine Probleme, verursacht nur überproportional große Datenmengen beim Laden, was bei den heute üblichen Texturgrößen eine Rolle spielt.

Es ist sogar noch einfacher: Ist eine gleichnamige DDS Datei im Verzeichnis vorhanden, nimmt OMSi diese bevorzugt, egal welche Endung in der Config eingetragen ist, im repaint oder im Modell. Man brauchts nicht mal löschen, außer man möchte den Speicherplatz nicht verschwenden... Sauberer wäre es dennoch wenn direkt DDS genommen werden würde und auch eingetragen. In OMSI 1 hat das zumindest paar Milli/Nanosekündchen ausgemacht und sich in der Masse bemerkbar gemacht. Eventuell erübrigt sich das aber mit Abschaltung des Loggens.

Ich hab ja Tools um sowas zu bearbeiten, kostet halt viel Zeit, da man doch immer gucken muss zum Beispiel ob die Texturen im Quadratischen Format sind. Konvertiere ich also direkt eine PNG mit 2048x1475 bekomme ich eine kaputte Textur. Die muss ich entweder auf 2048x1024 oder 2048x2048 wandeln. Und wie oft übersieht man da einen Alpha-Kanal, weshalb ich bei TGAs sehr vorsichtig bin. Mit viel Mühe geht das aber. Bei so Sachen wie Matrix würde ich mir das dann sparen.

Ähm ich könnte also `Texturen aus den Vehicles in den Textur-Ordner schmeißen wenn sie sich gleichen? Noch nie probiert;-D

Zitat von Lµkas

Das Problem beim Größen verändern ist halt auch, dass das Mapping verloren geht - oder man verzerrt die Textur, was Nachbearbeitungen schwieriger macht.

An sich kein Problem, denn gemappt aufs Modell wird sie wieder entzerrt. In Einzelfällen kann es aber tatsächlich problematisch sein. Dummerweise zerhaut mein Konverter jede Textur die mit "krummen" Auflösungen nach DDS exportiert wird. Würde eigentlich auch dazu neigen sie krumm zu belassen, daher geh ich auch lieber eine Stufe rauf um die Auflösung quadratisch zu machen, und runter nur wenn der Unterschied wenige Pixel sind.

Nachtrag:

Also die Große macht echt nix. Hab bei zwei bussen von 4096x1475 auf 4096x2048 hochskalliert, was mir sehr weh tat, aber auf 1024 runter wollte ich dann auch nicht. So viel Pixelverschwendung;-D Problem beim Skallieren war dass mir der Alpha der PNG erstmal flöten ging. Hab das per IrfanView gemacht und war mir nicht sicher welche Einstellung ich brauche beim Abspeichern des Zwischenstandes. Überhaupt sind PNGs mit Transparenzen für mich noch seltsam. Bei TGAs sehe ich in Photoshop zumindest den Alphakanal, bei PNGs kann ich manchmal nur raten. Dann hatte der Bus auf einmal keine Scheiben mehr;-D

Ich bräuchte also ein Tool bei dem ich direkt klipp und klar sehe ob da eine Alpha drin ist oder nicht, auch bei PNGs. DXTbmp hat ja einige Möglichkeiten, aber es skaliert automatisch runter, hätte also ohne zu fragen aus der Textur 4096x1024 gemacht, was ich nicht wollte.

Und dann gibt es ja noch bei den Alphas Unterschiede, ob die nur 1 bittig sind oder mit Abstufungen. Ist mir auch nicht ganz klar wie ich das erkennen soll.

Beim Zielformat würde ich natürlich gerne die kleinste Dateigröße vorziehen, aber da gibt es unterschiede. Ich denke für Häuser etc reicht DXT1 ohne Alpha, bei Bussen wäre es auch für Dinge aus dem Innenraum sinnvoll anstatt stur DXT3 oder DXT5 anzuwenden. Das wichtigste wäre aber die Außentextur: mach ich eigentlich DXT5, aber ist das nötig?

Ich glaube nicht dass dds bevorzugt wird aufgrund der Stellung im Alphabet. Hat man nämlich das gleiche mit bmp und dds, Verweis auf bmp in Modell und Config, nimmt sich OMSI trotzdem die dds. Also offenbar ist es das erste wonach es sucht, danach die anderen Sachen.

Und komischerweise reicht es nicht nur die benötigten Repaints zu bearbeiten. Wenn beim Ausgewählten Busmodell andere Repaints drin sind die aber aktiv nicht genutzt werden weder vom Spieler noch der AI Liste, lädt OMSI diese trotzdem gerne rein. Ich hatte auf Grunddorf einen Bus getestet bei dem ich die Bearbeitungen testen wollte und als ich mir die geladenen Texturen auflisten ließ kamen da Dateien zum Vorschein die garnicht relevant waren.

Nachtrag 2:

Dass die Speicherverwaltung von OMSI sagen wir mal seltsam ist war mir ja bekannt. Dass es ohne virtuellen Speicher abschmiert auch (hatte das vor Jahren mal probiert). Gestern aber doch was sonderbares entdeckt: ich bin zur HVZ in Fikcyjny Szczecin gefahren, hatte mir dort nach X10 Vorbild die Verkehrsdichte in Lastrichtung erhöht mit separater AI-Klasse und wollte das ausprobieren. Nun ist vor allem meine Bus-AI da nicht gerade optimal, denn es scheint üblich zu sein für jeden Wagen ein separates Repaint zu machen, da sonst nicht mal die Kennzeichen angezeigt werden. Dann gibt es natürlich keine AI-Versionen der Busse sondern mit Morphy-Sounds und Getrieben versehene Busse, die als Spielerbus toll sind, in der AI allerdings suboptimal, und natürlich PNGs zu hauf. Ein schwarzer Solaris kam also relativ oft vor wenn viel unterwegs war. Ich habe aber während der Fahrt etwas in Process Lasso rumgedoktort (ein Tool welches in jedem wärmstens empfehlen kann, nicht nur für OMSI) und hab spaßeshalber bei OMSI.exe auf "Virtuellen Arbeitssepicher trimmen" geklickt. Eine Funktion die ich nie genutzt habe bisher, da ich das Tool eigentlich nur zum klaren separieren von Prozessen auf einzelne CPU-Kerne nutze, damit Spiel und Rest (OS etc) wirklich getrennt laufen. Ergebnis: OMSI.exe schrumpfte von etwa 1,4 GB auf etwa 150 MB (!), und ich erwartete sofort eigentlich einen Absturz. Aber nix, lief astrein weiter und wuchs dann erneut, aber vielleicht auf nur 600 MB. Irgendwann das Spielchen nochmal wiederholt. Im Spiel selbst nix negatives bemerkt, nur immer mal geguckt im Debug Fenster viele KI-Busse so aktuell rumfahren, es waren knapp 200. In dieser Spielsession kam mir danach kein einziger schwarzer Bus entgegen, völlig unnormal wo ich ja weiss wie suboptimal das eingesetzte Fahrzeugmaterial ist. Noch überraschender war aber dass an den Kachelgrenzen die Nachladeverzögerungen deutlichst geringer waren und eigentlich nur zu spüren waren in den Bereichen wo es vorher auch mal Freezes gab, aber dort war es auch nur noch minimal. Ich kam aus dem Staunen echt nicht raus, zumal ich glaube dass die Größe der Exe sich deshalb reduziert hat, weil das Tool Teile in den virtuellen Arbeitsspeicher verfrachtet hat, oder zumindest in einen Cache im RAM. Aber offenbar hat es Tante OMSI sehr gut getan. Selbst bei OMSI 1 hatte ich noch nie gesehen dass die exe so klein war.

Jetzt beobachte ich das mal längerfristig bevor ich mir wirklich die Mühe mache alle PNGs and TGAs anzugehen, oder es dann halt mache wenn ich richtig viel Zeit habe. Unabhängig davon lege ich jedem ans Herz das besagte Tool mal zu testen, gerade auf Systemen mit deutlich mehr als vier Kernen. Bei Ryzen 8-Kernern der ersten zwei Generationen zum Beispiel kann man so auch vermeiden dass OMSI (und auch Lotus) seine Threads auf beide CCX verteilt, aber alleine die Trennung beim Spielbetrieb bringt einiges. In GTA 5 habe ich so jeden verbliebenen Mikroruckler eliminiert, bei Xplane stabilere Frameraten und in OMSI auch paar FPS rausgekratzt vor allem in Momenten wo das Betriebssystem halt trotzdem meint irgendwas rumwurschteln zu müssen. Vor allem auf guten, vielkernigen Systemen bringts was, könnnte aber auch durch ähnliche Maßnahmen bei kleineren helfen.

Zitat von James O'Neill

Das klingt interessant. Magst du dazu vielleicht mal generell ein Tutorial erstellen? Würde sicher viele hier, inkl. mir, interessieren.

Es gibt bei YouTube eins für XPlane, das gilt analog eigentlich auch für OMSI. Da geht es vor allem um die Separierung der Threads auf einzelne Kerne. Hier muss man dann aber im Einzelfall gucken was sinnvoll ist für einen selbst. In meinem Fall macht z.B. Sinn ein Profil anzulegen und die OMSI.exe auf die zweite Hälfte der Kerne zu legen (Threads 8-15, Alle OS-Sachen, Virenscanner und Google Chromes etc auf 0-7 oder gar 0-4 / 0-2 je nach dem...), wobei ich immer noch nicht ganz sicher bin ob nicht gar jeden zweiten ab 8 dann wegen SMT. Dann gibts noch I/O Prioritäten die man festlegen kann, Speicherpriorität, und Prozesspriorität, hat aber meiner Meinung nach kaum bis wenig Auswirkung. Das alles ginge auch ohne Tool, aber wär äußerst mühselig mit dem Taskmanager, gerade für die ganzen im Hintergrund laufenden Prozesse, Hier kann man einfach alle markieren und denen Einstellungen zuweisen.

Hier der Link zum Tutorial:

Die schwarzen Busse sind übrigens doch nicht ganz weg, und ein paar Hänger gabs auch wieder;-D Ich wundere mich trotzdem was da denn passiert dass die OMSI.exe so radikal schrumpft...

OMSI nimmt doch die Auflösung vom Desktop, kann also theoretisch auch in 4K und mehr laufen...