Did this only affect g965?  Since these are all vertex shader tests, it seems like it should have affected other vec4 vertex shader GPUs.  g965 and G45 did have additional limitations about the use of source modifiers with certain kinds of instructions, so it could be related to that.

Created attachment 119235 [details]
Before

INTEL_NO_HW=true INTEL_DEVID_OVERRIDE=0x29A2 INTEL_DEBUG=vs mesa master ./glcts --deqp-case=ES2-CTS.gtf.GL.exp.exp_float_vert_xvaryneg > /tmp/exp_float_vert_xvaryneg-before.txt 2>&1

Created attachment 119236 [details]
After

INTEL_NO_HW=true INTEL_DEVID_OVERRIDE=0x29A2 INTEL_DEBUG=vs mesa master ./glcts --deqp-case=ES2-CTS.gtf.GL.exp.exp_float_vert_xvaryneg > /tmp/exp_float_vert_xvaryneg-after.txt 2>&1

(In reply to Ian Romanick from comment #1)
> Did this only affect g965?  Since these are all vertex shader tests, it
> seems like it should have affected other vec4 vertex shader GPUs.  g965 and
> G45 did have additional limitations about the use of source modifiers with
> certain kinds of instructions, so it could be related to that.

The following platforms were tested:
bdw bsw byt g33 g45 g965 hsw ilk ivb skl snb

Only g965 fails these tests.

For example, g45:
http://otc-mesa-ci.jf.intel.com/job/Leeroy/229701/testReport/piglit.es2-cts.gtf.gl/exp/exp_float_vert_xvaryneg_g45m64/

The tests are reported daily, eg:
http://otc-mesa-ci.jf.intel.com/job/mesa_master_daily/1569/

Each of those output files contains two shaders.  The first is the actual test, and the second generates the reference image.  That is why the tests say they pass... since it's not running on hardware, both just generate black.  Since they're the same, the test passes.

Looking at the diff (I like diff --side-by-side -W 220 exp_float_vert_xvaryneg-before.txt exp_float_vert_xvaryneg-after.txt), the only significant change I can see is the before assembly doesn't depend on any of the old values in the other components of the math result register:

mov(8)          m5<1>.yzUD      0x00000000UD                    { align16 NoDDClr };
mul(8)          g5<1>.xF        -g3<4,4,1>.xF   4.32808F        { align16 };
mov(8)          g7<1>UD         0x00000000UD                    { align16 };
mov(8)          m5<1>.wD        1065353216D                     { align16 NoDDChk };
send(8) 1       g5<1>.xF        g5<4,4,1>.xF
                            math exp mlen 1 rlen 1                          { align16 };
mov(8)          m5<1>.xD        g5<4,4,1>.xD                    { align16 };

And no other part of g5 is write before being written again.  I don't know of that actually matters.

Mark: There is a method to have the gles2conform tests dump result image files, but you have to actually have hardware to do that.  Would it be possible for you to collect just the "after" images for us?

I'll take a look.

(In reply to Ian Romanick from comment #5)
> Mark: There is a method to have the gles2conform tests dump result image
> files, but you have to actually have hardware to do that.  Would it be
> possible for you to collect just the "after" images for us?

Never mind.

This is a known issue on g965 and 965gm.  There is no destination write hazard detection for send messages.  As a result, a sequence like

mov(8)          g5<1>.wD        1065353216D                     { align16 };
send(8) 1       g5<1>.xF        g6<4,4,1>.xF
                            math exp mlen 1 rlen 1                          { align16 };
mov(8)          m5<1>F          g5<4,4,1>F                      { align16 };

will cause the final mov to execute as soon as the first mov is complete... even though the send is not done.  The generator will just need to account for this.  This leads me to believe that this is an existing bug in the NIR vec4 backend, and Jason's change just caused these tests to tickle it.

(In reply to Ian Romanick from comment #7)
> will cause the final mov to execute as soon as the first mov is complete...
> even though the send is not done.  The generator will just need to account
> for this.  This leads me to believe that this is an existing bug in the NIR
> vec4 backend, and Jason's change just caused these tests to tickle it.

It's actually a known bug in vec4 in general.  We have a piglit test that tickles it with the old compiler as well.  As matt said in the e-mail, we need send dependency work-arounds.  We already have them in the FS, it just needs to be ported over.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1500.