[FFmpeg-devel] [PATCH] Revert

[Paul B Mahol]

On 11/1/12, Reimar Doeffinger <Reimar.Doeffinger at gmx.de> wrote:
> On 1 Nov 2012, at 02:08, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Thu, Nov 01, 2012 at 01:55:31AM +0100, Carl Eugen Hoyos wrote:
>>> On Thursday 01 November 2012 01:45:28 am Michael Niedermayer wrote:
>>>
>>>>> The problem is the MMX version of AV_COPY64()
>>>>
>>>> try adding a emms_c() somewhere, maybe after parse_bintree()
>>>
>>> Attached patch fixes direct rendering in MPlayer here when I revert my
>>> removal
>>> of CODEC_CAP_DR1.
>>>
>>> Thank you, Carl Eugen
>>
>>> indeo3.c |    1 +
>>> 1 file changed, 1 insertion(+)
>>> f958fd52d2eebcf9a0da9411a08cb8b5a3cf4c07  patchiv32dr.patch
>>> diff --git a/libavcodec/indeo3.c b/libavcodec/indeo3.c
>>> index 126bd2b..9501763 100644
>>> --- a/libavcodec/indeo3.c
>>> +++ b/libavcodec/indeo3.c
>>> @@ -1094,6 +1094,7 @@ static int decode_frame(AVCodecContext *avctx, void
>>> *data, int *data_size,
>>>
>>>     if ((res = decode_plane(ctx, avctx, &ctx->planes[2], ctx->v_data_ptr,
>>> ctx->v_data_size, 10)))
>>>         return res;
>>> +    emms_c();
>>>
>>>     if (ctx->frame.data[0])
>>>         avctx->release_buffer(avctx, &ctx->frame);
>>
>> patch ok, a emms is needed before calling outside code like
>> release_buffer, though i see no float/double in mplayers
>> release_buffer
>
> If I remember right, get/release buffer will end up calling code in the vo,
> so in this specific case even stuff in for example NVidia's libGL.
> Which might be doing all kinds of crazy stuff.
> I seriously wonder if there is sense in using MMX for AV_COPY though, it has
> a seriously high risk for this kind of bugs and we might have to add emms_c
> all over the place.
> Does it really give any performance benefit that is worth that?

That is easy to test, but I bet it is marginal.

Also it is written in inline assembly.