transmeta crusoe: Illegal instruction in libGL.so

[cb88]

gcc4hybrid hrev43718 built myself not a nightly

OpenGL software rendering used to work on here now it doesn't

I have an invalid opcode exception in libGL.so when running GLTeapot

gdb says 0x00718c8e in one_time_init() from /boot/system/lib/libGL.so0

The Crusoe should support all of i586 instructions and should even work for alot of programs compiled for i686 unless they also have -O2 which can trip it up.

I would like to build haiku with the -Os flag instead of -O2 I assume I can set that in UserBuildConfig? That said I am not sure that kallisti5's mesa build script would pick up those flags or just ignore them.

I have a radeon rv100 so it can run a few little OpenGL apps so I'd like to have it working eventually even if it is weak sauce it does make some games playable instead of software rendering on Linux.

[umccullough]

You might include a syslog, or at the very least the output from the commandline "sysinfo" which shows the list of CPU features supported by your processor.

My guess is that some mmx/sse opcodes are being used when they shouldn't be. I'm not sure what the gcc command looked like for kallisti's compilation of libGL.so, but it might be accidentally targeting i686 (which would be bad for Haiku's i586 minimum target).

[cb88]

syslog just after running GLteapot

[cb88]

I have checked on Linux and using the swrastg_dri causes an Illegal Instruction.... when running glxgears I guess that perhaps llvm emits code it doesn't like. Glxinfo however does run with swrastg on linux.

So... swrast_dri and radeon_drr drivers work swrastg_dri does not.

[kallisti5]

09:34 < umccullough> kallisti5, so you can use -mtune=i586 or -mtune=pentium
09:35 < umccullough> hopefully the mmx/sse code is in ASM
09:36 < umccullough> or, just use -mtune=generic i guess
09:36 < umccullough> but that one is ambiguous IMO
09:36 < umccullough> sounds like it targets i686
09:38 < umccullough> or, you can -march=i586 -mtune=i686 which hopefully makes compatible code that tries to optimize for 686
09:39 < umccullough> on gcc2, i think it's a little muddier
09:42 <@DeadYak> umccullough: that's precisely what it does, on gcc2 that'd be -march=pentium -mcpu=pentiumpro
09:43  * kallisti5 takes notes
09:43 <@DeadYak> -march restricts the instruction set it's allowed to use, -mcpu/-mtune tries to fine tune for that particular model and up's 
                 pipelines within the constraints of -march

[kallisti5]

trying a build of mesa with the following options:

-O0 -m32 -march=i586 -mtune=i686 -mmmx -msse -msse2 -mstackrealign -mfpmath=sse

I'm not sure if this is actually going to work as it doesn't make much sense... however there is some code in mesa to do CPU instruction support checking.

Building without any sse support at all would have pretty large performance cuts for Pentium 3+ CPUs which is 99% of our users.

If this works for gcc4, I'll do the same general thing with the gcc2 mesa package.

[kallisti5]

I have a confirmed fix for mesa gcc4, verifying if it's an issue in gcc2

[kallisti5]

gcc4 i686+ mesa package issue fixed in hrev43765

I didn't see the issue in the gcc2 build, let us know if you see any issues in gcc4 images or gcc2 images.

[kallisti5]

a small note. This patch was pushed upstream to mesa in: ​http://cgit.freedesktop.org/mesa/mesa/commit/?id=cb3054c849d8485af53da6a61b31b5c4e4eeb95d

Patch removed from 3rdparty/mesa in hrev44242