Bug 63435

I totally forgot my software and hardware specs:
I am using Debian testing with a self-compiled vanilla 3.8.5 kernel. Other than that, I use the distribution packages. My GPU is the one built-in my Core i5-2450M (Sandy Bridge), I believe that's an HD2000.

In the mean time, I added a GLES2 version of my test program to the repositories, which shows the same flickering issue.

This bug also breaks KWin on top of EGL when v-sync is enabled:
https://bugs.kde.org/show_bug.cgi?id=318212

Current master (b42fe195) still exhibits this problem, which effectively renders full-screen EGL applications using v-sync unusable (no matter whether they use OpenGL or OpenGLES). The erroneous behaviour was observed with KWin and a simple EGL test application, both with an Intel GPU and on a Radeon GPU.

The patch uncovering this issue ended up in Mesa 9.1.3. This means that full-screen EGL applications attempting to use v-sync are unusable with the current stable Mesa release.
Why is it that nobody cares about this bug, which breaks an entire GL window system?

I can confirm this bug, and that reverting Eric's patch does fix it.  I don't know if that's the right thing to do or not.

Eric, Chad, would one of you please take a look?

Patch incoming to list (mostly a revert)

(Oh, and re: "why doesn't anyone care", it was mostly that it wasn't in my regular bug search that just covers the intel drivers.)

I just checked mesa-dev for the patch Eric mentioned he was planning to send, but couldn't find it (it is a monday morning so i might have missed it)? Doesn't look like a fix hit mesa master either ;/

Even Debian (testing) updated to an affected version (mesa 9.1.4) by now, so EGL v-sync is broken for pretty much most users out there.

(In reply to comment #7)
> (Oh, and re: "why doesn't anyone care", it was mostly that it wasn't in my
> regular bug search that just covers the intel drivers.)
I used the "Other" component as I found no "EGL" component - and the issue really is not driver-specific. However, an "EGL" component exists by now, so I moved the bug there.

This should be fixed by 0e9549e on master.  Could you verify that?

No, it shouldn't be fixed by that, since the reverted commit didn't exist when the bug was reported.

The fix is:

Message-Id: <1371854092-13343-1-git-send-email-eric@anholt.net>

which I sent out a month ago, and pinged on IRC about again after I left, but I don't have the facilities to test and push from here.  Oh, looks like it never hit the list.  I've forwarded it again.

Indeed the issue persist in current master.

Fixed in master by:

commit eed0a80137dfac641adfd39ce316938dbcf2be10
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Jun 21 15:34:52 2013 -0700

    egl: Restore "bogus" DRI2 invalidate event code.
    
    I had removed it in commit 1e7776ca2bc59a6978d9b933d23852d47078dfa8
    because it was obviously wrong -- why do we care whether the server is a
    version that emits events, if we're not watching for the server's events,
    anyway?  And why would you only invalidate on a server that emits
    invalidate events, when the comment said to emit invalidates if the server
    *doesn't*?  Only, I missed that we otherwise don't flag that our buffers
    might have changed at swap time at all, so the driver was only checking
    for new buffers when triggered by the Viewport hack.  Of course you don't
    expect Viewport to be called after a swap.
    
    So, this is effectively a revert of the previous commit, except that I
    dropped the check for only emitting invalidates on a new server -- we
    *always* need to invalidate if we're doing a SwapBuffers.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63435
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Cc: "9.1 and 9.2" <mesa-stable@lists.freedesktop.org>

Hopefully Carl can merge it to the 9.2 and 9.1 branches soon.

I can confirm the issue is fixed, thanks a lot :)