Re: Bug#594093: NEON pass failure on ffmpeg
On Mo, Sep 13, 2010 at 11:28:32 (CEST), Loïc Minier wrote: > On Fri, Aug 27, 2010, Reinhard Tartler wrote: >> the general idea is to start an upload with an 'dummy' debian/changelog >> entry indicating the next version, and finalize it using git-dch(1) just >> before the upload. > > Would you mind creating it with "UNRELEASED" as the target dist? This > helps dch figure out that it should add to the current changelog rather > than increment the version in the changelog. hm. this hides the upload target of upcoming upload. But if it helps git-dch, it might make sense to communicate this via other means. ok, I'll try with UNRELEASED. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#594093: NEON pass failure on ffmpeg
On Fri, Aug 27, 2010, Reinhard Tartler wrote: > the general idea is to start an upload with an 'dummy' debian/changelog > entry indicating the next version, and finalize it using git-dch(1) just > before the upload. Would you mind creating it with "UNRELEASED" as the target dist? This helps dch figure out that it should add to the current changelog rather than increment the version in the changelog. Thanks! -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#594093: NEON pass failure on ffmpeg
On Fri, Aug 27, 2010 at 01:42:17 (CEST), Loïc Minier wrote: > On Thu, Aug 26, 2010, Reinhard Tartler wrote: >> For the base flavor, I totally agree. For the specialized neon flavor, >> I'm not sure if that's so important. But I have to admit that I'm really >> not an expert for armel, so I fully trust your judgement here. > > Actually my test logic was wrong; I realized when implementing the v7 > part I mentioned: if v7 isn't enabled by default, then the NEON pass > should enable it since NEON implies v7. v6t2 was a distraction, I > removed it. thanks! > I committed this to ffmpeg git, but I didn't understand the way the > changelog was maintained (apparently you create an entry after the last > upload?). Mind fixing it up? I've just fixed it up. the general idea is to start an upload with an 'dummy' debian/changelog entry indicating the next version, and finalize it using git-dch(1) just before the upload. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
On Thu, Aug 26, 2010, Reinhard Tartler wrote: > For the base flavor, I totally agree. For the specialized neon flavor, > I'm not sure if that's so important. But I have to admit that I'm really > not an expert for armel, so I fully trust your judgement here. Actually my test logic was wrong; I realized when implementing the v7 part I mentioned: if v7 isn't enabled by default, then the NEON pass should enable it since NEON implies v7. v6t2 was a distraction, I removed it. I committed this to ffmpeg git, but I didn't understand the way the changelog was maintained (apparently you create an entry after the last upload?). Mind fixing it up? Thanks! -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
On Thu, Aug 26, 2010, Reinhard Tartler wrote: > For the base flavor, I totally agree. For the specialized neon flavor, > I'm not sure if that's so important. But I have to admit that I'm really > not an expert for armel, so I fully trust your judgement here. It's a fair point; I don't think it's too big a deal either way, it's just that I don't feel comfortable overriding more than I strictly need. -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
On Wed, Aug 25, 2010 at 23:13:27 (CEST), Loïc Minier wrote: > On Wed, Aug 25, 2010, Reinhard Tartler wrote: >> Hm, why can't we unconditionally turn on armv7-a for the neon flavor? > > I'd prefer not overriding the toolchain defaults, only overriding the > minimum set of things. > For instance, it could be selecting a special core. For the base flavor, I totally agree. For the specialized neon flavor, I'm not sure if that's so important. But I have to admit that I'm really not an expert for armel, so I fully trust your judgement here. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
On Wed, Aug 25, 2010, Reinhard Tartler wrote: > Hm, why can't we unconditionally turn on armv7-a for the neon flavor? I'd prefer not overriding the toolchain defaults, only overriding the minimum set of things. For instance, it could be selecting a special core. -- Loïc Minier ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#594093: NEON pass failure on ffmpeg
Processing commands for cont...@bugs.debian.org: > clone 594093 -1 Bug#594093: mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? Bug 594093 cloned as bug 594417. > reassign -1 src:ffmpeg Bug #594417 [mplayer] mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? Bug reassigned from package 'mplayer' to 'src:ffmpeg'. Bug No longer marked as found in versions mplayer/2:1.0~rc3+svn20100502-3. > found -1 4:0.6-1 Bug #594417 [src:ffmpeg] mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? Bug Marked as found in versions ffmpeg/4:0.6-1. > severity -1 important Bug #594417 [src:ffmpeg] mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? Severity set to 'important' from 'normal' > retitle -1 FTBFS/armel: neon flavor requires 'ubfx' instruction Bug #594417 [src:ffmpeg] mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? Changed Bug title to 'FTBFS/armel: neon flavor requires 'ubfx' instruction' from 'mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)?' > reassign 594093 mplayer Bug #594093 [mplayer] mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? Ignoring request to reassign bug #594093 to the same package > fixed 594093 2:1.0~rc4~try1.dsfg1-1 Bug #594093 [mplayer] mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? Bug Marked as fixed in versions mplayer/2:1.0~rc4~try1.dsfg1-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 594093: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594093 594417: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594417 -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
clone 594093 -1 reassign -1 src:ffmpeg found -1 4:0.6-1 severity -1 important retitle -1 FTBFS/armel: neon flavor requires 'ubfx' instruction reassign 594093 mplayer fixed 594093 2:1.0~rc4~try1.dsfg1-1 thanks On Wed, Aug 25, 2010 at 21:49:54 (CEST), Loïc Minier wrote: > tags 594093 + patch confirmed > stop > > On Wed, Aug 25, 2010, Riku Voipio wrote: >> Neither is it a toolchain bug nor do we have any NEON capable buildds. > > It's ok, we don't need NEON capable buildds; this builds an alternate > set of ffmpeg libs for NEON (available via hwcaps). > >> And, btw ubfx is not even a NEON instruction. It is a ARMv7 instruction. > > It actually seems to have been added in armv6t2+ (even in ARM mode). > >> The error is caused by debians toolchain default flags. you need to pass >> -march=armv7-a for the debian-neon pass to get armv7 instructions accepted. > > Now the NEON flavor implies armv7-a, so that's what we should turn on. > > > Riku, Reinhard, I only checked the gcc tests in the attached debdiff, > but didn't do a full build under Debian; would you mind trying it out? I wouldn't mind, but I'd say, just commit it to our git branch, and I'll try to build it on a porter machine in a sid chroot. I don't have any other armel hardware available. Please note that bug 594093 was a bug in mplayer. This particular issue is actually another bug, so I'm cloning the bug with this message. So your patch now needs some minor adjustment to debian/changelog. > Now one thing which this patch does NOT do is turn on armv7-a for the > NEON flavour if the toolchain defaults to armv6t2, so we might be > missing some small optimizations, but I didn't check how to test for > armv7-a versus armv6t2. If ffmpeg relies on the some armv7-a-only > assembly, then we will quickly find out :-) Hm, why can't we unconditionally turn on armv7-a for the neon flavor? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
tags 594093 + patch confirmed
stop
On Wed, Aug 25, 2010, Riku Voipio wrote:
> Neither is it a toolchain bug nor do we have any NEON capable buildds.
It's ok, we don't need NEON capable buildds; this builds an alternate
set of ffmpeg libs for NEON (available via hwcaps).
> And, btw ubfx is not even a NEON instruction. It is a ARMv7 instruction.
It actually seems to have been added in armv6t2+ (even in ARM mode).
> The error is caused by debians toolchain default flags. you need to pass
> -march=armv7-a for the debian-neon pass to get armv7 instructions accepted.
Now the NEON flavor implies armv7-a, so that's what we should turn on.
Riku, Reinhard, I only checked the gcc tests in the attached debdiff,
but didn't do a full build under Debian; would you mind trying it out?
Now one thing which this patch does NOT do is turn on armv7-a for the
NEON flavour if the toolchain defaults to armv6t2, so we might be
missing some small optimizations, but I didn't check how to test for
armv7-a versus armv6t2. If ffmpeg relies on the some armv7-a-only
assembly, then we will quickly find out :-)
Thanks,
--
Loïc Minier
diff -u ffmpeg-0.6~svn20100505/debian/confflags
ffmpeg-0.6~svn20100505/debian/confflags
--- ffmpeg-0.6~svn20100505/debian/confflags
+++ ffmpeg-0.6~svn20100505/debian/confflags
@@ -33,11 +33,14 @@
has_vfp := $(call check_asm, $(vfp_asm))
neon_asm := vadd.i16 q0, q0, q0
has_neon := $(call check_asm, $(neon_asm))
+v6t2_asm := ubfx r0, r0, 0, 1
+has_v6t2 := $(call check_asm, $(v6t2_asm))
-# only build
+# only build a VFP flavour if the toolchain doesn't enable VFP by default
ifneq ($(has_vfp),1)
FLAVORS += vfp
endif
+# only build a NEON flavour if the toolchain doesn't enable NEON by default
ifneq ($(has_neon),1)
FLAVORS += neon
endif
@@ -161,6 +164,12 @@
# NB: NEON always implies v7+ and ffmpeg's NEON implementation requires VFP
neon_build_confflags += $(confflags)
neon_build_confflags += --shlibdir=/usr/lib/neon/vfp
+# the NEON pass now requires ubfx which was introduced in armv6t2; we need to
+# enable at least armv6t2 for the NEON pass to build, but NEON implies armv7-a
+# so pass armv7-a
+ifneq ($(has_v6t2),1)
+neon_build_confflags += --extra-cflags="-marmv7-a"
+endif
neon_build_confflags += --extra-cflags="-mfpu=neon -mfloat-abi=softfp -fPIC
-DPIC"
neon_build_confflags += --enable-shared
neon_build_confflags += --disable-static
diff -u ffmpeg-0.6~svn20100505/debian/changelog
ffmpeg-0.6~svn20100505/debian/changelog
--- ffmpeg-0.6~svn20100505/debian/changelog
+++ ffmpeg-0.6~svn20100505/debian/changelog
@@ -1,3 +1,12 @@
+ffmpeg (4:0.6~svn20100505-2) UNRELEASED; urgency=low
+
+ * debian/confflags: detect whether the toolchain supports armv6t2 ("ubfx")
+by default as that's now needed for the NEON pass; if it's not enabled by
+default, pass -marmv7-a in extra-cflags for the NEON pass since NEON
+implies ARMv7; closes: #594093.
+
+ -- Loïc Minier Wed, 25 Aug 2010 21:42:57 +0200
+
ffmpeg (4:0.6~svn20100505-1) experimental; urgency=low
* update to new upstream. Closes: #569727
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#594093: NEON pass failure on ffmpeg
Processing commands for cont...@bugs.debian.org: > tags 594093 + patch confirmed Bug #594093 [mplayer] mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)? Added tag(s) confirmed and patch. > stop Stopping processing here. Please contact me if you need assistance. -- 594093: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594093 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
Hi lool, I remember that you have tuned the debian/rules file to accomodate to the 'default' toolchain flags. Could you please have a look at this issue? Thanks On Wed, Aug 25, 2010 at 18:34:48 (CEST), Riku Voipio wrote: > reopen 594093 > thanks > >> /tmp/ccv13sip.s:6567: Error: selected processor does not support `ubfx >> ip,r2,#6,#2' >> make[1]: *** [libavcodec/aacdec.o] Error 1 >> make[1]: Leaving directory >> `/build/buildd-ffmpeg_0.6-2-armel-ldBGDA/ffmpeg-0.6/debian-neon' >> make: *** [build-stamp-neon] Error 2 > >> which seems to me to be a toolchain bug. The build should care if the >> processor is able to execute the NEON extensions; but compiling them >> should be possible in any case. It's not like this binary is needed >> during build or something. > >> I'm not going to investigate this further as the easiest fix would be >> probably to reschedule the build on a NEON capable buildd. > > Neither is it a toolchain bug nor do we have any NEON capable buildds. > And, btw ubfx is not even a NEON instruction. It is a ARMv7 instruction. > > The error is caused by debians toolchain default flags. you need to pass > -march=armv7-a for the debian-neon pass to get armv7 instructions accepted. > > Riku -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#594093: NEON pass failure on ffmpeg
reopen 594093 thanks > /tmp/ccv13sip.s:6567: Error: selected processor does not support `ubfx > ip,r2,#6,#2' > make[1]: *** [libavcodec/aacdec.o] Error 1 > make[1]: Leaving directory > `/build/buildd-ffmpeg_0.6-2-armel-ldBGDA/ffmpeg-0.6/debian-neon' > make: *** [build-stamp-neon] Error 2 > which seems to me to be a toolchain bug. The build should care if the > processor is able to execute the NEON extensions; but compiling them > should be possible in any case. It's not like this binary is needed > during build or something. > I'm not going to investigate this further as the easiest fix would be > probably to reschedule the build on a NEON capable buildd. Neither is it a toolchain bug nor do we have any NEON capable buildds. And, btw ubfx is not even a NEON instruction. It is a ARMv7 instruction. The error is caused by debians toolchain default flags. you need to pass -march=armv7-a for the debian-neon pass to get armv7 instructions accepted. Riku signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
