Bad Mood : Falcon030 'Doom'

[dml]

So worst-frame profiling tells me that those heavy duty Doom2 maps are occasionally spending a lot of time purging stuff from the cache to make space in RAM.

Code: Select all

Used cycles:
  21.58%  21.66%  30.31%      703440    706248    988216   D_CacheFlushPartial
  14.75%                      480916                       R_Column_TMip_2x1
   8.58%                      279572                       R_VPShaderStdDSP_2x1
   5.04%                      164460                       R_AddLine_loop
   4.33%                      141032                       R_BSPHyperPlane

Not seen that happen before - it is perhaps because I recently increased the size of the Doom memory arena and when summed with all the static overheads (3MB arena + 1MB binary + 0.6mb framebuffers + 2mb 'stuff') it is competing with BM's texture/sprite cache on the bigger, open maps.

This might be related to the slowdown I saw on some events (like shooting) on these maps, since all textures are pre-loaded and the cache might already be full from the start of the level.

There might be other problems though - like fragmentation or the block tag pool is too small. Will have to investigate.

[dml]

Did a quick test with the memory debugger bar enabled, and the cause is pretty obvious from that.

Huge amount of waste from the Doom arena, binary and static buffers. Partly a result of relaxing stuff to accommodate lots of large PWADs while doing compatibility testing, partly just long-term inefficiency which hasn't been dealt with yet.

load.png

All 14mb is busy and only about 5mb for textures

So that will be the next big job - joining the memory arenas, shrinking the bloated buffers and making a lot of static stuff short-lived. Have been putting that job off for a long time but it needs done.

[Eero Tamminen]

It takes ages to run, given that it's capturing profile info from both CPU and DSP, and it needs 2 runs to fully populate the disk cache and profile the game properly, so i will leave it running overnight. Will look in the morning to see what I find there.

First run, to populate cache, can be done without profiling. Great that you started using, and that it works fine!

[dml]

Great that you started using, and that it works fine!

In fact I have been using it for a while - it just had limited utility when used with PC-recorded demos. It was still helpful for measuring the effect of optimizations +/- so I was using it mainly for that.

Now with Falcon-recorded demos working, it's good for everything else that had been missing before

[dml]

Last night I went through some of the worst (memory-hogging) areas of the engine code, where most of the big 'ds.?' static buffers are defined, and removed many of them. I also fixed the memory allocator to store chunk headers in chunks, instead of a static pool. Texture conversion buffers were removed and made dynamic.

This has knocked about 1.5mb off the static profile of the game. There is still about 1.5mb of static waste left, related to WAD resource handling, hashtables, cache records. It will take time to fix all of that but doing so should solve HALF of the memory problems.

The other half will be joining Doom and BMEngine memory allocators. That won't be fun, because they use unrelated concepts. One thing at a time...

[Eero Tamminen]

I noticed this in your commit log:

Code: Select all

todo:
    still a lot of static buffer waste in textures.s, visible from mapfile. tricky
    to fix without a 2-pass scan of the WAD to count resources of different types
    before allocating space for records.

Maybe scanning things and saving the collected WAD-specific information to disk as separate file for next run could be part of the WAD caching utility / BM option?

[dml]

Maybe scanning things and saving the collected WAD-specific information to disk as separate file for next run could be part of the WAD caching utility / BM option?

The problem with some of these is the need for them never to be underestimated (or a crash), and the high cost of overestimating them (which it had been until now).

I have since figured out ways to deal with *most* of them. The fixes have been committed this evening.

The static footprint (bss, excluding code,data) has been reduced from 2.5mb to 740k. I'll work on the remainder next.

[dml]

Snap after optimizing memory a bit...

mem2.png

The bit on the far left (mainly .bss) has been shrunk significantly, and most of the stuff which has been made dynamic has got smaller by measuring requirements properly (either from the WAD or estimating worst case).

There is still a bit left to reduce, and then the Doom arena will need dealt with. :-z Would be nice to just make it disappear but that will not be easy...

[dml]

I have figured out a way (back of envelope only, so far) to absorb the Doom game code's Z_Zone memory arena into the BMEngine chunk allocator, using a thin wrapper and some changes to the BM side. It should be possible to implement all the funny stuff that Z_Zone does with a bit of effort.

This would free up nearly 3mb and might make it possible to play (or at least, load) e1m1 on a 4mb box.

[dml]

Tonight managed to implement Z_Zone in terms of the BMEngine chunk allocator and cache. This has freed up a ton of memory.

mem3.png

Unfortunately because the tagging/purging levels are different from the BMEngine cache - which until now kept all the tiny Doom AI/object allocations separate from graphics - fragmentation has got worse with everything mixed up together. The BMEngine allocator was also made to handle large resources quickly and recycle the least recently touched - which isn't a perfect fit for creating/destroying lots of small things for AI code. Will need to think about that a bit more to see if something can be done.

It still doesn't quite fit in 4MB so that will also need more work if it is ever going to happen.

[dml]

Ok so now I got it briefly running on 4mb, until the 2nd room of e1m1 then it blows up, failing to purge enough contiguous holes in the resource cache for some big texture or other.

[dml]

Another annoying thing - and I'm pretty sure another difference between LinuxDoom sources and Dos Doom - is the way sound samples are handled. It loads all of the samples in the WAD on startup, using the cache mode PU_STATIC, which means 'don't manage - just keep it loaded forever'.

For Ultimate Doom WAD, that's about half a meg of stuff. Converting that to manage the samples from disk (as with textures) on demand would make a big difference for 4mb machines - about 1/4 of the dynamic budget if not more. Unfortunately that's more unplanned work.

[dml]

Running (barely) on a 4mb machine...

mem5.png

About half of the budget is still executable/data, static buffers, display memory, and some TOS/GEM overhead.

Most of what is left is unmanaged game/level data, some of which is duplicated in a slightly different form by BMEngine. That leaves about 0.6mb for dynamic stuff like textures, which isn't enough. So it's constantly paging from disk to display the graphics.

OTOH it has come a long way from needing 14mb just to boot up

[Eero Tamminen]

Running (barely) on a 4mb machine...

About half of the budget is still executable/data, static buffers, display memory, and some TOS/GEM overhead.

Most of what is left is unmanaged game/level data, some of which is duplicated in a slightly different form by BMEngine. That leaves about 0.6mb for dynamic stuff like textures, which isn't enough. So it's constantly paging from disk to display the graphics.

OTOH it has come a long way from needing 14mb just to boot up

Long way indeed.

I guess you're already running it from the AUTO folder to save on TOS overhead?

You mentioned sounds taking a lot of memory, maybe there could be an option to play without sound? Game should then be also slightly faster.

As to memory taken by textures, would your earlier flat-shaded render mode help with this?

[dml]

I guess you're already running it from the AUTO folder to save on TOS overhead?

Actually no - it would help but it probably doesn't release an awful lot - less than 100k probably. I can still find ways to release much more than that from the code.

You mentioned sounds taking a lot of memory, maybe there could be an option to play without sound? Game should then be also slightly faster.

As to memory taken by textures, would your earlier flat-shaded render mode help with this?

Yes, these things would make it work easily. However there's still room to fix things. If I run completely into a brick wall then some cuts can be made to get it running on 4mb.

I'm not sure though, that many would bother to start up their Falcon to try a version of Doom with no textures or sounds So I'll keep looking for things to improve.

[ctirad]

Ok so now I got it briefly running on 4mb

Four milibits?

[dml]

Ok so now I got it briefly running on 4mb

Four milibits?

Well I thought 4Mb was too easy, and 4ub was probably a bit hard, so it seemed right to aim in the middle

[Eero Tamminen]

I'm not sure though, that many would bother to start up their Falcon to try a version of Doom with no textures or sounds So I'll keep looking for things to improve.

Well, depending on whether one has something connected to audio out, one could disable sound, and the flat shading is style thing too, not just memory optimization. Flat-shaded looks cleaner, so it would be nice option (f it wouldn't hide some things from the level).

I.e. they would be nice as run-time options regardless of whether BM fits well into 4MB.

[dml]

I'm not sure though, that many would bother to start up their Falcon to try a version of Doom with no textures or sounds So I'll keep looking for things to improve.

Well, depending on whether one has something connected to audio out, one could disable sound, and the flat shading is style thing too, not just memory optimization. Flat-shaded looks cleaner, so it would be nice option (f it wouldn't hide some things from the level).

I.e. they would be nice as run-time options regardless of whether BM fits well into 4MB.

I'll definitely add them as runtime options, via the .cfg file

I will *try* to avoid relying on them for 4Mb machines but they will be there as options anyway.

A few more notes:

Flat-shaded mode doesn't flat-shade sprites, and sprites are more expensive to load than walls or floors because they have transparency and many frames each...

The first episode of Doom was released for 4Mb PCs, but later episodes use a lot more ram. e.g. e3m3 uses 3x as much ram as e1m1, according to my memory profiler! So just getting e1m1 to fit in 4Mb doesn't mean all the episodes will be playable on 4MB...

[Eero Tamminen]

I think the goal could be limited to getting Doom1 shareware WAD working fine in 4MB (sorry, 4 millibits ).

One memory optimization could also be ripping out largest MiNTlib functionality (printf etc) from the binary and relying just on TOS functionality. And compiling non-performance related parts of sources with -Os. In total this would be just tens of KBs, so it belongs to "scraping the bottom of the barrel" memory optimization category.

[dml]

I think the goal could be limited to getting Doom1 shareware WAD working fine in 4MB (sorry, 4 millibits ).

One memory optimization could also be ripping out largest MiNTlib functionality (printf etc) from the binary and relying just on TOS functionality. And compiling non-performance related parts of sources with -Os. In total this would be just tens of KBs, so it belongs to "scraping the bottom of the barrel" memory optimization category.

Yes, the MiNTlib stripdown becomes more meaningful with 4Mb. I didn't complete it because it was insignificant for a 14Mb target. I'll look at it again before long.

The executable is quite big so if it saves 100k then it's worth some effort.

[Zamuel_a]

In my Falcon I have now replaced the NVRAM. Installed a new HD since the old one was broken and added a 14Mb card I got from "Lynxman", so I could now finally test DOOM I am impressed and look forward to the next release.

One question. What is it that takes so long time (several minutes) when starting a new level? Is it supposed to be like that or something strange with my setup?

[dml]

In my Falcon I have now replaced the NVRAM. Installed a new HD since the old one was broken and added a 14Mb card I got from "Lynxman", so I could now finally test DOOM I am impressed and look forward to the next release.

Cool

One question. What is it that takes so long time (several minutes) when starting a new level? Is it supposed to be like that or something strange with my setup?

There is a big section about this in the readme file (I recommend you read those text files - there are lots of configuration and performance notes). Some of this info is duplicated on the site.

The Falcon version doesn't run directly from the WAD - the graphics are in the wrong format because the engine is different. The first time it sees a new WAD resource, it converts the resource and stuffs it in a local BMC/ directory for next time, before drawing with it. The engine can then load it very quickly next time.

Conversion is... involved. It takes a long time. Mipmap filtering, colour reduction... etc. It is slow.

I will add an option to beta which converts the whole WAD in one go, using a commandline switch. This will also take ages, but it does at least happen only one time - when you expect it

There is already a disk icon added for disk activity, and another icon will be added for the conversion process (so it is clear that it hasn't stuck).

[Zamuel_a]

Aha ok. I understand. Could it be possible to convert the WAD file and save it in the new format or must it be done at runtime every time BM is started? Or maybe that was what you already explained.

[dml]

Aha ok. I understand. Could it be possible to convert the WAD file and save it in the new format or must it be done at runtime every time BM is started? Or maybe that was what you already explained.

Yes a new commandline switch will be added to let you convert the whole WAD at once, so it doesn't need to happen at runtime.

Note that it uses a file based cache, so even the current version will load quickly on the second time you visit that level, even if you turn the machine off in between. It's pretty annoying though on the first playthrough, in the alpha version. Especially with animated liquid textures, which causes a delay each time the animation updates!