Assigning to Mika for fun.

Hi lili, what BDW stepping are you using?

(In reply to comment #2)
> Hi lili, what BDW stepping are you using?

Both BDW-GT2-E2 and BDW-GT2-F0 two SKUs have this issue, they are using the same CPU stepping: stepping 4
Detail BDW-GT2-E2 CPU info: E2 2.1GHz 2Cores/4Thread 4 QGZ9 (Processor number: i3-5010U) 
Detail BDW-GT2-F0 CPU info: F0 i5-5500U 2.4GHz 2Cores/4Thread 4 QQC5

(In reply to comment #2)
> Hi lili, what BDW stepping are you using?

Hi Vivi,
please refer to reproduce steps:
---------------------------------------------
1.	xinit&
2.	vblank_mode=0 ./smokinguns.x86_64 +set r_fullscreen 1 +timedemo 1 +set demodone "quit" +set demoloop1 "demo pts; set nextdemo vstr demodone" +vstr demoloop1 +setr_customwidth 1920 +set r_customheight 1080

(In reply to comment #0)
> Bug detailed description:
> ---------------------------------------------
> Smokin-Guns v1.1 and urbanterror v4.1 performance reduced ~15% on BDW.This
> problem exist both on gnome-session and Raw X,it doesn't exist on
> IVB/HSW/BYT-M.
> It's kernel (drm-intel-next-queued)regression,bisect result first bad commit
> is:
> commit d37cf5f7e1b315585940a735a8508d955ffc0f16
> Author:     Mika Kuoppala <mika.kuoppala@linux.intel.com>
> AuthorDate: Fri Sep 19 20:05:26 2014 +0300
> Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
> CommitDate: Wed Sep 24 10:38:41 2014 +0200
> 
>     drm/i915/bdw: Cleanup pre prod workarounds
> 

This patches resolves bug#83482. Do we see that improvement on this machine?

(In reply to comment #5)
> (In reply to comment #0)
> > Bug detailed description:
> > ---------------------------------------------
> > Smokin-Guns v1.1 and urbanterror v4.1 performance reduced ~15% on BDW.This
> > problem exist both on gnome-session and Raw X,it doesn't exist on
> > IVB/HSW/BYT-M.
> > It's kernel (drm-intel-next-queued)regression,bisect result first bad commit
> > is:
> > commit d37cf5f7e1b315585940a735a8508d955ffc0f16
> > Author:     Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > AuthorDate: Fri Sep 19 20:05:26 2014 +0300
> > Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
> > CommitDate: Wed Sep 24 10:38:41 2014 +0200
> > 
> >     drm/i915/bdw: Cleanup pre prod workarounds
> > 
> 
> This patches resolves bug#83482. Do we see that improvement on this machine?

This patches did resolved bug#83482 issue, and it's pushed into commit d37cf5, this commit is culprit of bug#84444 by bisect. Otherwise bug#83482 && bug#84444 are not related. 

Developers show make sure whether their's patch cause bug#84444 exist.

Created attachment 107188 [details] [review]
drm/i915/bdw: Enable single subspan dispatch

Patch for testing. However we need more broad testing to be sure that this patch doesn't make things worse on other workloads.

(In reply to Mika Kuoppala from comment #8)
> Patch for testing. However we need more broad testing to be sure that this
> patch doesn't make things worse on other workloads.

This issue has been fixed with this patch,about if this patch will make things worse on other workloads,I will verify it and update the result later.

(In reply to lili from comment #9)
> (In reply to Mika Kuoppala from comment #8)
> Patch for testing. However we
> need more broad testing to be sure that this
> patch doesn't make things
> worse on other workloads.

This issue has been fixed with this patch,about
> if this patch will make things worse on other workloads,I will verify it and
> update the result later.

Installing the patch, the issue is fixed. I have run other cases and there is no big change compared to before test results.

pls help merge up the patch, thanks.

(In reply to lili from comment #10)
> This issue has been fixed with this patch

This was a test patch, not necessarily a fix.  Performance should be *in general* better with the multiple subspans (current state), but there can be corner-cases where single subspan (the attached patch) happens to provide a bit better performance.


>> about
>> if this patch will make things worse on other workloads,I will verify it and
>> update the result later.
> 
> Installing the patch, the issue is fixed. I have run other cases and there
> is no big change compared to before test results.

This is unexpected result.  Did you run all tests, or just a subset of them?

(In reply to Eero Tamminen from comment #12)
> (In reply to lili from comment #10)
> > This issue has been fixed with this patch
> 
> This was a test patch, not necessarily a fix.  Performance should be *in
> general* better with the multiple subspans (current state), but there can be
> corner-cases where single subspan (the attached patch) happens to provide a
> bit better performance.
> 
> 
> >> about
> >> if this patch will make things worse on other workloads,I will verify it and
> >> update the result later.
> > 
> > Installing the patch, the issue is fixed. I have run other cases and there
> > is no big change compared to before test results.
> 
> This is unexpected result.  Did you run all tests, or just a subset of them?


1.We tested some cases and found there is no big change before.

2.This time we installed the patch and tested all of the cases. The performance of the most cases are worse than that without patch,(for exzample:case unigine-sanctuary,reduced ~47%,Half_Life 2 reduced ~137%,....),and minor cases are better.

(In reply to lili from comment #13)
> 2.This time we installed the patch and tested all of the cases. The
> performance of the most cases are worse than that without patch,(for
> exzample:case unigine-sanctuary,reduced ~47%,Half_Life 2 reduced
> ~137%,....),and minor cases are better.

Sanctuary shaders won't get anymore compiled with Mesa, so any results with that can be ignored and how one can get >100% performance drop in a test?

(In reply to Eero Tamminen from comment #14)
> (In reply to lili from comment #13)
> > 2.This time we installed the patch and tested all of the cases. The
> > performance of the most cases are worse than that without patch,(for
> > exzample:case unigine-sanctuary,reduced ~47%,Half_Life 2 reduced
> > ~137%,....),and minor cases are better.
> 
> Sanctuary shaders won't get anymore compiled with Mesa, so any results with
> that can be ignored and how one can get >100% performance drop in a test?

Hi Eero, I sent you the full compare test result for the Mika's patch, and base on the each benchmark single cycle test result, we did see after applied Mika's patch, some case did show less than 1/2 FPS vs. without apply patch.
such as: 
Half_Life 2
GLBenchmark v2.7.0 FillTestC24Z16
GLBenchmark v2.7.0 FillTestC24Z16_Offscreen
SynMark2_v6_0_OglFillTexMulti
SynMark2_v6_0_OglPSPhong

According to your data, there were couple of cases where performance improved up to 10-30% (smoking guns, urban terror, TF2, zbuffer), with the attached test patch.

However, (as expected), it reduced performance in many more tests and the difference was *much* larger, up to >70% percent (in GLB fill test and sampler bound pixel shader test).

Based on your data, this bug should be closed as WONTFIX.

(ZBuffer being better with single span is a bit worrying, as its performance isn't currently quite what it should be.)

On basis of current performance measurements, the net gain is not positive.
Marking as wontfix. Please reopen if you disagree/have contradicting evidence.