Actual NDK support

[fuzun]

https://android.googlesource.com/platform/ndk/+/ndk-r12-release/docs/HardFloatAbi.md

We're removing support for the armeabi-v7a-hard ABI. Anyone targeting this ABI should target armeabi-v7a instead.

Why?

People often use it because they think it's required to get floating point instructions, which is incorrect.
Most of the cases where people do see a performance improvement here are likely bugs/missed optimizations in either the compiler or the user‘s code, and hiding those means they won’t get fixed.
It‘s full of bugs and fixing them and keeping them fixed isn’t worth the benefit, especially in a world where you can avoid the problem entirely by making your app 64-bit.

armeabi-v7a-hard is not a real ABI. No devices are built with this. Hard float code generation is already used in the armeabi-v7a ABI. The “hard float” variant only changes the function call ABI. That is, the floating point registers are used to pass floating point arguments rather than the integer registers.

This ABI should only be beneficial if the workload consists of many math function calls, the math function is cheap enough that the call itself is expensive, and it's not being inlined. The bug here is that the call is not being inlined.

There is a cost to keeping this functionality. The way this “ABI” works is by having an attribute((pcs("aapcs"))) on every function that is part of the Android ABI and has floating point parameters (anything that is in the system libraries or zygote). If we miss one (and we do, often), the function will not be called correctly.

I should note that the GCC docs explicitly state that linking -mfloat-abi=softfp and -mfloat-abi=hard is invalid: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

[fuzun]

I reopened this because there is no reason for supporting this.

armeabi-v7a-hard is not a real ABI. No devices are built with this. Hard float code generation is already used in the armeabi-v7a ABI. The “hard float” variant only changes the function call ABI. That is, the floating point registers are used to pass floating point arguments rather than the integer registers.

Even if it does not support (for now) compiling on newer NDKs, there is no sense to use this method according to Google.

[mittorn]

It is aapcs_vfp calling conversion. All mods now using this on armv7. Softfp engine cannot load mods with aapcs conversion. And it works faster than softfp. Xash3D now suports mods that built in 2015 BTW, new ndks desided to use clang instead of gcc. Porting mods to clang is hard procedure as it cannot get method pointers without classnames (e.g gcc allows use &DefaultTouch with -fpermissive, but clang does not allow it all, requring &CMyEntity::DefaultTouch. Dou you want to fix hundreds of such usages)? Impossibility to build with new ndk is really problem that we need to fix and it may be solved by using own libm_hard library. I've tried to do it with armv6 and it worked correctly.

[fuzun]

I do not know about aapcs conversion but if newer ndks only need "&CMyEntity::DefaultTouch", it would take time like hlsdk-xash3d but it will be better.

Also, theoretically, newer ndks must have more performance. I did not test anything yet but I think staying at old ndks is not a good thing. Whether or not it makes some compatibility issues. (Maybe make a legacy version of xash and continue with new ndks ?)

[a1batross]

Clang/LLVM can't into performance. xD

I am thought about switching to Crystax NDK, as they provise GCC6.

18 сент. 2016 г. 2:56 PM пользователь "fuzun" notifications@github.com написал:

I do not know about aapcs conversion but if newer ndks only need "&CMyEntity::DefaultTouch", it would take time like hlsdk-xash3d but it will be better.

Also, theoretically, newer ndks must have more performance. I did not test anything yet but I think staying at old ndks is not a good thing. Whether or not it makes some compatibility issues. (Maybe make a legacy version of xash and continue with new ndks ?)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FWGS/xash3d/issues/175#issuecomment-247843534, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEJgW8linaWcYaqaIXHAwYKyyCTycFwks5qrSb_gaJpZM4Juywz .

[fuzun]

Haha so this switch looks like another google bullshit. Why google hate native development so much...

I have looked Crystax NDK and it looks promising. Better give it a chance.

So, close issue?

[a1batross]

Actually, it's not bullshit. Clang/LLVM codebase is more simple, than GCC's.

2016-09-18 15:19 GMT+03:00 fuzun notifications@github.com:

Haha so this switch looks like another google bullshit. Why google hate native development so much...

I have looked Crystax NDK and it looks promising. Better give it a chance.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FWGS/xash3d/issues/175#issuecomment-247844462, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEJgY_ibHW-pUCQZ90PKHpwWMF1m1Wfks5qrSxBgaJpZM4Juywz .

[mittorn]

Changed title as dropping hardfp is not good idea. It is better to make it work with gcc's from last ndk (manually adding hardfp build) as fallback and switch main development to other ndk implementation

[nekonomicon]

Haha so this switch looks like another google bullshit. Why google hate native development so much...

It's better then gcc 4.x any way. https://www.phoronix.com/scan.php?page=article&item=gcc-61-clang39&num=1

[mittorn]

On x86 maybe, not on arm

[fuzun]

ndk 12b state:

The ndk-build command defaults to using Clang in r13. We will remove GCC in a subsequent release.

Can I use 12b or 12a(This allows hardfp) because they still support gcc according to statement?

Is there any particular reason why xash3d android uses 10e ?

[a1batross]

The NDK will neither be upgrading to 5.x, nor accept non-critical backports.

R11. No serious changes for GCC, so release builds uses 10e. Any developer can use it's own NDK, ofc. :) Switching to new NDK require deep testing.