All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
@ 2019-04-15 14:16 Ville Syrjala
  2019-04-15 15:02 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
                   ` (6 more replies)
  0 siblings, 7 replies; 15+ messages in thread
From: Ville Syrjala @ 2019-04-15 14:16 UTC (permalink / raw)
  To: intel-gfx; +Cc: Eero Tamminen

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Since SKL the eLLC has been sitting on the far side of the system
agent, meaning the display engine can utilize it. Let's enable that.

I chose WB for the caching mode, because my numbers are indicating
that WT might actually be WB and WC might actually be UC. I'm not
100% sure that is indeed the case but at least my simple rendercopy
based benchmark didn't see any difference in performance.

Also if I configure things to do LLCeLLC+WT I still get cache dirt
on my screen, suggesting that is in fact operating in WB mode
anyway. This is also the reason I had to fix the MOCS target cache
to really say PTE rather than LLC+eLLC.

Caveat: I've not benchmarked any real workloads. IIRC Eero did
benchmark an earlier version, but that didn't have the PTE vs.
LLC+eLLC MOCS fix so it wasn't actually doing the right thing
most likely.

Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h     | 3 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++++--
 drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
 drivers/gpu/drm/i915/intel_mocs.c   | 2 +-
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35d0782c077e..2a4f33fa2bba 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2517,8 +2517,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_LLC(dev_priv)	(INTEL_INFO(dev_priv)->has_llc)
 #define HAS_SNOOP(dev_priv)	(INTEL_INFO(dev_priv)->has_snoop)
 #define HAS_EDRAM(dev_priv)	((dev_priv)->edram_size_mb)
-#define HAS_WT(dev_priv)	((IS_HASWELL(dev_priv) || \
-				 IS_BROADWELL(dev_priv)) && HAS_EDRAM(dev_priv))
+#define HAS_WT(dev_priv)	HAS_EDRAM(dev_priv)
 
 #define HWS_NEEDS_PHYSICAL(dev_priv)	(INTEL_INFO(dev_priv)->hws_needs_physical)
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8f460cc4cc1f..038fbf52a997 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3071,7 +3071,7 @@ static void cnl_setup_private_ppat(struct intel_ppat *ppat)
 
 	__alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC);
 	__alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
-	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
+	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
 	__alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC);
 	__alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
 	__alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1));
@@ -3109,7 +3109,10 @@ static void bdw_setup_private_ppat(struct intel_ppat *ppat)
 
 	__alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC);      /* for normal objects, no eLLC */
 	__alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);  /* for something pointing to ptes? */
-	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);  /* for scanout with eLLC */
+	if (INTEL_GEN(ppat->i915) >= 9)
+		__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE); /* for scanout with eLLC */
+	else
+		__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); /* for scanout with eLLC */
 	__alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC);                      /* Uncached objects, mostly for scanout */
 	__alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
 	__alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
index f597f35b109b..47adc7268867 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -139,7 +139,7 @@ typedef u64 gen8_ppgtt_pml4e_t;
 #define PPAT_UNCACHED			(_PAGE_PWT | _PAGE_PCD)
 #define PPAT_CACHED_PDE			0 /* WB LLC */
 #define PPAT_CACHED			_PAGE_PAT /* WB LLCeLLC */
-#define PPAT_DISPLAY_ELLC		_PAGE_PCD /* WT eLLC */
+#define PPAT_DISPLAY_ELLC		_PAGE_PCD /* WT LLCeLLC (HSW/BDW) or WB eLLC (SKL+) */
 
 #define CHV_PPAT_SNOOP			(1<<6)
 #define GEN8_PPAT_AGE(x)		((x)<<4)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c b/drivers/gpu/drm/i915/intel_mocs.c
index 274ba78500c0..d984ccff94ef 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -115,7 +115,7 @@ struct drm_i915_mocs_table {
 		   LE_1_UC | LE_TC_2_LLC_ELLC, \
 		   L3_1_UC), \
 	MOCS_ENTRY(I915_MOCS_PTE, \
-		   LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3), \
+		   LE_0_PAGETABLE | LE_TC_0_PAGETABLE | LE_LRUM(3), \
 		   L3_3_WB)
 
 static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
-- 
2.21.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 14:16 [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
@ 2019-04-15 15:02 ` Patchwork
  2019-04-15 15:03 ` ✗ Fi.CI.SPARSE: " Patchwork
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 15+ messages in thread
From: Patchwork @ 2019-04-15 15:02 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Enable eLLC caching of display buffers for SKL+
URL   : https://patchwork.freedesktop.org/series/59502/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f13e05007cae drm/i915: Enable eLLC caching of display buffers for SKL+
-:63: WARNING:LONG_LINE_COMMENT: line over 100 characters
#63: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:3113:
+		__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE); /* for scanout with eLLC */

-:65: WARNING:LONG_LINE_COMMENT: line over 100 characters
#65: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:3115:
+		__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); /* for scanout with eLLC */

total: 0 errors, 2 warnings, 0 checks, 44 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* ✗ Fi.CI.SPARSE: warning for drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 14:16 [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
  2019-04-15 15:02 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
@ 2019-04-15 15:03 ` Patchwork
  2019-04-15 15:21 ` ✓ Fi.CI.BAT: success " Patchwork
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 15+ messages in thread
From: Patchwork @ 2019-04-15 15:03 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Enable eLLC caching of display buffers for SKL+
URL   : https://patchwork.freedesktop.org/series/59502/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Enable eLLC caching of display buffers for SKL+
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3616:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3615:16: warning: expression using sizeof(void)

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* ✓ Fi.CI.BAT: success for drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 14:16 [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
  2019-04-15 15:02 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
  2019-04-15 15:03 ` ✗ Fi.CI.SPARSE: " Patchwork
@ 2019-04-15 15:21 ` Patchwork
  2019-04-15 16:03   ` Chris Wilson
  2019-04-15 17:38 ` ✗ Fi.CI.IGT: failure " Patchwork
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 15+ messages in thread
From: Patchwork @ 2019-04-15 15:21 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Enable eLLC caching of display buffers for SKL+
URL   : https://patchwork.freedesktop.org/series/59502/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5934 -> Patchwork_12799
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/59502/revisions/1/mbox/

Known issues
------------

  Here are the changes found in Patchwork_12799 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_selftest@live_evict:
    - fi-bsw-kefka:       PASS -> DMESG-WARN [fdo#107709]

  * igt@i915_selftest@live_execlists:
    - fi-apl-guc:         PASS -> INCOMPLETE [fdo#103927] / [fdo#109720]

  * igt@kms_busy@basic-flip-a:
    - fi-bsw-n3050:       NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_chamelium@hdmi-crc-fast:
    - fi-bsw-n3050:       NOTRUN -> SKIP [fdo#109271] +57

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - fi-byt-clapper:     PASS -> FAIL [fdo#103191]

  * igt@runner@aborted:
    - fi-bsw-kefka:       NOTRUN -> FAIL [fdo#107709]
    - fi-apl-guc:         NOTRUN -> FAIL [fdo#108622] / [fdo#109720]

  
#### Possible fixes ####

  * igt@i915_selftest@live_hangcheck:
    - fi-skl-iommu:       INCOMPLETE [fdo#108602] / [fdo#108744] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
    - fi-byt-clapper:     FAIL [fdo#103191] -> PASS

  
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
  [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
  [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (50 -> 42)
------------------------------

  Additional (1): fi-bsw-n3050 
  Missing    (9): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-bdw-samus fi-snb-2600 


Build changes
-------------

    * Linux: CI_DRM_5934 -> Patchwork_12799

  CI_DRM_5934: cc5334c0e706ec423c5f1a139cf3da7bd3287db6 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4946: 56bdc68638cec64c6b02cd6b220b52b76059b51a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12799: f13e05007cae8890d8d6488b56f5c7e19b2f2e2b @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f13e05007cae drm/i915: Enable eLLC caching of display buffers for SKL+

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12799/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: ✓ Fi.CI.BAT: success for drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 15:21 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2019-04-15 16:03   ` Chris Wilson
  2019-04-15 16:20     ` Ville Syrjälä
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Wilson @ 2019-04-15 16:03 UTC (permalink / raw)
  To: Ville Syrjälä, Patchwork; +Cc: intel-gfx

Quoting Patchwork (2019-04-15 16:21:30)
> == Series Details ==
> 
> Series: drm/i915: Enable eLLC caching of display buffers for SKL+
> URL   : https://patchwork.freedesktop.org/series/59502/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_5934 -> Patchwork_12799
> ====================================================
> 
> Summary
> -------
> 
>   **SUCCESS**
> 
>   No regressions found.

How good is our testing for detecting cacheline dirt from rendering?

Now, it's pretty easy for us to test, you fire up a desktop and wiggle a
few windows, but how well automated is it in CI?
-chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: ✓ Fi.CI.BAT: success for drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 16:03   ` Chris Wilson
@ 2019-04-15 16:20     ` Ville Syrjälä
  0 siblings, 0 replies; 15+ messages in thread
From: Ville Syrjälä @ 2019-04-15 16:20 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Mon, Apr 15, 2019 at 05:03:09PM +0100, Chris Wilson wrote:
> Quoting Patchwork (2019-04-15 16:21:30)
> > == Series Details ==
> > 
> > Series: drm/i915: Enable eLLC caching of display buffers for SKL+
> > URL   : https://patchwork.freedesktop.org/series/59502/
> > State : success
> > 
> > == Summary ==
> > 
> > CI Bug Log - changes from CI_DRM_5934 -> Patchwork_12799
> > ====================================================
> > 
> > Summary
> > -------
> > 
> >   **SUCCESS**
> > 
> >   No regressions found.
> 
> How good is our testing for detecting cacheline dirt from rendering?
> 
> Now, it's pretty easy for us to test, you fire up a desktop and wiggle a
> few windows, but how well automated is it in CI?

Not well. Rendercopy sets MOCS to 0 which means UC, so it won't test
this at all. We should probably change that.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* ✗ Fi.CI.IGT: failure for drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 14:16 [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
                   ` (2 preceding siblings ...)
  2019-04-15 15:21 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2019-04-15 17:38 ` Patchwork
  2019-04-16 14:28 ` [PATCH] " Eero Tamminen
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 15+ messages in thread
From: Patchwork @ 2019-04-15 17:38 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Enable eLLC caching of display buffers for SKL+
URL   : https://patchwork.freedesktop.org/series/59502/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5934_full -> Patchwork_12799_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_12799_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12799_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_12799_full:

### IGT changes ###

#### Possible regressions ####

  * igt@gem_mocs_settings@mocs-isolation-vebox:
    - shard-kbl:          NOTRUN -> FAIL +1

  * igt@gem_mocs_settings@mocs-rc6-vebox:
    - shard-kbl:          PASS -> FAIL +27

  * igt@gem_mocs_settings@mocs-reset-dirty-render:
    - shard-skl:          PASS -> FAIL +18

  * igt@gem_mocs_settings@mocs-reset-render:
    - shard-apl:          PASS -> FAIL +19
    - shard-skl:          NOTRUN -> FAIL

  
Known issues
------------

  Here are the changes found in Patchwork_12799_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@bcs0-s3:
    - shard-apl:          PASS -> DMESG-WARN [fdo#108566] +2

  * igt@gem_softpin@noreloc-s3:
    - shard-skl:          PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]

  * igt@i915_selftest@live_workarounds:
    - shard-iclb:         PASS -> DMESG-FAIL [fdo#108954]

  * igt@kms_atomic_transition@2x-modeset-transitions-nonblocking:
    - shard-kbl:          NOTRUN -> SKIP [fdo#109271] +21

  * igt@kms_busy@extended-pageflip-hang-newfb-render-f:
    - shard-kbl:          NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_cursor_crc@cursor-64x21-offscreen:
    - shard-skl:          PASS -> FAIL [fdo#103232]

  * igt@kms_draw_crc@draw-method-xrgb8888-blt-ytiled:
    - shard-glk:          PASS -> FAIL [fdo#103184] / [fdo#107589]

  * igt@kms_flip@2x-flip-vs-expired-vblank:
    - shard-glk:          PASS -> FAIL [fdo#105363]

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-skl:          PASS -> FAIL [fdo#105363]

  * igt@kms_flip@flip-vs-suspend:
    - shard-kbl:          PASS -> DMESG-WARN [fdo#108566] +2

  * igt@kms_flip@plain-flip-fb-recreate:
    - shard-skl:          PASS -> FAIL [fdo#100368]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
    - shard-skl:          NOTRUN -> SKIP [fdo#109271] +75

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt:
    - shard-iclb:         PASS -> FAIL [fdo#103167] +5

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-blt:
    - shard-iclb:         PASS -> FAIL [fdo#109247] +4

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-f:
    - shard-skl:          NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
    - shard-skl:          PASS -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
    - shard-skl:          NOTRUN -> FAIL [fdo#108145] +1

  * igt@kms_psr@sprite_plane_onoff:
    - shard-iclb:         PASS -> FAIL [fdo#107383] / [fdo#110215]

  * igt@kms_setmode@basic:
    - shard-kbl:          PASS -> FAIL [fdo#99912]

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s3:
    - shard-kbl:          DMESG-WARN [fdo#108566] -> PASS +1

  * igt@i915_pm_rpm@i2c:
    - shard-iclb:         FAIL [fdo#104097] -> PASS

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-apl:          DMESG-WARN [fdo#108566] -> PASS +4

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         SKIP [fdo#109349] -> PASS

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-glk:          FAIL [fdo#102887] / [fdo#105363] -> PASS

  * igt@kms_flip@modeset-vs-vblank-race:
    - shard-glk:          FAIL [fdo#103060] -> PASS

  * igt@kms_flip_tiling@flip-to-x-tiled:
    - shard-skl:          FAIL [fdo#108134] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render:
    - shard-iclb:         FAIL [fdo#103167] -> PASS +3

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt:
    - shard-iclb:         FAIL [fdo#109247] -> PASS +15

  * igt@kms_plane@pixel-format-pipe-c-planes:
    - shard-glk:          SKIP [fdo#109271] -> PASS

  * igt@kms_plane_lowres@pipe-a-tiling-y:
    - shard-iclb:         FAIL [fdo#103166] -> PASS

  * igt@kms_plane_scaling@pipe-c-scaler-with-rotation:
    - shard-glk:          SKIP [fdo#109271] / [fdo#109278] -> PASS

  * igt@kms_psr2_su@page_flip:
    - shard-iclb:         SKIP [fdo#109642] -> PASS

  * igt@kms_psr@psr2_cursor_plane_onoff:
    - shard-iclb:         SKIP [fdo#109441] -> PASS +1

  * igt@kms_psr@sprite_mmap_cpu:
    - shard-iclb:         FAIL [fdo#107383] / [fdo#110215] -> PASS

  * igt@kms_setmode@basic:
    - shard-apl:          FAIL [fdo#99912] -> PASS

  
#### Warnings ####

  * igt@i915_pm_rpm@dpms-non-lpsp:
    - shard-skl:          INCOMPLETE [fdo#107807] -> SKIP [fdo#109271]

  
  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
  [fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#104097]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#107383]: https://bugs.freedesktop.org/show_bug.cgi?id=107383
  [fdo#107589]: https://bugs.freedesktop.org/show_bug.cgi?id=107589
  [fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773
  [fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
  [fdo#108134]: https://bugs.freedesktop.org/show_bug.cgi?id=108134
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108954]: https://bugs.freedesktop.org/show_bug.cgi?id=108954
  [fdo#109247]: https://bugs.freedesktop.org/show_bug.cgi?id=109247
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110215]: https://bugs.freedesktop.org/show_bug.cgi?id=110215
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (10 -> 9)
------------------------------

  Missing    (1): shard-hsw 


Build changes
-------------

    * Linux: CI_DRM_5934 -> Patchwork_12799

  CI_DRM_5934: cc5334c0e706ec423c5f1a139cf3da7bd3287db6 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4946: 56bdc68638cec64c6b02cd6b220b52b76059b51a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12799: f13e05007cae8890d8d6488b56f5c7e19b2f2e2b @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12799/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 14:16 [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
                   ` (3 preceding siblings ...)
  2019-04-15 17:38 ` ✗ Fi.CI.IGT: failure " Patchwork
@ 2019-04-16 14:28 ` Eero Tamminen
  2019-04-16 14:37   ` Ville Syrjälä
  2019-04-17  7:09 ` Chris Wilson
  2019-05-24 20:19 ` Chris Wilson
  6 siblings, 1 reply; 15+ messages in thread
From: Eero Tamminen @ 2019-04-16 14:28 UTC (permalink / raw)
  To: Ville Syrjala, intel-gfx

Hi,

Based on quick tests with the patch:

* Results in GfxBench and Unigine (Valley/Heaven) tests were within 
daily variation on the tested SKL machines

* SKL GT4e (128MB eLLC) / Wayland / Weston:
   +15-20% SynMark TexMem512 (512MB of textures)
    +4-6% SynMark TerrainFly*, CSCloth, ShMapVsm
   -5-10% SynMark TexMem128 (128MB of textures)

* SKL GT3e (64MB eLLC) / Xorg / Unity:
   +4-8% GpuTest Triangle fullscreen (FullHD)
  -5-10% GpuTest Triangle windowed (1/2 screen)

* SKL GT2 (no eLLC) / Xorg / Unity:
   * Some of the higher FPS SynMark pixel and vertex shader tests
     are few percent higher, more than daily variance
   => Do you see any reason why this machine would be impacted
      although it doesn't eLLC?

(I built it against drm-tip and compared results against previous and 
next day unpatched drm-tip results that I had otherwise.)


	- Eero

On 15.4.2019 17.16, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Since SKL the eLLC has been sitting on the far side of the system
> agent, meaning the display engine can utilize it. Let's enable that.
> 
> I chose WB for the caching mode, because my numbers are indicating
> that WT might actually be WB and WC might actually be UC. I'm not
> 100% sure that is indeed the case but at least my simple rendercopy
> based benchmark didn't see any difference in performance.
> 
> Also if I configure things to do LLCeLLC+WT I still get cache dirt
> on my screen, suggesting that is in fact operating in WB mode
> anyway. This is also the reason I had to fix the MOCS target cache
> to really say PTE rather than LLC+eLLC.
> 
> Caveat: I've not benchmarked any real workloads. IIRC Eero did
> benchmark an earlier version, but that didn't have the PTE vs.
> LLC+eLLC MOCS fix so it wasn't actually doing the right thing
> most likely.
> 
> Cc: Eero Tamminen <eero.t.tamminen@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>   drivers/gpu/drm/i915/i915_drv.h     | 3 +--
>   drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++++--
>   drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
>   drivers/gpu/drm/i915/intel_mocs.c   | 2 +-
>   4 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 35d0782c077e..2a4f33fa2bba 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2517,8 +2517,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>   #define HAS_LLC(dev_priv)	(INTEL_INFO(dev_priv)->has_llc)
>   #define HAS_SNOOP(dev_priv)	(INTEL_INFO(dev_priv)->has_snoop)
>   #define HAS_EDRAM(dev_priv)	((dev_priv)->edram_size_mb)
> -#define HAS_WT(dev_priv)	((IS_HASWELL(dev_priv) || \
> -				 IS_BROADWELL(dev_priv)) && HAS_EDRAM(dev_priv))
> +#define HAS_WT(dev_priv)	HAS_EDRAM(dev_priv)
>   
>   #define HWS_NEEDS_PHYSICAL(dev_priv)	(INTEL_INFO(dev_priv)->hws_needs_physical)
>   
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8f460cc4cc1f..038fbf52a997 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3071,7 +3071,7 @@ static void cnl_setup_private_ppat(struct intel_ppat *ppat)
>   
>   	__alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC);
>   	__alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
> -	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
> +	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
>   	__alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC);
>   	__alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
>   	__alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1));
> @@ -3109,7 +3109,10 @@ static void bdw_setup_private_ppat(struct intel_ppat *ppat)
>   
>   	__alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC);      /* for normal objects, no eLLC */
>   	__alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);  /* for something pointing to ptes? */
> -	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);  /* for scanout with eLLC */
> +	if (INTEL_GEN(ppat->i915) >= 9)
> +		__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE); /* for scanout with eLLC */
> +	else
> +		__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); /* for scanout with eLLC */
>   	__alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC);                      /* Uncached objects, mostly for scanout */
>   	__alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
>   	__alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1));
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index f597f35b109b..47adc7268867 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -139,7 +139,7 @@ typedef u64 gen8_ppgtt_pml4e_t;
>   #define PPAT_UNCACHED			(_PAGE_PWT | _PAGE_PCD)
>   #define PPAT_CACHED_PDE			0 /* WB LLC */
>   #define PPAT_CACHED			_PAGE_PAT /* WB LLCeLLC */
> -#define PPAT_DISPLAY_ELLC		_PAGE_PCD /* WT eLLC */
> +#define PPAT_DISPLAY_ELLC		_PAGE_PCD /* WT LLCeLLC (HSW/BDW) or WB eLLC (SKL+) */
>   
>   #define CHV_PPAT_SNOOP			(1<<6)
>   #define GEN8_PPAT_AGE(x)		((x)<<4)
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c b/drivers/gpu/drm/i915/intel_mocs.c
> index 274ba78500c0..d984ccff94ef 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -115,7 +115,7 @@ struct drm_i915_mocs_table {
>   		   LE_1_UC | LE_TC_2_LLC_ELLC, \
>   		   L3_1_UC), \
>   	MOCS_ENTRY(I915_MOCS_PTE, \
> -		   LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3), \
> +		   LE_0_PAGETABLE | LE_TC_0_PAGETABLE | LE_LRUM(3), \
>   		   L3_3_WB)
>   
>   static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-16 14:28 ` [PATCH] " Eero Tamminen
@ 2019-04-16 14:37   ` Ville Syrjälä
  0 siblings, 0 replies; 15+ messages in thread
From: Ville Syrjälä @ 2019-04-16 14:37 UTC (permalink / raw)
  To: Eero Tamminen; +Cc: intel-gfx

On Tue, Apr 16, 2019 at 05:28:57PM +0300, Eero Tamminen wrote:
> Hi,
> 
> Based on quick tests with the patch:
> 
> * Results in GfxBench and Unigine (Valley/Heaven) tests were within 
> daily variation on the tested SKL machines
> 
> * SKL GT4e (128MB eLLC) / Wayland / Weston:
>    +15-20% SynMark TexMem512 (512MB of textures)
>     +4-6% SynMark TerrainFly*, CSCloth, ShMapVsm
>    -5-10% SynMark TexMem128 (128MB of textures)

These seem mostly good. The 128MB case regression seems
understandable since we don't quite fit into the eLLC
anymore.

> 
> * SKL GT3e (64MB eLLC) / Xorg / Unity:
>    +4-8% GpuTest Triangle fullscreen (FullHD)
>   -5-10% GpuTest Triangle windowed (1/2 screen)

Not quite sure why the windowed case would suffer here :/

> 
> * SKL GT2 (no eLLC) / Xorg / Unity:
>    * Some of the higher FPS SynMark pixel and vertex shader tests
>      are few percent higher, more than daily variance
>    => Do you see any reason why this machine would be impacted
>       although it doesn't eLLC?

Can't think of a reason for that. All display buffers should still
be UC on such a machine.

> 
> (I built it against drm-tip and compared results against previous and 
> next day unpatched drm-tip results that I had otherwise.)
> 
> 
> 	- Eero
> 
> On 15.4.2019 17.16, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Since SKL the eLLC has been sitting on the far side of the system
> > agent, meaning the display engine can utilize it. Let's enable that.
> > 
> > I chose WB for the caching mode, because my numbers are indicating
> > that WT might actually be WB and WC might actually be UC. I'm not
> > 100% sure that is indeed the case but at least my simple rendercopy
> > based benchmark didn't see any difference in performance.
> > 
> > Also if I configure things to do LLCeLLC+WT I still get cache dirt
> > on my screen, suggesting that is in fact operating in WB mode
> > anyway. This is also the reason I had to fix the MOCS target cache
> > to really say PTE rather than LLC+eLLC.
> > 
> > Caveat: I've not benchmarked any real workloads. IIRC Eero did
> > benchmark an earlier version, but that didn't have the PTE vs.
> > LLC+eLLC MOCS fix so it wasn't actually doing the right thing
> > most likely.
> > 
> > Cc: Eero Tamminen <eero.t.tamminen@intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_drv.h     | 3 +--
> >   drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++++--
> >   drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
> >   drivers/gpu/drm/i915/intel_mocs.c   | 2 +-
> >   4 files changed, 8 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 35d0782c077e..2a4f33fa2bba 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2517,8 +2517,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >   #define HAS_LLC(dev_priv)	(INTEL_INFO(dev_priv)->has_llc)
> >   #define HAS_SNOOP(dev_priv)	(INTEL_INFO(dev_priv)->has_snoop)
> >   #define HAS_EDRAM(dev_priv)	((dev_priv)->edram_size_mb)
> > -#define HAS_WT(dev_priv)	((IS_HASWELL(dev_priv) || \
> > -				 IS_BROADWELL(dev_priv)) && HAS_EDRAM(dev_priv))
> > +#define HAS_WT(dev_priv)	HAS_EDRAM(dev_priv)
> >   
> >   #define HWS_NEEDS_PHYSICAL(dev_priv)	(INTEL_INFO(dev_priv)->hws_needs_physical)
> >   
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 8f460cc4cc1f..038fbf52a997 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -3071,7 +3071,7 @@ static void cnl_setup_private_ppat(struct intel_ppat *ppat)
> >   
> >   	__alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC);
> >   	__alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
> > -	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
> > +	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
> >   	__alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC);
> >   	__alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
> >   	__alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1));
> > @@ -3109,7 +3109,10 @@ static void bdw_setup_private_ppat(struct intel_ppat *ppat)
> >   
> >   	__alloc_ppat_entry(ppat, 0, GEN8_PPAT_WB | GEN8_PPAT_LLC);      /* for normal objects, no eLLC */
> >   	__alloc_ppat_entry(ppat, 1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);  /* for something pointing to ptes? */
> > -	__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);  /* for scanout with eLLC */
> > +	if (INTEL_GEN(ppat->i915) >= 9)
> > +		__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE); /* for scanout with eLLC */
> > +	else
> > +		__alloc_ppat_entry(ppat, 2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC); /* for scanout with eLLC */
> >   	__alloc_ppat_entry(ppat, 3, GEN8_PPAT_UC);                      /* Uncached objects, mostly for scanout */
> >   	__alloc_ppat_entry(ppat, 4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0));
> >   	__alloc_ppat_entry(ppat, 5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1));
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > index f597f35b109b..47adc7268867 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > @@ -139,7 +139,7 @@ typedef u64 gen8_ppgtt_pml4e_t;
> >   #define PPAT_UNCACHED			(_PAGE_PWT | _PAGE_PCD)
> >   #define PPAT_CACHED_PDE			0 /* WB LLC */
> >   #define PPAT_CACHED			_PAGE_PAT /* WB LLCeLLC */
> > -#define PPAT_DISPLAY_ELLC		_PAGE_PCD /* WT eLLC */
> > +#define PPAT_DISPLAY_ELLC		_PAGE_PCD /* WT LLCeLLC (HSW/BDW) or WB eLLC (SKL+) */
> >   
> >   #define CHV_PPAT_SNOOP			(1<<6)
> >   #define GEN8_PPAT_AGE(x)		((x)<<4)
> > diff --git a/drivers/gpu/drm/i915/intel_mocs.c b/drivers/gpu/drm/i915/intel_mocs.c
> > index 274ba78500c0..d984ccff94ef 100644
> > --- a/drivers/gpu/drm/i915/intel_mocs.c
> > +++ b/drivers/gpu/drm/i915/intel_mocs.c
> > @@ -115,7 +115,7 @@ struct drm_i915_mocs_table {
> >   		   LE_1_UC | LE_TC_2_LLC_ELLC, \
> >   		   L3_1_UC), \
> >   	MOCS_ENTRY(I915_MOCS_PTE, \
> > -		   LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3), \
> > +		   LE_0_PAGETABLE | LE_TC_0_PAGETABLE | LE_LRUM(3), \
> >   		   L3_3_WB)
> >   
> >   static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 14:16 [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
                   ` (4 preceding siblings ...)
  2019-04-16 14:28 ` [PATCH] " Eero Tamminen
@ 2019-04-17  7:09 ` Chris Wilson
  2019-04-17 17:15   ` Ville Syrjälä
  2019-05-24 20:19 ` Chris Wilson
  6 siblings, 1 reply; 15+ messages in thread
From: Chris Wilson @ 2019-04-17  7:09 UTC (permalink / raw)
  To: Ville Syrjala, intel-gfx; +Cc: Eero Tamminen

Quoting Ville Syrjala (2019-04-15 15:16:41)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Since SKL the eLLC has been sitting on the far side of the system
> agent, meaning the display engine can utilize it. Let's enable that.
> 
> I chose WB for the caching mode, because my numbers are indicating
> that WT might actually be WB and WC might actually be UC. I'm not
> 100% sure that is indeed the case but at least my simple rendercopy
> based benchmark didn't see any difference in performance.
> 
> Also if I configure things to do LLCeLLC+WT I still get cache dirt
> on my screen, suggesting that is in fact operating in WB mode
> anyway. This is also the reason I had to fix the MOCS target cache
> to really say PTE rather than LLC+eLLC.

We also need to check with hybrid setups that supply buffers via prime,
and we may need to end up marking those as explicitly uncached.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-17  7:09 ` Chris Wilson
@ 2019-04-17 17:15   ` Ville Syrjälä
  2019-04-26 14:54     ` Ville Syrjälä
  0 siblings, 1 reply; 15+ messages in thread
From: Ville Syrjälä @ 2019-04-17 17:15 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, Eero Tamminen

On Wed, Apr 17, 2019 at 08:09:07AM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-04-15 15:16:41)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Since SKL the eLLC has been sitting on the far side of the system
> > agent, meaning the display engine can utilize it. Let's enable that.
> > 
> > I chose WB for the caching mode, because my numbers are indicating
> > that WT might actually be WB and WC might actually be UC. I'm not
> > 100% sure that is indeed the case but at least my simple rendercopy
> > based benchmark didn't see any difference in performance.
> > 
> > Also if I configure things to do LLCeLLC+WT I still get cache dirt
> > on my screen, suggesting that is in fact operating in WB mode
> > anyway. This is also the reason I had to fix the MOCS target cache
> > to really say PTE rather than LLC+eLLC.
> 
> We also need to check with hybrid setups that supply buffers via prime,
> and we may need to end up marking those as explicitly uncached.

I think all memory access should be able to snoop the eLLC. But yeah,
this should be confirmed on actual hardware. Anyone have a prime setup
handy?

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-17 17:15   ` Ville Syrjälä
@ 2019-04-26 14:54     ` Ville Syrjälä
  2019-04-26 15:01       ` Chris Wilson
  0 siblings, 1 reply; 15+ messages in thread
From: Ville Syrjälä @ 2019-04-26 14:54 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, Eero Tamminen

On Wed, Apr 17, 2019 at 08:15:43PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 17, 2019 at 08:09:07AM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2019-04-15 15:16:41)
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > Since SKL the eLLC has been sitting on the far side of the system
> > > agent, meaning the display engine can utilize it. Let's enable that.
> > > 
> > > I chose WB for the caching mode, because my numbers are indicating
> > > that WT might actually be WB and WC might actually be UC. I'm not
> > > 100% sure that is indeed the case but at least my simple rendercopy
> > > based benchmark didn't see any difference in performance.
> > > 
> > > Also if I configure things to do LLCeLLC+WT I still get cache dirt
> > > on my screen, suggesting that is in fact operating in WB mode
> > > anyway. This is also the reason I had to fix the MOCS target cache
> > > to really say PTE rather than LLC+eLLC.
> > 
> > We also need to check with hybrid setups that supply buffers via prime,
> > and we may need to end up marking those as explicitly uncached.
> 
> I think all memory access should be able to snoop the eLLC. But yeah,
> this should be confirmed on actual hardware. Anyone have a prime setup
> handy?

It occurred to me that finding a machine for this might be a little
difficult as most gt3e/gt4e chips are only available in laptops/nucs/etc.
IIRC there are some Xeons that would qualify, but I suppose those are
somewhat rare. Not sure if there are any other desktop parts that have
ellc.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-26 14:54     ` Ville Syrjälä
@ 2019-04-26 15:01       ` Chris Wilson
  2019-04-26 15:13         ` Ville Syrjälä
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Wilson @ 2019-04-26 15:01 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx, Eero Tamminen

Quoting Ville Syrjälä (2019-04-26 15:54:54)
> On Wed, Apr 17, 2019 at 08:15:43PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 17, 2019 at 08:09:07AM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2019-04-15 15:16:41)
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Since SKL the eLLC has been sitting on the far side of the system
> > > > agent, meaning the display engine can utilize it. Let's enable that.
> > > > 
> > > > I chose WB for the caching mode, because my numbers are indicating
> > > > that WT might actually be WB and WC might actually be UC. I'm not
> > > > 100% sure that is indeed the case but at least my simple rendercopy
> > > > based benchmark didn't see any difference in performance.
> > > > 
> > > > Also if I configure things to do LLCeLLC+WT I still get cache dirt
> > > > on my screen, suggesting that is in fact operating in WB mode
> > > > anyway. This is also the reason I had to fix the MOCS target cache
> > > > to really say PTE rather than LLC+eLLC.
> > > 
> > > We also need to check with hybrid setups that supply buffers via prime,
> > > and we may need to end up marking those as explicitly uncached.
> > 
> > I think all memory access should be able to snoop the eLLC. But yeah,
> > this should be confirmed on actual hardware. Anyone have a prime setup
> > handy?
> 
> It occurred to me that finding a machine for this might be a little
> difficult as most gt3e/gt4e chips are only available in laptops/nucs/etc.
> IIRC there are some Xeons that would qualify, but I suppose those are
> somewhat rare. Not sure if there are any other desktop parts that have
> ellc.

For now at least. Would an ePCI be a fun mix of coherency problems? Not
that they are any more common.

Did you finish up the rendercopy tests? I think I saw that you were
working on something that looked like it could be used for verifying
rendering into the frontbuffer (or at least leaving cache dirty prior to
flips)?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-26 15:01       ` Chris Wilson
@ 2019-04-26 15:13         ` Ville Syrjälä
  0 siblings, 0 replies; 15+ messages in thread
From: Ville Syrjälä @ 2019-04-26 15:13 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx, Eero Tamminen

On Fri, Apr 26, 2019 at 04:01:02PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2019-04-26 15:54:54)
> > On Wed, Apr 17, 2019 at 08:15:43PM +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 17, 2019 at 08:09:07AM +0100, Chris Wilson wrote:
> > > > Quoting Ville Syrjala (2019-04-15 15:16:41)
> > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > 
> > > > > Since SKL the eLLC has been sitting on the far side of the system
> > > > > agent, meaning the display engine can utilize it. Let's enable that.
> > > > > 
> > > > > I chose WB for the caching mode, because my numbers are indicating
> > > > > that WT might actually be WB and WC might actually be UC. I'm not
> > > > > 100% sure that is indeed the case but at least my simple rendercopy
> > > > > based benchmark didn't see any difference in performance.
> > > > > 
> > > > > Also if I configure things to do LLCeLLC+WT I still get cache dirt
> > > > > on my screen, suggesting that is in fact operating in WB mode
> > > > > anyway. This is also the reason I had to fix the MOCS target cache
> > > > > to really say PTE rather than LLC+eLLC.
> > > > 
> > > > We also need to check with hybrid setups that supply buffers via prime,
> > > > and we may need to end up marking those as explicitly uncached.
> > > 
> > > I think all memory access should be able to snoop the eLLC. But yeah,
> > > this should be confirmed on actual hardware. Anyone have a prime setup
> > > handy?
> > 
> > It occurred to me that finding a machine for this might be a little
> > difficult as most gt3e/gt4e chips are only available in laptops/nucs/etc.
> > IIRC there are some Xeons that would qualify, but I suppose those are
> > somewhat rare. Not sure if there are any other desktop parts that have
> > ellc.
> 
> For now at least. Would an ePCI be a fun mix of coherency problems? Not
> that they are any more common.

Hmm. I keep forgetting what century we're in. Some kind of external
thunderbolt enclosure might do the trick. Never actually seen one but
I suppose it shouldn't be an impossible task to procure some.

> 
> Did you finish up the rendercopy tests? I think I saw that you were
> working on something that looked like it could be used for verifying
> rendering into the frontbuffer (or at least leaving cache dirty prior to
> flips)?

I just fixed up the mocs setup in rendercopy. I didn't write a specific
testase yet.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+
  2019-04-15 14:16 [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
                   ` (5 preceding siblings ...)
  2019-04-17  7:09 ` Chris Wilson
@ 2019-05-24 20:19 ` Chris Wilson
  6 siblings, 0 replies; 15+ messages in thread
From: Chris Wilson @ 2019-05-24 20:19 UTC (permalink / raw)
  To: Ville Syrjala, intel-gfx; +Cc: Eero Tamminen

Quoting Ville Syrjala (2019-04-15 15:16:41)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Since SKL the eLLC has been sitting on the far side of the system
> agent, meaning the display engine can utilize it. Let's enable that.
> 
> I chose WB for the caching mode, because my numbers are indicating
> that WT might actually be WB and WC might actually be UC. I'm not
> 100% sure that is indeed the case but at least my simple rendercopy
> based benchmark didn't see any difference in performance.
> 
> Also if I configure things to do LLCeLLC+WT I still get cache dirt
> on my screen, suggesting that is in fact operating in WB mode
> anyway. This is also the reason I had to fix the MOCS target cache
> to really say PTE rather than LLC+eLLC.
> 
> Caveat: I've not benchmarked any real workloads. IIRC Eero did
> benchmark an earlier version, but that didn't have the PTE vs.
> LLC+eLLC MOCS fix so it wasn't actually doing the right thing
> most likely.
> 
> Cc: Eero Tamminen <eero.t.tamminen@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2019-05-24 20:19 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-15 14:16 [PATCH] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
2019-04-15 15:02 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-04-15 15:03 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-04-15 15:21 ` ✓ Fi.CI.BAT: success " Patchwork
2019-04-15 16:03   ` Chris Wilson
2019-04-15 16:20     ` Ville Syrjälä
2019-04-15 17:38 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-04-16 14:28 ` [PATCH] " Eero Tamminen
2019-04-16 14:37   ` Ville Syrjälä
2019-04-17  7:09 ` Chris Wilson
2019-04-17 17:15   ` Ville Syrjälä
2019-04-26 14:54     ` Ville Syrjälä
2019-04-26 15:01       ` Chris Wilson
2019-04-26 15:13         ` Ville Syrjälä
2019-05-24 20:19 ` Chris Wilson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.