* [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.