[FFmpeg-devel] [PATCH 09/13] avcodec/svq1dec: clear MMX state after MB decode loop

[Michael Niedermayer]

On Tue, Oct 25, 2016 at 12:00:01AM +0200, Hendrik Leppkes wrote:
> On Mon, Oct 24, 2016 at 10:31 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> > Hi,
> >
> > On Mon, Oct 24, 2016 at 4:26 PM, Henrik Gramner <henrik at gramner.com> wrote:
> >
> >> On Mon, Oct 24, 2016 at 9:59 PM, Ronald S. Bultje <rsbultje at gmail.com>
> >> wrote:
> >> > Good idea to reference Hendrik Gramner here, who keeps insisting we get
> >> rid
> >> > of all MMX code in ffmpeg (at least as an option) for future Intel CPUs
> >> in
> >> > which MMX will be deprecated.
> >>
> >> Replacing MMX with SSE2 is indeed the most "proper" fix in my opinion,
> >> but it's a fair amount of work and not done in an evening.
> >>
> >> The fact that a lot of assembly lacks unit tests is certainly not
> >> helping in that regard.
> >>
> >> Some MMX instructions are slower than the equivalent SSE2 code on
> >> Skylake. Intel hasn't officially commented on (as far as I know at
> >> least) if we should expect this trend to continue, but they certainly
> >> seem to treat MMX as legacy.
> >>
> >> I doubt they would completely remove support for it though, backwards
> >> compatibility is a big selling-point for x86.
> >
> >
> > Well, it gives us another way of fixing this issue (on x86-64 only): have
> > sse2 implementations for all code that has a mmx (register) path right now.
> >
> 
> I don't think the argument for pre-sse2 CPUs is that strong on 32-bit
> systems, either.

SSE2 was initially not faster than MMX as CPUs implemented it as 2
MMX operations internally not having a full width SIMD unit for SSE*
so there would be a performace loss on some x86-32 CPUs if MMX was
replaced by "half-width SSE2" there

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161026/ffd8c8a2/attachment.sig>