Try with just:

diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 48dcb58..1e9546d 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -1098,6 +1098,8 @@ static unsigned small_copy(const RegionRec *region)
 }
 
 #ifdef CREATE_PIXMAP_USAGE_SHARED
+#undef DBG
+#define DBG(x) ErrorF x
 static Bool
 sna_share_pixmap_backing(PixmapPtr pixmap, ScreenPtr slave, void **fd_handle)
 {
@@ -1290,6 +1292,8 @@ sna_create_pixmap_shared(struct sna *sna, ScreenPtr screen,
 
        return pixmap;
 }
+#undef DBG
+#define DBG(x)
 #endif
 
 static PixmapPtr sna_create_pixmap(ScreenPtr screen,

Hi Chris, I tried this patch and still fail.
ADD info:
the pinned flag of pixmap is PIN_DRI2.

I catch the xtrace of glxgears, when I change focus, it will get invalidateBuffers event
and get buffer again, the content shows. But I can't find why at the begging the pixmap
is get pinned first and the sequence can change with fast/slow DDX.

000:>:10ae2: Event DRI2-InvalidateBuffers(103) drawable=0x03600002
000:>:10ae2: Event DRI2-BufferSwapComplete(102) drawable=0x00000002 ust_hi=56623106 ust_lo=0 msc_hi=0 msc_lo=0 sbc_hi=0 sbc_lo=34143
000:>:0ae1:32: Reply to SwapBuffers: swap_hi=0 swap_lo=34143
000:>:0ae2:32: Reply to GetInputFocus: revert-to=Parent(0x02) focus=0x0380000b
000:<:10ae3: 20: DRI2-Request(153,7): GetBuffersWithFormat drawable=0x03600002 attachments={attachment=BackLeft(0x00000001) format=0x00000018};
000:>:0ae3:52: Reply to GetBuffersWithFormat: width=300 height=300 buffers={attachment=BackLeft(0x00000001) name=0x00000004 pitch=1280 cpp=4 flags=0x00000000};

(In reply to Qiang Yu from comment #3)
> I catch the xtrace of glxgears, when I change focus, it will get
> invalidateBuffers event
> and get buffer again, the content shows. But I can't find why at the begging
> the pixmap
> is get pinned first and the sequence can change with fast/slow DDX.

It depends upon a race with a client. I have an old patch for -ati to handle DRI2UpdatePrime failure.

(In reply to Qiang Yu from comment #3)
> I catch the xtrace of glxgears, when I change focus, it will get
> invalidateBuffers event
> and get buffer again, the content shows. But I can't find why at the begging
> the pixmap
> is get pinned first and the sequence can change with fast/slow DDX.

It depends upon a race with a client. I have an old patch for -ati to handle DRI2UpdatePrime failure.

Seem the race condition is between glxgears and compiz:
if the compiz call DRI2GetBufferWithFormat before first time glxgears
call DRI2SwapBuffer, the pixmap is pinned with PIN_DRI2.

Hi Chris, where is your patch? I can try it.

Created attachment 123250 [details] [review]
Fallback to std DRI2CopyRegion when DRI2UpdatePrime fails

(In reply to Chris Wilson from comment #8)
> Created attachment 123250 [details] [review] [review]
> Fallback to std DRI2CopyRegion when DRI2UpdatePrime fails

Hi Chris, this patch makes the amdgpu ddx crash.
Also I think this is not the root cause of my problem.
The root cause is why Intel DDX allocated pixmap gets
pinned before DRI2UpdatePrime by compiz.

(In reply to Qiang Yu from comment #9)
> Hi Chris, this patch makes the amdgpu ddx crash.
> Also I think this is not the root cause of my problem.
> The root cause is why Intel DDX allocated pixmap gets
> pinned before DRI2UpdatePrime by compiz.

It's handling user request and we do not have the api to change the backing bo once assigned. (DRI2InvalidateDrawable). Don't blame the driver for being correct.

(In reply to Chris Wilson from comment #10)
> (In reply to Qiang Yu from comment #9)
> > Hi Chris, this patch makes the amdgpu ddx crash.
> > Also I think this is not the root cause of my problem.
> > The root cause is why Intel DDX allocated pixmap gets
> > pinned before DRI2UpdatePrime by compiz.
> 
> It's handling user request and we do not have the api to change the backing
> bo once assigned. (DRI2InvalidateDrawable). Don't blame the driver for being
> correct.

You mean the client side should handle this problem?
Or XServer?

Finally it comes out the problem of Mesa not handling the
DRI2InvalidateBuffers event after SharePixmapToSlave().
https://patchwork.freedesktop.org/patch/92533/

Thanks for your help, Chris.

Fixed by Michel in Mesa.