Quake.. Again, Softfloat ! Options

[iamasmith]

Hi,

Through a couple of threads I stumbled on the fact that it is actually possible to build binaries with soft fload using libfloat and gcc-2.95.

The only problem seemed to be that the Embedix/Qtopia dev stuff didn't contain libfloat.

Well actually that wasn't a problem because the Sharp/Cacko ROM on the 860 DOES.

After copying this lib over to my dev kit, taking the PDAXROM quake source, adding the -msoft-fload gcc flags and the -lfloat linker flags I can quite happily build a quake binary with softfloat for the Cacko ROM.

BTW: It's not a source dependency on PDAX either, I have previously compiled this source for Cacko with exception float but it was desperately slow.

However, what I find is that when I do try to run it I get a blank screen, no graphics (plenty of sound though) and quake bombs out with...

Error: D_SCAlloc: bad cache size 0

I tried updating from gcc-2.95.2 to gcc-2.95.3 and had exactly the same results.

BTW: I HAVE verified that the soft float mechanism does work using more simple floating point samples.

Anyone got any ideas ? I'm really keen to see how many FPS we can get out of Quake on Cacko using this method.

BTW: Haven't tried recompiling libSDL to soft-float yet, I guess most of the maths is in the quake engine.

- Andy

[stupkid]

Once you solve the video problem you might want to try using the gcc options:

-03 -march=armv4 -mtune=strongarm

To optimize the binary for strongarm processors. GCC 2.95.3 doesn't optimize for xscale unfortunately.

Sounds like a cool project!

[cmisip]

I have been researching this as well. Won't you have to recompile all the libraries that quake uses using a toolchain that has softfloat enabled? Then if you wish to run it in an environment where the dynamic libs are not compiled with softfloat (like sharp rom), then the quake binary must have the recompiled libs statically linked? I think quake uses zlib and sdl and sdl uses qtopia.

I am investigating the possibility of creating a binary for the sharp rom. Unless one is already available that I dont know about.

Seems to be an enormous task. I am currently trying to create the toolchain.

[iamasmith]

I have been researching this as well. Won't you have to recompile all the libraries that quake uses using a toolchain that has softfloat enabled?

No, shouldn't need to do this.

The main program that seems to use libfloat is the Java PersonalProfile which is why libfloat is in the SL-C860 Sharp and Cacko ROMs.

Math will be self contained within the user application so you should be able to exploit soft FP functions in your application with library sets that use exception floating point and vica-versa.

Since my original post I have rebuild zports libSDL with -msoft-float and it runs all my other SDL applications fine. + as I say I have built some FP test stuff as well and that all seems to work well.

Now obviously there is something else going on with Quake and it is indeed a symptom caused by the compilation but it all seems to be related to SDL initialisation at the moment.... I can feel a remote gdb session coming on.

- Andy

[cybersphinx]

Another thing you might do is to compile the C stuff with gcc 3 to get better optimizations. This should work because IIRC the C ABI hasn't changed between versions, only the C++ ABI.

[iamasmith]

This should work because IIRC the C ABI hasn't changed between versions, only the C++ ABI.

That sounds sensible, thanks I might give that a go. I can't change libfloat though so I'm just hoping that libfloat ABI is compatible using -msoft-float on GCC 3.....

[iamasmith]

Hmm, I'll build a newer GCC toolchain later.

I tried patching in the PDAXROM 3.2 gcc and ld and hacking a specs file into shape but even with the --no-warn-mismatch it still doesn't link the objects

My next step is to trace the 2.95.2 build.

[iamasmith]

It was zlib that was killing it. zlib links statically and it was compiled for FP exception not softfloat.

It's way too slow still with libfloat.

The search continues...

[cwaig]

Have you looked at the fixed point modifications that were made to the Quake engine for PocketQuake? That'd be a big win.....

It's possible that using the PocketQuake codebase as a startpoint is a better idea than using the standard Linux versions if you're looking for decent performance on a PDA......

[iamasmith]

I might look into the fixed point stuff but I have a feeling the PDAXROM sources (which is what I'm using) is derived from this source. Hint, talks about turning your PocketPC into a Palm when you quit

[cmisip]

Are you sure we dont need to recompile the libraries? I managed to create a soft float toolchain with gcc-3.4.1-glibc-2.3.3. I think it is working although I have not really created any useful binaries with it. At the end of the build for quake1src, It complains about a mismatch in FPU between Quake and SDL (my SDL was compiled using the sharp toolchain).

/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/bin/arm-softfloat-linux-gnu-gcc -s -o quake console.o d_sky.o menu.o pr_edict.o r_misc.o snd_mix.o wad.o cd_sdl.o crc.o d_sprite.o model.o pr_exec.o r_part.o snd_sdl.o world.o chase.o cvar.o d_surf.o net_bsd.o r_aclip.o r_sky.o sv_main.o zone.o cl_demo.o d_edge.o d_vars.o net_dgrm.o r_alias.o r_sprite.o sv_move.o cl_input.o d_fill.o d_zpoint.o net_loop.o r_bsp.o r_surf.o sv_phys.o cl_main.o d_init.o draw.o net_main.o r_draw.o r_vars.o sv_user.o cl_parse.o d_modech.o host.o net_udp.o r_edge.o sbar.o sys_sdl.o cl_tent.o d_part.o host_cmd.o net_vcr.o r_efrag.o screen.o cmd.o d_polyse.o keys.o nonintel.o r_light.o snd_dma.o vid_sdl.o common.o d_scan.o mathlib.o pr_cmds.o r_main.o snd_mem.o view.o `/home/cmisip/develop/usr/local/bin/sdl-config --libs` -lpthread -lz
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /home/cmisip/develop/usr/local/lib/libSDLmain.a(SDL_Qtopia_main.o) uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /home/cmisip/develop/usr/local/lib/libSDLmain.a(SDL_Qtopia_main.o)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /home/cmisip/develop/usr/local/lib/libSDL.so uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /home/cmisip/develop/usr/local/lib/libSDL.so
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /opt/Qtopia/sharp/lib/libqpe.so uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /opt/Qtopia/sharp/lib/libqpe.so
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /opt/Qtopia/sharp/lib/libqte.so uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /opt/Qtopia/sharp/lib/libqte.so
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: /home/cmisip/develop/usr/local/lib/libz.so uses hardware FP, whereas quake uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file /home/cmisip/develop/usr/local/lib/libz.so
collect2: ld returned 1 exit status
make: *** [quake] Error 1


So I decided to recompile SDL and it complains:


/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/bin/arm-softfloat-linux-gnu-gcc -shared SDL.lo SDL_error.lo SDL_fatal.lo SDL_getenv.lo SDL_loadso.lo -Wl,--whole-archive main/.libs/libarch.al audio/.libs/libaudio.al video/.libs/libvideo.al events/.libs/libevents.al joystick/.libs/libjoystick.al cdrom/.libs/libcdrom.al thread/.libs/libthread.al timer/.libs/libtimer.al endian/.libs/libendian.al file/.libs/libfile.al -Wl,--no-whole-archive -lm -lc -Wl,-soname -Wl,libSDL-1.2.so.0 -o .libs/libSDL-1.2.so.0.0.5
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_QWin.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_QWin.lo)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_sysmouse.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_sysmouse.lo)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_sysvideo.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_sysvideo.lo)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_syswm.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_syswm.lo)
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: ERROR: video/.libs/libvideo.al(SDL_sysevents.lo) uses hardware FP, whereas .libs/libSDL-1.2.so.0.0.5 uses software FP
/opt/crosstool/arm-softfloat-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/arm-softfloat-linux-gnu/3.4.1/../../../../arm-softfloat-linux-gnu/bin/ld: failed to merge target specific data of file video/.libs/libvideo.al(SDL_sysevents.lo)
collect2: ld returned 1 exit status
make[2]: *** [libSDL.la] Error 1
make[2]: Leaving directory `/home/cmisip/developfloat/SDL-1.2.5/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cmisip/developfloat/SDL-1.2.5/src'
make: *** [all-recursive] Error 1


If I remove the configure option that enables qtopia in SDL, it compiles cleanly.

I suspect that quake doesn't like SDL built using the sharp toochain (non soft float) and SDL(soft float) it doesn't like the qtopia libs (non soft float) which are compiled with hard FPU support.

Man, do I need to recompile the qtopia libs with soft-fpu?


Of course, I could be completely off track here.

[iamasmith]

cmisip,

Yep, been there too. Even using --no-warn-mismatch on ld doesn't get around that.

My best luck so far is just using the Embedix 2.95.2 toolchain, copying libfloat.so.1 off the Sharp ROM into the /opt/Qtopia/sharp/libs location, specifying -msoft-float on the gcc -o <mod> -s <source> lines and linking with -lfloat.

However, what I previously said about zlib screwing it up was false. I was tired and I had the wrong switches in my Makefile so I build an FPA rather than softfp build.

SO the problem remains... I CAN build quake with softfp but it crashes with error D_SCAlloc and displays no graphics (sound does seem to be running though).

It seems that the textures are not being read correctly and so when d_surf tries to create a cache it complains about a 0 size texture with a 0 size cache.

Tried to debug but current gdb is a crock. I think I need to build a newer version of that as stepping just DOESN'T seem to step all the assembler instructions when I'm debugging in source mode and seems to hop backwards and forwards in the session - hard to follow and not very useful. There are some patches out now which show the source lines as well when you use disassemble so I think my next step is to try that.

Actually regarding the libraries.. the FP intensive bits in quake aren't calling math.h stuff it's actually doing simple FP stuff... just a lot of it. Any application that makes a lot of use of math.h isn't going to benefit since the Z libraries are prebuilt with FPA rather then soft-float. I would NOT suggest recompiling these libraries since there may possibly be precision loss/change and that would introduce some compatibility issues. - but hey if you are a fan of Intel processors then I guess that's nothing new to you

- Andy

[iamasmith]

I can now confirm that 2.95.2 and 2.95.3 as cross-compilers produce the same duff quake executable when cross compiling from the desktop and 2.95.1 in dev-img-1.6 results in the same problem when compiling natively on the Z.

...goes off to build gdb-6.3.

[cmisip]

Well I am happy to report that I managed to compile a soft float enabled quake binary that runs under sharp rom. It is definitely much faster and very playable almost faster than prboom. Only, it runs outside of qtopia since I compiled my sdl without qtopia support (dont know yet how to recompile those qtopia libs). However it runs 320x240 so that up button makes it turn left, down button turns right, left is back and right is forward. Does anybody know how to influence screen rotation in fb mode with sdl?


The way to get this done:

1. create a soft float enabled toolchain.
2. recompile zlib and sdl without qtopia support to create static libs
3. compile quake with soft float linking with the static libs
4. transfer the binary to zaurus
5. open a terminal su to root
6. disable the sdl mouse
5 run quake


I can email the binary to anyone wanting to test.

[guylhem]

I'd be honnestly more interested in the toolchain :-) May I ask you a copy or the instructions, so I can see what's wrong with qtopia?

I'll send you a copy of a libsdl source where some little changes let you manually fix the keys and/or the screen rotation