Can you please always attach your Xorg.log?

Created attachment 76374 [details]
xorg.conf

The logfile, /var/log/Xorg.0.log.

ah .. sorry :( my bad

Created attachment 76375 [details]
Xorg.0.log

Hmm, found a bug but you shouldn't have been hitting that on 945gm...

commit 4f8fba31d7317248e0d4710ef5553dc1f9593314
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 12 10:12:12 2013 +0000

    sna: Apply the source offset to the transform when fixing up gradients
    
    Otherwise pixman will apply the source transform to the offsets.
    
    Reported-by: Ognian Tenchev <drJeckyll@Jeckyll.net>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62198
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Indeed, that bug does not reproduce for me on gen3. Treating as fixed, please reopen if you can reproduce and attach an Xorg.0.log with --enable-debug=full.

I'm little bit confused. 

After rebuilding xorg-server and xf86-video-intel (from git) both with --enable-debug=full Synapse windows is shown correctly, but everything is very slow, and Xorg.0.log become couple of GBs. 

Then again rebuild xorg-server and xf86-video-intel without debug same versions both, but Synapse windows is again corrupt.

I have 170MB Xorg.0.log (gzippped 17MB) can I upload it somewhere or extract relevant parts?

It's hard to tell in advance what's going to be most relevant, but the first and last 1 MB of the file should be the most interesting, and compress into the attachment limits.

Also, different compositing managers render the shadows using different techniques. It looks like you were using a gnome-shell variant, right?

Created attachment 76402 [details]
Xorg 1st MB

Created attachment 76403 [details]
Xorg last MB

windows manager is xfwm4 4.10.0

I haven't spotted anything worrying in there, no unusual paths or other oddities. Can you perhaps try a few different settings and see what peculiarities are required to trigger the bug?

Since I don't change any settings and just upgrade driver for me it is pointless to do it :) 

Instead I start to revert revisions and find that last revision that works for me is:
417c3f9b8c6b9a50dc1af440c53e94d2c6401251 - sna/trapezoids: Add a pair of unlikely hints for forced box emission

Next one:
7bb06b02e67435354778fe87a3e0429fe3750c23 - sna/gen3: Expand the number of SSE2 routines for basic composite ops

produce incorrect transparent border with Synapse ...

Interesting, very interesting. What version of gcc do you have?

So does

diff --git a/src/sna/sna_cpu.c b/src/sna/sna_cpu.c
index ef6843f..5b1c2d1 100644
--- a/src/sna/sna_cpu.c
+++ b/src/sna/sna_cpu.c
@@ -31,7 +31,7 @@
 
 #include "sna.h"
 
-#if HAS_GCC(4, 4)
+#if HAS_GCC(4, 4) && 0
 
 #include <cpuid.h>

restore your sanity?

gcc --version
gcc (Gentoo 4.7.2-r1 p1.5, pie-0.5.5) 4.7.2

let me try ...

#include "sna.h"

#if defined(__GNUC__) && (__GNUC__ >= 4) /* 4.4 */

#include <cpuid.h>

that is for me (rev 7bb06b02e67435354778fe87a3e0429fe3750c23) - to change 
#if defined(__GNUC__) && (__GNUC__ >= 4) /* 4.4 */

to:
#if HAS_GCC(4, 4) && 0

?

On master, make the change to #if 0 out the cpuid checks, so that you use the sna_cpu_detect() {return 0; } path. That will confirm your diagnosis that the sse2 routines are bad.

-#if HAS_GCC(4, 4)
+#if HAS_GCC(4, 4) && 0

on master make my poor Synapse look nice :) so sse2 is not playing nice for me ...

Do you mind doing a bit of detective work, and going through src/sna/gen3_render.c and disable each sse routine individually, like:

diff --git a/src/sna/gen3_render.c b/src/sna/gen3_render.c
index 59d13db..fd7c13d 100644
--- a/src/sna/gen3_render.c
+++ b/src/sna/gen3_render.c
@@ -3666,7 +3666,7 @@ gen3_render_composite(struct sna *sna,
                case SHADER_WHITE:
                case SHADER_CONSTANT:
 #if defined(sse2) && !defined(__x86_64__)
-                       if (sna->cpu_features & SSE2) {
+                       if (sna->cpu_features & SSE2 && 0) {
                                tmp->prim_emit = gen3_emit_composite_primitive_c
                                tmp->emit_boxes = gen3_emit_composite_boxes_cons
                        } else

Then when you find the one that is responsible for the error, please let me know and please attach your src/sna/.libs/gen3_render.o

pfu! 
Checked all 16 
if (sna->cpu_features & SSE2) {

I get lucky on second one:
        case SHADER_LINEAR:
        case SHADER_RADIAL:
            if (tmp->src.transform == NULL) {
#if defined(sse2) && !defined(__x86_64__)
                if (sna->cpu_features & SSE2 && 0) { //2 - ok
                    tmp->prim_emit = gen3_emit_composite_primitive_identity_gradient__sse2;
                    tmp->emit_boxes = gen3_emit_composite_boxes_identity_gradient__sse2;
                } else
#endif

Created attachment 76441 [details]
gen3_render.o

* scratches head.

Was the gen3_render.o from after you commented out the use of gen3_emit_composite_primitive_identity_gradient__sse2? I'm not finding it in the object file...

(In reply to comment #24)
> * scratches head.
> 
> Was the gen3_render.o from after you commented out the use of
> gen3_emit_composite_primitive_identity_gradient__sse2? I'm not finding it in
> the object file...

ah ... you want it without && 0? ok then

Created attachment 76442 [details]
gen3_render.o - without && 0

Can you please try with master?

commit f320e6908f24ff356303c8905c78ac290e24c2e6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 12 19:53:20 2013 +0000

    sna/gen3: Tweak code generation for gen3_emit_composite_primitive_identity_g
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=62198

Oh my word. The problem there was that is was making out-of-line calls to vertex_emit(), passing the value in %xmm0, but the vertex_emit() was compiled without sse2 and so expecting the parameter via %fp0. I had presumed that those functions would be inlined and so recompiled with sse2 at the callsite.

master should work, and I should have not had such high expectations.

have no idea what exactly this mean, but master WORK for me now :)
Thanks

Many, many thanks for your hard work. I believe I understand the bug now and I've scrutinized the code for similar issues, and think I have caught them all.