Jason wrote:
> x264 builds with NEON by default because x264 is so slow without NEON
> (and on any non-NEON chip) as to be useless. You can of course
> compile with --disable-asm on such chips, but we don't do it by
> default because we don't feel it's necessary to actively support chips
> on which x264 would be basically useless to begin with.
I agree with you that is is perfectly fine to build for NEON by
default.
However, uselsessness should be defined out of the view of the acutal
user.
And my use-case is perfectly fine with the limited speed of my ARM v5 (I
don't care if the encode job is done in 1 hour or some days, as my NAS
is up 24/7 and it is otherwise usually quite bored, so it can do some
number crunching..)
However, there is a usability question when running code that terminates
unexpectetly: For example, I use handbrake-cli for setting up encoding
steps. It took my quite a time to figure out that handbrake is not the
culprit but acutally a library that it is callling.
> The ARM people (of which I'm not one, I don't maintain the ARM part)
> also strongly discouraged us from using too much runtime detection...
The ARM people might discourage that, the ARM *company* say exactly the
opposite:
"When running applications with NEON, one should check which CPU these
are executed on." [1]
From my experience as programmer I would do that checks in the
initialization routine and bark out if something is not supported.
More nice of course would be an automatic detection of the supported
features and then run-time selection of the appropiate function.
But that, of course, burns some additional CPU cycles.
I think that would be overkill indeed.
[1]
http://www.arm.com/community/software-enablement/linux.php
