[FFmpeg-devel] [PATCH] update doc/optimization.txt

[Ronald S. Bultje]

Hi,

On Tue, Sep 21, 2010 at 3:20 AM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Mon, Sep 20, 2010 at 08:03:29PM -0400, Ronald S. Bultje wrote:
>> For the functions that I converted, I don't believe any of them will
>> be inlined. In fact, I believe we'll use more function pointers
>> because of new instruction sets (e.g. Intel's new AVX). These we can't
>> inline if you want to keep supporting "older" x86-64 CPUs (which you
>> most likely do).
>
> I don't think it will happen since we would need a less messy
> way to implement it, but the idea is to support building
> for one and only one specific CPU like libswscale does,
> there would be no need for any function pointers at all.

(Don't get me started on libswscale.) I would love to contribute to it
at some point, but it's seriously a mess... With this whole inline
thing, it seems like adding a new optimization (let's say I want to
write a AVX version of RGB->YUV for some obscure reason) is 3x as much
effort as it is in dsputil, where I can just add the new function,
assign a function pointer, make fate + some performance count to test
and _that's it_.

Not to mention that even if I did all the effort to make sure the
function _can_ be inlined in swscale, I'd likely never test it because
I simply don't care about that use case, so it'd probably not actually
work unless there's a fate test for this particular configuration. Is
that a good design?

Ronald