[V21 Stable - Ground Combat] GL_OUT_OF_MEMORY on massive crash sites under Linux

[asaz989]

On my first Carrier crash site, once I get deep into the UFO (around when the bottom floor is cleared) sprites start to be omitted - sometimes characters, but more frequently weapons in the UI and inventory screens. For example, in the screenshot below, Col. Frank Raskow is holding a Plasma Rifle, and you can see the ammo indicator and burst fire selector, but the image isn't there:

Shortly after this, usually during an alien turn, the game hangs (I notice it when the music stops playing - usually that stays running even during heavy AI calculations) and must be kill -9ed. The console is full of the following message:

err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353err:d3d:wined3d_debug_callback 0x17a648: "GL_OUT_OF_MEMORY in glMapBufferARB(map failed)".err:d3d:wined3d_buffer_map >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glMapBufferRange @ buffer.c / 1038wine: Unhandled page fault on write access to 0x00000000 at address 0xf746d2e0 (thread 0009), starting debugger...fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: semi-stub!fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: semi-stub!fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: semi-stub!fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: semi-stub!fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: semi-stub!fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: semi-stub!Killed

I'm running on a Thinkpad T431s with integrated graphics (Ivybridge Mobile) but oodles of RAM - it can run some recent FPSes at low settings, so not that underpowered.

Since you need to be in the pretty late game to see this, I've attached the autosave from the beginning of the mission.

Autosave3.sav

Autosave3.sav

[Gauddlike]

Interesting that this seems to occur on the same ship that others have reported having extremely long enemy turn times.

Have you noticed slow down of enemy turns before the freeze?

[asaz989]

Not very - the whole time turns a bit longer than on smaller UFOs, of course, but not longer than a minute. I do notice that the issues start around the same time that the camera starts to move up and down the carrier floors for different aliens' turns (despite my not being able to see any of the contents of those floors).

However, I have disabled Caesan psionics; perhaps with the current LoS/range issues, those are taking more computatio

[asaz989]

On 1.05HF (no modifications), I'm starting to get this issue even earlier in the game (GL_OUT_OF_MEMORY warnings, stuff failing to be drawn), on light scout and scout missions. So far it tends to be props rather than UI elements (e.g. walls or railcars that aren't visible to me but that no one can see or shoot through). No crashes yet, but I'll keep an eye out as I progress to bigger missions.

My system is running Intel HD3000 integrated graphics, and lspci indicates that it has 256MB of memory allocated to the video card.

[asaz989]

Yup, getting these crashes again. (On v1.07 through Steam.)

[Chris]

I imagine this is because the tiles in the game end up filling up your graphics card entirely. I'd guess the tile atlases we introduced in V1 just made the problem worse and that's why you're crashing earlier.

I'm going to upload a non-atlas pack of tiles for people to use if they are having these sorts of issues, hopefully it'll help you too....although I'm not sure we can do anything about the Carrier missions in this case.

[KevinHann]

I'm going to upload a non-atlas pack of tiles for people to use if they are having these sorts of issues, hopefully it'll help you too....although I'm not sure we can do anything about the Carrier missions in this case.

Thank you!

Disabled movement animations during alien turns helped tremendously in 1.0 - but trying that option now crashes the game during alien turns. If Carrier moves are ~10 min I'd personally be willing to ride the bullet on the untargetable alien bug, but can't fight random crashes. Pointing this out in case it is a possible alternative for that situation.

[asaz989]

Thanks a lot!

So what's interesting in my case is that this is an integrated graphics card, and I'm fuzzy on how the video RAM works with those. IIUC they share main memory with the CPU, but I don't know if they get a fixed allocation, or if they can ask for as much memory as they like. Maybe I just need to find the knob to allocate more and things will be good.