Emit vzeroupper after avx memcpy

Roland Scheidegger <[email protected]> Tue, 17 Sep 2013 19:58:07 +0200

Newsgroups	gmane.comp.video.xine.devel
Message-ID	<[email protected]>

------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk

_______________________________________________
xine-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xine-devel

xine_avx_vzeroupper.diff (text/x-patch, 1.4 KB)

Exportiere Patch:
# HG changeset patch
# User Roland Scheidegger <[email protected]>
# Date 1379439939 -7200
# Node ID 4d91e6b3d6c362af5de0e752c94822fc916d9b86
# Parent  ae03169fe7545faf962909669022045cc0edcc24
Emit vzeroupper after avx memcpy

Emitting vzeroupper is necessary to avoid avx<->sse transition penalties (when
using avx-256 instructions).
This didn't really matter much in the past, since other code wasn't using avx,
hence there was just a penalty once afterwards when sse code was executed.
However, there's code in ffmpeg which mixes avx-128 and sse a lot, and each
time this happens there's a huge penalty. This causes in particular
ff_deblock_v_luma_8_avx to slow down by a factor of 50 or so which makes the
whole decoding about twice as slow (might be dependent on the h264 stream or
maybe ffmpeg version too, since ffmpeg will also emit vzeroupper when using
avx-256 hence not doing it here might not always be an issue, but in the case
I was seeing nothing else used avx-256).

diff -r ae03169fe754 -r 4d91e6b3d6c3 src/xine-utils/memcpy.c
--- a/src/xine-utils/memcpy.c	Fri Sep 13 12:50:40 2013 +0200
+++ b/src/xine-utils/memcpy.c	Tue Sep 17 19:45:39 2013 +0200
@@ -342,6 +342,7 @@
     /* since movntq is weakly-ordered, a "sfence"
      * is needed to become ordered again. */
     __asm__ __volatile__ ("sfence":::"memory");
+    __asm__ __volatile__ ("vzeroupper");
   }
   /*
    *	Now do the tail of the block