What hardware are you running ToME 4 on?

[Final Master]

I'm very curious what it is actually dragging down. There have been a lot of people report different things in the past and as far as I've noticed there isn't really a pattern going.

[Lord Estraven]

It's memory. On Linux, if I disable my swap partition and try to run T4 b38, it triggers the OOM killer and dies. If I don't disable the swap partition, it hogs 3 GB (1 GB RAM + 2 GB swap) in about 30 seconds, bringing the system to a grinding halt. In that case the OOM killer doesn't even get a chance to do its thing.

(On Windows there's similar memory hogging, but it never crashes the system completely; things slow down but only the game hangs. I think Windows may be smarter about some issues of memory management - maybe it just refuses malloc() requests when out memory, like Solaris and *BSD? Whatever, it's a shame it has no package manager, otherwise I'd probably use it for everything.)

Anyway, some input from OSX users would be nice...

Also, as an interesting sidenote, Linux users might want to experiment with setting the sysctl value vm.overcommit_memory to 2, which supposedly prevents allocations of more than a certain percentage of memory [edit]but unfortunately doesn't prevent your system from crashing when something eats up all your swap space.[/edit]

[bricks]

Anyway, some input from OSX users would be nice...

b38 hasn't been released for OSX, and I'll be damned if I can ever figure out how to compile something. In past versions, performance is generally fine, a little lag from particles, definitely some slowdown on certain menus. It's somewhat memory heavy but I've never known it to crash from a lack of memory.

[lukep]

Anyway, some input from OSX users would be nice...

b38 hasn't been released for OSX, and I'll be damned if I can ever figure out how to compile something. In past versions, performance is generally fine, a little lag from particles, definitely some slowdown on certain menus. It's somewhat memory heavy but I've never known it to crash from a lack of memory.

Seconded, mostly. I play on a macbook, and have never had system problems with ToME. I haven't noticed slowdowns in menus. I have turned off some effects (day/night, weather, smooth fog of war) for non-performance-related reasons.

[Lord Estraven]

Okay... Let's go to the next level:

Is there anyone here who is playing T4, without any serious issues, on a computer with an Intel 9xx video controller?

(I now know there's at least one other complaint here about system crashes with T4 and an Intel 945 video controller, so my suspicion that this is a hardware problem is growing stronger. Personally I suspect there's some kind of effect that ToME asks for, which the GPU claims to be able to handle but actually can't - resulting in memory leaks and BSODs.)

[edge2054]

Not conclusive evidence but my wife and I just bought a new AMD 64 bit computer and ToME runs fine on it.

[Lord Estraven]

My intelligence may be out of date, but if it's AMD64 I doubt it has an Intel shared-memory graphics chipset.

[edge2054]

haha.. no it does not.

Was kinda my point though, I know it didn't answer the question you're asking but it's more evidence that it's not the operating system and has more to do with what chipset people are using.

I was nervous honestly, I've heard of a lot of people having issues with 64 bit windows OSes but it ran fine for me (thankfully).

[Lord Estraven]

Hmm. Possibly this bug is getting triggered somehow?

https://wiki.ubuntu.com/X/Testing/GEMLeak

That would certainly explain things. Maybe the Windows bug is entirely different.

I think I'll see if running T4 with LIBGL_ALWAYS_INDIRECT=1 helps any. If not, maybe I'll see what's holding things up with unaccelerated rendering.*

* With no GPU acceleration the graphics are quite fast and responsive, but the game never actually finishes loading.

[Lord Estraven]

Hmm interesting... LIBGL_ALWAYS_INDIRECT=1 makes the game actually load and not crash the system, though it flickers so badly it's unplayable. Also, it triggers the OOM killer once I get past the first stats screen. Yay. But again, at least it doesn't crash *everything.*

Hey. what do you want to bet that T4 would work fine with the old non-KMS intel drivers?

[Lord Estraven]

Well, beta 38 still takes an incredible amount of time to load stuff into RAM, generate the level, etc. - more than ten times longer than with acceleration, which makes almost no sense to me given that this is a shared memory video chipset. And I can't find any obvious reason in the game's output; it's just taking much, much longer per image, Lua script, etc.

Edit: it also takes several minutes just to save the game. There's something wrong here.

[Grey]

I was nervous honestly, I've heard of a lot of people having issues with 64 bit windows OSes but it ran fine for me (thankfully).

Yaeh, I'd be pretty damned distraught if I couldn't run ToME and the T-Engine.

[Lord Estraven]

Okay, I've taken a look at the GDB output... It looks to me as though T4 is just allocating vast amounts of memory (more than 100 MB per second) when loading graphical tiles. No idea why; less than 100 MB of PNG tiles can't possible require 2+ GB of RAM decompressed, can they?

(And it looks, at least on cursory examination, like the leak is in T4 itself and not the Intel drivers; htop shows T4 having allocated over 2 GB of memory, though it's only using 40 MB of that.)

[Lord Estraven]

Okay then, new question: is anyone here playing ToME 4 without issues on a computer with less than 2 GB of RAM?

[Lord Estraven]

Bump?

Is there anything I can do, at least, to ascertain where T4 is leaking memory? I tried strace but it didn't look abnormal, just lots of read operations. (Unless they were reading to enormous buffers? Dunno.)

Anyway I still don't see why a 65 MB game should require 2+ GB of RAM...

Edit: noticed a pattern... This:

Code: Select all

Loading tile    talents/evasion.png

Seems to be where things really start bogging down. Thoughts?