* [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
@ 2020-11-24 18:35 ` Chris Wilson
0 siblings, 0 replies; 11+ messages in thread
From: Chris Wilson @ 2020-11-24 18:35 UTC (permalink / raw)
To: intel-gfx; +Cc: Chris Wilson, Edward Baker, Andi Shyti, Lyude Paul, stable
We treat idling the GT (intel_rps_park) as a downclock event, and reduce
the frequency we intend to restart the GT with. Since the two workloads
are likely related (e.g. a compositor rendering every 16ms), we want to
carry the frequency and load information from across the idling.
However, we do also need to update the frequencies so that workloads
that run for less than 1ms are autotuned by RPS (otherwise we leave
compositors running at max clocks, draining excess power). Conversely,
if we try to run too slowly, the next workload has to run longer. Since
there is a hysteresis in the power graph, below a certain frequency
running a short workload for longer consumes more energy than running it
slightly higher for less time. The exact balance point is unknown
beforehand, but measurements with 30fps media playback indicate that RPe
is a better choice.
Reported-by: Edward Baker <edward.baker@intel.com>
Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Edward Baker <edward.baker@intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v5.8+
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
index b13e7845d483..f74d5e09e176 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
adj = -2;
rps->last_adj = adj;
rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
+ if (rps->cur_freq < rps->efficient_freq) {
+ rps->cur_freq = rps->efficient_freq;
+ rps->last_adj = 0;
+ }
GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
@ 2020-11-24 18:35 ` Chris Wilson
0 siblings, 0 replies; 11+ messages in thread
From: Chris Wilson @ 2020-11-24 18:35 UTC (permalink / raw)
To: intel-gfx; +Cc: stable, Chris Wilson
We treat idling the GT (intel_rps_park) as a downclock event, and reduce
the frequency we intend to restart the GT with. Since the two workloads
are likely related (e.g. a compositor rendering every 16ms), we want to
carry the frequency and load information from across the idling.
However, we do also need to update the frequencies so that workloads
that run for less than 1ms are autotuned by RPS (otherwise we leave
compositors running at max clocks, draining excess power). Conversely,
if we try to run too slowly, the next workload has to run longer. Since
there is a hysteresis in the power graph, below a certain frequency
running a short workload for longer consumes more energy than running it
slightly higher for less time. The exact balance point is unknown
beforehand, but measurements with 30fps media playback indicate that RPe
is a better choice.
Reported-by: Edward Baker <edward.baker@intel.com>
Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Edward Baker <edward.baker@intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v5.8+
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
index b13e7845d483..f74d5e09e176 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
adj = -2;
rps->last_adj = adj;
rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
+ if (rps->cur_freq < rps->efficient_freq) {
+ rps->cur_freq = rps->efficient_freq;
+ rps->last_adj = 0;
+ }
GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
}
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
2020-11-24 18:35 ` [Intel-gfx] " Chris Wilson
@ 2020-11-24 19:46 ` Rodrigo Vivi
-1 siblings, 0 replies; 11+ messages in thread
From: Rodrigo Vivi @ 2020-11-24 19:46 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, stable
On Tue, Nov 24, 2020 at 06:35:21PM +0000, Chris Wilson wrote:
> We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> the frequency we intend to restart the GT with. Since the two workloads
> are likely related (e.g. a compositor rendering every 16ms), we want to
> carry the frequency and load information from across the idling.
> However, we do also need to update the frequencies so that workloads
> that run for less than 1ms are autotuned by RPS (otherwise we leave
> compositors running at max clocks, draining excess power). Conversely,
> if we try to run too slowly, the next workload has to run longer. Since
> there is a hysteresis in the power graph, below a certain frequency
> running a short workload for longer consumes more energy than running it
> slightly higher for less time. The exact balance point is unknown
> beforehand, but measurements with 30fps media playback indicate that RPe
> is a better choice.
>
> Reported-by: Edward Baker <edward.baker@intel.com>
> Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Edward Baker <edward.baker@intel.com>
> Cc: Andi Shyti <andi.shyti@intel.com>
> Cc: Lyude Paul <lyude@redhat.com>
> Cc: <stable@vger.kernel.org> # v5.8+
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> index b13e7845d483..f74d5e09e176 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> adj = -2;
> rps->last_adj = adj;
> rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> + if (rps->cur_freq < rps->efficient_freq) {
> + rps->cur_freq = rps->efficient_freq;
> + rps->last_adj = 0;
this is indeed the smallest fix we can propagate:
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
but I wonder now if we couldn't simply kill the last_adj now and always go
with the rpe on park/unpark
> + }
>
> GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
> }
> --
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
@ 2020-11-24 19:46 ` Rodrigo Vivi
0 siblings, 0 replies; 11+ messages in thread
From: Rodrigo Vivi @ 2020-11-24 19:46 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, stable
On Tue, Nov 24, 2020 at 06:35:21PM +0000, Chris Wilson wrote:
> We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> the frequency we intend to restart the GT with. Since the two workloads
> are likely related (e.g. a compositor rendering every 16ms), we want to
> carry the frequency and load information from across the idling.
> However, we do also need to update the frequencies so that workloads
> that run for less than 1ms are autotuned by RPS (otherwise we leave
> compositors running at max clocks, draining excess power). Conversely,
> if we try to run too slowly, the next workload has to run longer. Since
> there is a hysteresis in the power graph, below a certain frequency
> running a short workload for longer consumes more energy than running it
> slightly higher for less time. The exact balance point is unknown
> beforehand, but measurements with 30fps media playback indicate that RPe
> is a better choice.
>
> Reported-by: Edward Baker <edward.baker@intel.com>
> Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Edward Baker <edward.baker@intel.com>
> Cc: Andi Shyti <andi.shyti@intel.com>
> Cc: Lyude Paul <lyude@redhat.com>
> Cc: <stable@vger.kernel.org> # v5.8+
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> index b13e7845d483..f74d5e09e176 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> adj = -2;
> rps->last_adj = adj;
> rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> + if (rps->cur_freq < rps->efficient_freq) {
> + rps->cur_freq = rps->efficient_freq;
> + rps->last_adj = 0;
this is indeed the smallest fix we can propagate:
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
but I wonder now if we couldn't simply kill the last_adj now and always go
with the rpe on park/unpark
> + }
>
> GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
> }
> --
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Limit frequency drop to RPe on parking
2020-11-24 18:35 ` [Intel-gfx] " Chris Wilson
(?)
(?)
@ 2020-11-24 20:14 ` Patchwork
-1 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2020-11-24 20:14 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/gt: Limit frequency drop to RPe on parking
URL : https://patchwork.freedesktop.org/series/84223/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
29d842e75c62 drm/i915/gt: Limit frequency drop to RPe on parking
-:26: WARNING:BAD_SIGN_OFF: email address '<stable@vger.kernel.org> # v5.8+' might be better as 'stable@vger.kernel.org# v5.8+'
#26:
Cc: <stable@vger.kernel.org> # v5.8+
total: 0 errors, 1 warnings, 0 checks, 10 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
2020-11-24 19:46 ` Rodrigo Vivi
@ 2020-11-24 20:16 ` Chris Wilson
-1 siblings, 0 replies; 11+ messages in thread
From: Chris Wilson @ 2020-11-24 20:16 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx, stable
Quoting Rodrigo Vivi (2020-11-24 19:46:29)
> On Tue, Nov 24, 2020 at 06:35:21PM +0000, Chris Wilson wrote:
> > We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> > the frequency we intend to restart the GT with. Since the two workloads
> > are likely related (e.g. a compositor rendering every 16ms), we want to
> > carry the frequency and load information from across the idling.
> > However, we do also need to update the frequencies so that workloads
> > that run for less than 1ms are autotuned by RPS (otherwise we leave
> > compositors running at max clocks, draining excess power). Conversely,
> > if we try to run too slowly, the next workload has to run longer. Since
> > there is a hysteresis in the power graph, below a certain frequency
> > running a short workload for longer consumes more energy than running it
> > slightly higher for less time. The exact balance point is unknown
> > beforehand, but measurements with 30fps media playback indicate that RPe
> > is a better choice.
> >
> > Reported-by: Edward Baker <edward.baker@intel.com>
> > Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Edward Baker <edward.baker@intel.com>
> > Cc: Andi Shyti <andi.shyti@intel.com>
> > Cc: Lyude Paul <lyude@redhat.com>
> > Cc: <stable@vger.kernel.org> # v5.8+
> > ---
> > drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index b13e7845d483..f74d5e09e176 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> > adj = -2;
> > rps->last_adj = adj;
> > rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> > + if (rps->cur_freq < rps->efficient_freq) {
> > + rps->cur_freq = rps->efficient_freq;
> > + rps->last_adj = 0;
>
> this is indeed the smallest fix we can propagate:
>
>
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> but I wonder now if we couldn't simply kill the last_adj now and always go
> with the rpe on park/unpark
Since we often have very bursty workloads that are less than 1ms, we do
want to keep the frequency across idling, or else we incur more latency
than is desired by the user (although unpark latency is no joke,
although that is mostly the context switches). The compromise for always
running shorter than an RPS interval is to "gradually" reduce the
frequency (so that compositors do not get stuck at max clocks, yet those
very same compositors also do require very quick autotuning so that
animations are smooth from idle.) Compute is another one where they have
both sustained and bursty workloads, and the shorter-than-RPS bursty
workloads are naturally expected to be to low latency.
So I still think keeping cur_freq is most often the best approach.
-Chris
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
@ 2020-11-24 20:16 ` Chris Wilson
0 siblings, 0 replies; 11+ messages in thread
From: Chris Wilson @ 2020-11-24 20:16 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx, stable
Quoting Rodrigo Vivi (2020-11-24 19:46:29)
> On Tue, Nov 24, 2020 at 06:35:21PM +0000, Chris Wilson wrote:
> > We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> > the frequency we intend to restart the GT with. Since the two workloads
> > are likely related (e.g. a compositor rendering every 16ms), we want to
> > carry the frequency and load information from across the idling.
> > However, we do also need to update the frequencies so that workloads
> > that run for less than 1ms are autotuned by RPS (otherwise we leave
> > compositors running at max clocks, draining excess power). Conversely,
> > if we try to run too slowly, the next workload has to run longer. Since
> > there is a hysteresis in the power graph, below a certain frequency
> > running a short workload for longer consumes more energy than running it
> > slightly higher for less time. The exact balance point is unknown
> > beforehand, but measurements with 30fps media playback indicate that RPe
> > is a better choice.
> >
> > Reported-by: Edward Baker <edward.baker@intel.com>
> > Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Edward Baker <edward.baker@intel.com>
> > Cc: Andi Shyti <andi.shyti@intel.com>
> > Cc: Lyude Paul <lyude@redhat.com>
> > Cc: <stable@vger.kernel.org> # v5.8+
> > ---
> > drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index b13e7845d483..f74d5e09e176 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> > adj = -2;
> > rps->last_adj = adj;
> > rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> > + if (rps->cur_freq < rps->efficient_freq) {
> > + rps->cur_freq = rps->efficient_freq;
> > + rps->last_adj = 0;
>
> this is indeed the smallest fix we can propagate:
>
>
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> but I wonder now if we couldn't simply kill the last_adj now and always go
> with the rpe on park/unpark
Since we often have very bursty workloads that are less than 1ms, we do
want to keep the frequency across idling, or else we incur more latency
than is desired by the user (although unpark latency is no joke,
although that is mostly the context switches). The compromise for always
running shorter than an RPS interval is to "gradually" reduce the
frequency (so that compositors do not get stuck at max clocks, yet those
very same compositors also do require very quick autotuning so that
animations are smooth from idle.) Compute is another one where they have
both sustained and bursty workloads, and the shorter-than-RPS bursty
workloads are naturally expected to be to low latency.
So I still think keeping cur_freq is most often the best approach.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Limit frequency drop to RPe on parking
2020-11-24 18:35 ` [Intel-gfx] " Chris Wilson
` (2 preceding siblings ...)
(?)
@ 2020-11-24 20:44 ` Patchwork
-1 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2020-11-24 20:44 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 4551 bytes --]
== Series Details ==
Series: drm/i915/gt: Limit frequency drop to RPe on parking
URL : https://patchwork.freedesktop.org/series/84223/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9385 -> Patchwork_18967
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/index.html
New tests
---------
New tests have been introduced between CI_DRM_9385 and Patchwork_18967:
### New CI tests (1) ###
* boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s
Known issues
------------
Here are the changes found in Patchwork_18967 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@gem_mmap_gtt@basic.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-tgl-y/igt@gem_mmap_gtt@basic.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-byt-j1900/igt@i915_module_load@reload.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-byt-j1900/igt@i915_module_load@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-soraka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-kbl-soraka/igt@kms_busy@basic@flip.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-kbl-soraka/igt@kms_busy@basic@flip.html
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar issue
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@kms_busy@basic@flip.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-tgl-y/igt@kms_busy@basic@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 similar issue
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u: [DMESG-WARN][11] ([i915#262]) -> [PASS][12] +1 similar issue
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-cfl-8109u/igt@gem_exec_suspend@basic-s0.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-cfl-8109u/igt@gem_exec_suspend@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-byt-j1900/igt@i915_pm_rpm@module-reload.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-byt-j1900/igt@i915_pm_rpm@module-reload.html
* igt@prime_vgem@basic-read:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1 similar issue
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/fi-tgl-y/igt@prime_vgem@basic-read.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/fi-tgl-y/igt@prime_vgem@basic-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (43 -> 39)
------------------------------
Missing (4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-------------
* Linux: CI_DRM_9385 -> Patchwork_18967
CI-20190529: 20190529
CI_DRM_9385: 3d37e624f60f40cea80e784617686ae2917e9b01 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5870: 08b13995b85df26a77212e4fb21fd772976ef33c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18967: 29d842e75c625457dd1cfe74dea57b8e1e300d17 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
29d842e75c62 drm/i915/gt: Limit frequency drop to RPe on parking
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/index.html
[-- Attachment #1.2: Type: text/html, Size: 5722 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
2020-11-24 18:35 ` [Intel-gfx] " Chris Wilson
@ 2020-11-24 21:58 ` Andi Shyti
-1 siblings, 0 replies; 11+ messages in thread
From: Andi Shyti @ 2020-11-24 21:58 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Edward Baker, Lyude Paul, stable
Hi Chris,
On Tue, Nov 24, 2020 at 06:35:21PM +0000, Chris Wilson wrote:
> We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> the frequency we intend to restart the GT with. Since the two workloads
> are likely related (e.g. a compositor rendering every 16ms), we want to
> carry the frequency and load information from across the idling.
> However, we do also need to update the frequencies so that workloads
> that run for less than 1ms are autotuned by RPS (otherwise we leave
> compositors running at max clocks, draining excess power). Conversely,
> if we try to run too slowly, the next workload has to run longer. Since
> there is a hysteresis in the power graph, below a certain frequency
> running a short workload for longer consumes more energy than running it
> slightly higher for less time. The exact balance point is unknown
> beforehand, but measurements with 30fps media playback indicate that RPe
> is a better choice.
>
> Reported-by: Edward Baker <edward.baker@intel.com>
> Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Edward Baker <edward.baker@intel.com>
> Cc: Andi Shyti <andi.shyti@intel.com>
> Cc: Lyude Paul <lyude@redhat.com>
> Cc: <stable@vger.kernel.org> # v5.8+
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> index b13e7845d483..f74d5e09e176 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> adj = -2;
> rps->last_adj = adj;
> rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> + if (rps->cur_freq < rps->efficient_freq) {
> + rps->cur_freq = rps->efficient_freq;
> + rps->last_adj = 0;
> + }
looks OK to me, makes sense:
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Thanks,
Andi
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking
@ 2020-11-24 21:58 ` Andi Shyti
0 siblings, 0 replies; 11+ messages in thread
From: Andi Shyti @ 2020-11-24 21:58 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, stable
Hi Chris,
On Tue, Nov 24, 2020 at 06:35:21PM +0000, Chris Wilson wrote:
> We treat idling the GT (intel_rps_park) as a downclock event, and reduce
> the frequency we intend to restart the GT with. Since the two workloads
> are likely related (e.g. a compositor rendering every 16ms), we want to
> carry the frequency and load information from across the idling.
> However, we do also need to update the frequencies so that workloads
> that run for less than 1ms are autotuned by RPS (otherwise we leave
> compositors running at max clocks, draining excess power). Conversely,
> if we try to run too slowly, the next workload has to run longer. Since
> there is a hysteresis in the power graph, below a certain frequency
> running a short workload for longer consumes more energy than running it
> slightly higher for less time. The exact balance point is unknown
> beforehand, but measurements with 30fps media playback indicate that RPe
> is a better choice.
>
> Reported-by: Edward Baker <edward.baker@intel.com>
> Fixes: 043cd2d14ede ("drm/i915/gt: Leave rps->cur_freq on unpark")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Edward Baker <edward.baker@intel.com>
> Cc: Andi Shyti <andi.shyti@intel.com>
> Cc: Lyude Paul <lyude@redhat.com>
> Cc: <stable@vger.kernel.org> # v5.8+
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
> index b13e7845d483..f74d5e09e176 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -907,6 +907,10 @@ void intel_rps_park(struct intel_rps *rps)
> adj = -2;
> rps->last_adj = adj;
> rps->cur_freq = max_t(int, rps->cur_freq + adj, rps->min_freq);
> + if (rps->cur_freq < rps->efficient_freq) {
> + rps->cur_freq = rps->efficient_freq;
> + rps->last_adj = 0;
> + }
looks OK to me, makes sense:
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Thanks,
Andi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Limit frequency drop to RPe on parking
2020-11-24 18:35 ` [Intel-gfx] " Chris Wilson
` (4 preceding siblings ...)
(?)
@ 2020-11-25 2:32 ` Patchwork
-1 siblings, 0 replies; 11+ messages in thread
From: Patchwork @ 2020-11-25 2:32 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 18832 bytes --]
== Series Details ==
Series: drm/i915/gt: Limit frequency drop to RPe on parking
URL : https://patchwork.freedesktop.org/series/84223/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9385_full -> Patchwork_18967_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_18967_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18967_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_18967_full:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live@gem_contexts:
- shard-skl: NOTRUN -> [INCOMPLETE][1]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl2/igt@i915_selftest@live@gem_contexts.html
New tests
---------
New tests have been introduced between CI_DRM_9385_full and Patchwork_18967_full:
### New CI tests (1) ###
* boot:
- Statuses : 198 pass(s)
- Exec time: [0.0] s
Known issues
------------
Here are the changes found in Patchwork_18967_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_mmap_wc@fault-concurrent:
- shard-iclb: [PASS][2] -> [DMESG-WARN][3] ([i915#1982])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-iclb3/igt@gem_mmap_wc@fault-concurrent.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-iclb2/igt@gem_mmap_wc@fault-concurrent.html
* igt@kms_cursor_crc@pipe-b-cursor-128x128-random:
- shard-skl: [PASS][4] -> [FAIL][5] ([i915#54]) +3 similar issues
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/igt@kms_cursor_crc@pipe-b-cursor-128x128-random.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl8/igt@kms_cursor_crc@pipe-b-cursor-128x128-random.html
* igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge:
- shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#1982])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-glk7/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-glk3/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2122])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-glk4/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@bc-hdmi-a1-hdmi-a2.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-glk3/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@bc-hdmi-a1-hdmi-a2.html
* igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-vga1-hdmi-a1:
- shard-hsw: [PASS][10] -> [DMESG-WARN][11] ([i915#1982])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-hsw4/igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-vga1-hdmi-a1.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-hsw6/igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-vga1-hdmi-a1.html
* igt@kms_flip@plain-flip-fb-recreate@a-edp1:
- shard-skl: [PASS][12] -> [DMESG-FAIL][13] ([i915#1982])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/igt@kms_flip@plain-flip-fb-recreate@a-edp1.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl5/igt@kms_flip@plain-flip-fb-recreate@a-edp1.html
* igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1:
- shard-skl: [PASS][14] -> [FAIL][15] ([i915#2122])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl3/igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
- shard-tglb: [PASS][16] -> [DMESG-WARN][17] ([i915#1982])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-tglb1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-tglb7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-cpu:
- shard-snb: [PASS][18] -> [SKIP][19] ([fdo#109271]) +2 similar issues
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-snb5/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-cpu.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-snb4/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-cpu.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-pwrite:
- shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) +3 similar issues
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-pwrite.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl3/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-pwrite.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][22] -> [FAIL][23] ([fdo#108145] / [i915#265])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl10/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl5/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-apl: [PASS][24] -> [DMESG-WARN][25] ([i915#1635] / [i915#1982] / [i915#2621])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-apl6/igt@kms_plane_lowres@pipe-a-tiling-y.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-apl6/igt@kms_plane_lowres@pipe-a-tiling-y.html
* igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][26] -> [SKIP][27] ([fdo#109441]) +1 similar issue
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-iclb8/igt@kms_psr@psr2_sprite_plane_move.html
* igt@kms_vblank@pipe-b-wait-forked-busy:
- shard-kbl: [PASS][28] -> [DMESG-WARN][29] ([i915#1982]) +6 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-kbl3/igt@kms_vblank@pipe-b-wait-forked-busy.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-kbl4/igt@kms_vblank@pipe-b-wait-forked-busy.html
- shard-apl: [PASS][30] -> [DMESG-WARN][31] ([i915#1635] / [i915#1982]) +2 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-apl8/igt@kms_vblank@pipe-b-wait-forked-busy.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-apl7/igt@kms_vblank@pipe-b-wait-forked-busy.html
* igt@sysfs_timeslice_duration@timeout@bcs0:
- shard-skl: [PASS][32] -> [FAIL][33] ([i915#1732])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl1/igt@sysfs_timeslice_duration@timeout@bcs0.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl4/igt@sysfs_timeslice_duration@timeout@bcs0.html
#### Possible fixes ####
* igt@drm_read@fault-buffer:
- shard-glk: [DMESG-WARN][34] ([i915#1982]) -> [PASS][35] +1 similar issue
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-glk4/igt@drm_read@fault-buffer.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-glk1/igt@drm_read@fault-buffer.html
* {igt@gem_exec_capture@pi@bcs0}:
- shard-iclb: [INCOMPLETE][36] ([i915#2369] / [i915#2502]) -> [PASS][37]
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-iclb5/igt@gem_exec_capture@pi@bcs0.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-iclb4/igt@gem_exec_capture@pi@bcs0.html
* igt@gem_exec_whisper@basic-fds-forked:
- shard-glk: [DMESG-WARN][38] ([i915#118] / [i915#95]) -> [PASS][39]
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-glk6/igt@gem_exec_whisper@basic-fds-forked.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-glk7/igt@gem_exec_whisper@basic-fds-forked.html
* igt@i915_module_load@reload:
- shard-tglb: [DMESG-WARN][40] ([i915#1982]) -> [PASS][41]
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-tglb2/igt@i915_module_load@reload.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-tglb5/igt@i915_module_load@reload.html
* igt@kms_big_fb@yf-tiled-16bpp-rotate-180:
- shard-skl: [DMESG-WARN][42] ([i915#1982]) -> [PASS][43] +2 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl9/igt@kms_big_fb@yf-tiled-16bpp-rotate-180.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl1/igt@kms_big_fb@yf-tiled-16bpp-rotate-180.html
* igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen:
- shard-skl: [FAIL][44] ([i915#54]) -> [PASS][45] +7 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl1/igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [FAIL][46] ([i915#96]) -> [PASS][47]
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-hsw2/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic:
- shard-skl: [FAIL][48] ([i915#2346]) -> [PASS][49]
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl9/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl1/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled:
- shard-apl: [DMESG-WARN][50] ([i915#1635] / [i915#1982]) -> [PASS][51]
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-apl2/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-apl4/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-tglb: [FAIL][52] ([i915#2598]) -> [PASS][53]
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
* igt@kms_flip@flip-vs-expired-vblank@b-edp1:
- shard-skl: [FAIL][54] ([i915#2122]) -> [PASS][55]
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl5/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl1/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
* igt@kms_flip@flip-vs-suspend@c-edp1:
- shard-skl: [INCOMPLETE][56] -> [PASS][57]
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl6/igt@kms_flip@flip-vs-suspend@c-edp1.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl5/igt@kms_flip@flip-vs-suspend@c-edp1.html
* igt@kms_flip@plain-flip-ts-check@a-dp1:
- shard-kbl: [DMESG-WARN][58] ([i915#1982]) -> [PASS][59] +1 similar issue
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-kbl4/igt@kms_flip@plain-flip-ts-check@a-dp1.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-kbl6/igt@kms_flip@plain-flip-ts-check@a-dp1.html
* igt@kms_frontbuffer_tracking@psr-suspend:
- shard-skl: [INCOMPLETE][60] ([i915#123]) -> [PASS][61]
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl9/igt@kms_frontbuffer_tracking@psr-suspend.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl8/igt@kms_frontbuffer_tracking@psr-suspend.html
* igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-b:
- shard-snb: [SKIP][62] ([fdo#109271]) -> [PASS][63] +2 similar issues
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-snb2/igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-b.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-snb6/igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-b.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [SKIP][64] ([fdo#109441]) -> [PASS][65] +2 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-iclb3/igt@kms_psr@psr2_cursor_mmap_cpu.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
#### Warnings ####
* igt@i915_pm_backlight@fade_with_suspend:
- shard-tglb: [INCOMPLETE][66] ([i915#1436] / [i915#1602] / [i915#1887] / [i915#2369] / [i915#2411] / [i915#456]) -> [DMESG-WARN][67] ([i915#1436] / [i915#1602] / [i915#1887] / [i915#2411])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-tglb7/igt@i915_pm_backlight@fade_with_suspend.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-tglb5/igt@i915_pm_backlight@fade_with_suspend.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: [WARN][68] ([i915#1804] / [i915#2684]) -> [WARN][69] ([i915#2684])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-iclb4/igt@i915_pm_rc6_residency@rc6-fence.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-iclb5/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [DMESG-WARN][70] ([i915#1226]) -> [SKIP][71] ([fdo#109349])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-iclb4/igt@kms_dp_dsc@basic-dsc-enable-edp.html
* igt@runner@aborted:
- shard-hsw: [FAIL][72] ([i915#2283] / [i915#2295] / [i915#483]) -> [FAIL][73] ([i915#2283] / [i915#2295])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-hsw1/igt@runner@aborted.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-hsw5/igt@runner@aborted.html
- shard-skl: ([FAIL][74], [FAIL][75], [FAIL][76]) ([i915#1814] / [i915#2029] / [i915#2295]) -> ([FAIL][77], [FAIL][78]) ([i915#2295] / [i915#483])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl2/igt@runner@aborted.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/igt@runner@aborted.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9385/shard-skl3/igt@runner@aborted.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl6/igt@runner@aborted.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/shard-skl7/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
[i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
[i915#123]: https://gitlab.freedesktop.org/drm/intel/issues/123
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1732]: https://gitlab.freedesktop.org/drm/intel/issues/1732
[i915#1804]: https://gitlab.freedesktop.org/drm/intel/issues/1804
[i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
[i915#1887]: https://gitlab.freedesktop.org/drm/intel/issues/1887
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
[i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
[i915#2598]: https://gitlab.freedesktop.org/drm/intel/issues/2598
[i915#2621]: https://gitlab.freedesktop.org/drm/intel/issues/2621
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#2684]: https://gitlab.freedesktop.org/drm/intel/issues/2684
[i915#456]: https://gitlab.freedesktop.org/drm/intel/issues/456
[i915#483]: https://gitlab.freedesktop.org/drm/intel/issues/483
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
[i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* Linux: CI_DRM_9385 -> Patchwork_18967
CI-20190529: 20190529
CI_DRM_9385: 3d37e624f60f40cea80e784617686ae2917e9b01 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5870: 08b13995b85df26a77212e4fb21fd772976ef33c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18967: 29d842e75c625457dd1cfe74dea57b8e1e300d17 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18967/index.html
[-- Attachment #1.2: Type: text/html, Size: 22741 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-11-25 2:32 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-24 18:35 [PATCH] drm/i915/gt: Limit frequency drop to RPe on parking Chris Wilson
2020-11-24 18:35 ` [Intel-gfx] " Chris Wilson
2020-11-24 19:46 ` Rodrigo Vivi
2020-11-24 19:46 ` Rodrigo Vivi
2020-11-24 20:16 ` Chris Wilson
2020-11-24 20:16 ` Chris Wilson
2020-11-24 20:14 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2020-11-24 20:44 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-11-24 21:58 ` [PATCH] " Andi Shyti
2020-11-24 21:58 ` [Intel-gfx] " Andi Shyti
2020-11-25 2:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork
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.