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

[Steve McIntyre]

On Mon, Feb 17, 2014 at 11:43:16AM +0100, Thomas Orgis wrote:
>Am Mon, 17 Feb 2014 10:00:48 +0200
>schrieb Riku Voipio <riku.voipio at iki.fi>: 
>
>> Thanks Peter for explaining, this was how I ended up the suggestion
>> in the bug.
>> 
>> > I see. In that case, I'll have to leave the package as it until
>> > something along those lines is implemented.
>> 
>> Yes. The ideal solution is for the upstream to implement cpu runtime
>> detection that:
>> 
>> 1) uses neon if it is available
>> 2) falls back to fixed point if app requested 16-bit playback
>> 3) finally falls back to generic fpu code if neither of above applies
>> 
>> Any packaging level workaround is going to be suboptimal for someone.
>
>Isn't the approach for the linker to select libraries like libavcodec
>on the table anymore? I see that I'll have to add that float conversion
>code to keep the features along all builds, but selecting a vfp and
>non-vfp variant for fixed point or floating point via the linker seems
>like the most clean approach you are going to get.

Yes, you can do that - build several copies of the library and use the
hwcaps / auxv approach to pick the best one for the hardware at link
time.

>NEON detection may come... but if we have linker selection, that would
>be covered right now.

Yup.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
Is there anybody out there?