OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
> Quake.. Again, Softfloat !
iamasmith
post Nov 24 2004, 12:30 PM
Post #1





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



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
Go to the top of the page
 
+Quote Post
stupkid
post Nov 24 2004, 12:51 PM
Post #2





Group: Members
Posts: 578
Joined: 2-January 04
From: Texas USA
Member No.: 1,324



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. sad.gif

Sounds like a cool project!
Go to the top of the page
 
+Quote Post
cmisip
post Nov 25 2004, 03:43 AM
Post #3





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



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.
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 25 2004, 04:49 AM
Post #4





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



QUOTE(cmisip @ Nov 25 2004, 11:43 AM)
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
Go to the top of the page
 
+Quote Post
cybersphinx
post Nov 25 2004, 05:43 AM
Post #5





Group: Members
Posts: 70
Joined: 24-May 04
From: Germany
Member No.: 3,406



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.
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 25 2004, 07:37 AM
Post #6





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



QUOTE(cybersphinx @ Nov 25 2004, 01:43 PM)
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.....
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 25 2004, 11:24 AM
Post #7





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



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 sad.gif

My next step is to trace the 2.95.2 build.
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 25 2004, 12:15 PM
Post #8





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



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...
Go to the top of the page
 
+Quote Post
cwaig
post Nov 25 2004, 12:42 PM
Post #9





Group: Members
Posts: 153
Joined: 5-January 04
Member No.: 1,081



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......
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 25 2004, 02:06 PM
Post #10





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



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 smile.gif
Go to the top of the page
 
+Quote Post
cmisip
post Nov 25 2004, 09:06 PM
Post #11





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



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.
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 26 2004, 07:09 AM
Post #12





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



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 smile.gif

- Andy
Go to the top of the page
 
+Quote Post
iamasmith
post Nov 26 2004, 09:41 AM
Post #13





Group: Members
Posts: 1,248
Joined: 6-July 04
Member No.: 3,928



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.
Go to the top of the page
 
+Quote Post
cmisip
post Nov 26 2004, 08:53 PM
Post #14





Group: Members
Posts: 256
Joined: 6-March 04
Member No.: 2,191



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.
Go to the top of the page
 
+Quote Post
guylhem
post Nov 27 2004, 04:29 AM
Post #15





Group: Members
Posts: 577
Joined: 17-March 04
Member No.: 2,365



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
Go to the top of the page
 
+Quote Post

3 Pages V   1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd November 2014 - 05:12 AM