[MPlayer-dev-eng] [PATCH] Stereo3D: Row-Interleave Output Support

[Steaphan Greene]

On 06/21/2011 03:58 PM, Reimar Döffinger wrote:
> On Tue, Jun 21, 2011 at 02:08:58PM -0400, Steaphan Greene wrote:
>> So, I would expect calling memcpy_pic for the first copy would actually
>> end up being slower than the version you just committed, despite the
>> additional instructions required to skip these unused rows.
>>
>> Dos that sound right to you?
> 
> I think that is in principle what will happen (I haven't checked
> though), however the semantics aren't that that the memcpy_pic
> _has_ to copy all "extra" bytes, it could just copy e.g. 8 extra
> bytes to reach a multiple of 16 to allow faster copying via
> some instruction that copies 16 bytes at a time.
> The memcpy_pic2 version with "1" as last argument will always
> have to copy those last 8 bytes with something else.

The way memcpy_pic2 (the actual inline function in both cases) is
written now, without the 1, it assumes that two with the same stride are
contiguous copies (it does not account for row-skipping), so it will
copy all the extra data by combining the row copies into a single
fast_memcpy() call for the whole frame (or half-frame).

I agree with you, though.  It COULD be written to better optimize this
case.  It just isn't now, and changing those core functions seemed like
a very bad idea for just this one output case.

Note that this copy setup was already exactly the same for outputting to
side-by-side stereo formats, as they have the same memory layout as the
new interleaved forms, just without the row-skipping, and with a
different stride (so it was already correctly detecting this case).

-- 
Steaphan Greene <sgreene at cs.binghamton.edu>
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt