A full-screen window rendered to via EGL using OpenGL flickers in current mesa master. The same application still works fine with the 9.0 branch. Steps to reproduce with my small egltest program (http://www.ralfj.de/git/gltest.git): * run "./egltest -o -i 1" * hit "F1" to enter-full-screen mode * now the screen flickers between the window content and my desktop In master since 7e9bd2b2, the commit 3998f8c6 needs to be cherry-picked so that swap interval can be set to 1. With swap interval 0, there is no flickering. Similarly, if I use a compositing window manager, there is no flickering. I did a regression test, which revealed the following commit to be the first bad one: commit 1e7776ca2bc59a6978d9b933d23852d47078dfa8 Author: Eric Anholt <eric@anholt.net> Date: Tue Sep 25 14:45:16 2012 -0700 egl: Remove bogus invalidate code. Reverting that commit (on top of current master) fixes the flickering. (I found no component for EGL, hence I chose "Other")
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 :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.