[FFmpeg-devel] [PATCH 0/7] [RFC] x86 assembly constants

[Ronald S. Bultje]

Hi,

On Sat, Oct 3, 2015 at 2:46 PM, James Darnley <james.darnley at gmail.com>
wrote:

> On 2015-10-03 04:08, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Oct 2, 2015 at 4:58 PM, Hendrik Leppkes <h.leppkes at gmail.com>
> wrote:
> >
> >> On Fri, Oct 2, 2015 at 7:16 PM, Timothy Gu <timothygu99 at gmail.com>
> wrote:
> >>> On Fri, Oct 2, 2015 at 10:08 AM James Darnley <james.darnley at gmail.com
> >
> >>> wrote:
> >>>
> >>>> The third patch uses them in the remaining inline assembly.
> >>>>
> >>>
> >>> That's the crux of the problem: inline asm uses these constants, but
> will
> >>> be unable to without yasm. Either we drop compatibility for inline asm
> >> for
> >>> x86 platforms w/o yasm, or we can't do this.
> >>>
> >>
> >> A build without yasm is gimped as it is, so disabling inline asm in
> >> the same go doesn't seem like a too terrible thing.
> >
> >
> > I'm leaning towards this as well.
>
> Then you will all be pleased to hear that I have fixed building with
> --disable-yasm by adding a HAVE_YASM check to a few functions in cavs
> (the Chinese H.264 knockoff) and many functions in vc1.  One conditional
> in inline_asm has also been extended.  At least this fixes building
> ffmpeg for the people who use --disable-yasm.
>
> As for porting, I know I said "how hard can this be"...quite a lot
> actually.  I ported 1 function in cavs last night but after going though
> vc1 to fix building I can see just how much work that would be.


We've had various efforts in that direction. The problem is that typically
people add new inline asm over time, even if it's discouraged. Any effort
you're willing to put into conversion of that code would be hugely
appreciated. But as you can also see, people don't care much about
vc1/cavs, not remotely as much as they do about mpeg1/2/4/h264/etc. Which
is why their conversion is lagging :)

Ronald