Textures that eat memory - Win7 crashes.

[Thargoid]

I don't think Win7 (or Vista) use boot.ini any more?

[fronclynne]

I don't think Win7 (or Vista) use boot.ini any more?

Uh, is that closer to AUTOEXEC.BAT or CONFIG.SYS in syntax? I'm asking for a, uh, friend.

[Capt. Murphy]

They don't Thargoid. That warning applies to running 32 bit apps with that flag set under 32 bit windows, in which case the Boot.ini also to be edited to allow the app to use upto 3GB. If Boot.ini doesn't have this set the flag is ignored. In 64 bit Windows just having the flag set on it's own allows 32 bit apps to use up to 4GB. So in theory compiling Oolite with this set for windows builds should be safe for all users. See http://msdn.microsoft.com/en-us/library ... ory_limits

I haven't been successful in editing the makefile (I think it's actually GNUmakefile that would need the edit) to complile Oolite with this flag set. Having trawled around the documentation for gcc, ld etc which I don't really understand I tried adding this line to GNUmakefile.

ADDITIONAL_LDFLAGS = -Wl,--large-address-aware, which returned on compiling
gcc.exe: unrecognized option '-Wl,--large-address-aware'

This was pretty much uninformed guesswork so maybe a_c can help out with some more specific instructions....

However I have had some prior experience in modifying existing .exe files (perfectly innocent - it was a technique used to mod an abandonware game Hardwar for which the source code was long lost), so knew that the PE header can be modifed after compilation. The program I've used before is OllyDbg - but there's a lot of guesswork in getting the edit right, and it's not the easiest of programs to use.

But I also found an another program CFF explorer, http://www.ntcore.com/exsuite.php, which makes the process much easier.

It's pretty much a case of opening Oolite.exe with CFF explorer, navigating to NT headers, File header, clicking on Characteristics, Click on Meaning, the tick the checkbox 'App can handle >2GB address space', before saving the modifed .exe.

And the test results having done this are good. I went back to the original Liners.oxp, and PAG_Oldships, spawned all of the wildship stations, one of each of the PAG_Oldships, 20 'stations', 50 'pirates', 50 'traders', 50 'police' and then an emerald, an aurora, and finally a tigershark. No crashes.

The GPU was using a full 1.7GB of system memory, whilst Oolite itself was using 2.34GB of memory in total...happy times.

The screenshot below is the output of sysinternals process explorer monitoring the Oolite's usage of the GPU, alongside Win 7 resmon reporting Oolite's memory use as a whole.



And this screenshot is from Oolite itself (this was a different test session so slightly different memory use reported)



So I think the upshot is if we can work out how to set this flag at compile time for windows builds we should, and I think it would fix stability issues some 64bit windows users have suffered with a high OXP load, partucularly when that load includes models with big/multiple textures.

If not, or in the meantime I can post a little tutorial with screenshots to make the necessary edit with CFF Explorer.

[Capt. Murphy]

Update -I don't know what I did different Having corrected a typo and retried the compilation again with a modified GNUmakefile it does seem to work...need to test the exe now...

Edit - and the results are good - again got to full GPU memory usage and Oolite using 2.3GB of memory with no CTD.

I still think this also counts as a bug in the graphics driver. It's evidently not checking if a 32 bit app is LARGEADDRESSAWARE or not, when allocating memory for very large textures.

Another_commander - I think this thread should probably be moved to Testing and bug reports.

GNUmakefile upto the extra line...

Code: Select all

include $(GNUSTEP_MAKEFILES)/common.make
include config.make

vpath %.m src/SDL:src/Core:src/Core/Entities:src/Core/Materials:src/Core/Scripting:src/Core/OXPVerifier:src/Core/Debug
vpath %.h src/SDL:src/Core:src/Core/Entities:src/Core/Materials:src/Core/Scripting:src/Core/OXPVerifier:src/Core/Debug
vpath %.c src/SDL:src/Core:src/BSDCompat:src/Core/Debug
GNUSTEP_INSTALLATION_DIR         = $(GNUSTEP_USER_ROOT)
GNUSTEP_OBJ_DIR_BASENAME         := $(GNUSTEP_OBJ_DIR_NAME)
HOST_ARCH                        := $(shell echo $(GNUSTEP_HOST_CPU) | sed -e s/i.86/x86/ -e s/amd64/x86_64/ )
ifeq ($(GNUSTEP_HOST_OS),mingw32)
    JS_INCLUDE_DIR               = deps/Windows-x86-deps/JS32ECMAv5/include
    JS_LIB_DIR                   = deps/Windows-x86-deps/JS32ECMAv5/lib
    ifeq ($(debug),yes)
        JS_IMPORT_LIBRARY        = js32ECMAv5dbg
    else
        JS_IMPORT_LIBRARY        = js32ECMAv5
    endif
    ADDITIONAL_INCLUDE_DIRS      = -Ideps/Windows-x86-deps/include -I$(JS_INCLUDE_DIR) -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug -Isrc/Core/Tables
    ADDITIONAL_OBJC_LIBS         = -lglu32 -lopengl32 -lpng14.dll -lmingw32 -lSDLmain -lSDL -lSDL_mixer -lgnustep-base -l$(JS_IMPORT_LIBRARY) -lwinmm -mwindows
    ADDITIONAL_CFLAGS            = -DWIN32 -DNEED_STRLCPY `sdl-config --cflags`
# note the vpath stuff above isn't working for me, so adding src/SDL and src/Core explicitly
    ADDITIONAL_OBJCFLAGS         = -DLOADSAVEGUI -DWIN32 -DXP_WIN -Wno-import -std=gnu99 `sdl-config --cflags`
	ADDITIONAL_LDFLAGS		     = -Wl,--large-address-aware

[JensAyton]

And this screenshot is from Oolite itself (this was a different test session so slightly different memory use reported)

By the way, you can get better memory info from Oolite – including textures – using the console: console.writeMemoryStats().

[Thargoid]

Line 60475: 12:25:44.317 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x1469ace0>{"liners_aurora.dat", 18 vertices, 28 faces, radius: 3572.97 m normals: per-face}
Line 60475: 12:25:44.317 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x1469ace0>{"liners_aurora.dat", 18 vertices, 28 faces, radius: 3572.97 m normals: per-face}
Line 60476: 12:25:44.317 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x141d9298>{"liners_auroraEngineA.dat", 240 vertices, 414 faces, radius: 688.845 m normals: per-face}
Line 60476: 12:25:44.317 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x141d9298>{"liners_auroraEngineA.dat", 240 vertices, 414 faces, radius: 688.845 m normals: per-face}
Line 60477: 12:25:44.318 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x11a05940>{"liners_auroraEngineB.dat", 240 vertices, 414 faces, radius: 589.723 m normals: per-face}
Line 60477: 12:25:44.318 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x11a05940>{"liners_auroraEngineB.dat", 240 vertices, 414 faces, radius: 589.723 m normals: per-face}
Line 60478: 12:25:44.318 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x13e22638>{"liners_auroraEngineC.dat", 240 vertices, 414 faces, radius: 708.784 m normals: per-face}
Line 60478: 12:25:44.318 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x13e22638>{"liners_auroraEngineC.dat", 240 vertices, 414 faces, radius: 708.784 m normals: per-face}
Line 60479: 12:25:44.318 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x147ac380>{"liners_auroraEngineD.dat", 240 vertices, 414 faces, radius: 696.8 m normals: per-face}
Line 60479: 12:25:44.318 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x147ac380>{"liners_auroraEngineD.dat", 240 vertices, 414 faces, radius: 696.8 m normals: per-face}
Line 60480: 12:25:44.318 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x119705e8>{"liners_tigershark.dat", 125 vertices, 236 faces, radius: 1172.09 m normals: per-face}
Line 60480: 12:25:44.318 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x119705e8>{"liners_tigershark.dat", 125 vertices, 236 faces, radius: 1172.09 m normals: per-face}
Line 60487: 12:25:44.579 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x1389e880>{"liners_tigershark.dat", 125 vertices, 236 faces, radius: 1172.09 m normals: per-face}
Line 60487: 12:25:44.579 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x1389e880>{"liners_tigershark.dat", 125 vertices, 236 faces, radius: 1172.09 m normals: per-face}

I think these are due to the fact that the WildShips ships are using two textures (one for the ship and one for the plasma effect). If I edit out the plasma effect texture from the dat file then the error doesn't appear.

If I get time I'll generate a simple model with a double-texture and see if that also has the issue, but as the error only shows up on detailed logging and doesn't seem to affect the game itself, I don't think this is a priority.

[JensAyton]

12:25:44.317 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: OOMesh after drawing <OOMesh 0x1469ace0>{"liners_aurora.dat", 18 vertices, 28 faces, radius: 3572.97 m normals: per-face}

I missed this lot. Capt. Murphy, could you build with OO_CHECK_GL_HEAVY=yes and try to reproduce these? It should say something more specific.

[Capt. Murphy]

Thanks Ahruman.

Update on tests completed this morning.

On my old Win XP machine - 32bit windows, 1GB RAM (+ 1GB Swap), ATI radeon x700 with 256MB discrete memory.

1) Used standard build of current 1.76.1 maintenance and replicated heavy load tests - using original big textures. (spawned 1 of each wildships stations, 1 of each of PAG_Oldships, an emerald, an aurora and finally a tigershark. Result - Extensive swap file usage, very slow computer, Black Screen of Death on spawning tigershark (GPU failure requiring hard reset).

2) Used LARGEADDRESSAWARE build of current 1.76.1 maintenance and played normally for 45 mins - no problems so using this flag for compile should be fine for both 32 bit and 64 bit windows users.

On my Win 7 machine.

1) Not LARGEADDESSAWARE with OO_CHECK_GL_HEAVY.

Error relating to Wildships DUMA.

06:38:37.891 [mesh.load.cached]: Retrieved mesh "wildShips_duma.dat" from cache.
06:38:38.261 [texture.upload]: Uploaded texture 59 (512x512 pixels, Textures/wildShips_duma.png:0x0007/0/0)
06:38:38.264 [texture.upload]: Uploaded texture 60 (512x512 pixels, Textures/wildShips_enginePlasma.png:0x0067/0/0)
06:38:38.280 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: POST OOShaderUniform.m:458 (-[OOShaderUniform(OOPrivate) applySimple]) -- glUniform4fvARB(location, 1, value.constVector)
06:38:38.280 [rendering.opengl.stateDump]: OpenGL state dump:
06:38:38.280 [rendering.opengl.stateDump]: Material state:
06:38:38.280 [rendering.opengl.stateDump]: Ambient: white
06:38:38.280 [rendering.opengl.stateDump]: Diffuse: white
06:38:38.280 [rendering.opengl.stateDump]: Emission: black
06:38:38.280 [rendering.opengl.stateDump]: Specular: black
06:38:38.280 [rendering.opengl.stateDump]: Shininess: 10
06:38:38.280 [rendering.opengl.stateDump]: Colour material: disabled
06:38:38.280 [rendering.opengl.stateDump]: Current color: (1.04f, 1.03f, 0.98f, 1.00f)
06:38:38.280 [rendering.opengl.stateDump]: Shade model: GL_SMOOTH
06:38:38.280 [rendering.opengl.stateDump]: Blending: disabled
06:38:38.280 [rendering.opengl.stateDump]: Texture env mode: GL_MODULATE
06:38:38.280 [rendering.opengl.stateDump]: Active texture unit: GL_TEXTURE0
06:38:38.280 [rendering.opengl.stateDump]: Active client texture unit: GL_TEXTURE0
06:38:38.280 [rendering.opengl.stateDump]: Cull face mode: GL_BACK
06:38:38.280 [rendering.opengl.stateDump]: Front face direction: GL_CCW
06:38:38.280 [rendering.opengl.stateDump]: Lighting: enabled
06:38:38.280 [rendering.opengl.stateDump]: Light 0: disabled
06:38:38.280 [rendering.opengl.stateDump]: Light 1: ENABLED
06:38:38.280 [rendering.opengl.stateDump]: Ambient: black
06:38:38.280 [rendering.opengl.stateDump]: Diffuse: (0.85f, 0.85f, 0.85f, 1.00f)
06:38:38.280 [rendering.opengl.stateDump]: Specular: (0.70f, 0.70f, 0.70f, 1.00f)
06:38:38.280 [rendering.opengl.stateDump]: Light 2: disabled
06:38:38.280 [rendering.opengl.stateDump]: Light 3: disabled
06:38:38.280 [rendering.opengl.stateDump]: Light 4: disabled
06:38:38.280 [rendering.opengl.stateDump]: Light 5: disabled
06:38:38.280 [rendering.opengl.stateDump]: Light 6: disabled
06:38:38.280 [rendering.opengl.stateDump]: Light 7: disabled
06:38:38.280 [rendering.opengl.stateDump]: Fog: disabled
06:38:38.280 [rendering.opengl.stateDump]: Selected state flags:
06:38:38.280 [rendering.opengl.stateDump]: GL_VERTEX_ARRAY: ENABLED
06:38:38.280 [rendering.opengl.stateDump]: GL_NORMAL_ARRAY: ENABLED
06:38:38.280 [rendering.opengl.stateDump]: GL_TEXTURE_COORD_ARRAY: ENABLED
06:38:38.281 [rendering.opengl.stateDump]: GL_COLOR_ARRAY: disabled
06:38:38.281 [rendering.opengl.stateDump]: GL_EDGE_FLAG_ARRAY: disabled
06:38:38.281 [rendering.opengl.stateDump]: GL_TEXTURE_2D: ENABLED
06:38:38.281 [rendering.opengl.stateDump]: GL_DEPTH_TEST: ENABLED
06:38:38.281 [rendering.opengl.stateDump]: GL_DEPTH_WRITEMASK: ENABLED
06:38:38.281 [rendering.opengl.stateDump]: GL_DITHER: ENABLED
06:38:38.281 [rendering.opengl.stateDump]: GL_POINT_SMOOTH: ENABLED
06:38:38.281 [rendering.opengl.stateDump]: GL_LINE_SMOOTH: ENABLED
06:38:38.326 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: POST OOShaderUniform.m:458 (-[OOShaderUniform(OOPrivate) applySimple]) -- glUniform4fvARB(location, 1, value.constVector)
06:38:38.326 [rendering.opengl.stateDump]: OpenGL state dump:
06:38:38.326 [rendering.opengl.stateDump]: Material state:
06:38:38.326 [rendering.opengl.stateDump]: Ambient: white
06:38:38.326 [rendering.opengl.stateDump]: Diffuse: white
06:38:38.326 [rendering.opengl.stateDump]: Emission: black
06:38:38.326 [rendering.opengl.stateDump]: Specular: black
06:38:38.326 [rendering.opengl.stateDump]: Shininess: 10
06:38:38.326 [rendering.opengl.stateDump]: Colour material: disabled
06:38:38.326 [rendering.opengl.stateDump]: Current color: (1.04f, 1.03f, 0.98f, 1.00f)
06:38:38.326 [rendering.opengl.stateDump]: Shade model: GL_SMOOTH
06:38:38.326 [rendering.opengl.stateDump]: Blending: disabled
06:38:38.326 [rendering.opengl.stateDump]: Texture env mode: GL_MODULATE
06:38:38.326 [rendering.opengl.stateDump]: Active texture unit: GL_TEXTURE0
06:38:38.326 [rendering.opengl.stateDump]: Active client texture unit: GL_TEXTURE0
06:38:38.326 [rendering.opengl.stateDump]: Cull face mode: GL_BACK
06:38:38.326 [rendering.opengl.stateDump]: Front face direction: GL_CCW
06:38:38.326 [rendering.opengl.stateDump]: Lighting: enabled
06:38:38.326 [rendering.opengl.stateDump]: Light 0: disabled
06:38:38.326 [rendering.opengl.stateDump]: Light 1: ENABLED
06:38:38.326 [rendering.opengl.stateDump]: Ambient: black
06:38:38.326 [rendering.opengl.stateDump]: Diffuse: black
06:38:38.327 [rendering.opengl.stateDump]: Specular: black
06:38:38.327 [rendering.opengl.stateDump]: Light 2: disabled
06:38:38.327 [rendering.opengl.stateDump]: Light 3: disabled
06:38:38.327 [rendering.opengl.stateDump]: Light 4: disabled
06:38:38.327 [rendering.opengl.stateDump]: Light 5: disabled
06:38:38.327 [rendering.opengl.stateDump]: Light 6: disabled
06:38:38.327 [rendering.opengl.stateDump]: Light 7: disabled
06:38:38.327 [rendering.opengl.stateDump]: Fog: disabled
06:38:38.327 [rendering.opengl.stateDump]: Selected state flags:
06:38:38.327 [rendering.opengl.stateDump]: GL_VERTEX_ARRAY: ENABLED
06:38:38.327 [rendering.opengl.stateDump]: GL_NORMAL_ARRAY: ENABLED
06:38:38.327 [rendering.opengl.stateDump]: GL_TEXTURE_COORD_ARRAY: ENABLED
06:38:38.327 [rendering.opengl.stateDump]: GL_COLOR_ARRAY: disabled
06:38:38.327 [rendering.opengl.stateDump]: GL_EDGE_FLAG_ARRAY: disabled
06:38:38.327 [rendering.opengl.stateDump]: GL_TEXTURE_2D: ENABLED
06:38:38.327 [rendering.opengl.stateDump]: GL_DEPTH_TEST: ENABLED
06:38:38.327 [rendering.opengl.stateDump]: GL_DEPTH_WRITEMASK: ENABLED
06:38:38.327 [rendering.opengl.stateDump]: GL_DITHER: ENABLED
06:38:38.327 [rendering.opengl.stateDump]: GL_POINT_SMOOTH: ENABLED
06:38:38.327 [rendering.opengl.stateDump]: GL_LINE_SMOOTH: ENABLED

Not able to replicate the errors for the Aurora and Tigershark posted above (they only appeared once in all previous testing I did).

2) LARGEADDESSAWARE with OO_CHECK_GL_HEAVY.

Same results as 1) above with no crashes.

[JensAyton]

06:38:38.280 [rendering.opengl.error]: OpenGL error: "invalid operation" (0x502), context: POST OOShaderUniform.m:458 (-[OOShaderUniform(OOPrivate) applySimple]) -- glUniform4fvARB(location, 1, value.constVector)

Ah, yes. This is probably a case of a shader having the wrong variable type for a uniform. Oolite needs to get better at detecting this and reporting it or converting values appropriately. I’ll verify later.

[JensAyton]

In wildShips_enginePlasma.fragment, the line uniform vec3 uSeed; should be uniform vec4 uSeed;.

[Thargoid]

D'oh! Thanks - corrected in the current download version. With luck that should resolve things with this OXP for now (aside from the sub-ent glitch I posted to Berlios earlier, but that's a minor issue).

[Kaks]

Fixed that subent glitch!

It took me a while to figure out exactly what was happening, but got there in the end... subtle one that!

[Lestradae]

So ... does the 1.76.1 nightly build already include the 64bit flag set to yes so that the exe will use the 4GB instead of the 2, or is this Capt. Murphy's testversion only at the moment?

[another_commander]

So ... does the 1.76.1 nightly build already include the 64bit flag set to yes so that the exe will use the 4GB instead of the 2, or is this Capt. Murphy's testversion only at the moment?

There are no 1.76.1 nightly builds. Only latest trunk (future v1.77) is built on a nightly basis.

[Lestradae]

So ... does the 1.76.1 nightly build already include the 64bit flag set to yes so that the exe will use the 4GB instead of the 2, or is this Capt. Murphy's testversion only at the moment?

There are no 1.76.1 nightly builds. Only latest trunk (future v1.77) is built on a nightly basis.

Aha! And, might I enquire, as to my original question?