[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM



On Tue, Mar 04, 2014 at 02:59:44AM +0000, peter green wrote:
> Seems sane to me. armv7 devices without neon are relatively uncommon
> so while it's important that they are supported it's IMO not vitally
> important to squeeze out every last drop of performance from them.

I don't agree.  At least the fisrt Tegra chips did not have neon, and the
marvell chips often don't have neon (the newer ones are starting to now
that they are moving to using Cortex-A designs, rather than marvell custom
cores (like the JP4 used in the armada 510 in the cubox for example),
but many chips don't have neon).  Do the qualcomm designs have neon?
I have been mostly ignoring them due to the anti open source attitude
of qualcomm.

If with=arm_fpu auto selects neon or VFP3 automatically, then I think
armhf is perfect for all armv7 devices.

> I wonder what we should use on raspbian? I haven't tested on a Pi
> yet but it seems that on all tests i've seen so-far the generic fpu
> code is quite a bit slower than the arm nofpu code. Is there any
> quality difference from using a fpu vs nonfpu decoder? If so how
> much performance degredation do you beleive should be accepted in
> exchange for that quality improvement.

So VFP2 is slower than interger math?  Interesting.

> IMO it's often better to be explicit about this sort of thing. While
> upstreams defaults may align with debian armhf's requirements at the
> present time and on the present build hardware such defaults are
> subject to change either as a result of upstream changes in new
> versions or as a result of different build hardware.

I suppose that makes sense.  Avoids unexpected surprises later.

-- 
Len Sorensen


Reply to: