Guild Wars 2

Das seit dem Release vermehrt OOM Fehler auftreten ist ja mittlerweile allgemein bekannt, das diese in der Regel nicht an der Hardware des Endnutzers liegen ist auch zu erkennen, da auch 64bit Betriebssysteme mit entsprechend Hardwareseitig vorhandenen Speicherausbau betroffen sind. Vielmehr tritt das Problem vermehrt bei leistungsfähiger Hardware auf, da durch die entsprechenden Einstellungen der Grafikoptionen, hohes Charakterlimit, qualitativ hochwertige Texturen etc. der RAM Verbrauch in die Höhe getrieben wird.
Bisher war ich davon ausgegangen das die Problematik im absoluten Speicherlimit (4Gibibyte) des 32bit Prozesses begründet liegt. Nach dem beobachten des Taskmanagers und der Speichernutzung durch GW2 habe ich jedoch eher das Gefühl das der Absturz bereits gegen eine 3Gibibyte Grenze (entspricht 3,22 Gigabyte) tendiert. Sehe ich das richtig, dass der Absturz hier im Speichermanagement durch GW2 selbst begründet liegt, da der 32bit Prozess dem Grunde nach bei der Nutzung eines 64bit Betriebssystem ja immer noch ein weiteres Gibibyte Adressraum zur Nutzung hergeben würde?
Da das Speichermanagement vermutlich tief in der Engine verankert sein dürfte, bei der es sich ja offenbar um eine stark modifizierte Engine GW1 Engine handelt die Frage, ist eine Fehlerbehebung überhaupt möglich? Zumindest stelle ich es mir als kaum möglich/ oder zumindest sehr kompliziert vor der Engine nachträglich noch beizubringen einen erweiterten Adressraum zu verwenden.
Neben der breiten Kompatibilität mit alten Betriebssystemen sicherlich auch ein Grund warum ihr GW2 nicht als 64bit Anwendung konzipiert habt? Es hieß zwar zum Release mal GW2 würde keinen Vorteil daraus ziehen wenn es als 64bit Anwendung konzipiert worden wäre, doch genau das wäre ja jetzt der Fall gewesen. Da bei einer 64bit fähigen Speicherverwaltung selbst eine deutlich höhere Speichernutzung nicht zu OOM Crashs führen würde.
Ich unterstelle jetzt also, das ihr den OOM Crashes maximal durch eine Optimierung des Speicherverbrauches entgegen wirken könnt, was aber nicht das Grundproblem behebt, da die Limitierung weiterhin vorhanden ist und es dann zwar seltener aber immer noch zu solchen Abstürzen kommen wird?
Für eine Stellungnahme insbesondere im Hinblick auf die Frage ob und ggf. in welchem Zeitraum mit einer Verbesserung der aktuellen Problematik zu rechnen ist wäre ich euch sehr dankbar. Ich empfände es als sehr schade wenn der Lösungsansatz lauten würde stellt doch mal bitte alle Optionen runter damit der Speicherverbrauch sinkt und die Engine nicht überfordert wird.

Ein 32-bit Prozess hat zwar einen Adressraum von 2^32 Bytes = 4 GB, aber von diesem Adressraum wird ihm von Windows nicht alles zur Verfügung gestellt. Unter einem 64-bit Windows sind 512 MB für das Betriebssystem reserviert. Dort liegen shared Memory, shared Programmcode wie DLLs und einige Verwaltungsdatenbereiche. Auch memory-mapped i/o Bereiche. Letztere dürften zusammen mit dem DLL Code den Großteil der 512 MB ausmachen.
Unter einem 32-bit Windows übrigens war der Betriebssystemanteil noch bei satten 2 GB (also halbe-halbe zwischen Prozess und Betriebssystem), und mit einigen Tweaks dort auf 1 GB zu reduzieren.

Dieser reservierte Bereich läßt sich nicht individuell pro Prozess verringern, weil er systemglobale Daten enthält (z.B. die DLLs), die in jedes 32-bit Program hineingemappt werden.

Deshalb hat GW2 auf 64-bit Systemen maximal 3.5 GB Speicherbelegung.

Ein Entwickler hat auf reddit bekannt, dass ein Teil der Speicherprobleme mit Speicherfragmentierung zu tun hat. Das bedeutet folgendes:

Im Laufe der Laufzeit von GW2 werden Speicherblöcke vom Betriebssystem angefordert und auch wieder zurückgegeben. GW2 sagt z.B. “gib mir 4 MB”. Dann sucht Windows einen 4 MB großen Block im Adressraum des Prozesses, der noch nicht in Verwendung ist, und stellt ihn dem Prozess zur Verfügung. Irgendwann braucht GW2 diese 4 MB nicht mehr und gibt sie dem Betriebssystem zurück. In der Zwischenzeit hat Windows aber hinter den 4 MB weiteren Speicher zur Verfügung gestellt. Es gibt also einen 4 MB großes “Loch” im Adressbereich. Dieser Adressbereich kann nur für eine neue Speicheranforderung verwendet werden, die 4 MB oder kleiner ist.

Es kann also sein, dass nach einiger Zeit der Speicher halb belegt und halb frei ist, und zwar bestehend aus lauter 4 MB großen Löchern. Will GW2 nun 16 MB am Stück anfordern, z.B. für eine besonders große Textur, dann geht das nicht, weil der ganze freie Adressbereich nur in kleinen Stückchen vorliegt, aber nicht zusammenhängend. Dann terminiert sich GW2 mit einem OOM, obwohl es sein könnte, dass wenn man die Löcher alle zusammenzählt, eigentlich noch genügend freier Platz vorhanden ist.

Wir als Spieler können allerdings an dieser Front nicht das geringste mitreden. Im Grunde genommen ist auch dieser Thread überflüssig, denn das sind technische Details in der Engine, über die ein Anwender keinerlei Kontrolle hat. Genausowenig wirst du einem Bauarbeiter auf der Autobahnbaustelle beim Vorbeifahren sagen können, dass er seine Schaufel anders halten möge, damit die Baustelle schneller fertig wird. Oder über das Wetter reden: ist ist zwar interessant über das Wetter zu reden, aber ändern kann das Wetter niemand auf der Welt.

Das meine ich auch gar nicht bitter oder vorwurfsvoll, sondern rein sachlich. Das sind Dinge, die zu 100% in die Engine-Programmierung gehören und nur dort zu diskutieren sind. Das sind Arenanet-interna. Ich gehe davon aus, dass Arenanet ein Reporting hat und die OOM Fehler “zählt”. Und je nachdem wie häufig er in der Gesamtspielerschaft vorkommt und wie teuer die Entwicklungszeit ist, um sich darum zu kümmern, wird das eine Sache sein, die dann entsprechend mehr oder auch weniger priorisiert wird. Darüber hast du als Spieler genausoviel Einfluss wie darüber, ob es morgen regnet oder die Sonne scheint.

Ob du für ein Event mehr Belohnung bekommen solltest, darüber ließe sich in der Spielerschaft durchaus diskutieren, aber was die Entwickler in der Engine rumzufummeln haben, das läßt sich in der Spielerschaft nicht diskutieren. Das steht ihr nicht zu.

Ein bisschen OT, aber ich wundere mich immer wieder wieviele diese Crashs haben müssen. Bekomme das bei Freunden sehr häufig mit.
Ich selber hatte wirklich noch nie einen, würde mich echt mal interessieren warum.

Danke Beldin, hilft vor allem beim Verstehen.

Silmar wir haben die gleichen Einstellungen, außer das ich Supersampling nutze und Lichtanpassung deaktiviert habe. Lade wie du auch erst immer alles runter. Und wie gesagt, nie einen Crash auch wenn gw2 manchmal sehr lange läuft.

Schon interessant, vielleicht sollte man einen Sammelthread eröffnen wo Hardware, Betriebssystem und Vorgehensweise beim Patchen reingeschrieben werden kann.

Scheint ja doch nicht die Regel sein.

Meine ursprünglichen Einstellungen (vor HoT) sind im Anhang, damit hatte ich aber soviele OOM Crashes das ich die Einstellungen “Charakterlimit” & “Charakterqualität” sowie HighRes Texturen & Reflektionen auf auf das niedrigste bzw. auf “Aus” gestellt.
Seit dem treten dann auch nur noch vereinzelt Abstürze auf.

Ich frage mich, wieso du bei 4k Auflösung auch noch Supersampling aktivierst. Bei der dpi Höhe kann man doch sowieso kein einzelnes Pixel mehr wahrnehmen. Da braucht man soweit ich das sehe weder Antialiasing noch Supersampling.

Bei dir würde ich vorschlagen machst du nativ und kannst wahrscheinlich das Charaktermodell-Limit und die Textursettings wieder höher stellen. Die Qualität, die man durch nicht-highres Texturen und so wenig angezeigte Charaktere um einen herum einbüßt, wiegt doch weitaus schwerer als die bei dieser Auflösung fast nicht zu erkennende Qualitätsänderung durch supersampling.

Bedenke: bei supersampling wird intern mit einer deutlich höheren Auflösung gerendert, als letztlich angezeigt wird. Bei 4k-Ausgabe bedeutet, dass Supersampling mehr als 4k intern rechnet, und das kostet ganz bestimmt nochmal mehr Speicher als 4k alleine. Gerade auch weil GW2 viel von den Texturen im Prozess-RAM verarbeitet und nicht im Grafik-RAM.

Positiver Nebeneffekt: höhere Framerate. Supersampling nimmt bei mir 15-20 fps.

@Silmar Alech
Jo ist auf jedenfall mal ne Idee. Werde Supersampling mal ausschalten. Die 4K sind allerdings in der Darstellung definitiv nicht “echt”. Es ist eine Downsampling Auflösung auf einem FHD Monitor, insofern hast du vermutlich recht, AA ist ja auch aus diesem Grund bei mir bereits ausgeschaltet.

Ein paar Gedanken eines Technik-Laien:
Ich konnte vor dem Addon auf Maximalen Einstellungen ohne Crash spielen. Die ersten Tage nach Release waren mit frustrierend häufigem Game Crash verbunden. Mittlerweile bin ich von jeder halben bis 2 Stunden pro Crash auf 2-4 Stunden pro Crash. Es geht also voran. Zusätzliches reduzieren der Grafik-Einstellungen bringt auf jeden Fall etwas mehr Zeit.
Aus meiner Sicht: Es gab eine stabile und funktionieren Engine vor Heart of Thorns. Einige Änderungen oder Ergänzungen die mit dem Addon kamen sind schlicht nicht ausgereift gewesen und führten zu kritischen Fehlern. Also muss ja für die Speicherproblematik bereits eine Lösung existiert haben. Demnach hielte ich es für irreführend davon auszugehen, das Problem läge an der Engine und deren Beziehung zum Speichermanagement von Windows.
Und wenn haufenweise 4 MB Löcher vorhanden wären, müsste man doch in der Lage sein größere Dateien in passenden Stücken zu teilen, mit einem Verweis an jedem Teil, wo die anderen dazu gehörigen Stücken liegen. Eben so wie wenn man z.B. eine Festplatte oder einen USB-Stick formatiert und gestückelte Bereiche entstehen, die die Daten bzw. Datenteile aufnehmen. Auch bei verschieden großen Löchern könnte man eine Datenkette bilden – so meine Theorie ^^

Kosten des Addons bisher: 30 FPS :O

Hui, das hätte ich ehrlich gesagt nicht gedacht, dass es tatsächlich jemals einen 64-bit Client für GW2 geben würde.

Es scheint so zu sein, dass man das gw2-64.exe in das Verzeichnis kopieren kann, in dem schon der alte Client liegt – die Archivdaten werden dann nicht nochmal runtergeladen.
Downloaden kann man den 64-bit Client über die Accountverwaltung.

But .. bad news .. got a crash in the character select screen .. after that already before
when i restart it. I guess it could have been TS3-Overlay .. will now try it without

• Crash <—*
  Exception: c0000005
  Memory at address ffffffff`ffffffff could not be read
  App: Gw2-64.exe
  Pid: 21680
  Cmdline: -autologin -maploadinfo
  BaseAddr: 00007FF7BD7A0000
  ProgramId: 101
  Build: 54869
  When: 2015-11-04T19:36:48Z 2015-11-04T20:36:48+01:00
  Uptime: 0 days 0:10:40
  Flags: 0

• System <—*
  Name: DESKTOP-402MECB
  IpAddr: 192.168.2.100
  Processors: 4 [GenuineIntel:6:10:7]
  OSVersion: Windows 6.2 (64 bit)

• System Memory <—*
  Physical: 3853MB/ 8175MB 47%
  Paged: 3868MB/ 9455MB 40%
  Virtual: 134215343MB/134217727MB 3%
  Load: 52%
  CommitTotal: 5586MB
  CommitLimit: 9455MB
  CommitPeak: 6419MB
  SystemCache: 4047MB
  HandleCount: 33768
  ProcessCount: 71
  ThreadCount: 1315

• Process Memory <—*
  Private: 2116MB
  WorkingSet: 1550MB
  PeakWorkingSet: 1550MB
  PageFaults: 1563426

Ja Overlays scheinen allgemein noch Probleme zu bereiten.

GemFX zickt bei mir auch noch mit der Erweiterung rum und sorgt für frameeinbrüche die ich im Core Game nie hatte, trotz in GemFX bereits heruntergschraubten Einstellungen.

Einen Abend lang damit gespielt, keinerlei Probleme. Nach kurzer Zeit habe ich vergessen, dass ich einen beta Client benutze. Nett.

Silmar Alech.4305:

Einen Abend lang damit gespielt, keinerlei Probleme. Nach kurzer Zeit habe ich vergessen, dass ich einen beta Client benutze. Nett.

Nee .. ich vergesse es nicht weil Overwolf einfach Mist ist gegen TS3Overlay :/

Aber sonst ..ja .. keine Probleme

ts3overlay? Ist das der alte Overlay, der mal als Plugin bei TS3 dabei war? Der läuft doch mit aktuellen Teamspeak Versionen gar nicht mehr und wird auch nicht mehr gepflegt. Bei mir hat er seinerzeit auch sehr zuverlässig alle paar Stunden zu Crashes geführt. Völlig inakzeptabel, was die Stabilität angeht, und deshalb unbenutzbar.

Silmar Alech.4305:

ts3overlay? Ist das der alte Overlay, der mal als Plugin bei TS3 dabei war? Der läuft doch mit aktuellen Teamspeak Versionen gar nicht mehr und wird auch nicht mehr gepflegt. Bei mir hat er seinerzeit auch sehr zuverlässig alle paar Stunden zu Crashes geführt. Völlig inakzeptabel, was die Stabilität angeht, und deshalb unbenutzbar.

Nö .. läuft bestens bei mir und auch diversen anderen Bekannten .. und ist vor allem
wesentlich unaufdringlicher wie Overwolf und es verhindert nicht das man auf
Buttons klicken kann die dahinter liegen.