Why does the sgx driver can't work with hard float distros ?

[asdfffdsa]

The 4.8.0.1 has hfp drivers for from es3 to es8. Dunno if the es3 drivers work though.


I can confirm that ES5 works fine.


As for archlinuxarm, I have binary repo here http://cloudef.eu/ar...nuxarm-pandora/ for pandora specific packages. So no compiling needed.


If you can confirm that es3.x userspace libraries work with the compiled kernel module, I can add package for it I guess.


However omapfb is no longer maintaned and the xorg driver doesn't compile against new Xorg ABI. So you can't use GLES with X applications with similar setup as in default OS. pvr xorg driver from the SGX sdk package works, but is really unstable and not really good.. There is omapdrm in the latest kernels that has KMS, etc.., but it's not in the 3.2.20 that notaz has.

Is omapdrm the successor to omapfb? And if so, do you think that it might be a better investment of my time to try getting the latest archarm kernel working with the open pandora (using notaz's kernel configs as a guide)?

 

[Cloudef]

omapdrm is still in experimental state. But if you get it to work on our omap then cool I guess.. I would love to play around with it as it has kms and what not. Just keep in mind that notaz's tree is more than just config. There are some pandora specific input hacks that are not mainline for example.

 

[Linux-SWAT]

Just to add things here about Slack hardfp:

http://boards.openpandora.org/index.php/topic/12647-hard-float-armv7-optimized-slackware/

I actually see a very little difference, and from reading things here and there, only some multimedia stuff will benefit from hfp. For example:

http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/

About mathematical calculations, i suppose it's wiser doing them on a more powerful machine.

 

[notaz]

Hardfp is misnamed and overrated, softfp (also misnamed) already does float calculation on FPU/VFP, it's only about how arguments are passed.

 

[ZXDunny]

The issues I have, and the reason that PandaBAS is faster is on the Raspberry PI than on the Pandora, is due to how the compiler works.

I've removed completely the need to pass floats to procedures and functions in my code. However, when the compiler encounters something like "float := float * float" it calls a procedure to perform the addition - which involves passing parameters via the soft-method. This is slower on the Pandora, even at 950MHz compared to the 700MHz Pi.

It's a touch depressing, but there's nothing I can do about that

D.

 

[ptitSeb]

The floating point Part of Pi processor is not the same as the one in the Pandora IIRC. The VFP on Pandora is "half pipelined", it's the VFP-Lite. Maybe it's just that that explain de performance difference, not the way float are passed (even if it should make a differnce, but not that big I think).

 

[notaz]

Yeah R-Pi's ARM11 has faster float in general than pandora's.

 

[TrashyMG]

Sure we're talking about float.. by pure mass and shape, I'd say the Pandora would sink faster than the Raspberry Pi.

Spoiler

I know the joke was bad.

 

[mcobit]

I actually don't.