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

Ronald S. Bultje rsbultje
Wed Sep 22 15:54:42 CEST 2010


On Wed, Sep 22, 2010 at 9:47 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> 2010/9/22 M?ns Rullg?rd <mans at mansr.com>:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>>> On Wed, Sep 22, 2010 at 02:11:49PM +0100, M?ns Rullg?rd wrote:
>>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>> > On Wed, Sep 22, 2010 at 08:37:07AM -0400, Ronald S. Bultje wrote:
>>>> >> Also, should I mention (in general tips) that functions that use huge
>>>> >> structs (e.g. MpegEncContext) are A) "discouragable" in general and B)
>>>> >> better written in inline asm than yasm because of the difficulty of
>>>> >> predicting struct offsets?
>>>> >
>>>> > B is ok about A, who uses huge structs when its not needed ...
>>>> If possible, the asm functions should be passed pointers into (or
>>>> values from) the struct in preference over passing a pointer to the
>>>> whole struct.
>>> if one needs just 1 pointer into a struct yes, if one needs 5, its not
>>> efficient to use up 5 registers and waste the time to initialize them
>>> besides that x86-32 has too few registers for this to work out
>> In many such cases, those values could be put in a struct of their own
>> contained within the larger struct. ?Manually managing offsets in a
>> small struct is simple enough.
> I think this is sort of the message I was hoping to put forward. I'm
> not saying we should change MpegEncContext, that code exists and works
> well, I'm just saying that for future (newly written) pieces of code
> requiring new simd, we should look into alternatives as both of you
> pointed out. Both of your alternatives could work in some situations,
> and there's others where a big struct is really the best solution.
> Hence no details in the doc, just "isn't always best".

And another updated patch. If particular chunks look OK, let me know
and I'll apply them to prevent this patch from becoming monstrously

-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc.diff
Type: application/octet-stream
Size: 2305 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100922/af7dc511/attachment.obj>

More information about the ffmpeg-devel mailing list