On Mon, Oct 3, 2016 at 1:37 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> Hi!
>
> 2016-10-03 13:05 GMT+02:00 Guillaume POIRIER <poiri...@gmail.com>:
>> Hello,
>>
>> On Mon, Oct 3, 2016 at 11:38 AM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
>>> 2016-10-03 3:52 GMT+02:00 Carl Eugen Hoyos <ceffm...@gmail.com>:
>>>
>>>> New patch attached.
>>>
>>>> +Compilation with @uref{http://www.musl-libc.org/, musl} on x86-64 is
>>>> supposed
>>>> +to work out-of-the-box.
>>>
>>> Is this true or is it just working by accident?
>>
>> AMD64 dictates that float operations must occur with scalar SSE
>> operations, so it's not working by accident. It works because float
>> operations don't use x87 stack (which is shared with MMX)
>
> Thank you for the explanation!
>
> Ping on the patch:
> We will not guard every asm call with emms_c() and Rich will not
> change his alloc() implementation for us: Can't we just document
> that it doesn't work and return to bugs that we can fix?
>
> Or should we consider to guard the three calls to mallc(), realloc()
> and free()?
> This works here as expected with 32bit musl but likely does not
> fix the underlying issue.
>
There is no reason to call anything unsupported because FFmpeg
violates the C calling convention, nor is there a reason to add
overhead to every single call.
The underlying problem is that mmx code is mixed with allocations,
which seems like an unusual case to begin with since allocations
should not be part of performance critical loops or something like
that.
So, the appropriate answer is to find the code in question that causes
these issues, and just add an emms there, or re-structure it to take
the allocations out of the mmx code.
Anything else just masks potential issues.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
