Performance issues

[prelude]

I have bentrying to get the SVN trunk compiled on one of my macs, to no avail at this time but I also tried it on my (old) gentoo workstation. This did succeed but after starting a single player game, just the defaults, my system crumbles to it's knees begging for mercy.

Now, I know that: 0 a.d. is supposed to support low(ish) end machines and that this might not yet be the case in this stage of development.

How am I supposed to determine what is "normal" behaviour or what is to be expected if I wish to make some feedback?

I did run into the S3TC "problem" and tried the simple driconfig trick at first and later on followed this url to get support into my machine. Lo and behold, it worked! To my surprise however the game was in no way faster or more responsive. I'd say it is actually unusable.

So, let me post my specs and result and perhaps we can make a list with results:

* pentium 4 1.7ghz

* 512Mb ram

* ati radeon mobility 7500 (as mentioned, S3TC enabled)

* gentoo linux

* a lot more specs but they are irrelevant I guess -g-

* result, audio is fine, graphics look good, mouse is very slow as is the rest of the game response. 99% cpu ofcourse.

[Ykkrosh]

The Radeon 7500 is apparently quite old, so one thing to try is disabling some graphical features: create a file ~/.config/0ad/config/local.cfg saying

fancywater=false
shadows=false

which will (hopefully) switch those off and make it a bit faster. (I don't know if fancywater will be disabled automatically due to lack of fragment shaders, or if Mesa will emulate them in software very slowly. We ideally ought to have something to automatically disable the more expensive effects if they're going to be very slow (#475).)

Another thing to try is compiling the game with optimisations (the default is unoptimised to make debugging much easier): build with "CONFIG=Release make".

Hopefully that'll make things smoother. Another thing to try is pressing F11 in the game (maybe once or twice), so it'll show a breakdown of exactly what parts of the code are taking time - that should suggest whether it's the rendering or simulation processing or something else.

[prelude]

Ok, thanx for the quick reply!

I did notice a difference turning shadows and fancy water off. Although the mouse is definatly more responsive, it does feel sluggish still. I am now recompiling to see what difference that makes.

PS I am seriously impressed by this project

[prelude]

I have tried the recompile, which had it's problems but that is of no concern right now, and the game runs smoothly as long as I keep the shadows off Fancywater does not seem to hurt performance in any way.

I'm still trying to get the darn thing working on OSX though, and that, to be honest, is quite a b*tch. macports dies on me just about everywhere whilst "normal" (define normal eh?) applications in the past have been installed without too much effort.

Ah well, keep you posted...

-P

[Ykkrosh]

What are the problems with MacPorts? I have it running okay on 10.5 (since yesterday), and the game appears to compile successfully now with Xcode 3.1 and (I think) the default GCC 4.0 without any hassle, though the tests fail because it terminates whenever it throws an exception (and I have no idea why). So it probably ought to mostly work for you.

[prelude]

oh, a great number of things

Let's see, I tried it on 3 different systems so far. A G4 powermac, a quad G5 powermac and a macbook pro. The PPC's running 10.5 (ofcourse) and the intel thingy running 10.6

The G4 bails out (at the moment) on:

Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_libdevil/work/devil-1.7.8" && /usr/bin/make -j1 all " returned error 2
Command output: Making all in lib
/bin/sh ../libtool --tag=CC   --mode=compile /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I../include/IL  -I ./../src-IL/include -I ./../include -I/opt/local/include -faltivec -maltivec  -O2 -arch ppc -MT libIL_la-il_alloc.lo -MD -MP -MF .deps/libIL_la-il_alloc.Tpo -c -o libIL_la-il_alloc.lo `test -f './../src-IL/src/il_alloc.c' || echo './'`./../src-IL/src/il_alloc.c
libtool: compile:  /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I../include/IL -I ./../src-IL/include -I ./../include -I/opt/local/include -faltivec -maltivec -O2 -arch ppc -MT libIL_la-il_alloc.lo -MD -MP -MF .deps/libIL_la-il_alloc.Tpo -c ./../src-IL/src/il_alloc.c  -fno-common -DPIC -o .libs/libIL_la-il_alloc.o
./../src-IL/src/il_alloc.c:74: error: conflicting types for 'ivec_align_buffer'
./../include/IL/devil_internal_exports.h:101: error: previous declaration of 'ivec_align_buffer' was here
make[1]: *** [libIL_la-il_alloc.lo] Error 1
make: *** [all-recursive] Error 1

whilst installing libdevil. I have not googled over extensively yet, but so far I have not yet found a solution

The G5 craps itself while installing xorg-libX11, a dependency for libsdl with the following error:

checking if /bin/cpp requires -undef... dyld: Symbol not found: ___gmpn_bases
  Referenced from: /libexec/gcc/powerpc-apple-darwin9.8.0/4.3.2/cc1
  Expected in: /usr/local/lib/libmpfr.1.dylib

Pretty dissapointing as well, and on this machine I completely started over from scratch with macports.

The macbook pro has completed all installs (macport) but is nagging me about some 32 bit architecture error that I can't get my head around (yet)

==== Building test_gen ====
In file included from ../../../source/lib/sysdep/arch/ia32/ia32.cpp:29:
../../../source/lib/sysdep/arch/ia32/ia32.h:31:3: error: #error "including ia32.h without ARCH_IA32=1"
x86_x64.cpp
make[1]: *** [obj/lowlevel_Debug/ia32.o] Error 1
make[1]: *** Waiting for unfinished jobs....
==== Building AtlasUI ====
make: *** [lowlevel] Error 2
make: *** Waiting for unfinished jobs....

I need to dig in deeper in all occasions but any help is much appreciated

-P

[Ykkrosh]

The game doesn't work at all on PPC, and it'll take some effort to make it do so, even if the dependencies were working. Sounds like the other issue is possibly that it's a 64-bit build and we're not detecting the 64-bit environment correctly - if you look in build/premake/premake.lua and change it to force arch="amd64" then does it work better?

[prelude]

Hmm now that is dissapointing. Could you clarify the PPC issue for me? I am by no means up to par in programming (though I used to program a lot in the distant past, not in Cpp) so I will most likely not be able to fix it but it would be nice to see the game be portable in this way.

-P

PS fixing some architecture problems on the mbp (port install xyz +universal)

[Ykkrosh]

There's some architecture-specific C++ and assembly code (around here) which would need to be rewritten, and there's possibly a few bugs throughout the code related to big-endian vs little-endian which would need to be found and fixed, and the build system would need some tweaks to cope with the differences. I don't imagine it would be impossible, and if somebody did the work then I'd be happy to add it into SVN if it doesn't add much complexity to the rest of the code.

[Ykkrosh]

If you set arch="amd64" then apparently you'll get

../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:27: error: `64' is not a valid segment size; must be 16 or 32

(and possibly some wxDebugReport errors? if so, then remove the "--atlas" from update-workspaces.sh to disable the editor (which doesn't really work on OS X anyway)).

That sounds like NASM is trying to assemble in 32-bit mode instead of 64-bit, apparently. Does anyone know why, or how to fix it?

[prelude]

Sorry, the macbook is not mine so I do not always have access to it.

I tried the --atlas removal and the amd64 in arch but I still seem to get the same error:

In file included from ../../../source/lib/sysdep/arch/ia32/ia32.cpp:29:

../../../source/lib/sysdep/arch/ia32/ia32.h:31:3: error: #error "including ia32.h without ARCH_IA32=1"

make[1]: *** [obj/lowlevel_Debug/ia32.o] Error 1

make[1]: *** Waiting for unfinished jobs....

make: *** [lowlevel] Error 2

make: *** Waiting for unfinished jobs....

I did a make clean ofcourse. Is there something similar to be done for update-workspaces ?

-P

[Ykkrosh]

Hmm, if you apply a patch like

--- a/build/premake/premake.lua Fri Apr 02 19:27:04 2010 +0100
+++ b/build/premake/premake.lua Fri Apr 02 23:21:48 2010 +0100
@@ -20,6 +20,7 @@
		end
 else
		arch = os.getenv("HOSTTYPE")
+	   arch = "amd64"
		if arch == "x86_64" then
				arch = "amd64"
		end

and then run update-workspaces.sh again (which regenerates the Makefiles - maybe you missed that step?), then it really shouldn't give that error any more.

Since it'd be nice for premake.lua to detect this automatically, could you give the output of "echo $HOSTTYPE" and "gcc -dumpmachine"?

(This is the kind of situation where the Premake-based build system gets rather messy and makes me wish someone would rewrite it in a system that has better automatic configuration detection )

[prelude]

That helped me get further, but now I get the following error...

amd64_asm.asm
../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:27: error: `64' is not a valid segment size; must be 16 or 32
make[1]: *** [obj/lowlevel_Debug/amd64_asm.o] Error 1
make: *** [lowlevel] Error 2

echo $HOSTTYPE

x86_64

gcc -dumpmachine

i686-apple-darwin10

-P

[Ykkrosh]

echo $HOSTTYPE

x86_64

Hmm, the old code tried looking at HOSTTYPE but it would never work (since it's a bash variable, not an environment variable). I've changed it so if /bin/sh is bash (which I think is the case on OS X?) then it should pick it up properly now.

That helped me get further, but now I get the following error...

amd64_asm.asm
../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:27: error: `64' is not a valid segment size; must be 16 or 32

Yeah, that's the one where NASM is trying to assemble in 32-bit mode instead of 64-bit, or something like that, and I don't know where to look for a solution

[janwas]

Actually, it sounds like the version of NASM in play doesn't support x64 at all.

What does "nasm -v" say? The Windows EXE in svn\build\bin is 0.98.39. The list displayed by "nasm -hf" doesn't include elf64 and win64, which is a clear indication that it doesn't support x64. I am using the much more recent (but still old) 2.06, which is sufficient. Are you able to upgrade NASM?

[Ykkrosh]

Hmm, apparently macho64 is only supported since 2.07. It sounds like Xcode ships with a version of nasm, which is presumably too old, but MacPorts currently has 2.07 which should work.

[prelude]

Sorry for beeing such a n00b but I did install nasm 2.07

nasm -v

NASM version 2.07 compiled on Apr 21 2010

and now I get this error:

amd64_asm.asm

../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:27: error: macho output format does not support 64-bit code

../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:36: error: impossible combination of address sizes

../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:36: error: invalid effective address

(and a bit more)

Any suggestions?

tnx.

[Ykkrosh]

I've committed a change to tell nasm to use the macho64 output format - if you update and run update-workspaces.sh and rebuild, does it work better now?

[prelude]

Unfortunatly...

ia32.cpp

In file included from ../../../source/lib/sysdep/arch/ia32/ia32.cpp:29:

../../../source/lib/sysdep/arch/ia32/ia32.h:31:3: error: #error "including ia32.h without ARCH_IA32=1"

PMDConvert.cpp

make[1]: *** [obj/lowlevel_Debug/ia32.o] Error 1

make: *** [lowlevel] Error 2

make: *** Waiting for unfinished jobs....

No. I checked it out of svn just 30 minutes ago or so.

Thanks for the effort btw

-P

[Ykkrosh]

That's the 'arch = "amd64"' problem from before - why did it work in your previous post (until it reached the nasm problem), but not any more? Maybe the HOSTTYPE thing doesn't work and you still need to patch premake.lua as before, if you reverted that patch?

[prelude]

Apart from me deleting everything even remotely related to this effort from the system, I tried nearly everything. Checking the latest version out of CVS, patching premake.lua (as mentioned before) running make clean in the gcc directory and STILL I end up with that friggin'

ia32.cpp

In file included from ../../../source/lib/sysdep/arch/ia32/ia32.cpp:29:

../../../source/lib/sysdep/arch/ia32/ia32.h:31:3: error: #error "including ia32.h without ARCH_IA32=1"

make[1]: *** [obj/lowlevel_Debug/ia32.o] Error 1

make: *** [lowlevel] Error 2

I don't get it

Ah well, souping up to much of your time already I suppose.. I guess I'll give it a rest till..

-P

[Kimball]

ia32.cpp

In file included from ../../../source/lib/sysdep/arch/ia32/ia32.cpp:29:

../../../source/lib/sysdep/arch/ia32/ia32.h:31:3: error: #error "including ia32.h without ARCH_IA32=1"

make[1]: *** [obj/lowlevel_Debug/ia32.o] Error 1

make: *** [lowlevel] Error 2

This is actually the same error I'm getting building on my MacBook Pro. Does it have something to do with it being a MacBook and less to do with the OS?

(Complete terminal output posted here: http://pastebin.com/e6yberLd