Beta experimental hardfp (armhf) support for Super Zaxxon

[Alperoot]

Hmm. It throws out an error for me :

ERROR: ld.so: object 'libGLES_CM.so' from LD_PRELOAD cannot be preloaded (can not open shared object file): ignored.

And because it cannot find that thing, Minecraft searches for libGLESv2.so , and fails to find. Any ideas?

 

[levi]

Interesting. I wonder if we could get a hardfp build of DraStic to test out its NEON performance? Or something else that's been optimised heavily with NEON, but DraStic is the main candidate I can think of.

 

[notaz]

Hmm. It throws out an error for me :

ERROR: ld.so: object 'libGLES_CM.so' from LD_PRELOAD cannot be preloaded (can not open shared object file): ignored.

And because it cannot find that thing, Minecraft searches for libGLESv2.so , and fails to find. Any ideas?

CC unit maybe? If so, read the first post.

Interesting. I wonder if we could get a hardfp build of DraStic to test out its NEON performance? Or something else that's been optimised heavily with NEON, but DraStic is the main candidate I can think of.

Why would it have any effect? The whole thing is only about floating point function arguments, nothing else, and I'm almost sure DraStic never does that.

 

[Alperoot]

CC unit maybe? If so, read the first post.

No, I have a rebirth one.

 

[TrashyMG]

No, I have a rebirth one.

Did you re-install the 4.10 SGX driver after installing the armhf support?

 

[Alperoot]

Did you re-install the 4.10 SGX driver after installing the armhf support?

Yeah, I did. I will reinstall the driver again when I get back to the home.

 

[notaz]

Are you sure you did not forget "sudo opkg upgrade"?

 

[fusion_power]

I feel so 2. class more and more as a CC-model owner. I hope this will not happen with the Pyra...

 

[Exophase]

Anyone have any ideas of programs that could be measurably faster with this? I had zero expectations with PCSX-reARMed because AFAIK FP is only used embedded in some assembly functions for reciprocal calculation. DraStic has two performance critical functions that use FP but arguments are passed as arrays of floats so this won't make a difference.

I was thinking maybe glesn64, but that too receives float parameters as small arrays. It does, however, have a function, DotProduct, that returns float. But it's actually hardcoded to softfp convention in inline assembly. That is, it includes the transfer from floating point to integer register. So maybe someone should look at this because there's a good chance it won't work at all with hardfp.

 

[Linux-SWAT]

POV-Ray.

 

[ashcloud]

Anyone have any ideas of programs that could be measurably faster with this? I had zero expectations with PCSX-reARMed because AFAIK FP is only used embedded in some assembly functions for reciprocal calculation. DraStic has two performance critical functions that use FP but arguments are passed as arrays of floats so this won't make a difference.

I guess anything that uses neon excessively while also avoiding vfp instructions can gain a speedup. There is a fifo buffer between the arm core and the neon engine on the Cortex-A8. Any neon instruction the cpu encounters is put into this buffer. Then the cpu and neon engine work concurrently as long as the buffer is non-empty. However, if you move registers from the neon registers into the cpu core registers as required by the old ABI, the cpu is stalled until neon completes. The same happens for vfp instructions, as they share the same registers with neon and thus require neon to be finished. Thus, as soon as you mix up normal floating point code with neon, the same problem arises and there won't be much speedup.
(see http://stackoverflow.com/questions/12277484/arm-and-neon-can-work-in-parallel/12285295#12285295)
Anyway, gcc won't emit any neon instruction unless using the intrinsics, so a normal C program won't see much speedup.

I was thinking maybe glesn64, but that too receives float parameters as small arrays. It does, however, have a function, DotProduct, that returns float. But it's actually hardcoded to softfp convention in inline assembly. That is, it includes the transfer from floating point to integer register. So maybe someone should look at this because there's a good chance it won't work at all with hardfp.

Arrays won't help much, as they are passed as a pointer. You only get the values passed in registers if either a plain float or one of the intrinsic neon datatypes is used. Also DotProduct sounds like a function small enough for inlining, instead of calling it. The compiler will have much more trouble calling it than inlining it. Also when using neon intrinsics, gcc can optimize them. When using inline assembler, gcc can't do that.

 

[Exophase]

I guess anything that uses neon excessively while also avoiding vfp instructions can gain a speedup. There is a fifo buffer between the arm core and the neon engine on the Cortex-A8. Any neon instruction the cpu encounters is put into this buffer. Then the cpu and neon engine work concurrently as long as the buffer is non-empty. However, if you move registers from the neon registers into the cpu core registers as required by the old ABI, the cpu is stalled until neon completes. The same happens for vfp instructions, as they share the same registers with neon and thus require neon to be finished. Thus, as soon as you mix up normal floating point code with neon, the same problem arises and there won't be much speedup.
(see http://stackoverflow.com/questions/12277484/arm-and-neon-can-work-in-parallel/12285295#12285295)

This is irrelevant to softfp/hardfp if NEON intrinsic variables aren't passed as parameters to functions or returned from them. I actually had to confirm this with compiler output because I couldn't find a softfp document stating it.. I think it's kind of obscure because softfp was made with pre-NEON architectures in mind (then we got we stuck with it forever for compatibility purposes)

If you do use NEON intrinsics this way (something I haven't seen very much of) then it'll be really bad on softfp because it'll take up a whole 4 scalar registers for one NEON register.

Anyway, gcc won't emit any neon instruction unless using the intrinsics, so a normal C program won't see much speedup.

GCC will vectorize and emit NEON instructions w/o intrinsics if you allow it to. It won't emit NEON function linkage if you don't specify it explicitly. But this isn't just about NEON, it's also about VFP.

Although on Pandora it's best if you can avoid VFP altogether for anything performance sensitive. Sometimes this doesn't really make sense though, like if you need divisions.

Arrays won't help much, as they are passed as a pointer. You only get the values passed in registers if either a plain float or one of the intrinsic neon datatypes is used.

Understood. This is what I was trying to say in my post.

Also DotProduct sounds like a function small enough for inlining, instead of calling it. The compiler will have much more trouble calling it than inlining it. Also when using neon intrinsics, gcc can optimize them. When using inline assembler, gcc can't do that.

Fair enough - the function is marked as inline but there's a lot less the compiler can do when it's using inline assembly like it is. But I was just looking for things that might see a speedup as is w/hardfp. If we want to talk about optimizing glesn64 we could do a whole new thread on it, there's much more high level restructuring you'd want to do to make better use of NEON.

 

[Alperoot]

Are you sure you did not forget "sudo opkg upgrade"?

Yeah, I was missing that one. Thanks for your help!

 

[notaz]

I feel so 2. class more and more as a CC-model owner.

If any serious software that needs the 3D makes good use of this, it should be possible to do some sort of wrapper/converter for CC's SGX driver. Right now you're only missing some rather poor version of minecraft.

 

[fusion_power]

I have Minecraft on my PC so I actualy don't need a mobile version, not even the official one.
I don't blame any software devs here, the CC Pandora is old and slow and has not enough RAM for alot of stuff. You have pulled out alot from the Pandora, even the CC Pandora, this is still remarkable.

 

[Hồng Thất Công]

Oh wow! You are the man! Even 3D SGX driver work in hardfp? Can this be made to work if I'm running PYRA OS on my Pandora?

 

[TrashyMG]

Oh wow! You are the man! Even 3D SGX driver work in hardfp? Can this be made to work if I'm running PYRA OS on my Pandora?

Well if you have a Rebirth and 1Ghz it has a working Hard float driver, the CC units are in the lurch. I was experimenting with to get it to work on Pyra OS image, but I'm missing something not quite obvious in my attempt.

 

[Hồng Thất Công]

So you are saying the driver is already in the Pyra OS image?

 

[TrashyMG]

So you are saying the driver is already in the Pyra OS image?

No, I was trying to hack it in.

 

[Hồng Thất Công]

Hmm... Not sure I am imagining, but GBA Emu Alpha seems to run faster. Prior to this new armhf support, it was a slideshow when I enabled h2q. But now it seems to run OK...