Caanoo / WIZ Howto For Opengl-es 1.1 Lite On The Wiz

[Jan-Nik]

Yes, this one: http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,1,0,0,23,54

MD5: ab217998d5da3eef0e824ad0ef2de645 libopengles_lite.so

 

[spued]

I think any opengles lib from GPH that gives VFP errors was a very old version. Did you get the lib from the wiz archive?

Yes. I got from GP2Xwiz archive. Same as above.

Check sum:

ab217998d5da3eef0e824ad0ef2de645 libopengles_lite.so

 

[Aurelio]

Hi, i got the same VFP error. How can we compile using VFP?
Thanks

 

[Pickle]

Hi, i got the same VFP error. How can we compile using VFP?
Thanks

The VFP shouldnt be in there, the pollux doesnt support it. I thought it was removed at one point. The only way to use it is to open the library at runtime use dsym to get addresses to the functions you need. This is what the nanogl lib does.

 

[Aurelio]

Hi, i got the same VFP error. How can we compile using VFP?
Thanks

The VFP shouldnt be in there, the pollux doesnt support it. I thought it was removed at one point. The only way to use it is to open the library at runtime use dsym to get addresses to the functions you need. This is what the nanogl lib does.

Ehm...how?

 

[spued]

Refer to Picodrive. I got the same problem too.
CODE
/home/sunya/arm-openwiz-linux-gnu/bin/../lib/gcc/arm-openwiz-linux-gnu/4.2.4/../../../../arm-openwiz-linux-gnu/bin/ld: ERROR: ../../Pico/draw_asm.o uses VFP instructions, whereas PicoDrive.gpe does not
/home/sunya/arm-openwiz-linux-gnu/bin/../lib/gcc/arm-openwiz-linux-gnu/4.2.4/../../../../arm-openwiz-linux-gnu/bin/ld: failed to merge target specific data of file ../../Pico/draw_asm.o

I correct this by disable following in Makefile.

CODE
COPT = $(COPT_COMMON) -mcpu=arm926ej-s -mtune=arm926ej-s
ASOPT = -mcpu=arm926ej-s -mfloat-abi=soft #-mfpu=vfp
# -mcpu=arm920t -mfloat-abi=soft


Makefile was success. The picodrive runs OK. But it's not help for this VFP case.

I use Ubuntu 8.0.4 + toolchains from archive. What the Linux distribution you suggest to try?

 

[Aurelio]

-mcpu=arm926ej-s -mtune=arm926ej-s
ASOPT = -mcpu=arm926ej-s -mfloat-abi=soft #-mfpu=vfp
# -mcpu=arm920t -mfloat-abi=soft

Makefile was success. The picodrive runs OK. But it's not help for this VFP case.

I use Ubuntu 8.0.4 + toolchains from archive. What the Linux distribution you suggest to try?
Thanks, I will try this later.
I'm using ubuntu 9.04, a different distro won't make any difference for wiz compiling.
If you are not a linux expert use ubuntu, it is the better distro for a new linux user, else if you are a linux expert you can try slackware or gentoo.

 

[Pickle]

Refer to Picodrive. I got the same problem too.
Makefile was success. The picodrive runs OK. But it's not help for this VFP case.
I use Ubuntu 8.0.4 + toolchains from archive. What the Linux distribution you suggest to try?

Your solution would be valid if we had the opengles_lite.so source, the shared lib is complied with VFP not the application its being linked to.

 

[Aurelio]

Refer to Picodrive. I got the same problem too.
Makefile was success. The picodrive runs OK. But it's not help for this VFP case.
I use Ubuntu 8.0.4 + toolchains from archive. What the Linux distribution you suggest to try?

Your solution would be valid if we had the opengles_lite.so source, the shared lib is complied with VFP not the application its being linked to.

So I have to ask to GPH the source of their library? If yes, how can I do that?
Thanks

 

[Exophase]

Refer to Picodrive. I got the same problem too.
Makefile was success. The picodrive runs OK. But it's not help for this VFP case.
I use Ubuntu 8.0.4 + toolchains from archive. What the Linux distribution you suggest to try?

Your solution would be valid if we had the opengles_lite.so source, the shared lib is complied with VFP not the application its being linked to.

So I have to ask to GPH the source of their library? If yes, how can I do that?
Thanks

Huhu, good luck with that...

 

[Aurelio]

Refer to Picodrive. I got the same problem too.
Makefile was success. The picodrive runs OK. But it's not help for this VFP case.
I use Ubuntu 8.0.4 + toolchains from archive. What the Linux distribution you suggest to try?

Your solution would be valid if we had the opengles_lite.so source, the shared lib is complied with VFP not the application its being linked to.

So I have to ask to GPH the source of their library? If yes, how can I do that?
Thanks

Huhu, good luck with that...

Yeah I know, it's near impossible that they'll realease the source, but i think that this is the only way...

 

[Pickle]

Refer to Picodrive. I got the same problem too.
Makefile was success. The picodrive runs OK. But it's not help for this VFP case.
I use Ubuntu 8.0.4 + toolchains from archive. What the Linux distribution you suggest to try?

Your solution would be valid if we had the opengles_lite.so source, the shared lib is complied with VFP not the application its being linked to.

So I have to ask to GPH the source of their library? If yes, how can I do that?
Thanks

Huhu, good luck with that...

Yeah I know, it's near impossible that they'll realease the source, but i think that this is the only way...

And even they may not have the source, it may be developed by mes

 

[spued]

If we can not change the lib so we could change our tools.

I try to check the option of toolchains.

CODE
sunya@ns2:~/arm-openwiz-linux-gnu/bin$ ./arm-openwiz-linux-gnu-g++ -v
Using built-in specs.
Target: arm-openwiz-linux-gnu
Configured with: /opt/toolchains/openwiz/crosstool-ng-1.2.4/targets/src/gcc-4.2.4/configure --build=i686-pc-linux-gnu --target=arm-openwiz-linux-gnu --host=i686-pc-linux-gnu --prefix=/toolchain/arm-openwiz-linux-gnu --with-sysroot=/toolchain/arm-openwiz-linux-gnu/arm-openwiz-linux-gnu/sys-root --enable-languages=c,c++ --disable-multilib --with-arch=armv5te --with-cpu=arm926ej-s --with-tune=arm926ej-s --with-float=soft --enable-__cxa_atexit --with-local-prefix=/toolchain/arm-openwiz-linux-gnu/arm-openwiz-linux-gnu/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace
Thread model: posix
gcc version 4.2.4


From the options. I think, there are no VFP in compiler so the object that we compile will not have the VFP. I guess that at lease we should add the VFP support. I try google and found that for ARM architecture. It usually uses VFP.
Can someone built the toochains for me?

 

[Aurelio]

Pickle, can you post a demo showing a polygon using wizGLES and NanoGL?
Thanks

 

[spued]

I solve the VFP problem. I don't know it is the right way or not. But at least I can compile the GL surface in this thread.
From this thread ...
I build the toolchain with vfp option, build the libwizGLES then compile the code.
My code is do nothing. Just create the surface then flip buffer. I got the garbage screen flicker around. I need to reboot after run.
At least I got this in stdout.

CODE
VID_Init: Creating the window
EGL Init Completed
GL_VENDOR: MagicEyes
GL_RENDERER: VR3520F
GL_VERSION: OpenGL ES-CM 1.1
GL_EXTENSIONS: GL_OES_matrix_palette


So they look nice. I will try to plot something in next step.

 

[Exophase]

For the record, the CPU used in Wiz (ARM926EJ) does not have VFP. If you compile a program that has VFP or the older FPA instructions then they'll get trapped by the kernel, which will either emulate them or kill the program depending on how it's configured. If the kernel emulates it then the result will be much slower than if you had the compiler generate code to emulate it, because it involves syscall overhead.

Object files are tagged whether or not they use VFP for their functions because the calling convention between VFP and soft-fp is different. You can't link the two together. What you did is fine as a workaround but if you're relying on floating point code then you're going to be pay for it dearly. Of course, you probably shouldn't be relying on floating point code anyway.

 

[Pickle]

does not have VFP. If you compile a program that has VFP or the older FPA instructions then they'll get trapped by the kernel, which will either emulate them or kill the program depending on how it's configured. If the kernel emulates it then the result will be much slower than if you had the compiler generate code to emulate it, because it involves syscall overhead.

Object files are tagged whether or not they use VFP for their functions because the calling convention between VFP and soft-fp is different. You can't link the two together. What you did is fine as a workaround but if you're relying on floating point code then you're going to be pay for it dearly. Of course, you probably shouldn't be relying on floating point code anyway.

Ive pointed out to gph that the library has VFP in it and that it should be removed, hopefully they can get fixed and release something we can properly link to.

 

[Exophase]

Yeah, go GPH *thumbs down*

I wonder how much floats are used here. I don't really know the OpenGL ES implementation, but if you have to use floats to pass parameters then this is going to get bad really quickly because not only the floating point operations but the VFP registers themselves have to be emulated by the kernel. So all of the instructions for loading then accessing parameters trigger traps. It's not good.

 

[sbock]

Hey Pickle. I don't know if it's related, but I noticed that the libs provided in firmware 1.0.0 are different from those in the archive.
See my post here.

Regards,
Stephan

 

[Pickle]

Hey Pickle. I don't know if it's related, but I noticed that the libs provided in firmware 1.0.0 are different from those in the archive.
See my post here.

Regards,
Stephan

To be honest, Im so confused that I dont which ones are the latest. Theres no version labeling, no documentation, im tired of it. The other issue is the port.cpp, that has to match the library. The library has callbacks which the port.cpp provide. The may be why some libs work and some dont. Why these funtions couldnt be in the opengles lib is odd. My guess the lib is coming from a 3rd party.
Im trying to get some answers from gph, but its going to be tough.