Bug 67934

It also happens on ivybridge and haswell.

This patch exists on master and 9.2.  I don't think the bisect is correct.

Bisect it again.
a3f48d97cd0ea679f35e39176c4d8b960151e627 is the first bad commit
commit a3f48d97cd0ea679f35e39176c4d8b960151e627
Author:     Eric Anholt <eric@anholt.net>
AuthorDate: Fri Jun 21 15:34:52 2013 -0700
Commit:     Ian Romanick <ian.d.romanick@intel.com>
CommitDate: Mon Aug 5 17:07:15 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>
    (cherry picked from commit eed0a80137dfac641adfd39ce316938dbcf2be10)

Created attachment 84044 [details]
output

Created attachment 84159 [details]
Test logs on Ivybridge

Reproduced the failure on Ivybridge. Test passes most of the times when run with -minfmt option. I also confirm that the observed failure is triggered by the bisected commit (a3f48d9). I have no understanding of dri2 related changes in bisected commit. It seems like running the test continuously without much delay triggers the failure. Running test without -minfmt exactly does that.

I have verified Lu Hua's bisect to

commit a3f48d97cd0ea679f35e39176c4d8b960151e627
Author:     Eric Anholt <eric@anholt.net>
AuthorDate: Fri Jun 21 15:34:52 2013 -0700
Commit:     Ian Romanick <ian.d.romanick@intel.com>
CommitDate: Mon Aug 5 17:07:15 2013 -0700

    egl: Restore "bogus" DRI2 invalidate event code.

using 

   cmd: ./GTF -width=64 -height=64 -run=GL2Tests/glUniform/glUniform.test
   haswell
   archlinux x86-64
   xorg-server-1.14.2-2
   gnome-shell-3.8.4-1 (with compositing enabled)

The test fails intermittently with a failure rate of approximately 5%.

I observed no failures when replacing gnome-shell with either
  - openbox, no compositing
  - openbox, with xcompmgr as compositor

Between commits during the bisect, I installed a proper Mesa package and restarted X, to ensure that the X server and GTF were using the same Mesa.

Paul is the resident expert on inconsistent test failures due to DRI2 bugs. Maybe he has a clue, because I sure don't.

Paul, I recall that you submitted DRI2 fixes to the X server. Are your fixes present in xorg-server-1.14.2? Are your fixes relevant to this bug?

Paul, this bug bisects to a commit on the 9.2 branch that alters DRI2 behavior. And, you are our resident expert on erratic test failure due to DRI2 bugs.

I recall that you submitted DRI2 fixes to the X server. Are your fixes present in xorg-server-1.14.2? Are your fixes relevant to this bug, or the bisected commit?

(In reply to comment #7)
> Paul, this bug bisects to a commit on the 9.2 branch that alters DRI2
> behavior. And, you are our resident expert on erratic test failure due to
> DRI2 bugs.
> 
> I recall that you submitted DRI2 fixes to the X server. Are your fixes
> present in xorg-server-1.14.2? Are your fixes relevant to this bug, or the
> bisected commit?

It was actually Eric who submitted fixes to the X server, and his fixes landed (see xserver commit 77e51d5bbb97eb5c9d9dbff9a7c44d7e53620e68).  I don't know if that commit is relevant or not.

Here's what I discovered in my testing this morning:

- Checking out master and reverting a3f48d97cd0ea679f35e39176c4d8b960151e627 causes Mesa to avoid querying the X server for new buffers after a swap.  For some reason this makes the problem go away (although it's definitely not a solution--that commit is necessary!).

- If I run the test with "-imagefileio" and look at  GL2Tests/glUniform/glUniformMatrix4fv_2loc_array_of_mat4_first_loc_no_transpose_second_loc_no_transpose_vert_64x64.{good,output,diff}.ppm I can see that the quad that was rendered looks fine, but the background of the image (the clear color) shows up different.

- When drawing both the "good" and "output" images, the clear color is set to (0.1, 0.2, 0.3).  However, the clear color that actually gets drawn in the "good" case is (0.349, 0.482, 0.584).  This is what you would get if you sRGB encoded (0.1, 0.2, 0.3).

- Disabling fast color clears has no effect on the problem.

- Disabling the blorp color clear path makes the problem go away.


From this I'm inferring that:

(a) When Mesa receives a new buffer from the X server, somehow that is causing some piece of sRGB state to change.

(b) The blorp color clear path uses that state to decide whether to sRGB encode the clear color.  The meta path doesn't.


I still haven't figured out:

- Which piece of sRGB state is changing?

- Should it be changing or not?

- Should color clears use that piece of state to decide whether to sRGB encode the clear color?

I solved the bug.

The first call to glClear believes the buffer is SARGB. If the X server later re-allocates the color buffer, then later calls to glClear believe the buffer is ARGB.

The driver changes the renderbuffer's format from SARGB to ARGB during the first call to eglMakeCurrent. This works around a quirk in GLES3. The bug rootcause is that the driver applies the workaround too late, *after* the renderbuffer's miptree is already allocated.

The fix is to move the workaround (intel_gles3_srgb_workaround) up two lines, before the call to intel_prepare_render.

Patches will arrive on mesa-dev after they get regression tested.

Fixed by commit on master, and will be cherry-picked to 9.2.

commit ce8639a766d0c36e676eea6f55135d9dccf1cb90
Author: Chad Versace <chad.versace@linux.intel.com>
Date:   Tue Aug 20 17:36:24 2013 -0700

    i965: Fix misapplication of gles3 srgb workaround

Verified.Fixed.