Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FS#2997 - Recent change of fpu settings on mvebu #7847

Closed
openwrt-bot opened this issue Apr 12, 2020 · 5 comments
Closed

FS#2997 - Recent change of fpu settings on mvebu #7847

openwrt-bot opened this issue Apr 12, 2020 · 5 comments
Labels
flyspray

Comments

@openwrt-bot
Copy link

n30dg:

Referring to commit: [[https://github.com/openwrt/openwrt/commit/2d61f8821c7cf99354e904139226c132554ba180|2d61f8821c7cf99354e904139226c132554ba180]]

Recently the FPU-Settings for Marvell Armada 37x/38x/XP-devices where changed from vfp3 to vfp3-d16.

But this is at least suboptimal on all 38x based devices like the Linksys WRT3200ACM and the Turris Omnia.
This patch should only be applied for Armada-37x based Devices, as the Armada-38x has a full set of 32 vfp3-Registers.

See, page 73: [[https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf|Datasheet]]

Under some circumstances this can significant hit float performance and should therefore only be applied for older Armada SoC's.
@openwrt-bot
Copy link
Author

anomeome:

[[https://forum.openwrt.org/t/change-of-interest-to-some-mvebu-targets/58799|forum thread]], commit is really the unintended consequence of conversation in [[https://github.com//pull/2804|PR2804]], the road forward is probably implementing [[https://bugs.openwrt.org/index.php?do=details&task_id=867|FS#867]]

@openwrt-bot
Copy link
Author

n8v8R:

Turris Omnia with a Marvell Armada 385 88F6820 features

half thumb fastmult vfp edsp neon vfpv3 tls vfpd32

and this commit just castrates the CPU capabilities.

There is no point in sticking with OpenWrt if the repo is not able to diversify the CPU architecture for the target class but instead penalising device owners.

@openwrt-bot
Copy link
Author

jow-:

There is no point in sticking with OpenWrt if the repo is not able to diversify the CPU architecture for the target class but instead penalising device owners.

Feel free to use alternatives that cater exclusively for a small subset of supported devices.

@openwrt-bot
Copy link
Author

jow-:

It has been decided for now to stick to vfpv3-d16 as lowest common denominator and not split the target into subtargets.

@openwrt-bot
Copy link
Author

n8v8R:

Feel free to use alternatives

Of course at liberty, what is the point?

It has been decided for now to stick to vfpv3-d16

That exhibits blatant disregard for owners of Neon | vfpd32 capable hardware. I did not buy such capable hardware just to get the number of 64-bit FPU registers cut in half by software and forego NEON optimizations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openwrt-bot