* [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
@ 2021-09-13 14:39 Vandita Kulkarni
2021-09-13 15:29 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
` (3 more replies)
0 siblings, 4 replies; 20+ messages in thread
From: Vandita Kulkarni @ 2021-09-13 14:39 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula, manasi.d.navare, Vandita Kulkarni
Each VDSC operates with 1ppc throughput, hence enable the second
VDSC engine when moderate is higher that the current cdclk.
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 161c33b2c869..55878f65f724 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -70,6 +70,7 @@
#include "intel_tc.h"
#include "intel_vdsc.h"
#include "intel_vrr.h"
+#include "intel_cdclk.h"
#define DP_DPRX_ESI_LEN 14
@@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct drm_connector_state *conn_state,
struct link_config_limits *limits)
{
+ struct intel_cdclk_state *cdclk_state;
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
+ struct intel_atomic_state *state =
+ to_intel_atomic_state(pipe_config->uapi.state);
int pipe_bpp;
int ret;
@@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
}
}
+ cdclk_state = intel_atomic_get_cdclk_state(state);
+ if (IS_ERR(cdclk_state))
+ return PTR_ERR(cdclk_state);
+
/*
* VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
- * is greater than the maximum Cdclock and if slice count is even
+ * is greater than the current Cdclock and if slice count is even
* then we need to use 2 VDSC instances.
*/
- if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
+ if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
pipe_config->bigjoiner) {
if (pipe_config->dsc.slice_count < 2) {
drm_dbg_kms(&dev_priv->drm,
--
2.32.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-13 14:39 [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates Vandita Kulkarni
@ 2021-09-13 15:29 ` Patchwork
2021-09-13 17:00 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: Patchwork @ 2021-09-13 15:29 UTC (permalink / raw)
To: Vandita Kulkarni; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 5811 bytes --]
== Series Details ==
Series: drm/i915/display: Enable second VDSC engine for higher moderates
URL : https://patchwork.freedesktop.org/series/94608/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10574 -> Patchwork_21022
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/index.html
Known issues
------------
Here are the changes found in Patchwork_21022 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-bdw-5557u/igt@amdgpu/amd_basic@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#3718])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-bdw-5557u/igt@core_hotunplug@unbind-rebind.html
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#3958])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600: [PASS][5] -> [INCOMPLETE][6] ([i915#3921])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-bdw-5557u/igt@kms_chamelium@dp-crc-fast.html
* igt@kms_flip@basic-flip-vs-modeset@c-dp2:
- fi-cfl-8109u: [PASS][8] -> [DMESG-WARN][9] ([i915#165]) +2 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-modeset@c-dp2.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-modeset@c-dp2.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#165] / [i915#295]) +20 similar issues
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/fi-cfl-8109u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-cfl-8109u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b.html
* igt@prime_vgem@basic-fence-flip:
- fi-rkl-guc: [PASS][12] -> [SKIP][13] ([i915#1845])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/fi-rkl-guc/igt@prime_vgem@basic-fence-flip.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-rkl-guc/igt@prime_vgem@basic-fence-flip.html
#### Possible fixes ####
* igt@i915_module_load@reload:
- fi-tgl-y: [DMESG-WARN][14] ([i915#1982]) -> [PASS][15]
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/fi-tgl-y/igt@i915_module_load@reload.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-tgl-y/igt@i915_module_load@reload.html
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][16] ([i915#3303]) -> [PASS][17]
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/fi-hsw-gt1/igt@i915_selftest@live@hangcheck.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-hsw-gt1/igt@i915_selftest@live@hangcheck.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-rkl-guc: [FAIL][18] ([i915#3983]) -> [PASS][19]
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/fi-rkl-guc/igt@kms_force_connector_basic@force-connector-state.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/fi-rkl-guc/igt@kms_force_connector_basic@force-connector-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958
[i915#3983]: https://gitlab.freedesktop.org/drm/intel/issues/3983
Participating hosts (44 -> 38)
------------------------------
Missing (6): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 fi-bdw-samus bat-jsl-1
Build changes
-------------
* Linux: CI_DRM_10574 -> Patchwork_21022
CI-20190529: 20190529
CI_DRM_10574: 3ad0415f7f7a68058d5ff02d8a7ac51d8b542cf9 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6204: 1084c5eb74fd0daf8c9b8e83e85f5208c396579b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21022: ddf7c104f2d2dec6ca0838eb4c6c8732e1babaaa @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ddf7c104f2d2 drm/i915/display: Enable second VDSC engine for higher moderates
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/index.html
[-- Attachment #2: Type: text/html, Size: 6823 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-13 14:39 [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates Vandita Kulkarni
2021-09-13 15:29 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
@ 2021-09-13 17:00 ` Patchwork
2021-09-14 7:19 ` [Intel-gfx] [PATCH] " Lisovskiy, Stanislav
2021-09-14 7:28 ` Ville Syrjälä
3 siblings, 0 replies; 20+ messages in thread
From: Patchwork @ 2021-09-13 17:00 UTC (permalink / raw)
To: Vandita Kulkarni; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30287 bytes --]
== Series Details ==
Series: drm/i915/display: Enable second VDSC engine for higher moderates
URL : https://patchwork.freedesktop.org/series/94608/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10574_full -> Patchwork_21022_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_21022_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_21022_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_21022_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt:
- shard-iclb: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-iclb7/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb8/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt.html
#### Warnings ####
* igt@kms_psr2_su@page_flip:
- shard-iclb: [SKIP][3] ([fdo#109642] / [fdo#111068] / [i915#658]) -> [FAIL][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-iclb6/igt@kms_psr2_su@page_flip.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb2/igt@kms_psr2_su@page_flip.html
Known issues
------------
Here are the changes found in Patchwork_21022_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][5] ([fdo#111827])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb6/igt@feature_discovery@chamelium.html
* igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +5 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-snb5/igt@gem_ctx_persistence@legacy-engines-mixed.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#2369] / [i915#2481] / [i915#3070])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-iclb2/igt@gem_eio@unwedge-stress.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb4/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2846])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-kbl7/igt@gem_exec_fair@basic-deadline.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl6/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-tglb2/igt@gem_exec_fair@basic-flow@rcs0.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: NOTRUN -> [FAIL][13] ([i915#2842])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-glk1/igt@gem_exec_fair@basic-none-rrul@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-iclb1/igt@gem_exec_fair@basic-none-share@rcs0.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb2/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-kbl4/igt@gem_exec_fair@basic-none@vcs1.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl4/igt@gem_exec_fair@basic-none@vcs1.html
* igt@gem_mmap_gtt@coherency:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#111656])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb8/igt@gem_mmap_gtt@coherency.html
* igt@gem_pread@exhaustion:
- shard-apl: NOTRUN -> [WARN][19] ([i915#2658])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl6/igt@gem_pread@exhaustion.html
* igt@gem_softpin@evict-snoop:
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109312])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb8/igt@gem_softpin@evict-snoop.html
* igt@gem_userptr_blits@input-checking:
- shard-kbl: NOTRUN -> [DMESG-WARN][21] ([i915#3002])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl2/igt@gem_userptr_blits@input-checking.html
* igt@gen9_exec_parse@cmd-crossing-page:
- shard-tglb: NOTRUN -> [SKIP][22] ([i915#2856])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@gen9_exec_parse@cmd-crossing-page.html
* igt@i915_pm_backlight@bad-brightness:
- shard-glk: NOTRUN -> [SKIP][23] ([fdo#109271]) +37 similar issues
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-glk1/igt@i915_pm_backlight@bad-brightness.html
* igt@i915_pm_dc@dc6-dpms:
- shard-kbl: NOTRUN -> [FAIL][24] ([i915#454])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl1/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp:
- shard-kbl: NOTRUN -> [SKIP][25] ([fdo#109271] / [i915#1937])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl3/igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp.html
* igt@i915_pm_lpsp@screens-disabled:
- shard-tglb: NOTRUN -> [SKIP][26] ([i915#1902])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@i915_pm_lpsp@screens-disabled.html
* igt@i915_pm_rpm@system-suspend:
- shard-tglb: [PASS][27] -> [INCOMPLETE][28] ([i915#2411] / [i915#456]) +1 similar issue
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-tglb2/igt@i915_pm_rpm@system-suspend.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb7/igt@i915_pm_rpm@system-suspend.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-apl: NOTRUN -> [SKIP][29] ([fdo#109271] / [i915#3777]) +3 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl1/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180:
- shard-tglb: NOTRUN -> [SKIP][30] ([fdo#111615]) +2 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180.html
* igt@kms_big_joiner@invalid-modeset:
- shard-iclb: NOTRUN -> [SKIP][31] ([i915#2705])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb3/igt@kms_big_joiner@invalid-modeset.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#3886]) +7 similar issues
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl6/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#3886]) +1 similar issue
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-glk1/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
- shard-iclb: NOTRUN -> [SKIP][34] ([fdo#109278] / [i915#3886]) +1 similar issue
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb3/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-crc-primary-basic-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][35] ([i915#3689]) +2 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@kms_ccs@pipe-b-crc-primary-basic-yf_tiled_ccs.html
* igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
- shard-kbl: NOTRUN -> [SKIP][36] ([fdo#109271] / [i915#3886]) +2 similar issues
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl3/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][37] ([i915#3689] / [i915#3886])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_ccs:
- shard-snb: NOTRUN -> [SKIP][38] ([fdo#109271]) +445 similar issues
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-snb7/igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_ccs.html
* igt@kms_chamelium@hdmi-aspect-ratio:
- shard-kbl: NOTRUN -> [SKIP][39] ([fdo#109271] / [fdo#111827]) +2 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl1/igt@kms_chamelium@hdmi-aspect-ratio.html
* igt@kms_chamelium@hdmi-crc-single:
- shard-glk: NOTRUN -> [SKIP][40] ([fdo#109271] / [fdo#111827]) +2 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-glk1/igt@kms_chamelium@hdmi-crc-single.html
* igt@kms_chamelium@vga-hpd-fast:
- shard-tglb: NOTRUN -> [SKIP][41] ([fdo#109284] / [fdo#111827]) +1 similar issue
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@kms_chamelium@vga-hpd-fast.html
* igt@kms_chamelium@vga-hpd-without-ddc:
- shard-snb: NOTRUN -> [SKIP][42] ([fdo#109271] / [fdo#111827]) +26 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-snb7/igt@kms_chamelium@vga-hpd-without-ddc.html
* igt@kms_color@pipe-a-ctm-0-5:
- shard-skl: [PASS][43] -> [DMESG-WARN][44] ([i915#1982])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-skl5/igt@kms_color@pipe-a-ctm-0-5.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-skl8/igt@kms_color@pipe-a-ctm-0-5.html
* igt@kms_color_chamelium@pipe-a-ctm-limited-range:
- shard-apl: NOTRUN -> [SKIP][45] ([fdo#109271] / [fdo#111827]) +19 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl1/igt@kms_color_chamelium@pipe-a-ctm-limited-range.html
* igt@kms_color_chamelium@pipe-d-ctm-blue-to-red:
- shard-iclb: NOTRUN -> [SKIP][46] ([fdo#109278] / [fdo#109284] / [fdo#111827])
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb6/igt@kms_color_chamelium@pipe-d-ctm-blue-to-red.html
* igt@kms_content_protection@lic:
- shard-apl: NOTRUN -> [TIMEOUT][47] ([i915#1319]) +1 similar issue
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl2/igt@kms_content_protection@lic.html
* igt@kms_content_protection@uevent:
- shard-tglb: NOTRUN -> [SKIP][48] ([fdo#111828])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@kms_content_protection@uevent.html
* igt@kms_cursor_crc@pipe-a-cursor-32x10-rapid-movement:
- shard-tglb: NOTRUN -> [SKIP][49] ([i915#3359]) +2 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@kms_cursor_crc@pipe-a-cursor-32x10-rapid-movement.html
* igt@kms_cursor_crc@pipe-a-cursor-512x512-random:
- shard-tglb: NOTRUN -> [SKIP][50] ([fdo#109279] / [i915#3359]) +1 similar issue
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@kms_cursor_crc@pipe-a-cursor-512x512-random.html
* igt@kms_cursor_crc@pipe-b-cursor-32x32-onscreen:
- shard-kbl: NOTRUN -> [SKIP][51] ([fdo#109271]) +71 similar issues
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl1/igt@kms_cursor_crc@pipe-b-cursor-32x32-onscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-32x10-onscreen:
- shard-iclb: NOTRUN -> [SKIP][52] ([fdo#109278]) +2 similar issues
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb3/igt@kms_cursor_crc@pipe-c-cursor-32x10-onscreen.html
* igt@kms_cursor_crc@pipe-d-cursor-32x32-onscreen:
- shard-tglb: NOTRUN -> [SKIP][53] ([i915#3319])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@kms_cursor_crc@pipe-d-cursor-32x32-onscreen.html
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- shard-iclb: [PASS][54] -> [DMESG-WARN][55] ([i915#3728])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-iclb1/igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb2/igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled.html
* igt@kms_dsc@basic-dsc-enable@edp-1-pipe-a:
- shard-tglb: [PASS][56] -> [FAIL][57] ([i915#1385]) +3 similar issues
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-tglb8/igt@kms_dsc@basic-dsc-enable@edp-1-pipe-a.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb2/igt@kms_dsc@basic-dsc-enable@edp-1-pipe-a.html
* igt@kms_flip@2x-absolute-wf_vblank:
- shard-tglb: NOTRUN -> [SKIP][58] ([fdo#111825] / [i915#3966])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@kms_flip@2x-absolute-wf_vblank.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
- shard-skl: [PASS][59] -> [FAIL][60] ([i915#79])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
- shard-apl: NOTRUN -> [DMESG-WARN][61] ([i915#180]) +3 similar issues
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl6/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl: [PASS][62] -> [DMESG-WARN][63] ([i915#180]) +1 similar issue
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-kbl6/igt@kms_flip@flip-vs-suspend@c-dp1.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl7/igt@kms_flip@flip-vs-suspend@c-dp1.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-apl: NOTRUN -> [SKIP][64] ([fdo#109271]) +217 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl: [PASS][65] -> [DMESG-WARN][66] ([i915#180]) +1 similar issue
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-apl2/igt@kms_frontbuffer_tracking@fbc-suspend.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl7/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt:
- shard-iclb: [PASS][67] -> [FAIL][68] ([i915#2546]) +1 similar issue
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack-mmap-gtt:
- shard-skl: NOTRUN -> [SKIP][69] ([fdo#109271]) +5 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-skl6/igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack-mmap-gtt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-pwrite:
- shard-iclb: NOTRUN -> [SKIP][70] ([fdo#109280])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb3/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-cur-indfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move:
- shard-tglb: NOTRUN -> [SKIP][71] ([fdo#111825]) +12 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][72] -> [FAIL][73] ([i915#1188])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-skl10/igt@kms_hdr@bpc-switch-dpms.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-skl1/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_pipe_crc_basic@read-crc-pipe-d:
- shard-glk: NOTRUN -> [SKIP][74] ([fdo#109271] / [i915#533])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-glk1/igt@kms_pipe_crc_basic@read-crc-pipe-d.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-apl: NOTRUN -> [SKIP][75] ([fdo#109271] / [i915#533]) +3 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl1/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: NOTRUN -> [FAIL][76] ([fdo#108145] / [i915#265]) +1 similar issue
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl6/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl: NOTRUN -> [FAIL][77] ([fdo#108145] / [i915#265])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][78] -> [FAIL][79] ([fdo#108145] / [i915#265]) +1 similar issue
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_plane_lowres@pipe-c-tiling-none:
- shard-tglb: NOTRUN -> [SKIP][80] ([i915#3536])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@kms_plane_lowres@pipe-c-tiling-none.html
* igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
- shard-apl: NOTRUN -> [SKIP][81] ([fdo#109271] / [i915#2733])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl6/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2:
- shard-apl: NOTRUN -> [SKIP][82] ([fdo#109271] / [i915#658]) +5 similar issues
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl1/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2.html
- shard-skl: NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#658])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-skl2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-5:
- shard-kbl: NOTRUN -> [SKIP][84] ([fdo#109271] / [i915#658]) +2 similar issues
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl1/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-5.html
* igt@kms_psr@psr2_basic:
- shard-tglb: NOTRUN -> [FAIL][85] ([i915#132] / [i915#3467]) +1 similar issue
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb8/igt@kms_psr@psr2_basic.html
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: NOTRUN -> [SKIP][86] ([fdo#109441])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb3/igt@kms_psr@psr2_cursor_blt.html
* igt@kms_psr@psr2_primary_blt:
- shard-iclb: [PASS][87] -> [SKIP][88] ([fdo#109441])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-iclb2/igt@kms_psr@psr2_primary_blt.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb4/igt@kms_psr@psr2_primary_blt.html
* igt@kms_writeback@writeback-check-output:
- shard-kbl: NOTRUN -> [SKIP][89] ([fdo#109271] / [i915#2437])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl1/igt@kms_writeback@writeback-check-output.html
* igt@msm_submit@invalid-cmd-type-submit:
- shard-tglb: NOTRUN -> [SKIP][90] ([fdo#109315] / [i915#2575])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@msm_submit@invalid-cmd-type-submit.html
* igt@nouveau_crc@pipe-b-source-rg:
- shard-tglb: NOTRUN -> [SKIP][91] ([i915#2530])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@nouveau_crc@pipe-b-source-rg.html
* igt@prime_nv_test@i915_nv_sharing:
- shard-tglb: NOTRUN -> [SKIP][92] ([fdo#109291])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@prime_nv_test@i915_nv_sharing.html
* igt@sysfs_clients@fair-7:
- shard-apl: NOTRUN -> [SKIP][93] ([fdo#109271] / [i915#2994]) +4 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-apl1/igt@sysfs_clients@fair-7.html
- shard-tglb: NOTRUN -> [SKIP][94] ([i915#2994])
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb8/igt@sysfs_clients@fair-7.html
* igt@sysfs_clients@sema-10:
- shard-kbl: NOTRUN -> [SKIP][95] ([fdo#109271] / [i915#2994])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl1/igt@sysfs_clients@sema-10.html
* igt@tools_test@sysfs_l3_parity:
- shard-iclb: NOTRUN -> [SKIP][96] ([fdo#109307])
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb6/igt@tools_test@sysfs_l3_parity.html
#### Possible fixes ####
* igt@gem_eio@unwedge-stress:
- shard-tglb: [TIMEOUT][97] ([i915#2369] / [i915#3063] / [i915#3648]) -> [PASS][98]
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-tglb3/igt@gem_eio@unwedge-stress.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb3/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}: [FAIL][99] ([i915#2846]) -> [PASS][100]
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-6/igt@gem_exec_fair@basic-deadline.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [FAIL][101] ([i915#2842]) -> [PASS][102]
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-tglb6/igt@gem_exec_fair@basic-none-share@rcs0.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb1/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_whisper@basic-forked:
- shard-glk: [DMESG-WARN][103] ([i915#118] / [i915#95]) -> [PASS][104]
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-glk4/igt@gem_exec_whisper@basic-forked.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-glk7/igt@gem_exec_whisper@basic-forked.html
* igt@gem_exec_whisper@basic-queues-forked:
- shard-iclb: [INCOMPLETE][105] ([i915#1895]) -> [PASS][106]
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-iclb5/igt@gem_exec_whisper@basic-queues-forked.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-iclb3/igt@gem_exec_whisper@basic-queues-forked.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-180:
- {shard-rkl}: [SKIP][107] ([i915#3638]) -> [PASS][108]
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_big_fb@x-tiled-64bpp-rotate-180.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_big_fb@x-tiled-64bpp-rotate-180.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-async-flip:
- {shard-rkl}: [SKIP][109] ([i915#3721]) -> [PASS][110]
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html
* igt@kms_big_fb@y-tiled-16bpp-rotate-270:
- {shard-rkl}: [SKIP][111] ([fdo#111614]) -> [PASS][112]
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_big_fb@y-tiled-16bpp-rotate-270.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_big_fb@y-tiled-16bpp-rotate-270.html
* igt@kms_color@pipe-b-gamma:
- {shard-rkl}: [SKIP][113] ([i915#1149] / [i915#1849] / [i915#4070]) -> [PASS][114] +2 similar issues
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_color@pipe-b-gamma.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_color@pipe-b-gamma.html
* igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding:
- {shard-rkl}: [SKIP][115] ([fdo#112022] / [i915#4070]) -> [PASS][116] +1 similar issue
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-tglb: [INCOMPLETE][117] ([i915#2411] / [i915#456]) -> [PASS][118]
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-tglb7/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-tglb5/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- {shard-rkl}: [SKIP][119] ([fdo#111825] / [i915#4070]) -> [PASS][120] +1 similar issue
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
* igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled:
- {shard-rkl}: [SKIP][121] ([fdo#111314]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled.html
* igt@kms_flip@flip-vs-expired-vblank@c-edp1:
- shard-skl: [FAIL][123] ([i915#79]) -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-skl7/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-skl10/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html
* igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-glk: [FAIL][125] ([i915#1888] / [i915#2546]) -> [PASS][126] +1 similar issue
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-glk9/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-glk6/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-pgflip-blt:
- {shard-rkl}: [SKIP][127] ([i915#1849]) -> [PASS][128] +10 similar issues
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-pgflip-blt.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-pgflip-blt.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [FAIL][129] ([i915#1188]) -> [PASS][130]
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-skl4/igt@kms_hdr@bpc-switch-suspend.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-skl9/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl: [DMESG-WARN][131] ([i915#180]) -> [PASS][132] +5 similar issues
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-kbl7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-kbl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- {shard-rkl}: [SKIP][133] ([i915#1849] / [i915#4070]) -> [PASS][134]
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/shard-rkl-6/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html
* igt@kms_plane_cursor@pipe-a-primary-size-128:
- {shard-rkl}: [SKIP][135] ([i915#1845]) -> [PASS][136] +6 similar issues
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10574/shard-rkl-1/igt@kms_plane_cursor@pipe-a-primary-size-128.html
[136]:
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21022/index.html
[-- Attachment #2: Type: text/html, Size: 33571 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-13 14:39 [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates Vandita Kulkarni
2021-09-13 15:29 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2021-09-13 17:00 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2021-09-14 7:19 ` Lisovskiy, Stanislav
2021-09-14 7:37 ` Kulkarni, Vandita
2021-09-14 7:28 ` Ville Syrjälä
3 siblings, 1 reply; 20+ messages in thread
From: Lisovskiy, Stanislav @ 2021-09-14 7:19 UTC (permalink / raw)
To: Vandita Kulkarni; +Cc: intel-gfx, jani.nikula, manasi.d.navare
On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> Each VDSC operates with 1ppc throughput, hence enable the second
> VDSC engine when moderate is higher that the current cdclk.
>
> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 161c33b2c869..55878f65f724 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -70,6 +70,7 @@
> #include "intel_tc.h"
> #include "intel_vdsc.h"
> #include "intel_vrr.h"
> +#include "intel_cdclk.h"
>
> #define DP_DPRX_ESI_LEN 14
>
> @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> struct drm_connector_state *conn_state,
> struct link_config_limits *limits)
> {
> + struct intel_cdclk_state *cdclk_state;
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> const struct drm_display_mode *adjusted_mode =
> &pipe_config->hw.adjusted_mode;
> + struct intel_atomic_state *state =
> + to_intel_atomic_state(pipe_config->uapi.state);
> int pipe_bpp;
> int ret;
>
> @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> }
> }
>
> + cdclk_state = intel_atomic_get_cdclk_state(state);
> + if (IS_ERR(cdclk_state))
> + return PTR_ERR(cdclk_state);
> +
> /*
> * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> - * is greater than the maximum Cdclock and if slice count is even
> + * is greater than the current Cdclock and if slice count is even
> * then we need to use 2 VDSC instances.
> */
> - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
So in the end, we didn't have to bump CDCLK up to get rid of that?
Anyways, checked with BSpec 49259, seems to make sense, was no point in
comparing to max CDCLK, which is not even currently used.
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> pipe_config->bigjoiner) {
> if (pipe_config->dsc.slice_count < 2) {
> drm_dbg_kms(&dev_priv->drm,
> --
> 2.32.0
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-13 14:39 [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates Vandita Kulkarni
` (2 preceding siblings ...)
2021-09-14 7:19 ` [Intel-gfx] [PATCH] " Lisovskiy, Stanislav
@ 2021-09-14 7:28 ` Ville Syrjälä
2021-09-14 7:31 ` Kulkarni, Vandita
3 siblings, 1 reply; 20+ messages in thread
From: Ville Syrjälä @ 2021-09-14 7:28 UTC (permalink / raw)
To: Vandita Kulkarni; +Cc: intel-gfx, jani.nikula, manasi.d.navare
On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> Each VDSC operates with 1ppc throughput, hence enable the second
> VDSC engine when moderate is higher that the current cdclk.
>
> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 161c33b2c869..55878f65f724 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -70,6 +70,7 @@
> #include "intel_tc.h"
> #include "intel_vdsc.h"
> #include "intel_vrr.h"
> +#include "intel_cdclk.h"
>
> #define DP_DPRX_ESI_LEN 14
>
> @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> struct drm_connector_state *conn_state,
> struct link_config_limits *limits)
> {
> + struct intel_cdclk_state *cdclk_state;
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> const struct drm_display_mode *adjusted_mode =
> &pipe_config->hw.adjusted_mode;
> + struct intel_atomic_state *state =
> + to_intel_atomic_state(pipe_config->uapi.state);
> int pipe_bpp;
> int ret;
>
> @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> }
> }
>
> + cdclk_state = intel_atomic_get_cdclk_state(state);
> + if (IS_ERR(cdclk_state))
> + return PTR_ERR(cdclk_state);
> +
> /*
> * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> - * is greater than the maximum Cdclock and if slice count is even
> + * is greater than the current Cdclock and if slice count is even
> * then we need to use 2 VDSC instances.
> */
> - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
This is wrong. We compute the cdclk based on the requirements of the
mode/etc., not the other way around.
> pipe_config->bigjoiner) {
> if (pipe_config->dsc.slice_count < 2) {
> drm_dbg_kms(&dev_priv->drm,
> --
> 2.32.0
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 7:28 ` Ville Syrjälä
@ 2021-09-14 7:31 ` Kulkarni, Vandita
2021-09-14 7:48 ` Ville Syrjälä
0 siblings, 1 reply; 20+ messages in thread
From: Kulkarni, Vandita @ 2021-09-14 7:31 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, Nikula, Jani, Navare, Manasi D
> -----Original Message-----
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Sent: Tuesday, September 14, 2021 12:59 PM
> To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>;
> Navare, Manasi D <manasi.d.navare@intel.com>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
>
> On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
> > engine when moderate is higher that the current cdclk.
> >
> > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 161c33b2c869..55878f65f724 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -70,6 +70,7 @@
> > #include "intel_tc.h"
> > #include "intel_vdsc.h"
> > #include "intel_vrr.h"
> > +#include "intel_cdclk.h"
> >
> > #define DP_DPRX_ESI_LEN 14
> >
> > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> > struct drm_connector_state *conn_state,
> > struct link_config_limits *limits) {
> > + struct intel_cdclk_state *cdclk_state;
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port-
> >base.base.dev);
> > const struct drm_display_mode *adjusted_mode =
> > &pipe_config->hw.adjusted_mode;
> > + struct intel_atomic_state *state =
> > + to_intel_atomic_state(pipe_config-
> >uapi.state);
> > int pipe_bpp;
> > int ret;
> >
> > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> > }
> > }
> >
> > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > + if (IS_ERR(cdclk_state))
> > + return PTR_ERR(cdclk_state);
> > +
> > /*
> > * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> > - * is greater than the maximum Cdclock and if slice count is even
> > + * is greater than the current Cdclock and if slice count is even
> > * then we need to use 2 VDSC instances.
> > */
> > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> > + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
>
> This is wrong. We compute the cdclk based on the requirements of the
> mode/etc., not the other way around.
Okay , So you suggest that we set the cd clock to max when we have such requirement, than enabling the second engine?
>
> > pipe_config->bigjoiner) {
> > if (pipe_config->dsc.slice_count < 2) {
> > drm_dbg_kms(&dev_priv->drm,
> > --
> > 2.32.0
>
> --
> Ville Syrjälä
> Intel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 7:19 ` [Intel-gfx] [PATCH] " Lisovskiy, Stanislav
@ 2021-09-14 7:37 ` Kulkarni, Vandita
0 siblings, 0 replies; 20+ messages in thread
From: Kulkarni, Vandita @ 2021-09-14 7:37 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx, Nikula, Jani, Navare, Manasi D
> -----Original Message-----
> From: Lisovskiy, Stanislav <stanislav.lisovskiy@intel.com>
> Sent: Tuesday, September 14, 2021 12:49 PM
> To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>;
> Navare, Manasi D <manasi.d.navare@intel.com>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
>
> On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
> > engine when moderate is higher that the current cdclk.
> >
> > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 161c33b2c869..55878f65f724 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -70,6 +70,7 @@
> > #include "intel_tc.h"
> > #include "intel_vdsc.h"
> > #include "intel_vrr.h"
> > +#include "intel_cdclk.h"
> >
> > #define DP_DPRX_ESI_LEN 14
> >
> > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> > struct drm_connector_state *conn_state,
> > struct link_config_limits *limits) {
> > + struct intel_cdclk_state *cdclk_state;
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port-
> >base.base.dev);
> > const struct drm_display_mode *adjusted_mode =
> > &pipe_config->hw.adjusted_mode;
> > + struct intel_atomic_state *state =
> > + to_intel_atomic_state(pipe_config-
> >uapi.state);
> > int pipe_bpp;
> > int ret;
> >
> > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> > }
> > }
> >
> > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > + if (IS_ERR(cdclk_state))
> > + return PTR_ERR(cdclk_state);
> > +
> > /*
> > * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> > - * is greater than the maximum Cdclock and if slice count is even
> > + * is greater than the current Cdclock and if slice count is even
> > * then we need to use 2 VDSC instances.
> > */
> > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> > + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
>
> So in the end, we didn't have to bump CDCLK up to get rid of that?
The solution that could fix the underruns was either of these: set max cdclk that can drive this or enable the second dsc engine if slice count > 2 to achieve 2ppc.
>
> Anyways, checked with BSpec 49259, seems to make sense, was no point in
> comparing to max CDCLK, which is not even currently used.
>
> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
>
> > pipe_config->bigjoiner) {
> > if (pipe_config->dsc.slice_count < 2) {
> > drm_dbg_kms(&dev_priv->drm,
> > --
> > 2.32.0
> >
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 7:31 ` Kulkarni, Vandita
@ 2021-09-14 7:48 ` Ville Syrjälä
2021-09-14 8:59 ` Lisovskiy, Stanislav
0 siblings, 1 reply; 20+ messages in thread
From: Ville Syrjälä @ 2021-09-14 7:48 UTC (permalink / raw)
To: Kulkarni, Vandita; +Cc: intel-gfx, Nikula, Jani, Navare, Manasi D
On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita wrote:
> > -----Original Message-----
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Sent: Tuesday, September 14, 2021 12:59 PM
> > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>;
> > Navare, Manasi D <manasi.d.navare@intel.com>
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > engine for higher moderates
> >
> > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> > > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
> > > engine when moderate is higher that the current cdclk.
> > >
> > > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 161c33b2c869..55878f65f724 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -70,6 +70,7 @@
> > > #include "intel_tc.h"
> > > #include "intel_vdsc.h"
> > > #include "intel_vrr.h"
> > > +#include "intel_cdclk.h"
> > >
> > > #define DP_DPRX_ESI_LEN 14
> > >
> > > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
> > intel_dp *intel_dp,
> > > struct drm_connector_state *conn_state,
> > > struct link_config_limits *limits) {
> > > + struct intel_cdclk_state *cdclk_state;
> > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > struct drm_i915_private *dev_priv = to_i915(dig_port-
> > >base.base.dev);
> > > const struct drm_display_mode *adjusted_mode =
> > > &pipe_config->hw.adjusted_mode;
> > > + struct intel_atomic_state *state =
> > > + to_intel_atomic_state(pipe_config-
> > >uapi.state);
> > > int pipe_bpp;
> > > int ret;
> > >
> > > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
> > intel_dp *intel_dp,
> > > }
> > > }
> > >
> > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > > + if (IS_ERR(cdclk_state))
> > > + return PTR_ERR(cdclk_state);
> > > +
> > > /*
> > > * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> > > - * is greater than the maximum Cdclock and if slice count is even
> > > + * is greater than the current Cdclock and if slice count is even
> > > * then we need to use 2 VDSC instances.
> > > */
> > > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> > > + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
> >
> > This is wrong. We compute the cdclk based on the requirements of the
> > mode/etc., not the other way around.
>
> Okay , So you suggest that we set the cd clock to max when we have such requirement, than enabling the second engine?
That seems like the easiest solution. Another option might be to come up
with some lower dotclock limit for the use of the second vdsc. But not
sure we know where the tipping point is wrt. powr consumption.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 7:48 ` Ville Syrjälä
@ 2021-09-14 8:59 ` Lisovskiy, Stanislav
2021-09-14 12:04 ` Jani Nikula
0 siblings, 1 reply; 20+ messages in thread
From: Lisovskiy, Stanislav @ 2021-09-14 8:59 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Kulkarni, Vandita, intel-gfx, Nikula, Jani, Navare, Manasi D
On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita wrote:
> > > -----Original Message-----
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>;
> > > Navare, Manasi D <manasi.d.navare@intel.com>
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > > engine for higher moderates
> > >
> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> > > > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
> > > > engine when moderate is higher that the current cdclk.
> > > >
> > > > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 161c33b2c869..55878f65f724 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -70,6 +70,7 @@
> > > > #include "intel_tc.h"
> > > > #include "intel_vdsc.h"
> > > > #include "intel_vrr.h"
> > > > +#include "intel_cdclk.h"
> > > >
> > > > #define DP_DPRX_ESI_LEN 14
> > > >
> > > > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
> > > intel_dp *intel_dp,
> > > > struct drm_connector_state *conn_state,
> > > > struct link_config_limits *limits) {
> > > > + struct intel_cdclk_state *cdclk_state;
> > > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > > struct drm_i915_private *dev_priv = to_i915(dig_port-
> > > >base.base.dev);
> > > > const struct drm_display_mode *adjusted_mode =
> > > > &pipe_config->hw.adjusted_mode;
> > > > + struct intel_atomic_state *state =
> > > > + to_intel_atomic_state(pipe_config-
> > > >uapi.state);
> > > > int pipe_bpp;
> > > > int ret;
> > > >
> > > > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
> > > intel_dp *intel_dp,
> > > > }
> > > > }
> > > >
> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > > > + if (IS_ERR(cdclk_state))
> > > > + return PTR_ERR(cdclk_state);
> > > > +
> > > > /*
> > > > * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> > > > - * is greater than the maximum Cdclock and if slice count is even
> > > > + * is greater than the current Cdclock and if slice count is even
> > > > * then we need to use 2 VDSC instances.
> > > > */
> > > > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> > > > + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
> > >
> > > This is wrong. We compute the cdclk based on the requirements of the
> > > mode/etc., not the other way around.
According to BSpec guideline, we decide whether we enable or disable second VDSC engine, based
on that condition. As I understand that one is about DSC config calculation, based on CDCLK
which was calculated.
If we bump up CDCLK, to avoid this, will we even then use a second VDSC ever?
Another thing is that probably enabling second VDSC is cheaper in terms of power consumption,
than bumping up the CDCLK.
Stan
> >
> > Okay , So you suggest that we set the cd clock to max when we have such requirement, than enabling the second engine?
>
> That seems like the easiest solution. Another option might be to come up
> with some lower dotclock limit for the use of the second vdsc. But not
> sure we know where the tipping point is wrt. powr consumption.
>
> --
> Ville Syrjälä
> Intel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 8:59 ` Lisovskiy, Stanislav
@ 2021-09-14 12:04 ` Jani Nikula
2021-09-14 13:04 ` Lisovskiy, Stanislav
0 siblings, 1 reply; 20+ messages in thread
From: Jani Nikula @ 2021-09-14 12:04 UTC (permalink / raw)
To: Lisovskiy, Stanislav, Ville Syrjälä
Cc: Kulkarni, Vandita, intel-gfx, Navare, Manasi D
On Tue, 14 Sep 2021, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com> wrote:
> On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
>> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita wrote:
>> > > -----Original Message-----
>> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > > Sent: Tuesday, September 14, 2021 12:59 PM
>> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
>> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>;
>> > > Navare, Manasi D <manasi.d.navare@intel.com>
>> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
>> > > engine for higher moderates
>> > >
>> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
>> > > > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
>> > > > engine when moderate is higher that the current cdclk.
>> > > >
>> > > > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
>> > > > ---
>> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
>> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > > > index 161c33b2c869..55878f65f724 100644
>> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > > > @@ -70,6 +70,7 @@
>> > > > #include "intel_tc.h"
>> > > > #include "intel_vdsc.h"
>> > > > #include "intel_vrr.h"
>> > > > +#include "intel_cdclk.h"
>> > > >
>> > > > #define DP_DPRX_ESI_LEN 14
>> > > >
>> > > > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
>> > > intel_dp *intel_dp,
>> > > > struct drm_connector_state *conn_state,
>> > > > struct link_config_limits *limits) {
>> > > > + struct intel_cdclk_state *cdclk_state;
>> > > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> > > > struct drm_i915_private *dev_priv = to_i915(dig_port-
>> > > >base.base.dev);
>> > > > const struct drm_display_mode *adjusted_mode =
>> > > > &pipe_config->hw.adjusted_mode;
>> > > > + struct intel_atomic_state *state =
>> > > > + to_intel_atomic_state(pipe_config-
>> > > >uapi.state);
>> > > > int pipe_bpp;
>> > > > int ret;
>> > > >
>> > > > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
>> > > intel_dp *intel_dp,
>> > > > }
>> > > > }
>> > > >
>> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
>> > > > + if (IS_ERR(cdclk_state))
>> > > > + return PTR_ERR(cdclk_state);
>> > > > +
>> > > > /*
>> > > > * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
>> > > > - * is greater than the maximum Cdclock and if slice count is even
>> > > > + * is greater than the current Cdclock and if slice count is even
>> > > > * then we need to use 2 VDSC instances.
>> > > > */
>> > > > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
>> > > > + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
>> > >
>> > > This is wrong. We compute the cdclk based on the requirements of the
>> > > mode/etc., not the other way around.
>
> According to BSpec guideline, we decide whether we enable or disable second VDSC engine, based
> on that condition. As I understand that one is about DSC config calculation, based on CDCLK
> which was calculated.
Point is, at the time compute_config gets called, what guarantees are
there that cdclk_state->actual.cdclk contains anything useful? This is
the design we have.
> If we bump up CDCLK, to avoid this, will we even then use a second VDSC ever?
I think we'll eventually need better logic than unconditionally bumping
to max, and it needs to take *both* the cdclk and the number of dsc
engines into account. The referenced bspec only has the vdsc clock
perspective, not overall perspective.
BR,
Jani.
> Another thing is that probably enabling second VDSC is cheaper in terms of power consumption,
> than bumping up the CDCLK.
>
> Stan
>
>> >
>> > Okay , So you suggest that we set the cd clock to max when we have such requirement, than enabling the second engine?
>>
>> That seems like the easiest solution. Another option might be to come up
>> with some lower dotclock limit for the use of the second vdsc. But not
>> sure we know where the tipping point is wrt. powr consumption.
>>
>> --
>> Ville Syrjälä
>> Intel
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 12:04 ` Jani Nikula
@ 2021-09-14 13:04 ` Lisovskiy, Stanislav
2021-09-14 13:32 ` Lisovskiy, Stanislav
0 siblings, 1 reply; 20+ messages in thread
From: Lisovskiy, Stanislav @ 2021-09-14 13:04 UTC (permalink / raw)
To: Jani Nikula
Cc: Ville Syrjälä, Kulkarni, Vandita, intel-gfx, Navare, Manasi D
On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com> wrote:
> > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita wrote:
> >> > > -----Original Message-----
> >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>;
> >> > > Navare, Manasi D <manasi.d.navare@intel.com>
> >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> >> > > engine for higher moderates
> >> > >
> >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> >> > > > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
> >> > > > engine when moderate is higher that the current cdclk.
> >> > > >
> >> > > > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> >> > > > ---
> >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> >> > > >
> >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > > > index 161c33b2c869..55878f65f724 100644
> >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > > > @@ -70,6 +70,7 @@
> >> > > > #include "intel_tc.h"
> >> > > > #include "intel_vdsc.h"
> >> > > > #include "intel_vrr.h"
> >> > > > +#include "intel_cdclk.h"
> >> > > >
> >> > > > #define DP_DPRX_ESI_LEN 14
> >> > > >
> >> > > > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
> >> > > intel_dp *intel_dp,
> >> > > > struct drm_connector_state *conn_state,
> >> > > > struct link_config_limits *limits) {
> >> > > > + struct intel_cdclk_state *cdclk_state;
> >> > > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> >> > > > struct drm_i915_private *dev_priv = to_i915(dig_port-
> >> > > >base.base.dev);
> >> > > > const struct drm_display_mode *adjusted_mode =
> >> > > > &pipe_config->hw.adjusted_mode;
> >> > > > + struct intel_atomic_state *state =
> >> > > > + to_intel_atomic_state(pipe_config-
> >> > > >uapi.state);
> >> > > > int pipe_bpp;
> >> > > > int ret;
> >> > > >
> >> > > > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
> >> > > intel_dp *intel_dp,
> >> > > > }
> >> > > > }
> >> > > >
> >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> >> > > > + if (IS_ERR(cdclk_state))
> >> > > > + return PTR_ERR(cdclk_state);
> >> > > > +
> >> > > > /*
> >> > > > * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> >> > > > - * is greater than the maximum Cdclock and if slice count is even
> >> > > > + * is greater than the current Cdclock and if slice count is even
> >> > > > * then we need to use 2 VDSC instances.
> >> > > > */
> >> > > > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> >> > > > + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
> >> > >
> >> > > This is wrong. We compute the cdclk based on the requirements of the
> >> > > mode/etc., not the other way around.
> >
> > According to BSpec guideline, we decide whether we enable or disable second VDSC engine, based
> > on that condition. As I understand that one is about DSC config calculation, based on CDCLK
> > which was calculated.
>
> Point is, at the time compute_config gets called, what guarantees are
> there that cdclk_state->actual.cdclk contains anything useful? This is
> the design we have.
That is actually good question, was willing to check that as well.
>
> > If we bump up CDCLK, to avoid this, will we even then use a second VDSC ever?
>
> I think we'll eventually need better logic than unconditionally bumping
> to max, and it needs to take *both* the cdclk and the number of dsc
> engines into account. The referenced bspec only has the vdsc clock
> perspective, not overall perspective.
What we need to clarify here is that how this is supposed to work in theory.
Basically same issue can be fixed by both increasing the CDCLK or enabling
2nd VDSC engine.
There should be some guideline telling us, how to prioritize.
From overall perspective as I understand, by default, we are able to keep
CDCLK 2 times less than pixel rate(see intel_pixel_rate_to_cdclk), however
due to that VDSC limitation that it can use only 1 ppc this becomes, not
applicable anymore(at least as of BSpec 49259), so we have to increase amount
of VDSC instances then.
So the question is now - what is more optimal here?
Also if we bump up CDCLK(which we have done many times already in fact), we
then need to add some logic to intel_compute_min_cdclk to check if we are using
DSC or not, because otherwise we don't really need to do that.
Stan
>
> BR,
> Jani.
>
> > Another thing is that probably enabling second VDSC is cheaper in terms of power consumption,
> > than bumping up the CDCLK.
> >
> > Stan
> >
> >> >
> >> > Okay , So you suggest that we set the cd clock to max when we have such requirement, than enabling the second engine?
> >>
> >> That seems like the easiest solution. Another option might be to come up
> >> with some lower dotclock limit for the use of the second vdsc. But not
> >> sure we know where the tipping point is wrt. powr consumption.
> >>
> >> --
> >> Ville Syrjälä
> >> Intel
>
> --
> Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 13:04 ` Lisovskiy, Stanislav
@ 2021-09-14 13:32 ` Lisovskiy, Stanislav
2021-09-14 14:02 ` Jani Nikula
0 siblings, 1 reply; 20+ messages in thread
From: Lisovskiy, Stanislav @ 2021-09-14 13:32 UTC (permalink / raw)
To: Jani Nikula
Cc: Ville Syrjälä, Kulkarni, Vandita, intel-gfx, Navare, Manasi D
On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com> wrote:
> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita wrote:
> > >> > > -----Original Message-----
> > >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>;
> > >> > > Navare, Manasi D <manasi.d.navare@intel.com>
> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > >> > > engine for higher moderates
> > >> > >
> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> > >> > > > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
> > >> > > > engine when moderate is higher that the current cdclk.
> > >> > > >
> > >> > > > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> > >> > > > ---
> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> > >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >> > > >
> > >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > >> > > > index 161c33b2c869..55878f65f724 100644
> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > >> > > > @@ -70,6 +70,7 @@
> > >> > > > #include "intel_tc.h"
> > >> > > > #include "intel_vdsc.h"
> > >> > > > #include "intel_vrr.h"
> > >> > > > +#include "intel_cdclk.h"
> > >> > > >
> > >> > > > #define DP_DPRX_ESI_LEN 14
> > >> > > >
> > >> > > > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
> > >> > > intel_dp *intel_dp,
> > >> > > > struct drm_connector_state *conn_state,
> > >> > > > struct link_config_limits *limits) {
> > >> > > > + struct intel_cdclk_state *cdclk_state;
> > >> > > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > >> > > > struct drm_i915_private *dev_priv = to_i915(dig_port-
> > >> > > >base.base.dev);
> > >> > > > const struct drm_display_mode *adjusted_mode =
> > >> > > > &pipe_config->hw.adjusted_mode;
> > >> > > > + struct intel_atomic_state *state =
> > >> > > > + to_intel_atomic_state(pipe_config-
> > >> > > >uapi.state);
> > >> > > > int pipe_bpp;
> > >> > > > int ret;
> > >> > > >
> > >> > > > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
> > >> > > intel_dp *intel_dp,
> > >> > > > }
> > >> > > > }
> > >> > > >
> > >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > >> > > > + if (IS_ERR(cdclk_state))
> > >> > > > + return PTR_ERR(cdclk_state);
> > >> > > > +
> > >> > > > /*
> > >> > > > * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
> > >> > > > - * is greater than the maximum Cdclock and if slice count is even
> > >> > > > + * is greater than the current Cdclock and if slice count is even
> > >> > > > * then we need to use 2 VDSC instances.
> > >> > > > */
> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
> > >> > > > + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
> > >> > >
> > >> > > This is wrong. We compute the cdclk based on the requirements of the
> > >> > > mode/etc., not the other way around.
> > >
> > > According to BSpec guideline, we decide whether we enable or disable second VDSC engine, based
> > > on that condition. As I understand that one is about DSC config calculation, based on CDCLK
> > > which was calculated.
> >
> > Point is, at the time compute_config gets called, what guarantees are
> > there that cdclk_state->actual.cdclk contains anything useful? This is
> > the design we have.
>
> That is actually good question, was willing to check that as well.
>
> >
> > > If we bump up CDCLK, to avoid this, will we even then use a second VDSC ever?
> >
> > I think we'll eventually need better logic than unconditionally bumping
> > to max, and it needs to take *both* the cdclk and the number of dsc
> > engines into account. The referenced bspec only has the vdsc clock
> > perspective, not overall perspective.
>
> What we need to clarify here is that how this is supposed to work in theory.
> Basically same issue can be fixed by both increasing the CDCLK or enabling
> 2nd VDSC engine.
> There should be some guideline telling us, how to prioritize.
> From overall perspective as I understand, by default, we are able to keep
> CDCLK 2 times less than pixel rate(see intel_pixel_rate_to_cdclk), however
> due to that VDSC limitation that it can use only 1 ppc this becomes, not
> applicable anymore(at least as of BSpec 49259), so we have to increase amount
> of VDSC instances then.
>
> So the question is now - what is more optimal here?
> Also if we bump up CDCLK(which we have done many times already in fact), we
> then need to add some logic to intel_compute_min_cdclk to check if we are using
> DSC or not, because otherwise we don't really need to do that.
>
> Stan
Checked and indeed, encoder->compute_config is called way before, basically
CDCLK calculation is called almost in the end of atomic_check, so in
compute_config, there would be an old CDCLK value copied from previous
cdclk state, but not the last one.
Vandita, this means we actually can't do it that way, if you want to do
anything with VDSC based on CDCLK this has to be done _after_
intel_compute_min_cdclk was called. Which is not very sweet, I guess.
So as of current architecture, it seems that the easiest way is indeed
to bump the CDCLK or we need to figure the way how to enable 2nd VDSC
somewhere else, after CDCLK was calculated.
Stan
>
> >
> > BR,
> > Jani.
> >
> > > Another thing is that probably enabling second VDSC is cheaper in terms of power consumption,
> > > than bumping up the CDCLK.
> > >
> > > Stan
> > >
> > >> >
> > >> > Okay , So you suggest that we set the cd clock to max when we have such requirement, than enabling the second engine?
> > >>
> > >> That seems like the easiest solution. Another option might be to come up
> > >> with some lower dotclock limit for the use of the second vdsc. But not
> > >> sure we know where the tipping point is wrt. powr consumption.
> > >>
> > >> --
> > >> Ville Syrjälä
> > >> Intel
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 13:32 ` Lisovskiy, Stanislav
@ 2021-09-14 14:02 ` Jani Nikula
2021-09-14 14:40 ` Kulkarni, Vandita
0 siblings, 1 reply; 20+ messages in thread
From: Jani Nikula @ 2021-09-14 14:02 UTC (permalink / raw)
To: Lisovskiy, Stanislav
Cc: Ville Syrjälä, Kulkarni, Vandita, intel-gfx, Navare, Manasi D
On Tue, 14 Sep 2021, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com> wrote:
> On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
>> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
>> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com> wrote:
>> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
>> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita wrote:
>> > >> > > -----Original Message-----
>> > >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
>> > >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
>> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>;
>> > >> > > Navare, Manasi D <manasi.d.navare@intel.com>
>> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
>> > >> > > engine for higher moderates
>> > >> > >
>> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
>> > >> > > > Each VDSC operates with 1ppc throughput, hence enable the second VDSC
>> > >> > > > engine when moderate is higher that the current cdclk.
>> > >> > > >
>> > >> > > > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
>> > >> > > > ---
>> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
>> > >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
>> > >> > > >
>> > >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > >> > > > index 161c33b2c869..55878f65f724 100644
>> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > >> > > > @@ -70,6 +70,7 @@
>> > >> > > > #include "intel_tc.h"
>> > >> > > > #include "intel_vdsc.h"
>> > >> > > > #include "intel_vrr.h"
>> > >> > > > +#include "intel_cdclk.h"
>> > >> > > >
>> > >> > > > #define DP_DPRX_ESI_LEN 14
>> > >> > > >
>> > >> > > > @@ -1291,10 +1292,13 @@ static int intel_dp_dsc_compute_config(struct
>> > >> > > intel_dp *intel_dp,
>> > >> > > > struct drm_connector_state *conn_state,
>> > >> > > > struct link_config_limits *limits) {
>> > >> > > > + struct intel_cdclk_state *cdclk_state;
>> > >> > > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> > >> > > > struct drm_i915_private *dev_priv = to_i915(dig_port-
>> > >> > > >base.base.dev);
>> > >> > > > const struct drm_display_mode *adjusted_mode =
>> > >> > > > &pipe_config->hw.adjusted_mode;
>> > >> > > > + struct intel_atomic_state *state =
>> > >> > > > + to_intel_atomic_state(pipe_config-
>> > >> > > >uapi.state);
>> > >> > > > int pipe_bpp;
>> > >> > > > int ret;
>> > >> > > >
>> > >> > > > @@ -1373,12 +1377,16 @@ static int intel_dp_dsc_compute_config(struct
>> > >> > > intel_dp *intel_dp,
>> > >> > > > }
>> > >> > > > }
>> > >> > > >
>> > >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
>> > >> > > > + if (IS_ERR(cdclk_state))
>> > >> > > > + return PTR_ERR(cdclk_state);
>> > >> > > > +
>> > >> > > > /*
>> > >> > > > * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
>> > >> > > > - * is greater than the maximum Cdclock and if slice count is even
>> > >> > > > + * is greater than the current Cdclock and if slice count is even
>> > >> > > > * then we need to use 2 VDSC instances.
>> > >> > > > */
>> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq ||
>> > >> > > > + if (adjusted_mode->crtc_clock > cdclk_state->actual.cdclk ||
>> > >> > >
>> > >> > > This is wrong. We compute the cdclk based on the requirements of the
>> > >> > > mode/etc., not the other way around.
>> > >
>> > > According to BSpec guideline, we decide whether we enable or disable second VDSC engine, based
>> > > on that condition. As I understand that one is about DSC config calculation, based on CDCLK
>> > > which was calculated.
>> >
>> > Point is, at the time compute_config gets called, what guarantees are
>> > there that cdclk_state->actual.cdclk contains anything useful? This is
>> > the design we have.
>>
>> That is actually good question, was willing to check that as well.
>>
>> >
>> > > If we bump up CDCLK, to avoid this, will we even then use a second VDSC ever?
>> >
>> > I think we'll eventually need better logic than unconditionally bumping
>> > to max, and it needs to take *both* the cdclk and the number of dsc
>> > engines into account. The referenced bspec only has the vdsc clock
>> > perspective, not overall perspective.
>>
>> What we need to clarify here is that how this is supposed to work in theory.
>> Basically same issue can be fixed by both increasing the CDCLK or enabling
>> 2nd VDSC engine.
>> There should be some guideline telling us, how to prioritize.
>> From overall perspective as I understand, by default, we are able to keep
>> CDCLK 2 times less than pixel rate(see intel_pixel_rate_to_cdclk), however
>> due to that VDSC limitation that it can use only 1 ppc this becomes, not
>> applicable anymore(at least as of BSpec 49259), so we have to increase amount
>> of VDSC instances then.
>>
>> So the question is now - what is more optimal here?
>> Also if we bump up CDCLK(which we have done many times already in fact), we
>> then need to add some logic to intel_compute_min_cdclk to check if we are using
>> DSC or not, because otherwise we don't really need to do that.
intel_compute_min_cdclk() already needs to be dsc aware when slice count
is 1 and we can't use two dsc engines anyway. See the recent commit
fe01883fdcef ("drm/i915: Get proper min cdclk if vDSC enabled").
Looking again, I'm not sure that does the right decision for when
dsc.slice_count > 1, but dsc.split == false. It should probably use
dsc.split for the decision.
>>
>> Stan
>
> Checked and indeed, encoder->compute_config is called way before, basically
> CDCLK calculation is called almost in the end of atomic_check, so in
> compute_config, there would be an old CDCLK value copied from previous
> cdclk state, but not the last one.
>
> Vandita, this means we actually can't do it that way, if you want to do
> anything with VDSC based on CDCLK this has to be done _after_
> intel_compute_min_cdclk was called. Which is not very sweet, I guess.
>
> So as of current architecture, it seems that the easiest way is indeed
> to bump the CDCLK or we need to figure the way how to enable 2nd VDSC
> somewhere else, after CDCLK was calculated.
Alternatively, we could use two dsc engines more aggressively, but that
decision currently can't take overall chosen cdclk into account.
We'll end up sometimes unnecessarily using a too high cdclk or two dsc
engines, just have to pick the poison.
I think trying to do dsc decisions after intel_compute_min_cdclk() gets
way too complicated.
BR,
Jani
>
> Stan
>
>>
>> >
>> > BR,
>> > Jani.
>> >
>> > > Another thing is that probably enabling second VDSC is cheaper in terms of power consumption,
>> > > than bumping up the CDCLK.
>> > >
>> > > Stan
>> > >
>> > >> >
>> > >> > Okay , So you suggest that we set the cd clock to max when we have such requirement, than enabling the second engine?
>> > >>
>> > >> That seems like the easiest solution. Another option might be to come up
>> > >> with some lower dotclock limit for the use of the second vdsc. But not
>> > >> sure we know where the tipping point is wrt. powr consumption.
>> > >>
>> > >> --
>> > >> Ville Syrjälä
>> > >> Intel
>> >
>> > --
>> > Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 14:02 ` Jani Nikula
@ 2021-09-14 14:40 ` Kulkarni, Vandita
2021-09-14 15:10 ` Jani Nikula
0 siblings, 1 reply; 20+ messages in thread
From: Kulkarni, Vandita @ 2021-09-14 14:40 UTC (permalink / raw)
To: Nikula, Jani, Lisovskiy, Stanislav
Cc: Ville Syrjälä, intel-gfx, Navare, Manasi D
> -----Original Message-----
> From: Nikula, Jani <jani.nikula@intel.com>
> Sent: Tuesday, September 14, 2021 7:33 PM
> To: Lisovskiy, Stanislav <stanislav.lisovskiy@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; Kulkarni, Vandita
> <vandita.kulkarni@intel.com>; intel-gfx@lists.freedesktop.org; Navare,
> Manasi D <manasi.d.navare@intel.com>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
>
> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
> wrote:
> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> <stanislav.lisovskiy@intel.com> wrote:
> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita wrote:
> >> > >> > > -----Original Message-----
> >> > >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> >> > >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> >> > >> > > <jani.nikula@intel.com>; Navare, Manasi D
> >> > >> > > <manasi.d.navare@intel.com>
> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable
> >> > >> > > second VDSC engine for higher moderates
> >> > >> > >
> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni
> wrote:
> >> > >> > > > Each VDSC operates with 1ppc throughput, hence enable the
> >> > >> > > > second VDSC engine when moderate is higher that the current
> cdclk.
> >> > >> > > >
> >> > >> > > > Signed-off-by: Vandita Kulkarni
> >> > >> > > > <vandita.kulkarni@intel.com>
> >> > >> > > > ---
> >> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
> >> > >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> >> > >> > > >
> >> > >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > >> > > > index 161c33b2c869..55878f65f724 100644
> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > >> > > > @@ -70,6 +70,7 @@
> >> > >> > > > #include "intel_tc.h"
> >> > >> > > > #include "intel_vdsc.h"
> >> > >> > > > #include "intel_vrr.h"
> >> > >> > > > +#include "intel_cdclk.h"
> >> > >> > > >
> >> > >> > > > #define DP_DPRX_ESI_LEN 14
> >> > >> > > >
> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
> >> > >> > > > intel_dp_dsc_compute_config(struct
> >> > >> > > intel_dp *intel_dp,
> >> > >> > > > struct drm_connector_state
> *conn_state,
> >> > >> > > > struct link_config_limits *limits) {
> >> > >> > > > + struct intel_cdclk_state *cdclk_state;
> >> > >> > > > struct intel_digital_port *dig_port =
> dp_to_dig_port(intel_dp);
> >> > >> > > > struct drm_i915_private *dev_priv = to_i915(dig_port-
> >> > >> > > >base.base.dev);
> >> > >> > > > const struct drm_display_mode *adjusted_mode =
> >> > >> > > > &pipe_config->hw.adjusted_mode;
> >> > >> > > > + struct intel_atomic_state *state =
> >> > >> > > > + to_intel_atomic_state(pipe_config-
> >> > >> > > >uapi.state);
> >> > >> > > > int pipe_bpp;
> >> > >> > > > int ret;
> >> > >> > > >
> >> > >> > > > @@ -1373,12 +1377,16 @@ static int
> >> > >> > > > intel_dp_dsc_compute_config(struct
> >> > >> > > intel_dp *intel_dp,
> >> > >> > > > }
> >> > >> > > > }
> >> > >> > > >
> >> > >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> >> > >> > > > + if (IS_ERR(cdclk_state))
> >> > >> > > > + return PTR_ERR(cdclk_state);
> >> > >> > > > +
> >> > >> > > > /*
> >> > >> > > > * VDSC engine operates at 1 Pixel per clock, so if peak pixel
> rate
> >> > >> > > > - * is greater than the maximum Cdclock and if slice count is
> even
> >> > >> > > > + * is greater than the current Cdclock and if slice
> >> > >> > > > +count is even
> >> > >> > > > * then we need to use 2 VDSC instances.
> >> > >> > > > */
> >> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq
> ||
> >> > >> > > > + if (adjusted_mode->crtc_clock >
> >> > >> > > > +cdclk_state->actual.cdclk ||
> >> > >> > >
> >> > >> > > This is wrong. We compute the cdclk based on the
> >> > >> > > requirements of the mode/etc., not the other way around.
> >> > >
> >> > > According to BSpec guideline, we decide whether we enable or
> >> > > disable second VDSC engine, based on that condition. As I
> >> > > understand that one is about DSC config calculation, based on CDCLK
> which was calculated.
> >> >
> >> > Point is, at the time compute_config gets called, what guarantees
> >> > are there that cdclk_state->actual.cdclk contains anything useful?
> >> > This is the design we have.
> >>
> >> That is actually good question, was willing to check that as well.
> >>
> >> >
> >> > > If we bump up CDCLK, to avoid this, will we even then use a second
> VDSC ever?
> >> >
> >> > I think we'll eventually need better logic than unconditionally
> >> > bumping to max, and it needs to take *both* the cdclk and the
> >> > number of dsc engines into account. The referenced bspec only has
> >> > the vdsc clock perspective, not overall perspective.
> >>
> >> What we need to clarify here is that how this is supposed to work in
> theory.
> >> Basically same issue can be fixed by both increasing the CDCLK or
> >> enabling 2nd VDSC engine.
> >> There should be some guideline telling us, how to prioritize.
> >> From overall perspective as I understand, by default, we are able to
> >> keep CDCLK 2 times less than pixel rate(see
> >> intel_pixel_rate_to_cdclk), however due to that VDSC limitation that
> >> it can use only 1 ppc this becomes, not applicable anymore(at least
> >> as of BSpec 49259), so we have to increase amount of VDSC instances
> then.
> >>
> >> So the question is now - what is more optimal here?
> >> Also if we bump up CDCLK(which we have done many times already in
> >> fact), we then need to add some logic to intel_compute_min_cdclk to
> >> check if we are using DSC or not, because otherwise we don't really need
> to do that.
>
> intel_compute_min_cdclk() already needs to be dsc aware when slice count
> is 1 and we can't use two dsc engines anyway. See the recent commit
> fe01883fdcef ("drm/i915: Get proper min cdclk if vDSC enabled").
>
> Looking again, I'm not sure that does the right decision for when
> dsc.slice_count > 1, but dsc.split == false. It should probably use dsc.split for
> the decision.
>
> >>
> >> Stan
> >
> > Checked and indeed, encoder->compute_config is called way before,
> > basically CDCLK calculation is called almost in the end of
> > atomic_check, so in compute_config, there would be an old CDCLK value
> > copied from previous cdclk state, but not the last one.
> >
> > Vandita, this means we actually can't do it that way, if you want to
> > do anything with VDSC based on CDCLK this has to be done _after_
> > intel_compute_min_cdclk was called. Which is not very sweet, I guess.
> >
> > So as of current architecture, it seems that the easiest way is indeed
> > to bump the CDCLK or we need to figure the way how to enable 2nd VDSC
> > somewhere else, after CDCLK was calculated.
>
> Alternatively, we could use two dsc engines more aggressively, but that
> decision currently can't take overall chosen cdclk into account.
>
> We'll end up sometimes unnecessarily using a too high cdclk or two dsc
> engines, just have to pick the poison.
>
> I think trying to do dsc decisions after intel_compute_min_cdclk() gets way
> too complicated.
In this case, can we just use the 2nd VDSC engine if slice_count is 2 or more?
Which would mean we always operate in joiner enabled mode(small joiner) of all the compression modes of operation
mentioned in the table bspec: 49259
Because we are still going to hit the max cdclk restriction for higher resolutions, and many lower resolutions wouldn’t need max cdclk.
And eventually once we have more details on cd clk vs 2VDSC engine we could add
the logic to choose one over the other?
I see that in case of DSI we do split = true, for slice_count > 1 but that would need a different set of checks, thats a TBD.
Or Do you suggest I just do this for now max cdclk when slice_count =1 (what we are doing now) replace with compression = true and split = false
Thanks,
Vandita
>
> BR,
> Jani
>
>
>
>
> >
> > Stan
> >
> >>
> >> >
> >> > BR,
> >> > Jani.
> >> >
> >> > > Another thing is that probably enabling second VDSC is cheaper in
> >> > > terms of power consumption, than bumping up the CDCLK.
> >> > >
> >> > > Stan
> >> > >
> >> > >> >
> >> > >> > Okay , So you suggest that we set the cd clock to max when we
> have such requirement, than enabling the second engine?
> >> > >>
> >> > >> That seems like the easiest solution. Another option might be to
> >> > >> come up with some lower dotclock limit for the use of the second
> >> > >> vdsc. But not sure we know where the tipping point is wrt. powr
> consumption.
> >> > >>
> >> > >> --
> >> > >> Ville Syrjälä
> >> > >> Intel
> >> >
> >> > --
> >> > Jani Nikula, Intel Open Source Graphics Center
>
> --
> Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 14:40 ` Kulkarni, Vandita
@ 2021-09-14 15:10 ` Jani Nikula
2022-01-10 7:15 ` Kulkarni, Vandita
0 siblings, 1 reply; 20+ messages in thread
From: Jani Nikula @ 2021-09-14 15:10 UTC (permalink / raw)
To: Kulkarni, Vandita, Lisovskiy, Stanislav
Cc: Ville Syrjälä, intel-gfx, Navare, Manasi D
On Tue, 14 Sep 2021, "Kulkarni, Vandita" <vandita.kulkarni@intel.com> wrote:
>> -----Original Message-----
>> From: Nikula, Jani <jani.nikula@intel.com>
>> Sent: Tuesday, September 14, 2021 7:33 PM
>> To: Lisovskiy, Stanislav <stanislav.lisovskiy@intel.com>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; Kulkarni, Vandita
>> <vandita.kulkarni@intel.com>; intel-gfx@lists.freedesktop.org; Navare,
>> Manasi D <manasi.d.navare@intel.com>
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
>> engine for higher moderates
>>
>> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
>> wrote:
>> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
>> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
>> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
>> <stanislav.lisovskiy@intel.com> wrote:
>> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
>> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita wrote:
>> >> > >> > > -----Original Message-----
>> >> > >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
>> >> > >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
>> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
>> >> > >> > > <jani.nikula@intel.com>; Navare, Manasi D
>> >> > >> > > <manasi.d.navare@intel.com>
>> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable
>> >> > >> > > second VDSC engine for higher moderates
>> >> > >> > >
>> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni
>> wrote:
>> >> > >> > > > Each VDSC operates with 1ppc throughput, hence enable the
>> >> > >> > > > second VDSC engine when moderate is higher that the current
>> cdclk.
>> >> > >> > > >
>> >> > >> > > > Signed-off-by: Vandita Kulkarni
>> >> > >> > > > <vandita.kulkarni@intel.com>
>> >> > >> > > > ---
>> >> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++--
>> >> > >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
>> >> > >> > > >
>> >> > >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
>> >> > >> > > > index 161c33b2c869..55878f65f724 100644
>> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> >> > >> > > > @@ -70,6 +70,7 @@
>> >> > >> > > > #include "intel_tc.h"
>> >> > >> > > > #include "intel_vdsc.h"
>> >> > >> > > > #include "intel_vrr.h"
>> >> > >> > > > +#include "intel_cdclk.h"
>> >> > >> > > >
>> >> > >> > > > #define DP_DPRX_ESI_LEN 14
>> >> > >> > > >
>> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
>> >> > >> > > > intel_dp_dsc_compute_config(struct
>> >> > >> > > intel_dp *intel_dp,
>> >> > >> > > > struct drm_connector_state
>> *conn_state,
>> >> > >> > > > struct link_config_limits *limits) {
>> >> > >> > > > + struct intel_cdclk_state *cdclk_state;
>> >> > >> > > > struct intel_digital_port *dig_port =
>> dp_to_dig_port(intel_dp);
>> >> > >> > > > struct drm_i915_private *dev_priv = to_i915(dig_port-
>> >> > >> > > >base.base.dev);
>> >> > >> > > > const struct drm_display_mode *adjusted_mode =
>> >> > >> > > > &pipe_config->hw.adjusted_mode;
>> >> > >> > > > + struct intel_atomic_state *state =
>> >> > >> > > > + to_intel_atomic_state(pipe_config-
>> >> > >> > > >uapi.state);
>> >> > >> > > > int pipe_bpp;
>> >> > >> > > > int ret;
>> >> > >> > > >
>> >> > >> > > > @@ -1373,12 +1377,16 @@ static int
>> >> > >> > > > intel_dp_dsc_compute_config(struct
>> >> > >> > > intel_dp *intel_dp,
>> >> > >> > > > }
>> >> > >> > > > }
>> >> > >> > > >
>> >> > >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
>> >> > >> > > > + if (IS_ERR(cdclk_state))
>> >> > >> > > > + return PTR_ERR(cdclk_state);
>> >> > >> > > > +
>> >> > >> > > > /*
>> >> > >> > > > * VDSC engine operates at 1 Pixel per clock, so if peak pixel
>> rate
>> >> > >> > > > - * is greater than the maximum Cdclock and if slice count is
>> even
>> >> > >> > > > + * is greater than the current Cdclock and if slice
>> >> > >> > > > +count is even
>> >> > >> > > > * then we need to use 2 VDSC instances.
>> >> > >> > > > */
>> >> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq
>> ||
>> >> > >> > > > + if (adjusted_mode->crtc_clock >
>> >> > >> > > > +cdclk_state->actual.cdclk ||
>> >> > >> > >
>> >> > >> > > This is wrong. We compute the cdclk based on the
>> >> > >> > > requirements of the mode/etc., not the other way around.
>> >> > >
>> >> > > According to BSpec guideline, we decide whether we enable or
>> >> > > disable second VDSC engine, based on that condition. As I
>> >> > > understand that one is about DSC config calculation, based on CDCLK
>> which was calculated.
>> >> >
>> >> > Point is, at the time compute_config gets called, what guarantees
>> >> > are there that cdclk_state->actual.cdclk contains anything useful?
>> >> > This is the design we have.
>> >>
>> >> That is actually good question, was willing to check that as well.
>> >>
>> >> >
>> >> > > If we bump up CDCLK, to avoid this, will we even then use a second
>> VDSC ever?
>> >> >
>> >> > I think we'll eventually need better logic than unconditionally
>> >> > bumping to max, and it needs to take *both* the cdclk and the
>> >> > number of dsc engines into account. The referenced bspec only has
>> >> > the vdsc clock perspective, not overall perspective.
>> >>
>> >> What we need to clarify here is that how this is supposed to work in
>> theory.
>> >> Basically same issue can be fixed by both increasing the CDCLK or
>> >> enabling 2nd VDSC engine.
>> >> There should be some guideline telling us, how to prioritize.
>> >> From overall perspective as I understand, by default, we are able to
>> >> keep CDCLK 2 times less than pixel rate(see
>> >> intel_pixel_rate_to_cdclk), however due to that VDSC limitation that
>> >> it can use only 1 ppc this becomes, not applicable anymore(at least
>> >> as of BSpec 49259), so we have to increase amount of VDSC instances
>> then.
>> >>
>> >> So the question is now - what is more optimal here?
>> >> Also if we bump up CDCLK(which we have done many times already in
>> >> fact), we then need to add some logic to intel_compute_min_cdclk to
>> >> check if we are using DSC or not, because otherwise we don't really need
>> to do that.
>>
>> intel_compute_min_cdclk() already needs to be dsc aware when slice count
>> is 1 and we can't use two dsc engines anyway. See the recent commit
>> fe01883fdcef ("drm/i915: Get proper min cdclk if vDSC enabled").
>>
>> Looking again, I'm not sure that does the right decision for when
>> dsc.slice_count > 1, but dsc.split == false. It should probably use dsc.split for
>> the decision.
>>
>> >>
>> >> Stan
>> >
>> > Checked and indeed, encoder->compute_config is called way before,
>> > basically CDCLK calculation is called almost in the end of
>> > atomic_check, so in compute_config, there would be an old CDCLK value
>> > copied from previous cdclk state, but not the last one.
>> >
>> > Vandita, this means we actually can't do it that way, if you want to
>> > do anything with VDSC based on CDCLK this has to be done _after_
>> > intel_compute_min_cdclk was called. Which is not very sweet, I guess.
>> >
>> > So as of current architecture, it seems that the easiest way is indeed
>> > to bump the CDCLK or we need to figure the way how to enable 2nd VDSC
>> > somewhere else, after CDCLK was calculated.
>>
>> Alternatively, we could use two dsc engines more aggressively, but that
>> decision currently can't take overall chosen cdclk into account.
>>
>> We'll end up sometimes unnecessarily using a too high cdclk or two dsc
>> engines, just have to pick the poison.
>>
>> I think trying to do dsc decisions after intel_compute_min_cdclk() gets way
>> too complicated.
>
> In this case, can we just use the 2nd VDSC engine if slice_count is 2 or more?
> Which would mean we always operate in joiner enabled mode(small joiner) of all the compression modes of operation
> mentioned in the table bspec: 49259
> Because we are still going to hit the max cdclk restriction for higher resolutions, and many lower resolutions wouldn’t need max cdclk.
> And eventually once we have more details on cd clk vs 2VDSC engine we could add
> the logic to choose one over the other?
>
> I see that in case of DSI we do split = true, for slice_count > 1 but that would need a different set of checks, thats a TBD.
>
> Or Do you suggest I just do this for now max cdclk when slice_count =1 (what we are doing now) replace with compression = true and split = false
I think the check in intel_compute_min_cdclk() should be:
if (crtc_state->dsc.compression_enable && !crtc_state->dsc.dsc_split)
That's a separate change.
Enabling two dsc engines more aggressively... I don't mind doing it
unconditionally when slice count > 1 for starters. But I think we'll
need to improve this going forward, including fixing the mode valid
checks etc. as we've discussed.
Ville, any objections?
BR,
Jani.
>
> Thanks,
> Vandita
>>
>> BR,
>> Jani
>>
>>
>>
>>
>> >
>> > Stan
>> >
>> >>
>> >> >
>> >> > BR,
>> >> > Jani.
>> >> >
>> >> > > Another thing is that probably enabling second VDSC is cheaper in
>> >> > > terms of power consumption, than bumping up the CDCLK.
>> >> > >
>> >> > > Stan
>> >> > >
>> >> > >> >
>> >> > >> > Okay , So you suggest that we set the cd clock to max when we
>> have such requirement, than enabling the second engine?
>> >> > >>
>> >> > >> That seems like the easiest solution. Another option might be to
>> >> > >> come up with some lower dotclock limit for the use of the second
>> >> > >> vdsc. But not sure we know where the tipping point is wrt. powr
>> consumption.
>> >> > >>
>> >> > >> --
>> >> > >> Ville Syrjälä
>> >> > >> Intel
>> >> >
>> >> > --
>> >> > Jani Nikula, Intel Open Source Graphics Center
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2021-09-14 15:10 ` Jani Nikula
@ 2022-01-10 7:15 ` Kulkarni, Vandita
2022-01-10 19:36 ` Navare, Manasi
0 siblings, 1 reply; 20+ messages in thread
From: Kulkarni, Vandita @ 2022-01-10 7:15 UTC (permalink / raw)
To: Nikula, Jani, Lisovskiy, Stanislav; +Cc: intel-gfx
Revisiting this thread after update from the bspec.
> -----Original Message-----
> From: Nikula, Jani <jani.nikula@intel.com>
> Sent: Tuesday, September 14, 2021 8:40 PM
> To: Kulkarni, Vandita <vandita.kulkarni@intel.com>; Lisovskiy, Stanislav
> <stanislav.lisovskiy@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; intel-
> gfx@lists.freedesktop.org; Navare, Manasi D <manasi.d.navare@intel.com>
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
>
> On Tue, 14 Sep 2021, "Kulkarni, Vandita" <vandita.kulkarni@intel.com>
> wrote:
> >> -----Original Message-----
> >> From: Nikula, Jani <jani.nikula@intel.com>
> >> Sent: Tuesday, September 14, 2021 7:33 PM
> >> To: Lisovskiy, Stanislav <stanislav.lisovskiy@intel.com>
> >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; Kulkarni, Vandita
> >> <vandita.kulkarni@intel.com>; intel-gfx@lists.freedesktop.org;
> >> Navare, Manasi D <manasi.d.navare@intel.com>
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> >> engine for higher moderates
> >>
> >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> >> <stanislav.lisovskiy@intel.com>
> >> wrote:
> >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> >> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> >> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> >> <stanislav.lisovskiy@intel.com> wrote:
> >> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> >> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita
> wrote:
> >> >> > >> > > -----Original Message-----
> >> >> > >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> >> >> > >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> >> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> >> >> > >> > > <jani.nikula@intel.com>; Navare, Manasi D
> >> >> > >> > > <manasi.d.navare@intel.com>
> >> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable
> >> >> > >> > > second VDSC engine for higher moderates
> >> >> > >> > >
> >> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita
> >> >> > >> > > Kulkarni
> >> wrote:
> >> >> > >> > > > Each VDSC operates with 1ppc throughput, hence enable
> >> >> > >> > > > the second VDSC engine when moderate is higher that the
> >> >> > >> > > > current
> >> cdclk.
> >> >> > >> > > >
> >> >> > >> > > > Signed-off-by: Vandita Kulkarni
> >> >> > >> > > > <vandita.kulkarni@intel.com>
> >> >> > >> > > > ---
> >> >> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12
> >> >> > >> > > > ++++++++++--
> >> >> > >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> >> >> > >> > > >
> >> >> > >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> > >> > > > index 161c33b2c869..55878f65f724 100644
> >> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> >> > >> > > > @@ -70,6 +70,7 @@
> >> >> > >> > > > #include "intel_tc.h"
> >> >> > >> > > > #include "intel_vdsc.h"
> >> >> > >> > > > #include "intel_vrr.h"
> >> >> > >> > > > +#include "intel_cdclk.h"
> >> >> > >> > > >
> >> >> > >> > > > #define DP_DPRX_ESI_LEN 14
> >> >> > >> > > >
> >> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
> >> >> > >> > > > intel_dp_dsc_compute_config(struct
> >> >> > >> > > intel_dp *intel_dp,
> >> >> > >> > > > struct
> drm_connector_state
> >> *conn_state,
> >> >> > >> > > > struct link_config_limits
> *limits) {
> >> >> > >> > > > + struct intel_cdclk_state *cdclk_state;
> >> >> > >> > > > struct intel_digital_port *dig_port =
> >> dp_to_dig_port(intel_dp);
> >> >> > >> > > > struct drm_i915_private *dev_priv =
> to_i915(dig_port-
> >> >> > >> > > >base.base.dev);
> >> >> > >> > > > const struct drm_display_mode *adjusted_mode =
> >> >> > >> > > > &pipe_config->hw.adjusted_mode;
> >> >> > >> > > > + struct intel_atomic_state *state =
> >> >> > >> > > > +
> to_intel_atomic_state(pipe_config-
> >> >> > >> > > >uapi.state);
> >> >> > >> > > > int pipe_bpp;
> >> >> > >> > > > int ret;
> >> >> > >> > > >
> >> >> > >> > > > @@ -1373,12 +1377,16 @@ static int
> >> >> > >> > > > intel_dp_dsc_compute_config(struct
> >> >> > >> > > intel_dp *intel_dp,
> >> >> > >> > > > }
> >> >> > >> > > > }
> >> >> > >> > > >
> >> >> > >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> >> >> > >> > > > + if (IS_ERR(cdclk_state))
> >> >> > >> > > > + return PTR_ERR(cdclk_state);
> >> >> > >> > > > +
> >> >> > >> > > > /*
> >> >> > >> > > > * VDSC engine operates at 1 Pixel per clock, so if
> >> >> > >> > > > peak pixel
> >> rate
> >> >> > >> > > > - * is greater than the maximum Cdclock and if slice
> count is
> >> even
> >> >> > >> > > > + * is greater than the current Cdclock and if slice
> >> >> > >> > > > +count is even
> >> >> > >> > > > * then we need to use 2 VDSC instances.
> >> >> > >> > > > */
> >> >> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv-
> >max_cdclk_freq
> >> ||
> >> >> > >> > > > + if (adjusted_mode->crtc_clock >
> >> >> > >> > > > +cdclk_state->actual.cdclk ||
> >> >> > >> > >
> >> >> > >> > > This is wrong. We compute the cdclk based on the
> >> >> > >> > > requirements of the mode/etc., not the other way around.
> >> >> > >
> >> >> > > According to BSpec guideline, we decide whether we enable or
> >> >> > > disable second VDSC engine, based on that condition. As I
> >> >> > > understand that one is about DSC config calculation, based on
> >> >> > > CDCLK
> >> which was calculated.
> >> >> >
> >> >> > Point is, at the time compute_config gets called, what
> >> >> > guarantees are there that cdclk_state->actual.cdclk contains
> anything useful?
> >> >> > This is the design we have.
> >> >>
> >> >> That is actually good question, was willing to check that as well.
> >> >>
> >> >> >
> >> >> > > If we bump up CDCLK, to avoid this, will we even then use a
> >> >> > > second
> >> VDSC ever?
> >> >> >
> >> >> > I think we'll eventually need better logic than unconditionally
> >> >> > bumping to max, and it needs to take *both* the cdclk and the
> >> >> > number of dsc engines into account. The referenced bspec only
> >> >> > has the vdsc clock perspective, not overall perspective.
> >> >>
> >> >> What we need to clarify here is that how this is supposed to work
> >> >> in
> >> theory.
> >> >> Basically same issue can be fixed by both increasing the CDCLK or
> >> >> enabling 2nd VDSC engine.
> >> >> There should be some guideline telling us, how to prioritize.
> >> >> From overall perspective as I understand, by default, we are able
> >> >> to keep CDCLK 2 times less than pixel rate(see
> >> >> intel_pixel_rate_to_cdclk), however due to that VDSC limitation
> >> >> that it can use only 1 ppc this becomes, not applicable anymore(at
> >> >> least as of BSpec 49259), so we have to increase amount of VDSC
> >> >> instances
> >> then.
> >> >>
> >> >> So the question is now - what is more optimal here?
> >> >> Also if we bump up CDCLK(which we have done many times already in
> >> >> fact), we then need to add some logic to intel_compute_min_cdclk
> >> >> to check if we are using DSC or not, because otherwise we don't
> >> >> really need
> >> to do that.
> >>
> >> intel_compute_min_cdclk() already needs to be dsc aware when slice
> >> count is 1 and we can't use two dsc engines anyway. See the recent
> >> commit fe01883fdcef ("drm/i915: Get proper min cdclk if vDSC enabled").
> >>
> >> Looking again, I'm not sure that does the right decision for when
> >> dsc.slice_count > 1, but dsc.split == false. It should probably use
> >> dsc.split for the decision.
> >>
> >> >>
> >> >> Stan
> >> >
> >> > Checked and indeed, encoder->compute_config is called way before,
> >> > basically CDCLK calculation is called almost in the end of
> >> > atomic_check, so in compute_config, there would be an old CDCLK
> >> > value copied from previous cdclk state, but not the last one.
> >> >
> >> > Vandita, this means we actually can't do it that way, if you want
> >> > to do anything with VDSC based on CDCLK this has to be done _after_
> >> > intel_compute_min_cdclk was called. Which is not very sweet, I guess.
> >> >
> >> > So as of current architecture, it seems that the easiest way is
> >> > indeed to bump the CDCLK or we need to figure the way how to enable
> >> > 2nd VDSC somewhere else, after CDCLK was calculated.
> >>
> >> Alternatively, we could use two dsc engines more aggressively, but
> >> that decision currently can't take overall chosen cdclk into account.
> >>
> >> We'll end up sometimes unnecessarily using a too high cdclk or two
> >> dsc engines, just have to pick the poison.
> >>
> >> I think trying to do dsc decisions after intel_compute_min_cdclk()
> >> gets way too complicated.
> >
> > In this case, can we just use the 2nd VDSC engine if slice_count is 2 or
> more?
> > Which would mean we always operate in joiner enabled mode(small
> > joiner) of all the compression modes of operation mentioned in the
> > table bspec: 49259 Because we are still going to hit the max cdclk restriction
> for higher resolutions, and many lower resolutions wouldn’t need max cdclk.
> > And eventually once we have more details on cd clk vs 2VDSC engine we
> > could add the logic to choose one over the other?
> >
> > I see that in case of DSI we do split = true, for slice_count > 1 but that
> would need a different set of checks, thats a TBD.
> >
> > Or Do you suggest I just do this for now max cdclk when slice_count =1
> > (what we are doing now) replace with compression = true and split =
> > false
>
> I think the check in intel_compute_min_cdclk() should be:
>
> if (crtc_state->dsc.compression_enable && !crtc_state-
> >dsc.dsc_split)
>
> That's a separate change.
>
> Enabling two dsc engines more aggressively... I don't mind doing it
> unconditionally when slice count > 1 for starters. But I think we'll need to
> improve this going forward, including fixing the mode valid checks etc. as
> we've discussed.
Design recommendation is to use 2 VDSC instances while meeting the following constraint so that cdclk can stay as low as possible.
DP/HDMI PPR spec provided slice size < DPCD provided MaxSliceWidth
Thanks,
Vandita
>
> Ville, any objections?
>
> BR,
> Jani.
>
>
> >
> > Thanks,
> > Vandita
> >>
> >> BR,
> >> Jani
> >>
> >>
> >>
> >>
> >> >
> >> > Stan
> >> >
> >> >>
> >> >> >
> >> >> > BR,
> >> >> > Jani.
> >> >> >
> >> >> > > Another thing is that probably enabling second VDSC is cheaper
> >> >> > > in terms of power consumption, than bumping up the CDCLK.
> >> >> > >
> >> >> > > Stan
> >> >> > >
> >> >> > >> >
> >> >> > >> > Okay , So you suggest that we set the cd clock to max when
> >> >> > >> > we
> >> have such requirement, than enabling the second engine?
> >> >> > >>
> >> >> > >> That seems like the easiest solution. Another option might be
> >> >> > >> to come up with some lower dotclock limit for the use of the
> >> >> > >> second vdsc. But not sure we know where the tipping point is
> >> >> > >> wrt. powr
> >> consumption.
> >> >> > >>
> >> >> > >> --
> >> >> > >> Ville Syrjälä
> >> >> > >> Intel
> >> >> >
> >> >> > --
> >> >> > Jani Nikula, Intel Open Source Graphics Center
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
>
> --
> Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2022-01-10 7:15 ` Kulkarni, Vandita
@ 2022-01-10 19:36 ` Navare, Manasi
2022-01-11 4:24 ` Kulkarni, Vandita
0 siblings, 1 reply; 20+ messages in thread
From: Navare, Manasi @ 2022-01-10 19:36 UTC (permalink / raw)
To: Kulkarni, Vandita; +Cc: Nikula, Jani, intel-gfx
Thankf for revisiting this thread. The use of max_cdclk is currently in 2 places in DSC code
1. . if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq) {
if (pipe_config->dsc.slice_count > 1) {
pipe_config->dsc.dsc_split = true;
2. if (bigjoiner) {
u32 max_bpp_bigjoiner =
i915->max_cdclk_freq * 48 /
intel_dp_mode_to_fec_clock(mode_clock);
DRM_DEBUG_KMS("Max big joiner bpp: %u\n", max_bpp_bigjoiner);
bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
}
In both these places, using max_cdclk can cause problems, like for compressed bpp it can give a higher bpp based
on max_cdclk and we might actually end up chosing lower cdclk at what point this will cause underruns.
So when I was discussing with Ville on this, my first thought was also to use the cdclk_state->actual_cdclk but like
Ville mentioned later in the review comments the challenge there was that actual cdclk does get computed
much later than dsc_compute_config.
So I think as suggested in one of the reviews we just to check if DSC is enabled then we dont allow lowering the cdclk
which would also prevent underruns caused by possibly setting up higher bpp based on max cdclk.
@Ville @Jani does this sound like a good approach. Then @Vandita we can pursue that change.
Regards
Manasi
On Sun, Jan 09, 2022 at 11:15:04PM -0800, Kulkarni, Vandita wrote:
> Revisiting this thread after update from the bspec.
>
> > -----Original Message-----
> > From: Nikula, Jani <jani.nikula@intel.com>
> > Sent: Tuesday, September 14, 2021 8:40 PM
> > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>; Lisovskiy, Stanislav
> > <stanislav.lisovskiy@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; intel-
> > gfx@lists.freedesktop.org; Navare, Manasi D <manasi.d.navare@intel.com>
> > Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > engine for higher moderates
> >
> > On Tue, 14 Sep 2021, "Kulkarni, Vandita" <vandita.kulkarni@intel.com>
> > wrote:
> > >> -----Original Message-----
> > >> From: Nikula, Jani <jani.nikula@intel.com>
> > >> Sent: Tuesday, September 14, 2021 7:33 PM
> > >> To: Lisovskiy, Stanislav <stanislav.lisovskiy@intel.com>
> > >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; Kulkarni, Vandita
> > >> <vandita.kulkarni@intel.com>; intel-gfx@lists.freedesktop.org;
> > >> Navare, Manasi D <manasi.d.navare@intel.com>
> > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > >> engine for higher moderates
> > >>
> > >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > >> <stanislav.lisovskiy@intel.com>
> > >> wrote:
> > >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> > >> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > >> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > >> <stanislav.lisovskiy@intel.com> wrote:
> > >> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> > >> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni, Vandita
> > wrote:
> > >> >> > >> > > -----Original Message-----
> > >> >> > >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > >> >> > >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> > >> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > >> >> > >> > > <jani.nikula@intel.com>; Navare, Manasi D
> > >> >> > >> > > <manasi.d.navare@intel.com>
> > >> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable
> > >> >> > >> > > second VDSC engine for higher moderates
> > >> >> > >> > >
> > >> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita
> > >> >> > >> > > Kulkarni
> > >> wrote:
> > >> >> > >> > > > Each VDSC operates with 1ppc throughput, hence enable
> > >> >> > >> > > > the second VDSC engine when moderate is higher that the
> > >> >> > >> > > > current
> > >> cdclk.
> > >> >> > >> > > >
> > >> >> > >> > > > Signed-off-by: Vandita Kulkarni
> > >> >> > >> > > > <vandita.kulkarni@intel.com>
> > >> >> > >> > > > ---
> > >> >> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12
> > >> >> > >> > > > ++++++++++--
> > >> >> > >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >> >> > >> > > >
> > >> >> > >> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > >> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > >> >> > >> > > > index 161c33b2c869..55878f65f724 100644
> > >> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > >> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > >> >> > >> > > > @@ -70,6 +70,7 @@
> > >> >> > >> > > > #include "intel_tc.h"
> > >> >> > >> > > > #include "intel_vdsc.h"
> > >> >> > >> > > > #include "intel_vrr.h"
> > >> >> > >> > > > +#include "intel_cdclk.h"
> > >> >> > >> > > >
> > >> >> > >> > > > #define DP_DPRX_ESI_LEN 14
> > >> >> > >> > > >
> > >> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
> > >> >> > >> > > > intel_dp_dsc_compute_config(struct
> > >> >> > >> > > intel_dp *intel_dp,
> > >> >> > >> > > > struct
> > drm_connector_state
> > >> *conn_state,
> > >> >> > >> > > > struct link_config_limits
> > *limits) {
> > >> >> > >> > > > + struct intel_cdclk_state *cdclk_state;
> > >> >> > >> > > > struct intel_digital_port *dig_port =
> > >> dp_to_dig_port(intel_dp);
> > >> >> > >> > > > struct drm_i915_private *dev_priv =
> > to_i915(dig_port-
> > >> >> > >> > > >base.base.dev);
> > >> >> > >> > > > const struct drm_display_mode *adjusted_mode =
> > >> >> > >> > > > &pipe_config->hw.adjusted_mode;
> > >> >> > >> > > > + struct intel_atomic_state *state =
> > >> >> > >> > > > +
> > to_intel_atomic_state(pipe_config-
> > >> >> > >> > > >uapi.state);
> > >> >> > >> > > > int pipe_bpp;
> > >> >> > >> > > > int ret;
> > >> >> > >> > > >
> > >> >> > >> > > > @@ -1373,12 +1377,16 @@ static int
> > >> >> > >> > > > intel_dp_dsc_compute_config(struct
> > >> >> > >> > > intel_dp *intel_dp,
> > >> >> > >> > > > }
> > >> >> > >> > > > }
> > >> >> > >> > > >
> > >> >> > >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > >> >> > >> > > > + if (IS_ERR(cdclk_state))
> > >> >> > >> > > > + return PTR_ERR(cdclk_state);
> > >> >> > >> > > > +
> > >> >> > >> > > > /*
> > >> >> > >> > > > * VDSC engine operates at 1 Pixel per clock, so if
> > >> >> > >> > > > peak pixel
> > >> rate
> > >> >> > >> > > > - * is greater than the maximum Cdclock and if slice
> > count is
> > >> even
> > >> >> > >> > > > + * is greater than the current Cdclock and if slice
> > >> >> > >> > > > +count is even
> > >> >> > >> > > > * then we need to use 2 VDSC instances.
> > >> >> > >> > > > */
> > >> >> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv-
> > >max_cdclk_freq
> > >> ||
> > >> >> > >> > > > + if (adjusted_mode->crtc_clock >
> > >> >> > >> > > > +cdclk_state->actual.cdclk ||
> > >> >> > >> > >
> > >> >> > >> > > This is wrong. We compute the cdclk based on the
> > >> >> > >> > > requirements of the mode/etc., not the other way around.
> > >> >> > >
> > >> >> > > According to BSpec guideline, we decide whether we enable or
> > >> >> > > disable second VDSC engine, based on that condition. As I
> > >> >> > > understand that one is about DSC config calculation, based on
> > >> >> > > CDCLK
> > >> which was calculated.
> > >> >> >
> > >> >> > Point is, at the time compute_config gets called, what
> > >> >> > guarantees are there that cdclk_state->actual.cdclk contains
> > anything useful?
> > >> >> > This is the design we have.
> > >> >>
> > >> >> That is actually good question, was willing to check that as well.
> > >> >>
> > >> >> >
> > >> >> > > If we bump up CDCLK, to avoid this, will we even then use a
> > >> >> > > second
> > >> VDSC ever?
> > >> >> >
> > >> >> > I think we'll eventually need better logic than unconditionally
> > >> >> > bumping to max, and it needs to take *both* the cdclk and the
> > >> >> > number of dsc engines into account. The referenced bspec only
> > >> >> > has the vdsc clock perspective, not overall perspective.
> > >> >>
> > >> >> What we need to clarify here is that how this is supposed to work
> > >> >> in
> > >> theory.
> > >> >> Basically same issue can be fixed by both increasing the CDCLK or
> > >> >> enabling 2nd VDSC engine.
> > >> >> There should be some guideline telling us, how to prioritize.
> > >> >> From overall perspective as I understand, by default, we are able
> > >> >> to keep CDCLK 2 times less than pixel rate(see
> > >> >> intel_pixel_rate_to_cdclk), however due to that VDSC limitation
> > >> >> that it can use only 1 ppc this becomes, not applicable anymore(at
> > >> >> least as of BSpec 49259), so we have to increase amount of VDSC
> > >> >> instances
> > >> then.
> > >> >>
> > >> >> So the question is now - what is more optimal here?
> > >> >> Also if we bump up CDCLK(which we have done many times already in
> > >> >> fact), we then need to add some logic to intel_compute_min_cdclk
> > >> >> to check if we are using DSC or not, because otherwise we don't
> > >> >> really need
> > >> to do that.
> > >>
> > >> intel_compute_min_cdclk() already needs to be dsc aware when slice
> > >> count is 1 and we can't use two dsc engines anyway. See the recent
> > >> commit fe01883fdcef ("drm/i915: Get proper min cdclk if vDSC enabled").
> > >>
> > >> Looking again, I'm not sure that does the right decision for when
> > >> dsc.slice_count > 1, but dsc.split == false. It should probably use
> > >> dsc.split for the decision.
> > >>
> > >> >>
> > >> >> Stan
> > >> >
> > >> > Checked and indeed, encoder->compute_config is called way before,
> > >> > basically CDCLK calculation is called almost in the end of
> > >> > atomic_check, so in compute_config, there would be an old CDCLK
> > >> > value copied from previous cdclk state, but not the last one.
> > >> >
> > >> > Vandita, this means we actually can't do it that way, if you want
> > >> > to do anything with VDSC based on CDCLK this has to be done _after_
> > >> > intel_compute_min_cdclk was called. Which is not very sweet, I guess.
> > >> >
> > >> > So as of current architecture, it seems that the easiest way is
> > >> > indeed to bump the CDCLK or we need to figure the way how to enable
> > >> > 2nd VDSC somewhere else, after CDCLK was calculated.
> > >>
> > >> Alternatively, we could use two dsc engines more aggressively, but
> > >> that decision currently can't take overall chosen cdclk into account.
> > >>
> > >> We'll end up sometimes unnecessarily using a too high cdclk or two
> > >> dsc engines, just have to pick the poison.
> > >>
> > >> I think trying to do dsc decisions after intel_compute_min_cdclk()
> > >> gets way too complicated.
> > >
> > > In this case, can we just use the 2nd VDSC engine if slice_count is 2 or
> > more?
> > > Which would mean we always operate in joiner enabled mode(small
> > > joiner) of all the compression modes of operation mentioned in the
> > > table bspec: 49259 Because we are still going to hit the max cdclk restriction
> > for higher resolutions, and many lower resolutions wouldn’t need max cdclk.
> > > And eventually once we have more details on cd clk vs 2VDSC engine we
> > > could add the logic to choose one over the other?
> > >
> > > I see that in case of DSI we do split = true, for slice_count > 1 but that
> > would need a different set of checks, thats a TBD.
> > >
> > > Or Do you suggest I just do this for now max cdclk when slice_count =1
> > > (what we are doing now) replace with compression = true and split =
> > > false
> >
> > I think the check in intel_compute_min_cdclk() should be:
> >
> > if (crtc_state->dsc.compression_enable && !crtc_state-
> > >dsc.dsc_split)
> >
> > That's a separate change.
> >
> > Enabling two dsc engines more aggressively... I don't mind doing it
> > unconditionally when slice count > 1 for starters. But I think we'll need to
> > improve this going forward, including fixing the mode valid checks etc. as
> > we've discussed.
>
> Design recommendation is to use 2 VDSC instances while meeting the following constraint so that cdclk can stay as low as possible.
> DP/HDMI PPR spec provided slice size < DPCD provided MaxSliceWidth
>
> Thanks,
> Vandita
> >
> > Ville, any objections?
> >
> > BR,
> > Jani.
> >
> >
> > >
> > > Thanks,
> > > Vandita
> > >>
> > >> BR,
> > >> Jani
> > >>
> > >>
> > >>
> > >>
> > >> >
> > >> > Stan
> > >> >
> > >> >>
> > >> >> >
> > >> >> > BR,
> > >> >> > Jani.
> > >> >> >
> > >> >> > > Another thing is that probably enabling second VDSC is cheaper
> > >> >> > > in terms of power consumption, than bumping up the CDCLK.
> > >> >> > >
> > >> >> > > Stan
> > >> >> > >
> > >> >> > >> >
> > >> >> > >> > Okay , So you suggest that we set the cd clock to max when
> > >> >> > >> > we
> > >> have such requirement, than enabling the second engine?
> > >> >> > >>
> > >> >> > >> That seems like the easiest solution. Another option might be
> > >> >> > >> to come up with some lower dotclock limit for the use of the
> > >> >> > >> second vdsc. But not sure we know where the tipping point is
> > >> >> > >> wrt. powr
> > >> consumption.
> > >> >> > >>
> > >> >> > >> --
> > >> >> > >> Ville Syrjälä
> > >> >> > >> Intel
> > >> >> >
> > >> >> > --
> > >> >> > Jani Nikula, Intel Open Source Graphics Center
> > >>
> > >> --
> > >> Jani Nikula, Intel Open Source Graphics Center
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2022-01-10 19:36 ` Navare, Manasi
@ 2022-01-11 4:24 ` Kulkarni, Vandita
2022-01-11 6:12 ` Navare, Manasi
0 siblings, 1 reply; 20+ messages in thread
From: Kulkarni, Vandita @ 2022-01-11 4:24 UTC (permalink / raw)
To: Navare, Manasi D, Nikula, Jani; +Cc: intel-gfx
> -----Original Message-----
> From: Navare, Manasi D <manasi.d.navare@intel.com>
> Sent: Tuesday, January 11, 2022 1:07 AM
> To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> Cc: Nikula, Jani <jani.nikula@intel.com>; Lisovskiy, Stanislav
> <stanislav.lisovskiy@intel.com>; Ville Syrjälä <ville.syrjala@linux.intel.com>;
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
>
> Thankf for revisiting this thread. The use of max_cdclk is currently in 2 places
> in DSC code 1. . if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq)
> {
> if (pipe_config->dsc.slice_count > 1) {
> pipe_config->dsc.dsc_split = true; 2. if (bigjoiner) {
> u32 max_bpp_bigjoiner =
> i915->max_cdclk_freq * 48 /
> intel_dp_mode_to_fec_clock(mode_clock);
>
> DRM_DEBUG_KMS("Max big joiner bpp: %u\n",
> max_bpp_bigjoiner);
> bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> }
>
> In both these places, using max_cdclk can cause problems, like for
> compressed bpp it can give a higher bpp based on max_cdclk and we might
> actually end up chosing lower cdclk at what point this will cause underruns.
>
> So when I was discussing with Ville on this, my first thought was also to use
> the cdclk_state->actual_cdclk but like Ville mentioned later in the review
> comments the challenge there was that actual cdclk does get computed
> much later than dsc_compute_config.
>
> So I think as suggested in one of the reviews we just to check if DSC is
> enabled then we dont allow lowering the cdclk which would also prevent
> underruns caused by possibly setting up higher bpp based on max cdclk.
Thanks for the review.
This is taken care now, in case if we cannot split, then we already are using max_cdclk.
Regarding the bigjoiner_bpp, you may need to make the change if you need it to be set to max cdclk.
As we all of us here agree that we do not have computed cd clk at that time.
>
> @Ville @Jani does this sound like a good approach. Then @Vandita we can
> pursue that change.
>
> Regards
> Manasi
>
> On Sun, Jan 09, 2022 at 11:15:04PM -0800, Kulkarni, Vandita wrote:
> > Revisiting this thread after update from the bspec.
> >
> > > -----Original Message-----
> > > From: Nikula, Jani <jani.nikula@intel.com>
> > > Sent: Tuesday, September 14, 2021 8:40 PM
> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>; Lisovskiy,
> > > Stanislav <stanislav.lisovskiy@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; intel-
> > > gfx@lists.freedesktop.org; Navare, Manasi D
> > > <manasi.d.navare@intel.com>
> > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > VDSC engine for higher moderates
> > >
> > > On Tue, 14 Sep 2021, "Kulkarni, Vandita"
> > > <vandita.kulkarni@intel.com>
> > > wrote:
> > > >> -----Original Message-----
> > > >> From: Nikula, Jani <jani.nikula@intel.com>
> > > >> Sent: Tuesday, September 14, 2021 7:33 PM
> > > >> To: Lisovskiy, Stanislav <stanislav.lisovskiy@intel.com>
> > > >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; Kulkarni,
> > > >> Vandita <vandita.kulkarni@intel.com>;
> > > >> intel-gfx@lists.freedesktop.org; Navare, Manasi D
> > > >> <manasi.d.navare@intel.com>
> > > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > >> VDSC engine for higher moderates
> > > >>
> > > >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > >> <stanislav.lisovskiy@intel.com>
> > > >> wrote:
> > > >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> > > >> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > > >> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > >> <stanislav.lisovskiy@intel.com> wrote:
> > > >> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> > > >> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni,
> > > >> >> > >> Vandita
> > > wrote:
> > > >> >> > >> > > -----Original Message-----
> > > >> >> > >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > > >> >> > >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> > > >> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > >> >> > >> > > <jani.nikula@intel.com>; Navare, Manasi D
> > > >> >> > >> > > <manasi.d.navare@intel.com>
> > > >> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display:
> > > >> >> > >> > > Enable second VDSC engine for higher moderates
> > > >> >> > >> > >
> > > >> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita
> > > >> >> > >> > > Kulkarni
> > > >> wrote:
> > > >> >> > >> > > > Each VDSC operates with 1ppc throughput, hence
> > > >> >> > >> > > > enable the second VDSC engine when moderate is
> > > >> >> > >> > > > higher that the current
> > > >> cdclk.
> > > >> >> > >> > > >
> > > >> >> > >> > > > Signed-off-by: Vandita Kulkarni
> > > >> >> > >> > > > <vandita.kulkarni@intel.com>
> > > >> >> > >> > > > ---
> > > >> >> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12
> > > >> >> > >> > > > ++++++++++--
> > > >> >> > >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > > >> >> > >> > > >
> > > >> >> > >> > > > diff --git
> > > >> >> > >> > > > a/drivers/gpu/drm/i915/display/intel_dp.c
> > > >> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > >> >> > >> > > > index 161c33b2c869..55878f65f724 100644
> > > >> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > >> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > >> >> > >> > > > @@ -70,6 +70,7 @@
> > > >> >> > >> > > > #include "intel_tc.h"
> > > >> >> > >> > > > #include "intel_vdsc.h"
> > > >> >> > >> > > > #include "intel_vrr.h"
> > > >> >> > >> > > > +#include "intel_cdclk.h"
> > > >> >> > >> > > >
> > > >> >> > >> > > > #define DP_DPRX_ESI_LEN 14
> > > >> >> > >> > > >
> > > >> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
> > > >> >> > >> > > > intel_dp_dsc_compute_config(struct
> > > >> >> > >> > > intel_dp *intel_dp,
> > > >> >> > >> > > > struct
> > > drm_connector_state
> > > >> *conn_state,
> > > >> >> > >> > > > struct link_config_limits
> > > *limits) {
> > > >> >> > >> > > > + struct intel_cdclk_state *cdclk_state;
> > > >> >> > >> > > > struct intel_digital_port *dig_port =
> > > >> dp_to_dig_port(intel_dp);
> > > >> >> > >> > > > struct drm_i915_private *dev_priv =
> > > to_i915(dig_port-
> > > >> >> > >> > > >base.base.dev);
> > > >> >> > >> > > > const struct drm_display_mode *adjusted_mode =
> > > >> >> > >> > > > &pipe_config->hw.adjusted_mode;
> > > >> >> > >> > > > + struct intel_atomic_state *state =
> > > >> >> > >> > > > +
> > > to_intel_atomic_state(pipe_config-
> > > >> >> > >> > > >uapi.state);
> > > >> >> > >> > > > int pipe_bpp;
> > > >> >> > >> > > > int ret;
> > > >> >> > >> > > >
> > > >> >> > >> > > > @@ -1373,12 +1377,16 @@ static int
> > > >> >> > >> > > > intel_dp_dsc_compute_config(struct
> > > >> >> > >> > > intel_dp *intel_dp,
> > > >> >> > >> > > > }
> > > >> >> > >> > > > }
> > > >> >> > >> > > >
> > > >> >> > >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > > >> >> > >> > > > + if (IS_ERR(cdclk_state))
> > > >> >> > >> > > > + return PTR_ERR(cdclk_state);
> > > >> >> > >> > > > +
> > > >> >> > >> > > > /*
> > > >> >> > >> > > > * VDSC engine operates at 1 Pixel per clock, so
> > > >> >> > >> > > > if peak pixel
> > > >> rate
> > > >> >> > >> > > > - * is greater than the maximum Cdclock and if slice
> > > count is
> > > >> even
> > > >> >> > >> > > > + * is greater than the current Cdclock and if
> > > >> >> > >> > > > +slice count is even
> > > >> >> > >> > > > * then we need to use 2 VDSC instances.
> > > >> >> > >> > > > */
> > > >> >> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv-
> > > >max_cdclk_freq
> > > >> ||
> > > >> >> > >> > > > + if (adjusted_mode->crtc_clock >
> > > >> >> > >> > > > +cdclk_state->actual.cdclk ||
> > > >> >> > >> > >
> > > >> >> > >> > > This is wrong. We compute the cdclk based on the
> > > >> >> > >> > > requirements of the mode/etc., not the other way
> around.
> > > >> >> > >
> > > >> >> > > According to BSpec guideline, we decide whether we enable
> > > >> >> > > or disable second VDSC engine, based on that condition. As
> > > >> >> > > I understand that one is about DSC config calculation,
> > > >> >> > > based on CDCLK
> > > >> which was calculated.
> > > >> >> >
> > > >> >> > Point is, at the time compute_config gets called, what
> > > >> >> > guarantees are there that cdclk_state->actual.cdclk contains
> > > anything useful?
> > > >> >> > This is the design we have.
> > > >> >>
> > > >> >> That is actually good question, was willing to check that as well.
> > > >> >>
> > > >> >> >
> > > >> >> > > If we bump up CDCLK, to avoid this, will we even then use
> > > >> >> > > a second
> > > >> VDSC ever?
> > > >> >> >
> > > >> >> > I think we'll eventually need better logic than
> > > >> >> > unconditionally bumping to max, and it needs to take *both*
> > > >> >> > the cdclk and the number of dsc engines into account. The
> > > >> >> > referenced bspec only has the vdsc clock perspective, not overall
> perspective.
> > > >> >>
> > > >> >> What we need to clarify here is that how this is supposed to
> > > >> >> work in
> > > >> theory.
> > > >> >> Basically same issue can be fixed by both increasing the CDCLK
> > > >> >> or enabling 2nd VDSC engine.
> > > >> >> There should be some guideline telling us, how to prioritize.
> > > >> >> From overall perspective as I understand, by default, we are
> > > >> >> able to keep CDCLK 2 times less than pixel rate(see
> > > >> >> intel_pixel_rate_to_cdclk), however due to that VDSC
> > > >> >> limitation that it can use only 1 ppc this becomes, not
> > > >> >> applicable anymore(at least as of BSpec 49259), so we have to
> > > >> >> increase amount of VDSC instances
> > > >> then.
> > > >> >>
> > > >> >> So the question is now - what is more optimal here?
> > > >> >> Also if we bump up CDCLK(which we have done many times
> already
> > > >> >> in fact), we then need to add some logic to
> > > >> >> intel_compute_min_cdclk to check if we are using DSC or not,
> > > >> >> because otherwise we don't really need
> > > >> to do that.
> > > >>
> > > >> intel_compute_min_cdclk() already needs to be dsc aware when
> > > >> slice count is 1 and we can't use two dsc engines anyway. See the
> > > >> recent commit fe01883fdcef ("drm/i915: Get proper min cdclk if vDSC
> enabled").
> > > >>
> > > >> Looking again, I'm not sure that does the right decision for when
> > > >> dsc.slice_count > 1, but dsc.split == false. It should probably
> > > >> use dsc.split for the decision.
> > > >>
> > > >> >>
> > > >> >> Stan
> > > >> >
> > > >> > Checked and indeed, encoder->compute_config is called way
> > > >> > before, basically CDCLK calculation is called almost in the end
> > > >> > of atomic_check, so in compute_config, there would be an old
> > > >> > CDCLK value copied from previous cdclk state, but not the last one.
> > > >> >
> > > >> > Vandita, this means we actually can't do it that way, if you
> > > >> > want to do anything with VDSC based on CDCLK this has to be
> > > >> > done _after_ intel_compute_min_cdclk was called. Which is not
> very sweet, I guess.
> > > >> >
> > > >> > So as of current architecture, it seems that the easiest way is
> > > >> > indeed to bump the CDCLK or we need to figure the way how to
> > > >> > enable 2nd VDSC somewhere else, after CDCLK was calculated.
> > > >>
> > > >> Alternatively, we could use two dsc engines more aggressively,
> > > >> but that decision currently can't take overall chosen cdclk into account.
> > > >>
> > > >> We'll end up sometimes unnecessarily using a too high cdclk or
> > > >> two dsc engines, just have to pick the poison.
> > > >>
> > > >> I think trying to do dsc decisions after
> > > >> intel_compute_min_cdclk() gets way too complicated.
> > > >
> > > > In this case, can we just use the 2nd VDSC engine if slice_count
> > > > is 2 or
> > > more?
> > > > Which would mean we always operate in joiner enabled mode(small
> > > > joiner) of all the compression modes of operation mentioned in the
> > > > table bspec: 49259 Because we are still going to hit the max cdclk
> > > > restriction
> > > for higher resolutions, and many lower resolutions wouldn’t need max
> cdclk.
> > > > And eventually once we have more details on cd clk vs 2VDSC engine
> > > > we could add the logic to choose one over the other?
> > > >
> > > > I see that in case of DSI we do split = true, for slice_count > 1
> > > > but that
> > > would need a different set of checks, thats a TBD.
> > > >
> > > > Or Do you suggest I just do this for now max cdclk when
> > > > slice_count =1 (what we are doing now) replace with compression =
> > > > true and split = false
> > >
> > > I think the check in intel_compute_min_cdclk() should be:
> > >
> > > if (crtc_state->dsc.compression_enable && !crtc_state-
> > > >dsc.dsc_split)
> > >
> > > That's a separate change.
> > >
> > > Enabling two dsc engines more aggressively... I don't mind doing it
> > > unconditionally when slice count > 1 for starters. But I think we'll
> > > need to improve this going forward, including fixing the mode valid
> > > checks etc. as we've discussed.
> >
> > Design recommendation is to use 2 VDSC instances while meeting the
> following constraint so that cdclk can stay as low as possible.
> > DP/HDMI PPR spec provided slice size < DPCD provided MaxSliceWidth
Based on the hw recommendation to me it looks like, as @Nikula, Jani suggested
We can set split to true based on " DP/HDMI PPR spec provided slice size < DPCD provided MaxSliceWidth"
In such cases we can avoid bumping up to max cdclk for vdsc reasons.
Will make this change and float V2.
Thanks,
Vandita
> >
> > Thanks,
> > Vandita
> > >
> > > Ville, any objections?
> > >
> > > BR,
> > > Jani.
> > >
> > >
> > > >
> > > > Thanks,
> > > > Vandita
> > > >>
> > > >> BR,
> > > >> Jani
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> >
> > > >> > Stan
> > > >> >
> > > >> >>
> > > >> >> >
> > > >> >> > BR,
> > > >> >> > Jani.
> > > >> >> >
> > > >> >> > > Another thing is that probably enabling second VDSC is
> > > >> >> > > cheaper in terms of power consumption, than bumping up the
> CDCLK.
> > > >> >> > >
> > > >> >> > > Stan
> > > >> >> > >
> > > >> >> > >> >
> > > >> >> > >> > Okay , So you suggest that we set the cd clock to max
> > > >> >> > >> > when we
> > > >> have such requirement, than enabling the second engine?
> > > >> >> > >>
> > > >> >> > >> That seems like the easiest solution. Another option
> > > >> >> > >> might be to come up with some lower dotclock limit for
> > > >> >> > >> the use of the second vdsc. But not sure we know where
> > > >> >> > >> the tipping point is wrt. powr
> > > >> consumption.
> > > >> >> > >>
> > > >> >> > >> --
> > > >> >> > >> Ville Syrjälä
> > > >> >> > >> Intel
> > > >> >> >
> > > >> >> > --
> > > >> >> > Jani Nikula, Intel Open Source Graphics Center
> > > >>
> > > >> --
> > > >> Jani Nikula, Intel Open Source Graphics Center
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2022-01-11 4:24 ` Kulkarni, Vandita
@ 2022-01-11 6:12 ` Navare, Manasi
2022-01-11 6:26 ` Kulkarni, Vandita
0 siblings, 1 reply; 20+ messages in thread
From: Navare, Manasi @ 2022-01-11 6:12 UTC (permalink / raw)
To: Kulkarni, Vandita; +Cc: Nikula, Jani, intel-gfx
On Mon, Jan 10, 2022 at 08:24:54PM -0800, Kulkarni, Vandita wrote:
> > -----Original Message-----
> > From: Navare, Manasi D <manasi.d.navare@intel.com>
> > Sent: Tuesday, January 11, 2022 1:07 AM
> > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> > Cc: Nikula, Jani <jani.nikula@intel.com>; Lisovskiy, Stanislav
> > <stanislav.lisovskiy@intel.com>; Ville Syrjälä <ville.syrjala@linux.intel.com>;
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> > engine for higher moderates
> >
> > Thankf for revisiting this thread. The use of max_cdclk is currently in 2 places
> > in DSC code 1. . if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq)
> > {
> > if (pipe_config->dsc.slice_count > 1) {
> > pipe_config->dsc.dsc_split = true; 2. if (bigjoiner) {
> > u32 max_bpp_bigjoiner =
> > i915->max_cdclk_freq * 48 /
> > intel_dp_mode_to_fec_clock(mode_clock);
> >
> > DRM_DEBUG_KMS("Max big joiner bpp: %u\n",
> > max_bpp_bigjoiner);
> > bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> > }
> >
> > In both these places, using max_cdclk can cause problems, like for
> > compressed bpp it can give a higher bpp based on max_cdclk and we might
> > actually end up chosing lower cdclk at what point this will cause underruns.
> >
> > So when I was discussing with Ville on this, my first thought was also to use
> > the cdclk_state->actual_cdclk but like Ville mentioned later in the review
> > comments the challenge there was that actual cdclk does get computed
> > much later than dsc_compute_config.
> >
> > So I think as suggested in one of the reviews we just to check if DSC is
> > enabled then we dont allow lowering the cdclk which would also prevent
> > underruns caused by possibly setting up higher bpp based on max cdclk.
>
> Thanks for the review.
> This is taken care now, in case if we cannot split, then we already are using max_cdclk.
> Regarding the bigjoiner_bpp, you may need to make the change if you need it to be set to max cdclk.
> As we all of us here agree that we do not have computed cd clk at that time.
>
So the resolution was to keep it at max_cdclock when we set the dsc.split and decide to use 2 VDSC engines? Is this change merged upstream now?
For bpp calculation, that was pointed out by Srikanth that they were seeing underruns and was a bug they had found in their code.
And infact there we dont want to set it to max_cdclk because if we lower the cdclk later then that bpp will cause underuns.
One of the comments in here was to then check if DSC enabled in function that tries to lower the cdclk and not allow if DSC enabled.
Are you already working on that change or do I need to follow up on that with Ville/ Jani?
Manasi
> >
> > @Ville @Jani does this sound like a good approach. Then @Vandita we can
> > pursue that change.
> >
> > Regards
> > Manasi
> >
> > On Sun, Jan 09, 2022 at 11:15:04PM -0800, Kulkarni, Vandita wrote:
> > > Revisiting this thread after update from the bspec.
> > >
> > > > -----Original Message-----
> > > > From: Nikula, Jani <jani.nikula@intel.com>
> > > > Sent: Tuesday, September 14, 2021 8:40 PM
> > > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>; Lisovskiy,
> > > > Stanislav <stanislav.lisovskiy@intel.com>
> > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; intel-
> > > > gfx@lists.freedesktop.org; Navare, Manasi D
> > > > <manasi.d.navare@intel.com>
> > > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > > VDSC engine for higher moderates
> > > >
> > > > On Tue, 14 Sep 2021, "Kulkarni, Vandita"
> > > > <vandita.kulkarni@intel.com>
> > > > wrote:
> > > > >> -----Original Message-----
> > > > >> From: Nikula, Jani <jani.nikula@intel.com>
> > > > >> Sent: Tuesday, September 14, 2021 7:33 PM
> > > > >> To: Lisovskiy, Stanislav <stanislav.lisovskiy@intel.com>
> > > > >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; Kulkarni,
> > > > >> Vandita <vandita.kulkarni@intel.com>;
> > > > >> intel-gfx@lists.freedesktop.org; Navare, Manasi D
> > > > >> <manasi.d.navare@intel.com>
> > > > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > > >> VDSC engine for higher moderates
> > > > >>
> > > > >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > > >> <stanislav.lisovskiy@intel.com>
> > > > >> wrote:
> > > > >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> > > > >> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > > > >> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > > >> <stanislav.lisovskiy@intel.com> wrote:
> > > > >> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> > > > >> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni,
> > > > >> >> > >> Vandita
> > > > wrote:
> > > > >> >> > >> > > -----Original Message-----
> > > > >> >> > >> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > >> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > > > >> >> > >> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> > > > >> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > > >> >> > >> > > <jani.nikula@intel.com>; Navare, Manasi D
> > > > >> >> > >> > > <manasi.d.navare@intel.com>
> > > > >> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display:
> > > > >> >> > >> > > Enable second VDSC engine for higher moderates
> > > > >> >> > >> > >
> > > > >> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita
> > > > >> >> > >> > > Kulkarni
> > > > >> wrote:
> > > > >> >> > >> > > > Each VDSC operates with 1ppc throughput, hence
> > > > >> >> > >> > > > enable the second VDSC engine when moderate is
> > > > >> >> > >> > > > higher that the current
> > > > >> cdclk.
> > > > >> >> > >> > > >
> > > > >> >> > >> > > > Signed-off-by: Vandita Kulkarni
> > > > >> >> > >> > > > <vandita.kulkarni@intel.com>
> > > > >> >> > >> > > > ---
> > > > >> >> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12
> > > > >> >> > >> > > > ++++++++++--
> > > > >> >> > >> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > > > >> >> > >> > > >
> > > > >> >> > >> > > > diff --git
> > > > >> >> > >> > > > a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > >> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > >> >> > >> > > > index 161c33b2c869..55878f65f724 100644
> > > > >> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > >> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > >> >> > >> > > > @@ -70,6 +70,7 @@
> > > > >> >> > >> > > > #include "intel_tc.h"
> > > > >> >> > >> > > > #include "intel_vdsc.h"
> > > > >> >> > >> > > > #include "intel_vrr.h"
> > > > >> >> > >> > > > +#include "intel_cdclk.h"
> > > > >> >> > >> > > >
> > > > >> >> > >> > > > #define DP_DPRX_ESI_LEN 14
> > > > >> >> > >> > > >
> > > > >> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
> > > > >> >> > >> > > > intel_dp_dsc_compute_config(struct
> > > > >> >> > >> > > intel_dp *intel_dp,
> > > > >> >> > >> > > > struct
> > > > drm_connector_state
> > > > >> *conn_state,
> > > > >> >> > >> > > > struct link_config_limits
> > > > *limits) {
> > > > >> >> > >> > > > + struct intel_cdclk_state *cdclk_state;
> > > > >> >> > >> > > > struct intel_digital_port *dig_port =
> > > > >> dp_to_dig_port(intel_dp);
> > > > >> >> > >> > > > struct drm_i915_private *dev_priv =
> > > > to_i915(dig_port-
> > > > >> >> > >> > > >base.base.dev);
> > > > >> >> > >> > > > const struct drm_display_mode *adjusted_mode =
> > > > >> >> > >> > > > &pipe_config->hw.adjusted_mode;
> > > > >> >> > >> > > > + struct intel_atomic_state *state =
> > > > >> >> > >> > > > +
> > > > to_intel_atomic_state(pipe_config-
> > > > >> >> > >> > > >uapi.state);
> > > > >> >> > >> > > > int pipe_bpp;
> > > > >> >> > >> > > > int ret;
> > > > >> >> > >> > > >
> > > > >> >> > >> > > > @@ -1373,12 +1377,16 @@ static int
> > > > >> >> > >> > > > intel_dp_dsc_compute_config(struct
> > > > >> >> > >> > > intel_dp *intel_dp,
> > > > >> >> > >> > > > }
> > > > >> >> > >> > > > }
> > > > >> >> > >> > > >
> > > > >> >> > >> > > > + cdclk_state = intel_atomic_get_cdclk_state(state);
> > > > >> >> > >> > > > + if (IS_ERR(cdclk_state))
> > > > >> >> > >> > > > + return PTR_ERR(cdclk_state);
> > > > >> >> > >> > > > +
> > > > >> >> > >> > > > /*
> > > > >> >> > >> > > > * VDSC engine operates at 1 Pixel per clock, so
> > > > >> >> > >> > > > if peak pixel
> > > > >> rate
> > > > >> >> > >> > > > - * is greater than the maximum Cdclock and if slice
> > > > count is
> > > > >> even
> > > > >> >> > >> > > > + * is greater than the current Cdclock and if
> > > > >> >> > >> > > > +slice count is even
> > > > >> >> > >> > > > * then we need to use 2 VDSC instances.
> > > > >> >> > >> > > > */
> > > > >> >> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv-
> > > > >max_cdclk_freq
> > > > >> ||
> > > > >> >> > >> > > > + if (adjusted_mode->crtc_clock >
> > > > >> >> > >> > > > +cdclk_state->actual.cdclk ||
> > > > >> >> > >> > >
> > > > >> >> > >> > > This is wrong. We compute the cdclk based on the
> > > > >> >> > >> > > requirements of the mode/etc., not the other way
> > around.
> > > > >> >> > >
> > > > >> >> > > According to BSpec guideline, we decide whether we enable
> > > > >> >> > > or disable second VDSC engine, based on that condition. As
> > > > >> >> > > I understand that one is about DSC config calculation,
> > > > >> >> > > based on CDCLK
> > > > >> which was calculated.
> > > > >> >> >
> > > > >> >> > Point is, at the time compute_config gets called, what
> > > > >> >> > guarantees are there that cdclk_state->actual.cdclk contains
> > > > anything useful?
> > > > >> >> > This is the design we have.
> > > > >> >>
> > > > >> >> That is actually good question, was willing to check that as well.
> > > > >> >>
> > > > >> >> >
> > > > >> >> > > If we bump up CDCLK, to avoid this, will we even then use
> > > > >> >> > > a second
> > > > >> VDSC ever?
> > > > >> >> >
> > > > >> >> > I think we'll eventually need better logic than
> > > > >> >> > unconditionally bumping to max, and it needs to take *both*
> > > > >> >> > the cdclk and the number of dsc engines into account. The
> > > > >> >> > referenced bspec only has the vdsc clock perspective, not overall
> > perspective.
> > > > >> >>
> > > > >> >> What we need to clarify here is that how this is supposed to
> > > > >> >> work in
> > > > >> theory.
> > > > >> >> Basically same issue can be fixed by both increasing the CDCLK
> > > > >> >> or enabling 2nd VDSC engine.
> > > > >> >> There should be some guideline telling us, how to prioritize.
> > > > >> >> From overall perspective as I understand, by default, we are
> > > > >> >> able to keep CDCLK 2 times less than pixel rate(see
> > > > >> >> intel_pixel_rate_to_cdclk), however due to that VDSC
> > > > >> >> limitation that it can use only 1 ppc this becomes, not
> > > > >> >> applicable anymore(at least as of BSpec 49259), so we have to
> > > > >> >> increase amount of VDSC instances
> > > > >> then.
> > > > >> >>
> > > > >> >> So the question is now - what is more optimal here?
> > > > >> >> Also if we bump up CDCLK(which we have done many times
> > already
> > > > >> >> in fact), we then need to add some logic to
> > > > >> >> intel_compute_min_cdclk to check if we are using DSC or not,
> > > > >> >> because otherwise we don't really need
> > > > >> to do that.
> > > > >>
> > > > >> intel_compute_min_cdclk() already needs to be dsc aware when
> > > > >> slice count is 1 and we can't use two dsc engines anyway. See the
> > > > >> recent commit fe01883fdcef ("drm/i915: Get proper min cdclk if vDSC
> > enabled").
> > > > >>
> > > > >> Looking again, I'm not sure that does the right decision for when
> > > > >> dsc.slice_count > 1, but dsc.split == false. It should probably
> > > > >> use dsc.split for the decision.
> > > > >>
> > > > >> >>
> > > > >> >> Stan
> > > > >> >
> > > > >> > Checked and indeed, encoder->compute_config is called way
> > > > >> > before, basically CDCLK calculation is called almost in the end
> > > > >> > of atomic_check, so in compute_config, there would be an old
> > > > >> > CDCLK value copied from previous cdclk state, but not the last one.
> > > > >> >
> > > > >> > Vandita, this means we actually can't do it that way, if you
> > > > >> > want to do anything with VDSC based on CDCLK this has to be
> > > > >> > done _after_ intel_compute_min_cdclk was called. Which is not
> > very sweet, I guess.
> > > > >> >
> > > > >> > So as of current architecture, it seems that the easiest way is
> > > > >> > indeed to bump the CDCLK or we need to figure the way how to
> > > > >> > enable 2nd VDSC somewhere else, after CDCLK was calculated.
> > > > >>
> > > > >> Alternatively, we could use two dsc engines more aggressively,
> > > > >> but that decision currently can't take overall chosen cdclk into account.
> > > > >>
> > > > >> We'll end up sometimes unnecessarily using a too high cdclk or
> > > > >> two dsc engines, just have to pick the poison.
> > > > >>
> > > > >> I think trying to do dsc decisions after
> > > > >> intel_compute_min_cdclk() gets way too complicated.
> > > > >
> > > > > In this case, can we just use the 2nd VDSC engine if slice_count
> > > > > is 2 or
> > > > more?
> > > > > Which would mean we always operate in joiner enabled mode(small
> > > > > joiner) of all the compression modes of operation mentioned in the
> > > > > table bspec: 49259 Because we are still going to hit the max cdclk
> > > > > restriction
> > > > for higher resolutions, and many lower resolutions wouldn’t need max
> > cdclk.
> > > > > And eventually once we have more details on cd clk vs 2VDSC engine
> > > > > we could add the logic to choose one over the other?
> > > > >
> > > > > I see that in case of DSI we do split = true, for slice_count > 1
> > > > > but that
> > > > would need a different set of checks, thats a TBD.
> > > > >
> > > > > Or Do you suggest I just do this for now max cdclk when
> > > > > slice_count =1 (what we are doing now) replace with compression =
> > > > > true and split = false
> > > >
> > > > I think the check in intel_compute_min_cdclk() should be:
> > > >
> > > > if (crtc_state->dsc.compression_enable && !crtc_state-
> > > > >dsc.dsc_split)
> > > >
> > > > That's a separate change.
> > > >
> > > > Enabling two dsc engines more aggressively... I don't mind doing it
> > > > unconditionally when slice count > 1 for starters. But I think we'll
> > > > need to improve this going forward, including fixing the mode valid
> > > > checks etc. as we've discussed.
> > >
> > > Design recommendation is to use 2 VDSC instances while meeting the
> > following constraint so that cdclk can stay as low as possible.
> > > DP/HDMI PPR spec provided slice size < DPCD provided MaxSliceWidth
>
> Based on the hw recommendation to me it looks like, as @Nikula, Jani suggested
> We can set split to true based on " DP/HDMI PPR spec provided slice size < DPCD provided MaxSliceWidth"
>
> In such cases we can avoid bumping up to max cdclk for vdsc reasons.
> Will make this change and float V2.
>
> Thanks,
> Vandita
> > >
> > > Thanks,
> > > Vandita
> > > >
> > > > Ville, any objections?
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > > Vandita
> > > > >>
> > > > >> BR,
> > > > >> Jani
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > Stan
> > > > >> >
> > > > >> >>
> > > > >> >> >
> > > > >> >> > BR,
> > > > >> >> > Jani.
> > > > >> >> >
> > > > >> >> > > Another thing is that probably enabling second VDSC is
> > > > >> >> > > cheaper in terms of power consumption, than bumping up the
> > CDCLK.
> > > > >> >> > >
> > > > >> >> > > Stan
> > > > >> >> > >
> > > > >> >> > >> >
> > > > >> >> > >> > Okay , So you suggest that we set the cd clock to max
> > > > >> >> > >> > when we
> > > > >> have such requirement, than enabling the second engine?
> > > > >> >> > >>
> > > > >> >> > >> That seems like the easiest solution. Another option
> > > > >> >> > >> might be to come up with some lower dotclock limit for
> > > > >> >> > >> the use of the second vdsc. But not sure we know where
> > > > >> >> > >> the tipping point is wrt. powr
> > > > >> consumption.
> > > > >> >> > >>
> > > > >> >> > >> --
> > > > >> >> > >> Ville Syrjälä
> > > > >> >> > >> Intel
> > > > >> >> >
> > > > >> >> > --
> > > > >> >> > Jani Nikula, Intel Open Source Graphics Center
> > > > >>
> > > > >> --
> > > > >> Jani Nikula, Intel Open Source Graphics Center
> > > >
> > > > --
> > > > Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates
2022-01-11 6:12 ` Navare, Manasi
@ 2022-01-11 6:26 ` Kulkarni, Vandita
0 siblings, 0 replies; 20+ messages in thread
From: Kulkarni, Vandita @ 2022-01-11 6:26 UTC (permalink / raw)
To: Navare, Manasi D; +Cc: Nikula, Jani, intel-gfx
> -----Original Message-----
> From: Navare, Manasi D <manasi.d.navare@intel.com>
> Sent: Tuesday, January 11, 2022 11:42 AM
> To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> Cc: Nikula, Jani <jani.nikula@intel.com>; Lisovskiy, Stanislav
> <stanislav.lisovskiy@intel.com>; Ville Syrjälä <ville.syrjala@linux.intel.com>;
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
>
> On Mon, Jan 10, 2022 at 08:24:54PM -0800, Kulkarni, Vandita wrote:
> > > -----Original Message-----
> > > From: Navare, Manasi D <manasi.d.navare@intel.com>
> > > Sent: Tuesday, January 11, 2022 1:07 AM
> > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> > > Cc: Nikula, Jani <jani.nikula@intel.com>; Lisovskiy, Stanislav
> > > <stanislav.lisovskiy@intel.com>; Ville Syrjälä
> > > <ville.syrjala@linux.intel.com>; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > VDSC engine for higher moderates
> > >
> > > Thankf for revisiting this thread. The use of max_cdclk is currently
> > > in 2 places in DSC code 1. . if (adjusted_mode->crtc_clock >
> > > dev_priv->max_cdclk_freq) {
> > > if (pipe_config->dsc.slice_count > 1) {
> > > pipe_config->dsc.dsc_split = true; 2. if (bigjoiner) {
> > > u32 max_bpp_bigjoiner =
> > > i915->max_cdclk_freq * 48 /
> > > intel_dp_mode_to_fec_clock(mode_clock);
> > >
> > > DRM_DEBUG_KMS("Max big joiner bpp: %u\n",
> > > max_bpp_bigjoiner);
> > > bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> > > }
> > >
> > > In both these places, using max_cdclk can cause problems, like for
> > > compressed bpp it can give a higher bpp based on max_cdclk and we
> > > might actually end up chosing lower cdclk at what point this will cause
> underruns.
> > >
> > > So when I was discussing with Ville on this, my first thought was
> > > also to use the cdclk_state->actual_cdclk but like Ville mentioned
> > > later in the review comments the challenge there was that actual
> > > cdclk does get computed much later than dsc_compute_config.
> > >
> > > So I think as suggested in one of the reviews we just to check if
> > > DSC is enabled then we dont allow lowering the cdclk which would
> > > also prevent underruns caused by possibly setting up higher bpp based
> on max cdclk.
> >
> > Thanks for the review.
> > This is taken care now, in case if we cannot split, then we already are using
> max_cdclk.
> > Regarding the bigjoiner_bpp, you may need to make the change if you
> need it to be set to max cdclk.
> > As we all of us here agree that we do not have computed cd clk at that
> time.
> >
>
Just to clarify this patch doesn’t do anything wrt the big joiner bpp calclulation.
> So the resolution was to keep it at max_cdclock when we set the dsc.split
> and decide to use 2 VDSC engines?
The solution was to keep it at max_cdclk when we dsc.split is false.
>Is this change merged upstream now?
Yes
> For bpp calculation, that was pointed out by Srikanth that they were seeing
> underruns and was a bug they had found in their code.
> And infact there we dont want to set it to max_cdclk because if we lower the
> cdclk later then that bpp will cause underuns.
I am guessing you are talking about big joiner cases, this patch was made for addressing pure dsc cases
Where we were seeing underruns. Due to 1 ppc limitation.
> One of the comments in here was to then check if DSC enabled in function
> that tries to lower the cdclk and not allow if DSC enabled.
The suggestion was to check if we are not using split = true (2 dsc engines), then use max cdclk.
PS : intel_crtc_compute_min_cdclk
This whole patch was to make sure that when we cannot use 2 dsc engine, to increase the cdclk.
Or use 2 engines based on the current cdclk, which is not possible.
And we were checking against max cdclk to enable second engine.
This got resolved with the change that is merged now, sets cdclk to max if we cannot enable the second vdsc engine.
The suggestion from the bspec is directing to use 2 vdsc engines based on the condition that I have mentioned below,
And that means we really do not need the check if (adjusted_mode->crtc_clock > dev_priv- max_cdclk_freq) to set split = true.
> Are you already working on that change or do I need to follow up on that
> with Ville/ Jani?
Here in this patch we are not talking about the bpp calculation based on cd clk at all, which comes into picture with big joiner.
If you want to make changes wrt bigjoiner, you may need to make another patch, which I am not working on.
As per my previous email: this is what I will be sending.
"> > Based on the hw recommendation to me it looks like, as @Nikula, Jani
> suggested
> > We can set split to true based on " DP/HDMI PPR spec provided slice size <
> DPCD provided MaxSliceWidth"
> >
> > In such cases we can avoid bumping up to max cdclk for vdsc reasons.
> > Will make this change and float V2.
> >
> > Thanks,
> > Vandita
"
>
> Manasi
>
> > >
> > > @Ville @Jani does this sound like a good approach. Then @Vandita we
> > > can pursue that change.
> > >
> > > Regards
> > > Manasi
> > >
> > > On Sun, Jan 09, 2022 at 11:15:04PM -0800, Kulkarni, Vandita wrote:
> > > > Revisiting this thread after update from the bspec.
> > > >
> > > > > -----Original Message-----
> > > > > From: Nikula, Jani <jani.nikula@intel.com>
> > > > > Sent: Tuesday, September 14, 2021 8:40 PM
> > > > > To: Kulkarni, Vandita <vandita.kulkarni@intel.com>; Lisovskiy,
> > > > > Stanislav <stanislav.lisovskiy@intel.com>
> > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; intel-
> > > > > gfx@lists.freedesktop.org; Navare, Manasi D
> > > > > <manasi.d.navare@intel.com>
> > > > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Enable second
> > > > > VDSC engine for higher moderates
> > > > >
> > > > > On Tue, 14 Sep 2021, "Kulkarni, Vandita"
> > > > > <vandita.kulkarni@intel.com>
> > > > > wrote:
> > > > > >> -----Original Message-----
> > > > > >> From: Nikula, Jani <jani.nikula@intel.com>
> > > > > >> Sent: Tuesday, September 14, 2021 7:33 PM
> > > > > >> To: Lisovskiy, Stanislav <stanislav.lisovskiy@intel.com>
> > > > > >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>; Kulkarni,
> > > > > >> Vandita <vandita.kulkarni@intel.com>;
> > > > > >> intel-gfx@lists.freedesktop.org; Navare, Manasi D
> > > > > >> <manasi.d.navare@intel.com>
> > > > > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable
> > > > > >> second VDSC engine for higher moderates
> > > > > >>
> > > > > >> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > > > >> <stanislav.lisovskiy@intel.com>
> > > > > >> wrote:
> > > > > >> > On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav
> wrote:
> > > > > >> >> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > > > > >> >> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > > > > >> <stanislav.lisovskiy@intel.com> wrote:
> > > > > >> >> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä
> wrote:
> > > > > >> >> > >> On Tue, Sep 14, 2021 at 07:31:46AM +0000, Kulkarni,
> > > > > >> >> > >> Vandita
> > > > > wrote:
> > > > > >> >> > >> > > -----Original Message-----
> > > > > >> >> > >> > > From: Ville Syrjälä
> > > > > >> >> > >> > > <ville.syrjala@linux.intel.com>
> > > > > >> >> > >> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > > > > >> >> > >> > > To: Kulkarni, Vandita
> > > > > >> >> > >> > > <vandita.kulkarni@intel.com>
> > > > > >> >> > >> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > > > > >> >> > >> > > <jani.nikula@intel.com>; Navare, Manasi D
> > > > > >> >> > >> > > <manasi.d.navare@intel.com>
> > > > > >> >> > >> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display:
> > > > > >> >> > >> > > Enable second VDSC engine for higher moderates
> > > > > >> >> > >> > >
> > > > > >> >> > >> > > On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita
> > > > > >> >> > >> > > Kulkarni
> > > > > >> wrote:
> > > > > >> >> > >> > > > Each VDSC operates with 1ppc throughput, hence
> > > > > >> >> > >> > > > enable the second VDSC engine when moderate is
> > > > > >> >> > >> > > > higher that the current
> > > > > >> cdclk.
> > > > > >> >> > >> > > >
> > > > > >> >> > >> > > > Signed-off-by: Vandita Kulkarni
> > > > > >> >> > >> > > > <vandita.kulkarni@intel.com>
> > > > > >> >> > >> > > > ---
> > > > > >> >> > >> > > > drivers/gpu/drm/i915/display/intel_dp.c | 12
> > > > > >> >> > >> > > > ++++++++++--
> > > > > >> >> > >> > > > 1 file changed, 10 insertions(+), 2
> > > > > >> >> > >> > > > deletions(-)
> > > > > >> >> > >> > > >
> > > > > >> >> > >> > > > diff --git
> > > > > >> >> > >> > > > a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > >> >> > >> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > >> >> > >> > > > index 161c33b2c869..55878f65f724 100644
> > > > > >> >> > >> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > >> >> > >> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > >> >> > >> > > > @@ -70,6 +70,7 @@ #include "intel_tc.h"
> > > > > >> >> > >> > > > #include "intel_vdsc.h"
> > > > > >> >> > >> > > > #include "intel_vrr.h"
> > > > > >> >> > >> > > > +#include "intel_cdclk.h"
> > > > > >> >> > >> > > >
> > > > > >> >> > >> > > > #define DP_DPRX_ESI_LEN 14
> > > > > >> >> > >> > > >
> > > > > >> >> > >> > > > @@ -1291,10 +1292,13 @@ static int
> > > > > >> >> > >> > > > intel_dp_dsc_compute_config(struct
> > > > > >> >> > >> > > intel_dp *intel_dp,
> > > > > >> >> > >> > > > struct
> > > > > drm_connector_state
> > > > > >> *conn_state,
> > > > > >> >> > >> > > > struct
> link_config_limits
> > > > > *limits) {
> > > > > >> >> > >> > > > + struct intel_cdclk_state *cdclk_state;
> > > > > >> >> > >> > > > struct intel_digital_port *dig_port =
> > > > > >> dp_to_dig_port(intel_dp);
> > > > > >> >> > >> > > > struct drm_i915_private *dev_priv =
> > > > > to_i915(dig_port-
> > > > > >> >> > >> > > >base.base.dev);
> > > > > >> >> > >> > > > const struct drm_display_mode
> *adjusted_mode =
> > > > > >> >> > >> > > > &pipe_config->hw.adjusted_mode;
> > > > > >> >> > >> > > > + struct intel_atomic_state *state =
> > > > > >> >> > >> > > > +
> > > > > to_intel_atomic_state(pipe_config-
> > > > > >> >> > >> > > >uapi.state);
> > > > > >> >> > >> > > > int pipe_bpp;
> > > > > >> >> > >> > > > int ret;
> > > > > >> >> > >> > > >
> > > > > >> >> > >> > > > @@ -1373,12 +1377,16 @@ static int
> > > > > >> >> > >> > > > intel_dp_dsc_compute_config(struct
> > > > > >> >> > >> > > intel_dp *intel_dp,
> > > > > >> >> > >> > > > }
> > > > > >> >> > >> > > > }
> > > > > >> >> > >> > > >
> > > > > >> >> > >> > > > + cdclk_state =
> intel_atomic_get_cdclk_state(state);
> > > > > >> >> > >> > > > + if (IS_ERR(cdclk_state))
> > > > > >> >> > >> > > > + return PTR_ERR(cdclk_state);
> > > > > >> >> > >> > > > +
> > > > > >> >> > >> > > > /*
> > > > > >> >> > >> > > > * VDSC engine operates at 1 Pixel per clock,
> so
> > > > > >> >> > >> > > > if peak pixel
> > > > > >> rate
> > > > > >> >> > >> > > > - * is greater than the maximum Cdclock and if
> slice
> > > > > count is
> > > > > >> even
> > > > > >> >> > >> > > > + * is greater than the current Cdclock and if
> > > > > >> >> > >> > > > +slice count is even
> > > > > >> >> > >> > > > * then we need to use 2 VDSC instances.
> > > > > >> >> > >> > > > */
> > > > > >> >> > >> > > > - if (adjusted_mode->crtc_clock > dev_priv-
> > > > > >max_cdclk_freq
> > > > > >> ||
> > > > > >> >> > >> > > > + if (adjusted_mode->crtc_clock >
> > > > > >> >> > >> > > > +cdclk_state->actual.cdclk ||
> > > > > >> >> > >> > >
> > > > > >> >> > >> > > This is wrong. We compute the cdclk based on the
> > > > > >> >> > >> > > requirements of the mode/etc., not the other way
> > > around.
> > > > > >> >> > >
> > > > > >> >> > > According to BSpec guideline, we decide whether we
> enable
> > > > > >> >> > > or disable second VDSC engine, based on that condition. As
> > > > > >> >> > > I understand that one is about DSC config calculation,
> > > > > >> >> > > based on CDCLK
> > > > > >> which was calculated.
> > > > > >> >> >
> > > > > >> >> > Point is, at the time compute_config gets called, what
> > > > > >> >> > guarantees are there that cdclk_state->actual.cdclk contains
> > > > > anything useful?
> > > > > >> >> > This is the design we have.
> > > > > >> >>
> > > > > >> >> That is actually good question, was willing to check that as well.
> > > > > >> >>
> > > > > >> >> >
> > > > > >> >> > > If we bump up CDCLK, to avoid this, will we even then use
> > > > > >> >> > > a second
> > > > > >> VDSC ever?
> > > > > >> >> >
> > > > > >> >> > I think we'll eventually need better logic than
> > > > > >> >> > unconditionally bumping to max, and it needs to take *both*
> > > > > >> >> > the cdclk and the number of dsc engines into account. The
> > > > > >> >> > referenced bspec only has the vdsc clock perspective, not
> overall
> > > perspective.
> > > > > >> >>
> > > > > >> >> What we need to clarify here is that how this is supposed to
> > > > > >> >> work in
> > > > > >> theory.
> > > > > >> >> Basically same issue can be fixed by both increasing the CDCLK
> > > > > >> >> or enabling 2nd VDSC engine.
> > > > > >> >> There should be some guideline telling us, how to prioritize.
> > > > > >> >> From overall perspective as I understand, by default, we are
> > > > > >> >> able to keep CDCLK 2 times less than pixel rate(see
> > > > > >> >> intel_pixel_rate_to_cdclk), however due to that VDSC
> > > > > >> >> limitation that it can use only 1 ppc this becomes, not
> > > > > >> >> applicable anymore(at least as of BSpec 49259), so we have to
> > > > > >> >> increase amount of VDSC instances
> > > > > >> then.
> > > > > >> >>
> > > > > >> >> So the question is now - what is more optimal here?
> > > > > >> >> Also if we bump up CDCLK(which we have done many times
> > > already
> > > > > >> >> in fact), we then need to add some logic to
> > > > > >> >> intel_compute_min_cdclk to check if we are using DSC or not,
> > > > > >> >> because otherwise we don't really need
> > > > > >> to do that.
> > > > > >>
> > > > > >> intel_compute_min_cdclk() already needs to be dsc aware when
> > > > > >> slice count is 1 and we can't use two dsc engines anyway. See the
> > > > > >> recent commit fe01883fdcef ("drm/i915: Get proper min cdclk if
> vDSC
> > > enabled").
> > > > > >>
> > > > > >> Looking again, I'm not sure that does the right decision for when
> > > > > >> dsc.slice_count > 1, but dsc.split == false. It should probably
> > > > > >> use dsc.split for the decision.
> > > > > >>
> > > > > >> >>
> > > > > >> >> Stan
> > > > > >> >
> > > > > >> > Checked and indeed, encoder->compute_config is called way
> > > > > >> > before, basically CDCLK calculation is called almost in the end
> > > > > >> > of atomic_check, so in compute_config, there would be an old
> > > > > >> > CDCLK value copied from previous cdclk state, but not the last
> one.
> > > > > >> >
> > > > > >> > Vandita, this means we actually can't do it that way, if you
> > > > > >> > want to do anything with VDSC based on CDCLK this has to be
> > > > > >> > done _after_ intel_compute_min_cdclk was called. Which is not
> > > very sweet, I guess.
> > > > > >> >
> > > > > >> > So as of current architecture, it seems that the easiest way is
> > > > > >> > indeed to bump the CDCLK or we need to figure the way how to
> > > > > >> > enable 2nd VDSC somewhere else, after CDCLK was calculated.
> > > > > >>
> > > > > >> Alternatively, we could use two dsc engines more aggressively,
> > > > > >> but that decision currently can't take overall chosen cdclk into
> account.
> > > > > >>
> > > > > >> We'll end up sometimes unnecessarily using a too high cdclk or
> > > > > >> two dsc engines, just have to pick the poison.
> > > > > >>
> > > > > >> I think trying to do dsc decisions after
> > > > > >> intel_compute_min_cdclk() gets way too complicated.
> > > > > >
> > > > > > In this case, can we just use the 2nd VDSC engine if slice_count
> > > > > > is 2 or
> > > > > more?
> > > > > > Which would mean we always operate in joiner enabled
> mode(small
> > > > > > joiner) of all the compression modes of operation mentioned in the
> > > > > > table bspec: 49259 Because we are still going to hit the max cdclk
> > > > > > restriction
> > > > > for higher resolutions, and many lower resolutions wouldn’t need
> max
> > > cdclk.
> > > > > > And eventually once we have more details on cd clk vs 2VDSC
> engine
> > > > > > we could add the logic to choose one over the other?
> > > > > >
> > > > > > I see that in case of DSI we do split = true, for slice_count > 1
> > > > > > but that
> > > > > would need a different set of checks, thats a TBD.
> > > > > >
> > > > > > Or Do you suggest I just do this for now max cdclk when
> > > > > > slice_count =1 (what we are doing now) replace with compression =
> > > > > > true and split = false
> > > > >
> > > > > I think the check in intel_compute_min_cdclk() should be:
> > > > >
> > > > > if (crtc_state->dsc.compression_enable && !crtc_state-
> > > > > >dsc.dsc_split)
> > > > >
> > > > > That's a separate change.
> > > > >
> > > > > Enabling two dsc engines more aggressively... I don't mind doing it
> > > > > unconditionally when slice count > 1 for starters. But I think we'll
> > > > > need to improve this going forward, including fixing the mode valid
> > > > > checks etc. as we've discussed.
> > > >
> > > > Design recommendation is to use 2 VDSC instances while meeting the
> > > following constraint so that cdclk can stay as low as possible.
> > > > DP/HDMI PPR spec provided slice size < DPCD provided MaxSliceWidth
> >
> > Based on the hw recommendation to me it looks like, as @Nikula, Jani
> suggested
> > We can set split to true based on " DP/HDMI PPR spec provided slice size <
> DPCD provided MaxSliceWidth"
> >
> > In such cases we can avoid bumping up to max cdclk for vdsc reasons.
> > Will make this change and float V2.
> >
> > Thanks,
> > Vandita
> > > >
> > > > Thanks,
> > > > Vandita
> > > > >
> > > > > Ville, any objections?
> > > > >
> > > > > BR,
> > > > > Jani.
> > > > >
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Vandita
> > > > > >>
> > > > > >> BR,
> > > > > >> Jani
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> >
> > > > > >> > Stan
> > > > > >> >
> > > > > >> >>
> > > > > >> >> >
> > > > > >> >> > BR,
> > > > > >> >> > Jani.
> > > > > >> >> >
> > > > > >> >> > > Another thing is that probably enabling second VDSC is
> > > > > >> >> > > cheaper in terms of power consumption, than bumping up
> the
> > > CDCLK.
> > > > > >> >> > >
> > > > > >> >> > > Stan
> > > > > >> >> > >
> > > > > >> >> > >> >
> > > > > >> >> > >> > Okay , So you suggest that we set the cd clock to max
> > > > > >> >> > >> > when we
> > > > > >> have such requirement, than enabling the second engine?
> > > > > >> >> > >>
> > > > > >> >> > >> That seems like the easiest solution. Another option
> > > > > >> >> > >> might be to come up with some lower dotclock limit for
> > > > > >> >> > >> the use of the second vdsc. But not sure we know where
> > > > > >> >> > >> the tipping point is wrt. powr
> > > > > >> consumption.
> > > > > >> >> > >>
> > > > > >> >> > >> --
> > > > > >> >> > >> Ville Syrjälä
> > > > > >> >> > >> Intel
> > > > > >> >> >
> > > > > >> >> > --
> > > > > >> >> > Jani Nikula, Intel Open Source Graphics Center
> > > > > >>
> > > > > >> --
> > > > > >> Jani Nikula, Intel Open Source Graphics Center
> > > > >
> > > > > --
> > > > > Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2022-01-11 6:26 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-13 14:39 [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC engine for higher moderates Vandita Kulkarni
2021-09-13 15:29 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2021-09-13 17:00 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-09-14 7:19 ` [Intel-gfx] [PATCH] " Lisovskiy, Stanislav
2021-09-14 7:37 ` Kulkarni, Vandita
2021-09-14 7:28 ` Ville Syrjälä
2021-09-14 7:31 ` Kulkarni, Vandita
2021-09-14 7:48 ` Ville Syrjälä
2021-09-14 8:59 ` Lisovskiy, Stanislav
2021-09-14 12:04 ` Jani Nikula
2021-09-14 13:04 ` Lisovskiy, Stanislav
2021-09-14 13:32 ` Lisovskiy, Stanislav
2021-09-14 14:02 ` Jani Nikula
2021-09-14 14:40 ` Kulkarni, Vandita
2021-09-14 15:10 ` Jani Nikula
2022-01-10 7:15 ` Kulkarni, Vandita
2022-01-10 19:36 ` Navare, Manasi
2022-01-11 4:24 ` Kulkarni, Vandita
2022-01-11 6:12 ` Navare, Manasi
2022-01-11 6:26 ` Kulkarni, Vandita
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.