Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9

Chiou, Cooper
2021-03-11T01:27:10Z

> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Hi,
>
> On 08/03/2021 17:32, Chiou, Cooper wrote:
> > I've tested on GLK, KBL, CFL Intel NUC devices and got the following
> performance results, there is no performance regression per my testing.
> >
> > Patch: [v5] drm/i915: Enable
> > WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 Test suite:
> > phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranPa
> > radisoIsland.frames_per_second
> > Kernel version: 5.12.0-rc1 (drm-tip)
> >
> > a. Device: Intel NUC kit NUC7JY Gemini Lake Celeron J4005 @2.7GHz (2
> Cores)
> > Without patch, fps=57.45
> > With patch, fps=57.49
> > b. Device: Intel NUC kit NUC8BEH Coffee Lake Core i3-8109U @3.6GHz(4
> Cores)
> > Without patch, fps=117.23
> > With patch, fps=117.27
> > c. Device: Intel NUC kit NUC7i3BNH Kaby Lake Core i3-7100U @2.4GHz(4
> Cores)
> > Without patch, fps=114.05
> > With patch, fps=114.34
> >
> > Meanwhile, Intel lkp team has validated performance on lkp-kbl-nuc1 and
> no regression.
> > f69d02e37a85645a d912096c40cdc3bc9364966971
> > testcase/testparams/testbox
> > ---------------- -------------------------- ---------------------------
> > %stddev change %stddev
> > \ | \
> > 29.79 29.67
> > phoronix-test-suite/performance-true-Fullscreen-Ultimate-1-
> Gran_Paradiso_Island__Approxima-supertuxkart-1.5.2-ucode=0xde/lkp-kbl-
> nuc1
> > 29.79 29.67 GEO-MEAN phoronix-test-
> suite.supertuxkart.1280x1024.Fullscreen.Ultimate.1.GranParadisoIsland.fram
> es_per_second
> >
>
> CI results are green so that is good.
>
> Do the machines used for performance testing include unusual fusing?
[Chiou, Cooper] Yes, this performance test included fusing sku as following NUC GLK Celeron Linux device,
Intel NUC kit NUC7JY Gemini Lake Celeron J4005 @2.7GHz (2 Cores)
Without patch, fps=57.45
With patch, fps=57.49

> Worrying thing is that we were never able to reproduce the reported regression in house due lack of identical machine, right?
[Chiou, Cooper] Yes, if device is core-i3/5/7 GT2, then hang issue isn’t able to reproduce due to there is no fused/disabled subslice0.

But VP8 hw encoding GPU hang issue can be 100% reproduced on CML/KBL Pentium/Celeron GT1 sku,
explain root cause as the following,
on Chrome CML Pentium 6450u GT1 sku, we observed when system exit PC7 power state, MGSR(0xFDC) is reset to 0x10000000,
read its reg(fuse2:0x9120)=0x02988480 bit 20-23=1001 means subslice0/3 are fused disabled, it's defined in bspec as well.
on CML core-i5 sku, reg(fuse2)=0x22889140 bit 20-23=1000 only subslice3 is fused.

so we have to skip this "fused/disabled" subslice 0/3 on GT1 sku in i915, then use sublice 1 or 2 and re-program 0xFDC=0x11000000 or 0x12000000
since reg[0xfdc]=0x10000000 to use subslice0, but sublice0 is fused/disabled, so once go this fused disabled subslice0 then GPU hang happened.

In some OEM Linux projects, they only have core-i sku no Pentium/Celeron sku as I knew and vp8 hw encoding is rare to use on Ubuntu,
as this two reasons then Linux didn't reproduce this fused subslice0 gpu hang issue before, but it does happen on Chrome projects.

Cooper

> Worrying thing is that we were never able to reproduce the reported
> regression in house due lack of identical machine, right? Although I guess
> avoiding hangs trumps performance.
>
> Regards,
>
> Tvrtko