Please attach your Xorg.log from the DRI3 hedgewars session.

Hmm, has a definite feel to it that mesa/dri3 is rendering into the current scanout buffer.

Created attachment 126833 [details]
Xorg.log

The problem happens only if fullscreen is turned on in the game.

So what happens is we get a back-to-back glXSwapBuffers(); glXSwapBuffers(); and mesa submits the same pixmap for swapping twice and then loses track of when it is idle.

Fix https://cgit.freedesktop.org/~ickle/mesa/commit/?h=brw-batch&id=8ffee986f537888921716ab632236ea4c55fb0f1

*** Bug 97173 has been marked as a duplicate of this bug. ***

Hello Chris,

did you send this
https://cgit.freedesktop.org/~ickle/mesa/commit/?h=brw-batch&id=8ffee986f537888921716ab632236ea4c55fb0f1
in for review?

E.g. to Michel?
Maybe it solve this
https://bugs.freedesktop.org/show_bug.cgi?id=97260#c56
one , too?

(In reply to Dieter Nützel from comment #7)
> E.g. to Michel?
> Maybe it solve this
> https://bugs.freedesktop.org/show_bug.cgi?id=97260#c56
> one , too?

I'll take a look at Chris' patch once it's submitted for review with a proper rationale for all the changes. Meanwhile, for bug 97260 it would be more useful if somebody tested the patch I attached there.

Removing myself from Cc because I get notified of updates to this report via the mesa-dev mailing list.

Hi,

Has the patch stuck in review? 

The same problem appears with the modesetting driver. Besides, right now with mesa 17.0.1 when using DRI3 every movement on the screen seems blurred, both on windowed mode and fullscreen. This doesn't happen with DRI2, both with xf86-video-intel and modesetting.

Chris, are you planning to submit the fix for review?

Thomas, since you've been fixing DRI3 related issues, maybe you can take a look?

Created attachment 132276 [details] [review]
Patch to grab a new backbuffer if we're presenting a buffer that's already in the swap chain

It sounds to me like a back- to back SwapBuffers() is an application bug. The back buffer content is undefined after a SwapBuffers().

But we shouldn't present a back buffer that's already in the swap chain. Hence the attached patch.

Also, we should perhaps considering implementing and advertizing GLX_SWAP_COPY_OML and GLX_SWAP_EXCHANGE_OML on dri3. There seems to be apps relying on the GLX_SWAP_COPY_OML behavior. Among others glretrace playing back traces captured on WGL.

Actually, it seems that at least Gallium advertises GLX_SWAP_COPY_OML. But dri3 doesn't implemented it.

(In reply to Thomas Hellström from comment #13)
> It sounds to me like a back- to back SwapBuffers() is an application bug.
> The back buffer content is undefined after a SwapBuffers().

It is not undefined when the implementation supports EXT_buffer_age.

(In reply to Fredrik Höglund from comment #15)
> (In reply to Thomas Hellström from comment #13)
> > It sounds to me like a back- to back SwapBuffers() is an application bug.
> > The back buffer content is undefined after a SwapBuffers().
> 
> It is not undefined when the implementation supports EXT_buffer_age.

Well it may be for some buffers. Whether or not the app uses EXT_buffer_age correctly in this case doesn't really matter as there are apps out there that most certainly don't. Perhaps we can use a driconf option for such apps to restrict available swap methods.

But most importantly there is a mesa dri3 bug here. And looking closer at the code the glx/dri implementation of GLX_OML_swap_method appears utterly broken, so it will take some time to fix.

I'm working on a solution to the dri3 bug as well as a dri3 client side implementation of GLX_OML_swap_method.

Created attachment 132422 [details] [review]
Patch to grab a new backbuffer if we're presenting a buffer that's already in the swap chain

Here's a fixed version of Thomas' patch which fixes this problem for me.

Created attachment 132424 [details]
attachment-12843-0.html

Hi!

I'm on vacation and will be back on Monday July 31st. For vmware linux graphics driver issues, please contact
<linux-graphics-maintainer@vmware.com>

Thanks,
Thomas Hellström

Thanks for the report, fixed in Git master:

Module: Mesa
Branch: master
Commit: 81fb1547772d42c527318837d4207ecdb6899e5d
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=81fb1547772d42c527318837d4207ecdb6899e5d

Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Tue Jul  4 12:55:15 2017 +0900

loader/dri3: Use dri3_find_back in loader_dri3_swap_buffers_msc

Thanks for fixing! I had a similar problems when using the modesetting driver, I'll check if it's gone when this gets into a release. 

For completeness, I describe how the modesetting driver behaves with mesa : whenever running Hedgewars with DRI3 enabled, I has a little screen tearing and the display is blurry when moving around the cursor (moving around the battlefield in the game). Disabling DRI3 (falling back to DRI2) fixed all problems and the display was smooth again.
This happens even when running the game within a DE.

Please don't reopen a bug report without justification.

I ran the S3(the computer suspends into memory) test 500 times and my Linux system crashed,an abnormal image appears on the monitor,But it happened by accident
In the five test, the system died 3 times and passed 2 times
Error: [780]: segfault at a0 IP 00007fdd98671e sp 00007ffea5328810 error 4 in radeonsi_dri. So [7fdd9f287000+93c000]

Has the problem been solved
Thank you...!

I ran the S3(the computer suspends into memory) test 500 times and my Linux system crashed,an abnormal image appears on the monitor,But it happened by accident
In the five test, the system died 3 times and passed 2 times
Error: [780]: segfault at a0 IP 00007fdd98671e sp 00007ffea5328810 error 4 in radeonsi_dri. So [7fdd9f287000+93c000]

Has the problem been solved
Thank you...!

(In reply to 赵九胤 from comment #24)
> I ran the S3(the computer suspends into memory) test 500 times and my Linux
> system crashed, [...]

That doesn't sound related to this bug report at all. Please file your own report.