Bad Mood : Falcon030 'Doom'

[Eero Tamminen]

These are the settings I have:

Ah, stupid me. I forgot that BM uses FPU, FPU being selectable in WinUAE CPU core, and it not being enabled by default for Falcon (as base Falcon doesn't have FPU).

After enabling FPU, all BM versions work fine also with WinUAE CPU.

PS. I noticed that map one gets with TAB, looks garbage.

As to the crash I mentioned, you can get it e.g. by typing "doom11.wad". Crash happens after BM outputs this:

Code: Select all

 BadMood - Falcon030 Doom engine v4.02.alpha
 Optimized for: <modified Falcon system> 
 Release: Thursday, 7st March 2013 

  + DSP visplane texturing & mipmaps
  + Accelerated visibility testing
  + Misc. improvements & bugfixes

  - Special shaders disabled (sky, lava)

(Note: "--conout 2" will output TOS console output to Hatari console which helps copy&pasting...)

[dml]

After enabling FPU, all BM versions work fine also with WinUAE CPU.

I thought this might be the case - but figured it was more efficient just to spam a screenshot, in case it was one of the other settings. And to make sure I was using the correct UI

The FPU stuff will come out at some point, although I recently had doubts about the order of muls/divs in the old FPS and profiler code, and converted it all to FPU as well, for precise measurements. I'll restore the FPS counter back to fixed point later but the profiler will probably remain as FPU code permanently - it's not an important part of the engine for a user.

PS. I noticed that map one gets with TAB, looks garbage.

I expect changing the WAD memory structures recently broke that temporarily. Will fix it later.

As to the crash I mentioned, you can get it e.g. by typing "doom11.wad". Crash happens after BM outputs this:
(Note: "--conout 2" will output TOS console output to Hatari console which helps copy&pasting...)

Thanks, that's useful.

[Eero Tamminen]

As to DSP, perspected_column() takes over half the DSP, but nearly 4/5 is host port waiting.
[...]

This makes sense - the perspected_column routine is the one with the heavy divides - generally hidden behind the wall column drawing on the CPU.

I forgot to attach callgraph after fixing the minor DSP side caller information issues in profiler, so I generated new one from the old bmsym1.ttp for which I have symbols. This time it's from doom2.wad (again, of running from start to exit room).

Profile data statistics look about the same:

Code: Select all

Time spent in profile = 27.35117s.

Calls:
- max = 573445, in read_real at 0x92c, on line 1771
- 1189200 in total
Executed instructions:
- max = 54959455, in perspected_column+51 at 0x3ce, on line 803
- 196932091 in total
Used cycles:
- max = 329756730, in perspected_column+51 at 0x3ce, on line 803
- 877561866 in total
...
Calls:
 48.22%    573445  read_real
  6.70%     79721  finish_column
  6.70%     79721  dummy_column
...
Executed instructions:
 30.93%  60919427  perspected_column
 24.85%  48945108  VPRenderPlaneDT_
  9.10%  17916941  command_base
...
Used cycles:
 39.06% 342762284  perspected_column
 16.92% 148469740  VPRenderPlaneDT_
 12.16% 106678356  command_base
...
Largest cycle differences (= code changes during profiling):
100.00%         2  NewScene

Of the 31% of instructions spent in perspected_column(), most are again host port waiting (28% of instructions are on line doing host port waiting).

Callgraph is attached.

[Eero Tamminen]

I forgot to mention that this is now also with WinUAE CPU core instead of the old UAE CPU core, like the earlier datas.

CPU data that matches the DSP data (started & ended at same time as DSP profile):

Code: Select all

$ hatari-profile.py -its -g --ignore-to framecounter,ikbd_handler,new_vbi,stabilizer_b bmsym.txt
...
Time spent in profile = 13.67558s.

Calls:
- max = 150332, in load_real_s_a5_d16_a2 at 0x25384, on line 1320
- 312443 in total
Executed instructions:
- max = 1458192, in render_wall_1x1+216 at 0x26922, on line 1908
- 56109559 in total
Used cycles:
- max = 8614760, in render_wall_1x1+202 at 0x26914, on line 1903
- 219390466 in total
Instruction cache misses:
- max = 16431, in end_ssector+24 at 0x24cba, on line 1029
- 2045790 in total

Calls:
 48.11%    150305  load_real_s_a5_d16_a2
  3.24%     10118  nodeincone
  2.95%      9215  segment_loop
  2.95%      9213  invisible
  2.55%      7976  next_node
  2.28%      7126  loop_line_scan
  1.96%      6115  end_segment
 ...
Executed instructions:
 69.59%  39045113  render_wall_1x1
 11.98%   6720902  render_flats_1x1
  3.42%   1917762  enable_pixel_spans
  2.86%   1606147  stack_visplane_area
  1.96%   1099541  add_wall_segment
...
Used cycles:
 55.29% 121296396  render_wall_1x1             (0x02684a,  7.56094s)
 16.96%  37213576  render_flats_1x1            (0x02618e,  2.31969s)
  6.63%  14550568  enable_pixel_spans          (0x0260e2,  0.90700s)
  4.09%   8981410  add_wall_segment            (0x0250e2,  0.55985s)
  3.49%   7652226  stack_visplane_area         (0x0257a2,  0.47700s)
  2.78%   6088212  segment_loop                (0x02472e,  0.37951s)
  2.31%   5071300  nodeincone                  (0x024d56,  0.31612s)
  1.41%   3091388  initialise_freetable        (0x025e72,  0.19270s)
  1.08%   2371444  load_real_s_a5_d16_a2       (0x025384,  0.14782s)

Instruction cache misses:
 25.46%    520777  add_wall_segment
 24.61%    503532  segment_loop
 10.61%    216982  render_wall_1x1
  2.95%     60274  build_ssector
  1.99%     40764  sector_wall

Callgraph with timings is attached.

[f030]

Try to get a NEMBENCH dump of your machine in 'clean' 16MHz mode and the 32MHz mode you're testing with - ideally in 320x240 truecolour mode. Would be interesting to see how this compares with other machines....

NEMBENCH 320x240tc 16mhz:

Code: Select all

NemBench v2.1 - precision CPU/FPU profiler.

Integer multiply (16bit)     -> 0.616 Mips (~100%)
Integer divide (16bit)       -> 0.363 Mips (~100%)
Linear (stalled) integer     -> 8.007 Mips (~100%)
Interleaved (piped) integer  -> 8.007 Mips (~100%)

Float multiply (64bit)       -> 0.238 MegaFlops (~89%)
Float divide (64bit)         -> 0.167 MegaFlops (~96%)
Linear (stalled) float       -> 0.393 MegaFlops (~73%)
Interleaved (piped) float    -> 0.392 MegaFlops (~73%)

16bit read (100% hit)        -> 7.898 MByte/sec (~100%)
16bit write (100% hit)       -> 3.943 MByte/sec (~65%)
32bit read (100% hit)        -> 15.760 MByte/sec (~100%)
32bit write (100% hit)       -> 4.344 MByte/sec (~65%)

Linear 32bit read (ST-Ram)   -> 3.497 MByte/sec (~65%)
Linear 32bit write (ST-Ram)  -> 4.201 MByte/sec (~65%)
Linear 32bit copy (ST-Ram)   -> 2.103 MByte/sec (~65%)

32mhz:

Code: Select all

NemBench v2.1 - precision CPU/FPU profiler.

Integer multiply (16bit)     -> 1.232 Mips (~201%)
Integer divide (16bit)       -> 0.728 Mips (~201%)
Linear (stalled) integer     -> 16.000 Mips (~200%)
Interleaved (piped) integer  -> 16.000 Mips (~200%)

Float multiply (64bit)       -> 0.236 MegaFlops (~89%)
Float divide (64bit)         -> 0.160 MegaFlops (~92%)
Linear (stalled) float       -> 0.393 MegaFlops (~73%)
Interleaved (piped) float    -> 0.393 MegaFlops (~73%)

16bit read (100% hit)        -> 15.810 MByte/sec (~201%)
16bit write (100% hit)       -> 9.124 MByte/sec (~151%)
32bit read (100% hit)        -> 31.595 MByte/sec (~201%)
32bit write (100% hit)       -> 18.248 MByte/sec (~273%)

Linear 32bit read (ST-Ram)   -> 3.814 MByte/sec (~71%)
Linear 32bit write (ST-Ram)  -> 4.203 MByte/sec (~65%)
Linear 32bit copy (ST-Ram)   -> 2.101 MByte/sec (~65%)

Linear 32bit read (FastRAM)  -> 17.906 MByte/sec (~336%)
Linear 32bit write (FastRAM) -> 17.593 MByte/sec (~272%)
Linear 32bit copy (FastRAM)  -> 5.349 MByte/sec (~165%)

40mhz MS32+nemesis:

Code: Select all

NemBench v2.1 - precision CPU/FPU profiler.

Integer multiply (16bit)     -> 1.537 Mips (~250%)
Integer divide (16bit)       -> 0.909 Mips (~251%)
Linear (stalled) integer     -> 19.980 Mips (~250%)
Interleaved (piped) integer  -> 19.980 Mips (~250%)

Float multiply (64bit)       -> 0.295 MegaFlops (~111%)
Float divide (64bit)         -> 0.200 MegaFlops (~115%)
Linear (stalled) float       -> 0.491 MegaFlops (~92%)
Interleaved (piped) float    -> 0.490 MegaFlops (~92%)

16bit read (100% hit)        -> 19.704 MByte/sec (~250%)
16bit write (100% hit)       -> 11.389 MByte/sec (~189%)
32bit read (100% hit)        -> 39.370 MByte/sec (~250%)
32bit write (100% hit)       -> 22.727 MByte/sec (~340%)

Linear 32bit read (ST-Ram)   -> 5.328 MByte/sec (~100%)
Linear 32bit write (ST-Ram)  -> 5.882 MByte/sec (~91%)
Linear 32bit copy (ST-Ram)   -> 2.946 MByte/sec (~91%)

Linear 32bit read (FastRAM)  -> 22.329 MByte/sec (~420%)
Linear 32bit write (FastRAM) -> 21.936 MByte/sec (~340%)
Linear 32bit copy (FastRAM)  -> 6.673 MByte/sec (~206%)

DSPBENCH:

Code: Select all

DSPBench v1.0 - precision DSP profiler.

DSP ( X:Int Y:Int P:Int )    -> 16.045 Mips (~100%)
DSP ( X:Ext Y:Ext P:Int )    -> 8.021 Mips (~100%)
DSP ( X:Ext Y:Ext P:Ext )    -> 5.347 Mips (~100%)

[f030]

Also, do you have anything else that tests the DSP? Particularly DSP/CPU exchanges... I think the CT60 comes with something like that (or R Czuba provided a test app of some sort for checking the SRAM).

dsp_test:

INTERNAL RAM : OK
D23-D16 (U45) : OK
D15-D8 (U48) : OK
D7-D0 (U53) : OK

MS32 at 40mhz works mostly well.
falcamp works great
dspmod works great (cache must be disabled)
BM works at 16/20mhz with fastram
aniplayer does not work at all

any other app to test ?

[dml]

MS32 at 40mhz works mostly well.
falcamp works great
dspmod works great (cache must be disabled)
BM works at 16/20mhz with fastram
aniplayer does not work at all

any other app to test ?

No, looks ok to me if that lot is working properly. Only thing I see in the NEMBENCH results for 32MHz is that STRam reads look quite quick relative to writes. Need to do the same test on a normal Falcon to see how different that is - this might be an issue for DSP texturing as it is because it relies on timings of bus reads versus DSP performance.

I can't really see anything else there that would cause a problem.

[dml]

I forgot to attach callgraph after fixing the minor DSP side caller information issues in profiler, so I generated new one from the old bmsym1.ttp for which I have symbols. This time it's from doom2.wad (again, of running from start to exit room).

Thanks. I've had a quick look and it's largely sensible. There are some missing connections in the graph between things - so it's a little odd in places, but it looks right for the most part.

[dml]

This is the fastest version yet, on stock Falcon030. SSector processing speeded up by 30%. Small but measurable effect on simple scenes, bigger effect on complex scenes.

I'm changing the way wall texturing works and it is currently a bit broken when walls face the viewer exactly - ignore that for now. Will eventually get fixed in subsequent builds.

Still tons to do regarding optimization but creeping towards the hard bit... this time from the top down.

[EDIT]

While I do most of these uploads in a hurry, from now on I'm going to try to increment the version number properly and use 'C' or 'F' letter postfix for 'modified Falcon/[C]ompatible' or 'stock [F]alcon030' builds. The former is toned down a bit for accelerators, the latter optimized for bare bones machines.

[EvilFranky]

Been fantastic to read so far Doug, I haven't got a clue what most of it means mind but interesting none the less!

[dml]

Been fantastic to read so far Doug, I haven't got a clue what most of it means mind but interesting none the less!

BTW if you tap the '8' key it should toggle wall prelighting on/off. It's a bit dark so you might want to gamma your monitor up a bit for that, until I do something about it. Try toggling it on/off in a few different places with complex wall arrangements and see if they become better defined...

[Eero Tamminen]

I've had a quick look and it's largely sensible. There are some missing connections in the graph between things - so it's a little odd in places, but it looks right for the most part.

I had a dumb bug in the callgraph generation (code didn't take into account that same address might do calls to several different addresses). Attached is hopefully fixed callgraph.

The other callgraph is one using new graph reduction options to remove leaf and intermediate nodes and not using more than one arrow between two nodes (--compact --no-leafs --no-intermediate --limit 1.0). If callgraph is a large one, those options can make it more readable.

PS. of the profile post-processor functionalities, good symbol handling and cost propagation were trickiest. As cost propagation can only do estimates based on call count proportions, I don't think it gives that much extra value and therefore I haven't uploaded graphs using it (some calculated values also seem a bit strange with that, maybe due to loops in the graph which I apparently don't handle right yet).

[Eero Tamminen]

I'm changing the way wall texturing works and it is currently a bit broken when walls face the viewer exactly - ignore that for now. Will eventually get fixed in subsequent builds.

I think I found that bug.

Btw. What you've thought to do about the sound side? Sounds make quite a bit of the Doom atmosphere and are in stereo so that one knows on which side monsters are.

[Xerus]

(Falcon- RGB/320x168)
BM 307 5.2117 FPS
BM 401 7.4418 FPS
BM 403 7.8048 FPS
...impressive code as usual with you

[EvilFranky]

Is my maths right? 66.7% performance increase

[dml]

Btw. What you've thought to do about the sound side? Sounds make quite a bit of the Doom atmosphere and are in stereo so that one knows on which side monsters are.

There's actually a sound mixer in there already (disabled) but I'll have to look and see if it's worth reviewing and upgrading.

It would be nice to have MIDI output too and I think that's also in there, but I have no way to test it really ATM.

Will probably only get around to that stuff after tying up with Doom game code.

[dml]

(Falcon- RGB/320x168)
BM 307 5.2117 FPS
BM 401 7.4418 FPS
BM 403 7.8048 FPS
...impressive code as usual with you

Still quite a bit of work left unfortunately - and it's probably better to get most of the way there before gluing on the game side of it.

[dml]

The other callgraph is one using new graph reduction options to remove leaf and intermediate nodes and not using more than one arrow between two nodes (--compact --no-leafs --no-intermediate --limit 1.0). If callgraph is a large one, those options can make it more readable.

The 'reduced' graph of the DSP module looks the most sane & familiar of all so far. I didn't see any obvious errors, and 'command_base' seems to call out to practically all the sub commands - looks right.

I can even see where the visibility test (on the left of the graph) forks into 6 of the octant eliminators and converges again either on a shortcut, or on the projection & occlusion tests. Nice

BTW I use GraphViz a lot for other things, it's very useful - although it can be painful to force it to produce graphs with the layout intended!

graph1.jpg

[Eero Tamminen]

It would be nice to have MIDI output too and I think that's also in there, but I have no way to test it really ATM.

If you have Linux, you can get MIDI output with Hatari to a software sound synthetizer. Instructions are here:
http://hg.tuxfamily.org/mercurialroot/h ... -linux.txt

[dml]

If you have Linux, you can get MIDI output with Hatari to a software sound synthetizer. Instructions are here:
http://hg.tuxfamily.org/mercurialroot/h ... -linux.txt

I could give that a try - does it work with MIDI output under Windows also? I already have some MIDI softsynth stuff configured there.

[Eero Tamminen]

If you have Linux, you can get MIDI output with Hatari to a software sound synthetizer. Instructions are here:
http://hg.tuxfamily.org/mercurialroot/h ... -linux.txt

I could give that a try - does it work with MIDI output under Windows also? I already have some MIDI softsynth stuff configured there.

Hatari's Atari device IO works only with files. I doubt Windows offers MIDI interfaces as special files like Unixes do... :-/

[dml]

The BM MIDI code seems to load MIDI files explicitly from disk, not from the WAD file so that needs to be looked at sometime. I think Doom used plain MIDI file data so it should be able to work.

Trying to figure out who authored the MIDI code for BadMood... he left no name in his code - only a reference to NIKLAS.MID. It's been too long to remember who did each of these bits now. Maybe somebody remembers more detail?

The existing sample mixer is by PeyloW, but the two components were contributed separately (the mixer also loads sample files explicitly from disk, another thing that needs to be dealt with).

[mikro]

Doug, you want to say that you've got a MIDI replayer for the MIDI musics included in WAD files? If so, that would be frakking awesome, as the only solution right now I know about is to use SDL_audio + SDL_mixer +timidity patch and it's horribly expensive.

[Eero Tamminen]

Doug, you want to say that you've got a MIDI replayer for the MIDI musics included in WAD files? If so, that would be frakking awesome, as the only solution right now I know about is to use SDL_audio + SDL_mixer +timidity patch and it's horribly expensive.

MIDI player isn't that complicated, MIDI format is old standard and Atari has MIDI support at OS level (Bconout(DEV_MIDI, )). I did a MIDI player in GFA basic 20 years ago (sources lost)...

If you really want MIDI music to be synthetized internally on Atari, you can use EPSS (was shareware). Letting user to use real MIDI instruments is much better though, internal synthesis doesn't (typically) let user tune the instruments and IMHO sounds really crappy compared to real (HW or SW) synths.

[dml]

Hi,

Doug, you want to say that you've got a MIDI replayer for the MIDI musics included in WAD files? If so, that would be frakking awesome, as the only solution right now I know about is to use SDL_audio + SDL_mixer +timidity patch and it's horribly expensive.

I think we have a few options for music in BadMood, which won't require SDL.

A contributor provided a small MIDI replay routine (in ASM) before v3.07 which (IIRC) outputs direct to the MIDI port. It's small and fast. I'm not sure how easy it is to adapt that to mixing samples for native replay but it may not matter.

I have my own version of a MIDI parser which is likely more complete (?) but is in C not ASM, ported from a PC project. - I used for some silly experiments on STE (rendering down tone permutations using a simple waveform, at 0% CPU replay - just a prebuilt DMA page chain). This could also be modified for native replay, although it would benefit from flattening the command sequence into a cache before replay to reduce the player cost as much as possible (I had already done this flatten step for the STE experiment but not particularly with performance in mind - it was more about simplifying the tone permutation step).


I saw all the SDL code when I was poking through PMDOOM, before I went for LinuxDoom - it seemed to use SDL for nearly everything 'platform specific' except the row/column pixel filling (which as far as I could tell were the 0x0-optimized bits) - the rest is practically the original Doom code except for the replacement fixed-point mul/div. There's probably a c2p in there too but I don't remember seeing it.

It was actually the SDL dependency (and problems getting that to work with the mint gcc chain) - not the optimizations - which caused me to back away and start looking at LinuxDoom as the reference code for the game.