Bug 83127

Also bisect it on master branch, Bisect shows: a6860100b87415ab510d0d210cabfeeccebc9a0a is the first bad commit.
commit a6860100b87415ab510d0d210cabfeeccebc9a0a
Author: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Date:   Fri Mar 28 15:28:33 2014 +0200

    i965/fs: Change fs_visitor::emit_lrp to use MAC for gen<6

    This allows us to emit ADD/MUL/MAC instead of MUL/ADD/MUL/ADD,
    saving one instruction and two temporary registers.

    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

We add --quick in recently, the result is fail. On our earlier testing, We ran bin/glean -o -v -v -v -t +texCombine but not add --quick, the result was always timeout, So we didn't see this regression in time.

CC JP

We reverted that commit (a fair bit later), so it can't be the cause of the failure in master today.

Hi Ken,
I retest it on master branch.
Test on commit c2c639ecf667b4b7cf17cfe33dfe710432f2c43a(Revert commit)
Author: Matt Turner <mattst88@gmail.com>
Date:   Thu May 22 09:39:13 2014 -0700

    Revert "i965/fs: Change fs_visitor::emit_lrp to use MAC for gen<6"

    This reverts commit a6860100b87415ab510d0d210cabfeeccebc9a0a.

    Why this code didn't work in all circumstances is unknown and without a
    working Ironlake simulator (which uses a different AUB format) we'll
    probably never know, short of a lot of experimentation, and spending a
    bunch of time to try to optimize a few instructions on Ironlake is not
    time well spent.

    Moreover, for mix(vec4, vec4, vec4) using the accumulator introduces a
    dependence between the otherwise independent per-component calculations.
    Not using the accumulator, even if it means an extra instruction per
    component might be preferable. We don't know, we don't have data, and
    we don't have the necessary register on Ironlake for shader_time to tell
    us.

    Cc: "10.2" <mesa-stable@lists.freedesktop.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77707
    Acked-by: Kenneth Graunke <kenneth@whitecape.org>

[root@x-pk5 piglit]# bin/glean -o -v -v -v -t +texCombine --quick
----------------------------------------------------------------------
GL_EXT_texture_env_combine verification test.
We only test a subset of all possible texture env combinations
because there's simply too many to exhaustively test them all.

Segmentation fault (core dumped)

This segfault caused by commit f0f7fb181fc267934a44904da4530f50a698b18d. Revert this commit, then test commit c2c639ecf667b, it still fails.
output:
----------------------------------------------------------------------
GL_EXT_texture_env_combine verification test.
We only test a subset of all possible texture env combinations
because there's simply too many to exhaustively test them all.

texCombine:  FAIL rgba8, db, z24, s8, win+pmap, id 32
        expected 1, 0, 0.25, 0.5, got 1, 0, 0.247059, 0 in Single Texture Test
        Current combine state:
        Incoming Fragment RGBA = 0, 0.25, 0.5, 0.75
        Texture Unit 0:
          GL_COMBINE_RGB_EXT = GL_INTERPOLATE_EXT
          GL_COMBINE_ALPHA_EXT = GL_INTERPOLATE_EXT
          GL_SOURCE0_RGB_EXT = GL_TEXTURE
          GL_SOURCE1_RGB_EXT = GL_TEXTURE
          GL_SOURCE2_RGB_EXT = GL_TEXTURE
          GL_SOURCE0_ALPHA_EXT = GL_TEXTURE
          GL_SOURCE1_ALPHA_EXT = GL_TEXTURE
          GL_SOURCE2_ALPHA_EXT = GL_TEXTURE
          GL_OPERAND0_RGB_EXT = GL_SRC_COLOR
          GL_OPERAND1_RGB_EXT = GL_SRC_COLOR
          GL_OPERAND2_RGB_EXT = GL_SRC_ALPHA
          GL_OPERAND0_ALPHA_EXT = GL_SRC_ALPHA
          GL_OPERAND1_ALPHA_EXT = GL_SRC_ALPHA
          GL_OPERAND2_ALPHA_EXT = GL_SRC_ALPHA
          GL_RGB_SCALE_EXT = 1
          GL_ALPHA_SCALE = 1
          Tex Env RGBA = 0.25, 0.5, 0.75, 1
          Texture RGBA = 1, 0, 0.25, 0.5

Maybe it has the 2 bad commits between da0c3b02e71c7552ba9324a01a73602094105fcc and c2c639ecf667b4b7cf17cfe33dfe710432f2c43a ?

Since the release is coming up quickly... can someone with an ILK:

1. Rebase a temporary branch of master that actually deletes the commit below and its revert.

2. Verify that the crash happens in that case (it seems like it should).

3. Bisect again to see what the new breaking point is.

At the very least, could someone post a 'bt -full' from the crash on current master or 10.3 branch?

Test on b5fd762474fb7252e7e1158e6398c10f1a035b1a and revert a6860100b8, It's fail.
Test on 9bcb3698db98fe0ffc7bd6619b8324f13b3b67d2 and revert a6860100b8, It's pass.
Bisect is in process(each step revert a6860100b8).

(In reply to comment #6)
> Test on b5fd762474fb7252e7e1158e6398c10f1a035b1a and revert a6860100b8, It's
> fail.
> Test on 9bcb3698db98fe0ffc7bd6619b8324f13b3b67d2 and revert a6860100b8, It's
> pass.
> Bisect is in process(each step revert a6860100b8).

afe3d1556f6b77031f7025309511a0eea2a3e8df is the first bad commit
commit afe3d1556f6b77031f7025309511a0eea2a3e8df
Author: Eric Anholt <eric@anholt.net>
Date:   Tue May 6 15:19:55 2014 -0700

    i965: Stop doing remapping of "special" regs.

    Now that we aren't using pixel_[xy] in live variables, nothing is looking
    at these regs after the visitor stage.

    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Ouch.  Thanks for that bisect.

I was originally suspicious because Matt later fixed regressions caused by Eric's commit...but he apparently didn't fix it completely.  Whoops. :(

Patch incoming as soon as I run it through Piglit.

Should be fixed by:
http://lists.freedesktop.org/archives/mesa-dev/2014-September/067716.html

Wendy is in annual leave during Sep 13---Sep23, no email response, if any emergency, pls call my cell phone: 13764652249

Thanks!

(In reply to comment #9)
> Should be fixed by:
> http://lists.freedesktop.org/archives/mesa-dev/2014-September/067716.html

Fixed by this patch.

commit 78bd12619474e98503965541c61c5d7e9c408110
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Fri Sep 12 17:45:30 2014 -0700

    i965: Mark delta_x/y as BAD_FILE if remapped away completely.
    
    Commit afe3d1556f6b77031f7025309511a0eea2a3e8df (i965: Stop doing
    remapping of "special" regs.) stopped remapping delta_x/delta_y, and
    additionally stopped considering them always-live.  We later realized
    delta_x was used in register allocaiton, so we actually needed to remap
    it, which was fixed in commit 23d782067ae834ad53522b46638ea21c62e94ca3
    (i965/fs: Keep track of the register that hold delta_x/delta_y.).
    
    However, that commit didn't restore the "always consider it live" part.
    If all the code using delta_x was eliminated, fs_visitor::delta_x would
    be left pointing at its old register number.  Later code in register
    allocation would handle that register number specially...even though it
    wasn't actually delta_x.
    
    To combat this, set delta_x/y to BAD_FILE if they're eliminated, and
    check for that.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83127
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Cc: "10.3" <mesa-stable@lists.freedesktop.org>

Verified,fixed.