Re: RFC: inline assembly for alphablend functions

Roland Scheidegger <[email protected]>
Newsgroups gmane.comp.video.xine.devel
Message-ID <[email protected]>
Forgot the attachment...

Am 25.04.2012 21:00, schrieb Roland Scheidegger:
> Hi,
> 
> xine's alphablend functions are terrible cpu hogs (in particular with hd
> streams). I was wondering if it would be worthwile to improve things a
> bit with simd instructions. I started with mem_blend32 because that's a
> natural fit for mmx without touching anything else (and because this
> itself uses a lot of time with yuy2 blending). Seems to work and reduce
> executed instructions a lot though only on a K8 do I see any performance
> improvement (the thing is once again heavily limited by memory
> bandwidth). Of course it does exactly nothing unless you have
> video.output.disable_exact_alphablend set. The code is also compiled and
> executed unconditionally which obviously would need to change.
> I guess there would be more of an improvement with the exact blend
> function (looks a bit less limited by memory bandwidth) but that's
> definitely much more work.
> So what do you think?
> 
> Roland

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
xine-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xine-devel
ablend_asm.diff (text/x-patch, 1.2 KB)
diff -r bd20c9edb6ae src/xine-engine/alphablend.c
--- a/src/xine-engine/alphablend.c	Tue Apr 17 14:27:36 2012 +0300
+++ b/src/xine-engine/alphablend.c	Wed Apr 25 20:50:23 2012 +0200
@@ -81,6 +81,39 @@
 
 static void mem_blend32(uint8_t *mem, const uint8_t *src, uint8_t o, int len) {
   uint8_t *limit = mem + len*4;
+
+  if (1) {
+    int oadj = o * 0x11;
+    __asm__ __volatile__ (
+      "movd          %0, %%mm7 \n\t"
+      "pxor       %%mm6, %%mm6 \n\t"
+      "pshufw $0, %%mm7, %%mm7 \n\t"
+      :
+      : "r" (oadj)
+    );
+    while (mem < limit) {
+      __asm__ __volatile__ (
+        "movd        (%0), %%mm0 \n\t"
+        "movd        (%1), %%mm1 \n\t"
+        "punpcklbw  %%mm6, %%mm0 \n\t"
+        "punpcklbw  %%mm6, %%mm1 \n\t"
+        "psubw      %%mm0, %%mm1 \n\t"
+        "pmullw     %%mm7, %%mm1 \n\t"
+        "psraw         $8, %%mm1 \n\t"
+        "paddw      %%mm1, %%mm0 \n\t"
+        "packuswb   %%mm0, %%mm0 \n\t"
+        "movd       %%mm0, (%0)  \n\t"
+      :
+      : "r" (mem), "r" (src)
+      : "memory"
+      );
+      mem += 4;
+    }
+    __asm__ __volatile__ ("emms");
+    return;
+  }
+
+  
   while (mem < limit) {
     *mem = BLEND_BYTE(*mem, src[0], o);
     mem++;
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.