[x264-devel] libx264: Illegal instruction on ARMv5 (Thecus N2100)

[Tobias Frost]

Hallo debian-multimedia list,
Hallo x264 development list,

Note: I'm not on the list! Please do not forget to CC me.

When coding videos the codec fails immediatly with an illegal
instruction.
After browsing the code a bit, I think upstream did expect an
ARM V6 or better, my Thecus has:

$ uname -a
Linux thecus 2.6.32-bpo.5-iop32x #1 Sun Sep 19 16:59:11 UTC 2010
armv5tel GNU/Linux

How to reproduce:
==================

apt-get install x264
wget http://samples.mplayerhq.hu/yuv4mpeg2/example.y4m.bz2
bunzip example.y4m.bz2
x264 -o example.mkv example.y4m
Illegal instruction

Update: Also:
tobi at thecus:~$ x264
Illegal instruction


Obervations when compiling:
==============================

ccache cc -Wshadow -O1 -g -g -O2 -Wall -I. -g -O2 -std=gnu99
-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize
-c -o common/mc.o common/mc.c

I'm not sure if the -mcpu and -mfpu are right. The Thecus has
an Intel XScale 255. This one has no NEON extension, nor it is a cortex
A8.
A brief check of the configure scripts seems to show that this
is hardcoded as soon as ARM is set as ARCH, and it is only checked
if the assembler supports the instruction, not if the hardware really
does (would be hard for cross-compiling, I know...)


How to fix?
===========
A temporary fix is be to add "--disable-asm" to the
configure script (via debian rules) if building for
debian ARM. This is how I rebuild the packages to
get a working solution.

I assume that this should be really fixed on debian
side, but currently debian cannot differenciate
different CPU capabilites, ASFAIK.

But a runtime-detection might work as well ?
(Is a bad-instruction trapable?)

--
coldtobi

[Jason Garrett-Glaser]

Post by Tobias Frost
Hallo debian-multimedia list,
Hallo x264 development list,
Note: I'm not on the list! Please do not forget to CC me.
When coding videos the codec fails immediatly with an illegal
instruction.
After browsing the code a bit, I think upstream did expect an
$ uname -a
Linux thecus 2.6.32-bpo.5-iop32x #1 Sun Sep 19 16:59:11 UTC 2010
armv5tel GNU/Linux
==================
apt-get install x264
wget http://samples.mplayerhq.hu/yuv4mpeg2/example.y4m.bz2
bunzip example.y4m.bz2
x264 -o example.mkv example.y4m
Illegal instruction
tobi at thecus:~$ x264
Illegal instruction
==============================
ccache cc -Wshadow -O1 -g -g -O2 -Wall -I. -g -O2 -std=gnu99
-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp ? ?-fno-tree-vectorize
-c -o common/mc.o common/mc.c
I'm not sure if the -mcpu and -mfpu are right. The Thecus has
an Intel XScale 255. This one has no NEON extension, nor it is a cortex
A8.
A brief check of the configure scripts seems to show that this
is hardcoded as soon as ARM is set as ARCH, and it is only checked
if the assembler supports the instruction, not if the hardware really
does (would be hard for cross-compiling, I know...)
How to fix?
===========
A temporary fix is be to add "--disable-asm" to the
configure script (via debian rules) if building for
debian ARM. This is how I rebuild the packages to
get a working solution.
I assume that this should be really fixed on debian
side, but currently debian cannot differenciate
different CPU capabilites, ASFAIK.
But a runtime-detection might work as well ?
(Is a bad-instruction trapable?)
--
coldtobi
_______________________________________________
x264-devel mailing list
x264-devel at videolan.org
http://mailman.videolan.org/listinfo/x264-devel

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.

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...

Jason

[Tobias Frost]

Post by Jason Garrett-Glaser
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.

Post by Jason Garrett-Glaser
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

[Falk Hähle]

Hi Jason,

I?ve found you two years old message regarding compiling x264 without NEON support http://mailman.videolan.org/pipermail/x264-devel/2010-December/008093.html. I would also use x264 on ma 24/7 NAS box to encode some video files during idle time. I know your post is quite old but it would be very nice if you could give me some information if recompiling with "--disable-asm" was successful and if you managed to run x264 on your machine.

Best regards

Falk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20121231/d61efb6d/attachment.html>