ZFX + Developia

Hallo Leute,

ich habe gerade einen seltsamen Fehler verfolgt, der sich beim Splitterwelten-Leveldesigner als gelegentlicher Crash geäußert hat. Laut Log eine std::bad_alloc, mal hier, mal da. Jetzt habe ich den Crash mal daheim nachstellen können und habe festgestellt, dass der Task Manager kurz vor dem Crash einen Speicherbedarf von etwa 1,6GB anzeigt. Nach meinem Verständnis sollte da noch nichts schiefgehen. Es ist zwar eine 32Bit-Anwendung, aber auch bei der ist bei anderthalb GB noch lange nicht Schluss. Nun meine Fragen:

a) Hat der TaskManager den VideoRAM-Verbrauch schon mit reingerechnet? Wir haben inzwischen etwa 800MB allein an Texturen.
b) Gibt es gängige Schalter oder sowas, mit denen ich mehr Adressraum für meine App kriegen kann? Bis zu 4GB ist ja noch einige Luft, auch wenn ich davon natürlich nicht alles kriegen kann.
c) Und wenn das schiefgeht: Gibt es gängige Methoden, den Adressraum zu schonen?

Ich hab ein 64Bit-System mit 6Gb RAM, aber z.b. unser Leveldesigner ist noch mit 32bit-Windows7 unterwegs. Und ich möchte ehrlich gesagt auch nicht das erste Spiel weltweit sein, dass 64Bit voraussetzt.

Wenn ich mich richtig entsinne haben normale 32bit-Anwendungen, egal ob 32bit oder 64bit System unter Windows 2GB Adressraum zur Verfügung.
In C++ beim Visual Studio habe ich unter Linker->System die Einstellung "Enable Large Adresses" die das Large Adress Aware Feature anstellt mit dem afaik unter 32bit Systemen 3GB Adressraum und unter 64it Systemen 4GB Adressraum für ein 32bit Prozess zur Verfügung stehen.
Ist nur ein Schalter, ohne weitere Auswirkungen soweit ich weiß.

Nachtrag: YADC braucht den schon seit längerem *g*

Interessanter Hinweis, von dem Schalter wusste ich noch nichts. Das wär ja evtl. die Easy-Out-Lösung, die ich mir erhofft hatte :-)

[edit] Klappt! Du bist mein persönlicher Held!

Das dürfte auf einem 32bit-Windows mit Default-Konfiguration aber keinen Einfluss haben. Siehe hier:

Limit in on X86:

2 GB

Up to 3 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE and 4GT

Das "4GT" muss man erst explizit einschalten. Das sollte laut dieser Quelle so gehen:

To enable 4GT, use the BCDEdit /set command to set the increaseuserva boot entry option to a value between 2048 (2 GB) and 3072 (3 GB).

Artificial Mind hat geschrieben:Wenn ich mich richtig entsinne haben normale 32bit-Anwendungen, egal ob 32bit oder 64bit System unter Windows 2GB Adressraum zur Verfügung.
In C++ beim Visual Studio habe ich unter Linker->System die Einstellung "Enable Large Adresses" die das Large Adress Aware Feature anstellt mit dem afaik unter 32bit Systemen 3GB Adressraum und unter 64it Systemen 4GB Adressraum für ein 32bit Prozess zur Verfügung stehen.
Ist nur ein Schalter, ohne weitere Auswirkungen soweit ich weiß.

Jopp.. war bei mir auchmal so.
Hatte mich gewundert das mein Programm immer abschmiert aber noch genug RAM da war. War da fast am verzweifeln!! Bis mir da auch mal jemand den Tipp gab.
Sollte man mMn standartmäßig einachalten!

Default mässig einschalten würde ich nicht machen, kann auch Probleme geben (andere Programme). Das ist ja nur ne "Notlösung" von MS wie damals EMS. :)
Die richtigere Alternative wäre doch auf 64 Bit umzustellen, dann haste das Problem nicht.

Wieso sollte das mit anderen Programmen in Konflikt kommen?

Schrompf hat geschrieben:a) Hat der TaskManager den VideoRAM-Verbrauch schon mit reingerechnet? Wir haben inzwischen etwa 800MB allein an Texturen.

Gute Frage, welchen Wert im TaskManager meinst du denn genau? Unter Windows ist der VRAM virtualisiert, weswegen sowas wie ein "VideoRAM-Verbrauch" nicht unbedingt eindeutig definierbar ist. Sinnvoll wär wohl, eine Art Working Set zu betrachten. Ich würde jetzt aber mal vermuten, dass die entsprechenden Werte im TaskManager sich rein auf den Arbeitsspeicher beziehen.

Allerdings frag ich mich grad, ob 800MB Speicherverbrauch nur für Texturen nicht generell ein wenig viel is?

Schrompf hat geschrieben:c) Und wenn das schiefgeht: Gibt es gängige Methoden, den Adressraum zu schonen?

Weniger Speicher verbrauchen ;)
Falls das Game Direct3D 9 verwendet: Hast du irgendwelche Ressourcen im Managed Pool rumliegen?

/LARGEADDRESSAWARE wurde ja schon genannt. Ich würd das Flag auch defaultmäßig immer einschalten (im x64 Compiler ist es automatisch an), denn es gibt praktisch keine Nachteile, nur Vorteile. Problematisch wirds z.B. nur, wenn man's mit hässlichem Code zu tun, der von irgendwelchen Pointerhacks abhängig ist.
Aber: Durch dieses Flag bekommt man nicht automatisch mehr RAM! Das ist nur ein Hinweis ans OS, dass die Software den ganzen Adressraum nutzen kann. Aber unter 32bit Windows bekommt eine Anwendung niemals mehr als 2GB, sofern Windows nicht über eine Bootoption entsprechend konfiguriert wurde (die oberen 2GB sind prinzipiell für das OS reserviert) und auch dann ist bei 3GB Schluss. Unter 64bit Windows bekommt man damit allerdings die vollen 4GB.

odenter hat geschrieben:Default mässig einschalten würde ich nicht machen, kann auch Probleme geben (andere Programme). Das ist ja nur ne "Notlösung" von MS wie damals EMS. :)

Was für Probleme meinst du genau und inwiefern handelt es sich da um eine "Notlösung"?

Naja, 800 MiB fuer Texturen hat man schnell erreicht, ohne MIPs sind das ~600, was bei heutigen Texturaufloesungen nicht gerade viel ist.

Du kannst testweise mal ein paar der oeffentlich verfuegbaren Alternativ-Allokatoren/Heaps ausprobieren und gucken ob das den Speicherverbrauch merklich reduziert - die optimieren insbesondere kleine Allokationen, denn auch Kleinvieh macht bekanntlich Mist.

Einen Versuch ist das sicherlich wert, aber zu viel wuerde ich mir davon nicht versprechen. Vielleicht erinnerst du dich noch, dass wir bei Assimp mal vermutet hatten, dass unsere vielen Mikro-Allokationen fuer gewaltig Extra-Overhead und Fragmentierung sorgen koennten, aber letztlich wurde es nicht wesentlich besser als wir testweise einen alternativen Scratch-Heap mit Overhead ~0 ausprobiert haben.

Ansonsten wuerde ich mal gezielt nach Speicherlecks suchen.

Nachdem ich davon ausgehe dass du bei Splitterwelten im Editor vermutlich recht umfangreiche Textur- und Volumendaten im Arbeitsspeicher vorliegen hast, koenntest du es auch mal mit in-memory Kompression probieren. zlib blockweise ueber grosse Datensaetze drueberzujagen macht nicht viel Aufwand und sollte heutige CPUs nicht weiter anstrengen.

Es gibt auch eine ganze Menge komprimierter Texturformate, vielleicht kriegt man damit noch mal was raus. Jedenfalls auf der VRAM-Seite.

Ja, Texturkompression ist auf jeden Fall mal ein Tipp. Ich kenn natürlich deine Technologie nicht, aber vielleicht kann man die Sprites auch so in Spritesheets anordnen, dass die Anzahl der zu jedem Zeitpunkt benötigten Texturen minimiert wird (evtl. z.B. für jede Map einen eigenen Atlas baken, sodass nicht gleich ein paar 4k² Texturen geladen werden müssen nur weil aus jeder genau ein einzelnes 32x32 Bildchen benötigt wird)!?

Aramis hat geschrieben:Naja, 800 MiB fuer Texturen hat man schnell erreicht, ohne MIPs sind das ~600, was bei heutigen Texturaufloesungen nicht gerade viel ist.

Ja, für sowas wie Crysis 2 erscheint mir das auch nicht gerade viel. Aber für einen 2D Zombie Shooter doch irgendwie schon...

Also meine Erfahrung dazu ist:
- lustigerweise war der Verbrauch meines Programms auch bei ca. 1.6 GB wo es abgestürzt ist.
- ich hatte da nix mit VRAM zu tun gehabt
- es hatte bei mir auch definitiv nix mit Leaks zu tun gehabt...
=> scheint etwas anderes gewesen zu sein! Aber warum es sich so verhält wäre echt mal interessant zu erfahren. Vorallem, dass das nur auf x64-Windows-Systemen passiert ist...

dot hat geschrieben:Ja, für sowas wie Crysis 2 erscheint mir das auch nicht gerade viel. Aber für einen 2D Zombie Shooter doch irgendwie schon...

Ging um Splitterwelten ;)

Artificial Mind hat geschrieben:

dot hat geschrieben:Ja, für sowas wie Crysis 2 erscheint mir das auch nicht gerade viel. Aber für einen 2D Zombie Shooter doch irgendwie schon...

Ging um Splitterwelten ;)

Oops, dann hab ich nichts gesagt :mrgreen:

Alle Adressräume sind am Ende... heute wird doch jede ernst zu nehmende App in JS geschrieben und frag mal einen JS Programmierer was denn bitte ein 'Adressraum' ist !? Parallel dazu scheint fast jeder Browser in der Lage zu sein sämtlichen verfügbaren virtuellen und echten RAM einem Script zur Verfügung zu stellen, zumindest hab ich das schon öfters beobachtet :D

Aramis hat geschrieben:Du kannst testweise mal ein paar der oeffentlich verfuegbaren Alternativ-Allokatoren/Heaps ausprobieren und gucken ob das den Speicherverbrauch merklich reduziert - die optimieren insbesondere kleine Allokationen, denn auch Kleinvieh macht bekanntlich Mist.

Einen Versuch ist das sicherlich wert, aber zu viel wuerde ich mir davon nicht versprechen. Vielleicht erinnerst du dich noch, dass wir bei Assimp mal vermutet hatten, dass unsere vielen Mikro-Allokationen fuer gewaltig Extra-Overhead und Fragmentierung sorgen koennten, aber letztlich wurde es nicht wesentlich besser als wir testweise einen alternativen Scratch-Heap mit Overhead ~0 ausprobiert haben.

Ich würde mir davon auch nichts versprechen – bei Windows’ Low Fragmentation Heap, der ab Vista standardmäßig aktiviert ist, kannst du von Verschnitt in einer Größenordnung von 6 % nach 400 mio Allokationen ausgehen (im Vergleich zu einem theoretischen Allocator mit null Verschnitt). Bringt einfach nichts.

Komprimier deine Datenstrukturen. Minimale Datentypen; #pragma pack(1); mehr rechnen statt laden. Speicherzugriffe sind kostbarer als Rechenleistung; und seit dem Core 2 gibt es keine Leistungseinbuße mehr für nicht ausgerichtete Datenzugriffe. Ist natürlich für Texturen schwierig; aber die machen ja auch nur die eine Hälfte deiner Daten aus.

Ansonsten vllt für den 32-Bit-Level-Editor niedrigere Texturqualität wählen und nur das Spiel mit voller Farbtiefe laufen lassen?

Krishty hat geschrieben:[...]und seit dem Core 2 gibt es keine Leistungseinbuße mehr für nicht ausgerichtete Datenzugriffe.

Huch? Hast du das gemessen oder steht das irgendwo? Das wär mir jetzt nämlich sehr sehr neu...

Schrompf hat geschrieben:Interessanter Hinweis, von dem Schalter wusste ich noch nichts. Das wär ja evtl. die Easy-Out-Lösung, die ich mir erhofft hatte :-)

[edit] Klappt! Du bist mein persönlicher Held!

Bis die 3 GB wieder voll sind.
Aber mit dem Problem bist du nicht der einzige: http://news.softpedia.com/news/Firefox- ... 0112.shtml

Vor allem hilft es auf 32bit Windows eben erst wieder nix...

Btw: ProcessExplorer kann dir die VRAM Usage von jedem Prozess anzeigen, seh ich grad ;)

Danke für die vielen Tipps. Eine 64Bit-Version des Programms wär natürlich die finale Lösung, aber wie gesagt: es gibt bisher 0 Spiele da draußen, die 64Bit voraussetzen. Ich möchte mit den Splitterwelten nicht das erste sein. Zumal ich damit laut Steam Hardware Survey noch knapp 40% der Zielgruppe verliere. Mag ich nicht.

Nun hat /LARGEADRESSAWARE zumindest auf meinem 64Bit-Windows prima funktioniert. Keine std::bad_alloc mehr, egal was ich tue. Bei meinem Leveldesigner mit 32Bit-Win7 allerdings kracht es immernoch genauso wie vorher - identischer Callstack im Log, gleiche Reproduktionsschritte. Ich werde bei Gelegenheit mal diesen System-Flag verfolgen, ob ich damit das unabwendbare Elend noch ein Weilchen herausschieben kann.

Texturkompression wird übrigens schon überall angewendet - die 800MB sind bereits DXT1/DXT5-komprimiert. Wir haben in letzter Zeit halt einfach ein paar produktive Grafiker gehabt. Ein ziemliches Luxusproblem, wenn man meine früheren Jammereien über Grafiker-Zuverlässigkeit bedenkt :-) Ich habe seit Ewigkeiten ein paar Optimierungen im Blick - Texturen zusammenfassen, ein paar sind noch unkomprimiert, ein paar kann ich Dank serienmäßiger Shader-Umfärbelogik durch bestehende Texturen ersetzen. Aber das bringt vielleicht 50MB... eine kurze Errungenschaft. Aber ich habe erstmal die Idee der reduzierten Texturauflösung weitergeleitet - es gibt da schon eine Umgebungsvariable in der Engine, wodurch nur die erste MipMap aller Texturen geladen wird. Mit der müsste wieder etwas Luft im Adressraum sein, wenn der Editor mal wieder die ganze Welt umgraben will.

Und dann bleibt da noch die Datenkompression. Da ist sicher eine Menge zu holen, weil wir uns bisher sehr auf unsere Streaming-Funktionalität verlassen haben. Leider ist das keine Mal-Eben-Schnell-Lösung, sondern längerfristige Arbeit, die ich aktuell eigentlich nicht für die Splitterwelten investieren kann. Na mal schaun, was sich so ergibt...

Schrompf hat geschrieben:Bei meinem Leveldesigner mit 32Bit-Win7 allerdings kracht es immernoch genauso wie vorher - identischer Callstack im Log, gleiche Reproduktionsschritte.

dot hat geschrieben:Aber: Durch dieses Flag bekommt man nicht automatisch mehr RAM! Das ist nur ein Hinweis ans OS, dass die Software den ganzen Adressraum nutzen kann.

;)

Ja, ich weiß. Danke, dot, ich habe mich da ungenau ausgedrückt. Ich muss mal nach dem OS-Schalter suchen, der im Thread genannt wurde, um auf dem 32Bit-System das bisschen jenseits der 2GB freizuschalten.

Die Frage ist: Wenn du nicht das erste Spiel sein willst das 64bit voraussetzt, willst du wirklich das erste Spiel sein das eine spezielle Bootoption voraussetzt? ;)

dot hat geschrieben:

Krishty hat geschrieben:[...]und seit dem Core 2 gibt es keine Leistungseinbuße mehr für nicht ausgerichtete Datenzugriffe.

Huch? Hast du das gemessen oder steht das irgendwo? Das wär mir jetzt nämlich sehr sehr neu...

Jetzt, wo du es sagst, scheint das tatsächlich nur für 16-Byte-Lese- und -Schreibzugriffe zu gelten:

http://ispass.org/ispass2010/tutorials/Compiling_for_Nehalem_Win_JR_DL.pdf hat geschrieben:Unaligned Load / Store Improvements

Micro-architectural Feature

• Cache line splits are MUCH less expensive in Nehalem
• Unaligned 16-byte loads/stores are as fast as aligned 16-byte loads/stores when there is no cache line split

Consequence in 11.0 Compiler (with /QxSSE4.2 only):

• Favor 16-byte unaligned loads (e.g. movups) over multi-instruction sequences designed to avoid potential cache line splits
  • May replace up to 7 instructions
  • Reduces register pressure
  • Don’t do if cache line split is certain
  • 2-3% overall performance benefit on SPEC fp (application-dependent)

Eingeführt wurde das wohl mit den 45 nm-Core 2s.

Erscheint eigentlich logisch: Die ganze Ausrichterei hat eh keiner richtig hingekriegt und sie kann richtig Cache Lines kosten; da lassen sich CPUs einfacher optimieren als Programme.

Schrompf hat geschrieben:Ich muss mal nach dem OS-Schalter suchen, der im Thread genannt wurde, um auf dem 32Bit-System das bisschen jenseits der 2GB freizuschalten.

Hä? Sind meine Beiträge irgendwie unsichtbar?

Sternmull hat geschrieben:Das dürfte auf einem 32bit-Windows mit Default-Konfiguration aber keinen Einfluss haben. Siehe hier:

Limit in on X86:

2 GB

Up to 3 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE and 4GT

Das "4GT" muss man erst explizit einschalten. Das sollte laut dieser Quelle so gehen:

To enable 4GT, use the BCDEdit /set command to set the increaseuserva boot entry option to a value between 2048 (2 GB) and 3072 (3 GB).

Abgesehen davon das sowieso keiner liest was ich schreibe: Es gibt ja immer noch einen Unterschied zwischen verwendetem Speicher (private bytes) und verwendetem Adressraum (virtual size). Im deutschen Taskmanager ist das ein bisschen seltsam übersetzt, aber man kann sich zusätzliche Spalten anzeigen lassen um beides zu sehen. Ich gehe mal davon aus das die "virtual size" an das 2GB Limit gestoßen ist (diese Information taucht defaultmäßig nicht im Taskmanger auf, lässt sich aber wie gesagt hinzufügen).

Nein, Dein Beitrag war nicht unsichtbar. Keine Sorge, das kam schon an. Ich muss mich trotzdem ein wenig dazu belesen, bevor ich einem fremden Computer so eine systemweite Änderung zumute.

joggel hat geschrieben:Wieso sollte das mit anderen Programmen in Konflikt kommen?

Naja das setzen des Flags bringt natürlich keine Probleme.
Aber das gesetzte Flag bringt Dir auch nichts, wie Du bereits bemerkt hast, ohne weitere Schritte durchzuführen. Und da können in der Folge auf 32 Bit Systemen Probleme auftreten. Steht hier auch schon unter anderem dot.
Wenn ich Treiber habe die mit den Zeigern nicht klarkommen wars das, dann ist Ende im Gelände.

Entweder ich will 32 Bit, dann sollte ich mich auch an das halten was ohne gebastel geht.
Oder ich will will mehr als 32 Bit --> also 64.

PAE gibts auch noch, hab zwei Kumpels die Admis sind und beide berichteten nur von Problemen. Ist sicher auch schon eine weile her, mag sich gändert haben. Aber Bastellösung bleibt halt immer Bastellösung.

Ansichtssache. Es geht hier nur um den Editor, und der kommt auch nur bei bestimmten Arbeitsschritten an die Speichergrenze heran. Dazu kommt, dass ich aktuell eigentlich andere Probleme habe, als 12 Jahre Legacy-Code auf 64Bit zu portieren. Also bevorzuge ich die "kurzgedachte" Lösung. Ein GB später stoßen wir ja wieder an, und inzwischen erscheint mir diese Datenmenge gar nicht mehr so unerreichbar. Die 64Bit-Portierung ist langfristig also unausweichlich.

odenter hat geschrieben:

joggel hat geschrieben:Wieso sollte das mit anderen Programmen in Konflikt kommen?

Naja das setzen des Flags bringt natürlich keine Probleme.
Aber das gesetzte Flag bringt Dir auch nichts, wie Du bereits bemerkt hast, ohne weitere Schritte durchzuführen.

Sry wenn ich da nochmal ganz unwissend Frage:
Welche Schritte meinst Du zB?

Also meine Erfahrung war folgende:
Das Programm lief auf allen 32-Bit-Systemen (okay, ob auf Win7-32-Bit kann ich nicht sagen).
Es sollte Daten verarbeiten, die recht groß waren. Auf WinXP-32 lief das ohne Probleme.
Auf einem Win7- (-64Bit, glaube ich)-System gab es ein crash. Ich konnte mir das nicht recht erklären, da eben genug Arbeitsspeicher vorhanden war. Dann schaltete ich eben dieses Flag ein, und siehe da: es lief nun auf allen Systemen!
Aber klar, trotzdem muss man sein Programm so schreiben das es nicht endlos RAM verbraucht.
Also, da es unter 32-Bit-Systemen laufen soll eben auch so entwerfen.
Ich hoffe du weißt was ich meine ^^.

Und da können in der Folge auf 32 Bit Systemen Probleme auftreten. Steht hier auch schon unter anderem dot.
Wenn ich Treiber habe die mit den Zeigern nicht klarkommen wars das, dann ist Ende im Gelände.

Das verstehe ich jetzt auch wieder nicht :( ! Was hat ein Treiber damit zu tun?

odenter hat geschrieben:Aber das gesetzte Flag bringt Dir auch nichts, wie Du bereits bemerkt hast, ohne weitere Schritte durchzuführen.

Eben doch. Auf 64bit Systemen bekommt ein 32bit Prozess mit diesem Flag die vollen 4GB. Es einzuschalten kostet nichts. Anwendungen wie z.B. Adobe Photoshop haben aber massiv davon profitiert...

odenter hat geschrieben:Und da können in der Folge auf 32 Bit Systemen Probleme auftreten. Steht hier auch schon unter anderem dot.

Probleme können nur auftreten, wenn der Code irgendwelche hässlichen Hacks, z.B. von wegen Bitflags in Pointer packen, abzieht, also Dinge tut, die man nicht tun sollte. Wenn man sowas machen muss, dann muss man das Flag natürlich ausschalten.

odenter hat geschrieben:Wenn ich Treiber habe die mit den Zeigern nicht klarkommen wars das, dann ist Ende im Gelände.

Könntest du das etwas genauer ausführen?

odenter hat geschrieben:Entweder ich will 32 Bit, dann sollte ich mich auch an das halten was ohne gebastel geht.
Oder ich will will mehr als 32 Bit --> also 64.

Was hat das denn mit gebastel zu tun? Das Flag ist nur ein Hinweis an das OS dass die exe den kompletten 32bit Adressraum nutzen kann. Das ist alles.

odenter hat geschrieben:PAE gibts auch noch, hab zwei Kumpels die Admis sind und beide berichteten nur von Problemen. Ist sicher auch schon eine weile her, mag sich gändert haben. Aber Bastellösung bleibt halt immer Bastellösung.

Oh? Was denn für Probleme? Und was ist denn daran nun wieder eine "Bastellösung"? Von PAE bekommt dein Prozess nie was zu Gesicht...