* [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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox