[FFmpeg-devel] [PATCH] move h264 chromaMC x86 code to yasm
Ronald S. Bultje
Sun Aug 29 15:50:29 CEST 2010
On Sat, Aug 28, 2010 at 9:27 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Sat, Aug 28, 2010 at 4:40 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>> On Sat, Aug 28, 2010 at 7:31 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Sat, Aug 28, 2010 at 4:14 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>>>> as per subj. FATE passes on x86-32/64 OSX and this patch fixes
>>>> fate-vp6 on Win64 (which currently fails because of unmarked
>>>> clobbering of xmm registers). There's some nice optimizations that
>>>> could be done after this is applied, e.g. adding rv40 ssse3 mc should
>>>> be easy-as-hell, but all that is left for later.
>>> Are you sure this actually compiles with, for example, --disable-everything?
>> Didn't test yet... Jason says yasm doesn't have access to
>> CONFIG_xyz_DECODER macros, it probably should, or I'd have to split
>> these .asm files in ten smaller .asm files with various levels of
>> includability, which would suck major ass...
> Err, it's not such a big deal if we include unused functions in yasm
> code... the issue I'm wondering about is dsputil_mmx.c unconditionally
> referencing functions which are only compiled if h264dsp is enabled.
Oh I see what you mean now, yeah that's pretty bad. I've moved
h264dsp_chromamc.o from OBJS-CONFIG_H264DSP to OBJS-HAVE_YASM, which
is the level that dsputil_mmx.o is under also (without the YASM). I've
also added #if HAVE_YASM under all function pointer assignments in
dsputil_mmx.c. That should be enough as a quick fix, although of
course (just as was the case with dsputil) we're still including all
functions in the binary, even those part of decoders possibly not
compiled in. Similar to h264pred, creating a new configure item for
h264chromamc might be useful (?). Does anyone have opinions on this?
Long term, what would be nice if somehow A) config.h could be included
and parsed in YASM code (so I can use e.g. %ifdef CONFIG_VC1_DECODER
for the vc1-specific bits, likewise for rv40-specific bits), or B) to
have configure output a config.asm that is yasm-formatted, of course
only if yasm is enabled. Mans, Diego, flame me for this crazy idea if
you wish but is "yasm'ism" possible?
More information about the ffmpeg-devel