* [Intel-gfx] [PATCH v2 00/14] drm/i915/fbc: Fix FBC for glk+
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Jian-Hong Pan, Paulo Zanoni, Daniel Drake
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
CI got hopelessly confused with the v1 series so reposting in its
entirety.
I also slapped on an extra patch at the end which should hopefully
avoid the problems with FBC not getting enabled with fastboot.
Force pushed to
git://github.com/vsyrjala/linux.git glk_fbc_wa
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä (14):
drm/i915/fbc: Disable fbc by default on all glk+
drm/i915/fbc: Nuke bogus single pipe fbc1 restriction
drm/i915: Relocate intel_crtc_active()
drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB
drm/i915/fbc: Precompute gen9 cfb stride w/a
drm/i915/fbc: Track plane visibility
drm/i915/fbc: Store fence_id direction in fbc cache/params
drm/i915/fbc: Make fence_id optional for i965gm
drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/
drm/i915/fbc: Nuke fbc.enabled
drm/i915/fbc: Start using flip nuke
drm/i915/fbc: Wait for vblank after FBC disable on glk+
drm/i915/fbc: Enable fbc by default on glk+ once again
drm/i915/fbc: Reallocate cfb if we need more of it
drivers/gpu/drm/i915/display/intel_display.c | 25 +-
drivers/gpu/drm/i915/display/intel_display.h | 1 -
drivers/gpu/drm/i915/display/intel_fbc.c | 274 ++++++++++---------
drivers/gpu/drm/i915/display/intel_fbc.h | 3 +-
drivers/gpu/drm/i915/i915_drv.h | 14 +-
drivers/gpu/drm/i915/intel_pm.c | 19 ++
6 files changed, 169 insertions(+), 167 deletions(-)
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v2 01/14] drm/i915/fbc: Disable fbc by default on all glk+
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
Cc: stable, Daniel Drake, Paulo Zanoni, Jian-Hong Pan, Maarten Lankhorst
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
We're missing a workaround in the fbc code for all glk+ platforms
which can cause corruption around the top of the screen. So
enabling fbc by default is a bad idea. I'm not keen to backport
the w/a so let's start by disabling fbc by default on all glk+.
We'll lift the restriction once the w/a is in place.
Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 92c7eb243559..3cc1f4b4b5a3 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1284,7 +1284,7 @@ static int intel_sanitize_fbc_option(struct drm_i915_private *dev_priv)
return 0;
/* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
- if (IS_GEMINILAKE(dev_priv))
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
return 0;
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
--
2.23.0
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH v2 01/14] drm/i915/fbc: Disable fbc by default on all glk+
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Jian-Hong Pan, Paulo Zanoni, stable, Daniel Drake
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
We're missing a workaround in the fbc code for all glk+ platforms
which can cause corruption around the top of the screen. So
enabling fbc by default is a bad idea. I'm not keen to backport
the w/a so let's start by disabling fbc by default on all glk+.
We'll lift the restriction once the w/a is in place.
Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 92c7eb243559..3cc1f4b4b5a3 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1284,7 +1284,7 @@ static int intel_sanitize_fbc_option(struct drm_i915_private *dev_priv)
return 0;
/* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
- if (IS_GEMINILAKE(dev_priv))
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
return 0;
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCH v2 01/14] drm/i915/fbc: Disable fbc by default on all glk+
@ 2019-11-29 18:34 ` Sasha Levin
0 siblings, 0 replies; 54+ messages in thread
From: Sasha Levin @ 2019-11-29 18:34 UTC (permalink / raw)
To: Sasha Levin, Ville Syrjala, intel-gfx
Cc: Paulo Zanoni, stable, Daniel Drake, Jian-Hong Pan
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.3.13, v4.19.86, v4.14.156, v4.9.203, v4.4.203.
v5.3.13: Build OK!
v4.19.86: Failed to apply! Possible dependencies:
Unable to calculate
v4.14.156: Failed to apply! Possible dependencies:
Unable to calculate
v4.9.203: Failed to apply! Possible dependencies:
1d25724b41fa ("drm/i915/fbc: disable framebuffer compression on GeminiLake")
fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too")
v4.4.203: Failed to apply! Possible dependencies:
0e631adc1aef ("drm/i915: introduce is_active/activate/deactivate to the FBC terminology")
128d735606d4 ("drm/i915: use a single intel_fbc_work struct")
1d25724b41fa ("drm/i915/fbc: disable framebuffer compression on GeminiLake")
30c58d5896e5 ("drm/i915: extract crtc_is_valid() on the FBC code")
36dbc4d76918 ("drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake")
45b32a291978 ("drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()")
571050226c5d ("drm/i915: extract fbc_on_pipe_a_only()")
754d113304aa ("drm/i915: pass the crtc as an argument to intel_fbc_update()")
793af070a716 ("drm/i915: remove newline from a no_fbc_reason message")
80788a0fbbdf ("drm/i915/fbc: sanitize i915.enable_fbc during FBC init")
913a3a6acae3 ("drm/i915/fbc: don't print no_fbc_reason to dmesg")
a4dedd5a14a8 ("drm/i915: remove unnecessary check for crtc->primary->fb")
ab34a7e8b55a ("drm/i915/fbc: replace frequent dev_priv->fbc.x with fbc->x")
bf6189c6f062 ("drm/i915: change no_fbc_reason from enum to string")
c68ae339e710 ("drm/i915: don't disable_fbc() if FBC is already disabled")
e9c5fd26ac38 ("drm/i915: set dev_priv->fbc.crtc before scheduling the enable work")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH v2 01/14] drm/i915/fbc: Disable fbc by default on all glk+
@ 2019-11-29 18:34 ` Sasha Levin
0 siblings, 0 replies; 54+ messages in thread
From: Sasha Levin @ 2019-11-29 18:34 UTC (permalink / raw)
To: Sasha Levin, Ville Syrjala, Ville Syrjälä, intel-gfx
Cc: , Paulo Zanoni, stable, Daniel Drake, Jian-Hong Pan
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.3.13, v4.19.86, v4.14.156, v4.9.203, v4.4.203.
v5.3.13: Build OK!
v4.19.86: Failed to apply! Possible dependencies:
Unable to calculate
v4.14.156: Failed to apply! Possible dependencies:
Unable to calculate
v4.9.203: Failed to apply! Possible dependencies:
1d25724b41fa ("drm/i915/fbc: disable framebuffer compression on GeminiLake")
fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too")
v4.4.203: Failed to apply! Possible dependencies:
0e631adc1aef ("drm/i915: introduce is_active/activate/deactivate to the FBC terminology")
128d735606d4 ("drm/i915: use a single intel_fbc_work struct")
1d25724b41fa ("drm/i915/fbc: disable framebuffer compression on GeminiLake")
30c58d5896e5 ("drm/i915: extract crtc_is_valid() on the FBC code")
36dbc4d76918 ("drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake")
45b32a291978 ("drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()")
571050226c5d ("drm/i915: extract fbc_on_pipe_a_only()")
754d113304aa ("drm/i915: pass the crtc as an argument to intel_fbc_update()")
793af070a716 ("drm/i915: remove newline from a no_fbc_reason message")
80788a0fbbdf ("drm/i915/fbc: sanitize i915.enable_fbc during FBC init")
913a3a6acae3 ("drm/i915/fbc: don't print no_fbc_reason to dmesg")
a4dedd5a14a8 ("drm/i915: remove unnecessary check for crtc->primary->fb")
ab34a7e8b55a ("drm/i915/fbc: replace frequent dev_priv->fbc.x with fbc->x")
bf6189c6f062 ("drm/i915: change no_fbc_reason from enum to string")
c68ae339e710 ("drm/i915: don't disable_fbc() if FBC is already disabled")
e9c5fd26ac38 ("drm/i915: set dev_priv->fbc.crtc before scheduling the enable work")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v2 02/14] drm/i915/fbc: Nuke bogus single pipe fbc1 restriction
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Not sure where the single pipe only restriction came for fbc1.
Nothing I can see that would prevent this.
v2: Nuke no_fbc_on_multiple_pipes() too
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 2 -
drivers/gpu/drm/i915/display/intel_fbc.c | 52 --------------------
drivers/gpu/drm/i915/display/intel_fbc.h | 1 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
4 files changed, 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 53dc310a5f6d..d4ca0bc4b260 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17869,8 +17869,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
}
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
-
- intel_fbc_init_pipe_state(dev_priv);
}
void intel_display_resume(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 3cc1f4b4b5a3..2b64b172407d 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -50,11 +50,6 @@ static inline bool fbc_supported(struct drm_i915_private *dev_priv)
return HAS_FBC(dev_priv);
}
-static inline bool no_fbc_on_multiple_pipes(struct drm_i915_private *dev_priv)
-{
- return INTEL_GEN(dev_priv) <= 3;
-}
-
/*
* In some platforms where the CRTC's x:0/y:0 coordinates doesn't match the
* frontbuffer's x:0/y:0 coordinates we lie to the hardware about the plane's
@@ -419,25 +414,6 @@ static void intel_fbc_deactivate(struct drm_i915_private *dev_priv,
fbc->no_fbc_reason = reason;
}
-static bool multiple_pipes_ok(struct intel_crtc *crtc,
- struct intel_plane_state *plane_state)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_fbc *fbc = &dev_priv->fbc;
- enum pipe pipe = crtc->pipe;
-
- /* Don't even bother tracking anything we don't need. */
- if (!no_fbc_on_multiple_pipes(dev_priv))
- return true;
-
- if (plane_state->uapi.visible)
- fbc->visible_pipes_mask |= (1 << pipe);
- else
- fbc->visible_pipes_mask &= ~(1 << pipe);
-
- return (fbc->visible_pipes_mask & ~(1 << pipe)) != 0;
-}
-
static int find_compression_threshold(struct drm_i915_private *dev_priv,
struct drm_mm_node *node,
int size,
@@ -867,18 +843,12 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
- if (!multiple_pipes_ok(crtc, plane_state)) {
- reason = "more than one pipe active";
- goto deactivate;
- }
-
if (!fbc->enabled || fbc->crtc != crtc)
goto unlock;
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
-deactivate:
intel_fbc_deactivate(dev_priv, reason);
unlock:
mutex_unlock(&fbc->lock);
@@ -1244,28 +1214,6 @@ void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
schedule_work(&fbc->underrun_work);
}
-/**
- * intel_fbc_init_pipe_state - initialize FBC's CRTC visibility tracking
- * @dev_priv: i915 device instance
- *
- * The FBC code needs to track CRTC visibility since the older platforms can't
- * have FBC enabled while multiple pipes are used. This function does the
- * initial setup at driver load to make sure FBC is matching the real hardware.
- */
-void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv)
-{
- struct intel_crtc *crtc;
-
- /* Don't even bother tracking anything if we don't need. */
- if (!no_fbc_on_multiple_pipes(dev_priv))
- return;
-
- for_each_intel_crtc(&dev_priv->drm, crtc)
- if (intel_crtc_active(crtc) &&
- crtc->base.primary->state->visible)
- dev_priv->fbc.visible_pipes_mask |= (1 << crtc->pipe);
-}
-
/*
* The DDX driver changes its behavior depending on the value it reads from
* i915.enable_fbc, so sanitize it by translating the default value into either
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h b/drivers/gpu/drm/i915/display/intel_fbc.h
index 50272eda8d43..ba8eeefd4d9a 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -24,7 +24,6 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_plane_state *plane_state);
void intel_fbc_post_update(struct intel_crtc *crtc);
void intel_fbc_init(struct drm_i915_private *dev_priv);
-void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv);
void intel_fbc_enable(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14744c114475..d0e00078fbce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -366,7 +366,6 @@ struct intel_fbc {
unsigned threshold;
unsigned int possible_framebuffer_bits;
unsigned int busy_bits;
- unsigned int visible_pipes_mask;
struct intel_crtc *crtc;
struct drm_mm_node compressed_fb;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 02/14] drm/i915/fbc: Nuke bogus single pipe fbc1 restriction
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Not sure where the single pipe only restriction came for fbc1.
Nothing I can see that would prevent this.
v2: Nuke no_fbc_on_multiple_pipes() too
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 2 -
drivers/gpu/drm/i915/display/intel_fbc.c | 52 --------------------
drivers/gpu/drm/i915/display/intel_fbc.h | 1 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
4 files changed, 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 53dc310a5f6d..d4ca0bc4b260 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17869,8 +17869,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
}
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
-
- intel_fbc_init_pipe_state(dev_priv);
}
void intel_display_resume(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 3cc1f4b4b5a3..2b64b172407d 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -50,11 +50,6 @@ static inline bool fbc_supported(struct drm_i915_private *dev_priv)
return HAS_FBC(dev_priv);
}
-static inline bool no_fbc_on_multiple_pipes(struct drm_i915_private *dev_priv)
-{
- return INTEL_GEN(dev_priv) <= 3;
-}
-
/*
* In some platforms where the CRTC's x:0/y:0 coordinates doesn't match the
* frontbuffer's x:0/y:0 coordinates we lie to the hardware about the plane's
@@ -419,25 +414,6 @@ static void intel_fbc_deactivate(struct drm_i915_private *dev_priv,
fbc->no_fbc_reason = reason;
}
-static bool multiple_pipes_ok(struct intel_crtc *crtc,
- struct intel_plane_state *plane_state)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_fbc *fbc = &dev_priv->fbc;
- enum pipe pipe = crtc->pipe;
-
- /* Don't even bother tracking anything we don't need. */
- if (!no_fbc_on_multiple_pipes(dev_priv))
- return true;
-
- if (plane_state->uapi.visible)
- fbc->visible_pipes_mask |= (1 << pipe);
- else
- fbc->visible_pipes_mask &= ~(1 << pipe);
-
- return (fbc->visible_pipes_mask & ~(1 << pipe)) != 0;
-}
-
static int find_compression_threshold(struct drm_i915_private *dev_priv,
struct drm_mm_node *node,
int size,
@@ -867,18 +843,12 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
- if (!multiple_pipes_ok(crtc, plane_state)) {
- reason = "more than one pipe active";
- goto deactivate;
- }
-
if (!fbc->enabled || fbc->crtc != crtc)
goto unlock;
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
-deactivate:
intel_fbc_deactivate(dev_priv, reason);
unlock:
mutex_unlock(&fbc->lock);
@@ -1244,28 +1214,6 @@ void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
schedule_work(&fbc->underrun_work);
}
-/**
- * intel_fbc_init_pipe_state - initialize FBC's CRTC visibility tracking
- * @dev_priv: i915 device instance
- *
- * The FBC code needs to track CRTC visibility since the older platforms can't
- * have FBC enabled while multiple pipes are used. This function does the
- * initial setup at driver load to make sure FBC is matching the real hardware.
- */
-void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv)
-{
- struct intel_crtc *crtc;
-
- /* Don't even bother tracking anything if we don't need. */
- if (!no_fbc_on_multiple_pipes(dev_priv))
- return;
-
- for_each_intel_crtc(&dev_priv->drm, crtc)
- if (intel_crtc_active(crtc) &&
- crtc->base.primary->state->visible)
- dev_priv->fbc.visible_pipes_mask |= (1 << crtc->pipe);
-}
-
/*
* The DDX driver changes its behavior depending on the value it reads from
* i915.enable_fbc, so sanitize it by translating the default value into either
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h b/drivers/gpu/drm/i915/display/intel_fbc.h
index 50272eda8d43..ba8eeefd4d9a 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -24,7 +24,6 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_plane_state *plane_state);
void intel_fbc_post_update(struct intel_crtc *crtc);
void intel_fbc_init(struct drm_i915_private *dev_priv);
-void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv);
void intel_fbc_enable(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14744c114475..d0e00078fbce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -366,7 +366,6 @@ struct intel_fbc {
unsigned threshold;
unsigned int possible_framebuffer_bits;
unsigned int busy_bits;
- unsigned int visible_pipes_mask;
struct intel_crtc *crtc;
struct drm_mm_node compressed_fb;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 03/14] drm/i915: Relocate intel_crtc_active()
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Lucas De Marchi
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Move intel_crtc_active() next to its only remaining
user (pre-g4x wm code).
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 19 -------------------
drivers/gpu/drm/i915/display/intel_display.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 19 +++++++++++++++++++
3 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index d4ca0bc4b260..d592b7284406 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1040,25 +1040,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
NULL, best_clock);
}
-bool intel_crtc_active(struct intel_crtc *crtc)
-{
- /* Be paranoid as we can arrive here with only partial
- * state retrieved from the hardware during setup.
- *
- * We can ditch the adjusted_mode.crtc_clock check as soon
- * as Haswell has gained clock readout/fastboot support.
- *
- * We can ditch the crtc->primary->state->fb check as soon as we can
- * properly reconstruct framebuffers.
- *
- * FIXME: The intel_crtc->active here should be switched to
- * crtc->state->active once we have proper CRTC states wired up
- * for atomic.
- */
- return crtc->active && crtc->base.primary->state->fb &&
- crtc->config->hw.adjusted_mode.crtc_clock;
-}
-
enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
diff --git a/drivers/gpu/drm/i915/display/intel_display.h b/drivers/gpu/drm/i915/display/intel_display.h
index a5ec5eeff056..d18dc260fe83 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -558,7 +558,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
int chv_calc_dpll_params(int refclk, struct dpll *pll_clock);
-bool intel_crtc_active(struct intel_crtc *crtc);
bool hsw_crtc_state_ips_capable(const struct intel_crtc_state *crtc_state);
void hsw_enable_ips(const struct intel_crtc_state *crtc_state);
void hsw_disable_ips(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5aad9d49a528..eb54110119d6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -814,6 +814,25 @@ static bool intel_wm_plane_visible(const struct intel_crtc_state *crtc_state,
return plane_state->uapi.visible;
}
+static bool intel_crtc_active(struct intel_crtc *crtc)
+{
+ /* Be paranoid as we can arrive here with only partial
+ * state retrieved from the hardware during setup.
+ *
+ * We can ditch the adjusted_mode.crtc_clock check as soon
+ * as Haswell has gained clock readout/fastboot support.
+ *
+ * We can ditch the crtc->primary->state->fb check as soon as we can
+ * properly reconstruct framebuffers.
+ *
+ * FIXME: The intel_crtc->active here should be switched to
+ * crtc->state->active once we have proper CRTC states wired up
+ * for atomic.
+ */
+ return crtc->active && crtc->base.primary->state->fb &&
+ crtc->config->hw.adjusted_mode.crtc_clock;
+}
+
static struct intel_crtc *single_enabled_crtc(struct drm_i915_private *dev_priv)
{
struct intel_crtc *crtc, *enabled = NULL;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 03/14] drm/i915: Relocate intel_crtc_active()
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Lucas De Marchi
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Move intel_crtc_active() next to its only remaining
user (pre-g4x wm code).
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 19 -------------------
drivers/gpu/drm/i915/display/intel_display.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 19 +++++++++++++++++++
3 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index d4ca0bc4b260..d592b7284406 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1040,25 +1040,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
NULL, best_clock);
}
-bool intel_crtc_active(struct intel_crtc *crtc)
-{
- /* Be paranoid as we can arrive here with only partial
- * state retrieved from the hardware during setup.
- *
- * We can ditch the adjusted_mode.crtc_clock check as soon
- * as Haswell has gained clock readout/fastboot support.
- *
- * We can ditch the crtc->primary->state->fb check as soon as we can
- * properly reconstruct framebuffers.
- *
- * FIXME: The intel_crtc->active here should be switched to
- * crtc->state->active once we have proper CRTC states wired up
- * for atomic.
- */
- return crtc->active && crtc->base.primary->state->fb &&
- crtc->config->hw.adjusted_mode.crtc_clock;
-}
-
enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
diff --git a/drivers/gpu/drm/i915/display/intel_display.h b/drivers/gpu/drm/i915/display/intel_display.h
index a5ec5eeff056..d18dc260fe83 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -558,7 +558,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
int chv_calc_dpll_params(int refclk, struct dpll *pll_clock);
-bool intel_crtc_active(struct intel_crtc *crtc);
bool hsw_crtc_state_ips_capable(const struct intel_crtc_state *crtc_state);
void hsw_enable_ips(const struct intel_crtc_state *crtc_state);
void hsw_disable_ips(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5aad9d49a528..eb54110119d6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -814,6 +814,25 @@ static bool intel_wm_plane_visible(const struct intel_crtc_state *crtc_state,
return plane_state->uapi.visible;
}
+static bool intel_crtc_active(struct intel_crtc *crtc)
+{
+ /* Be paranoid as we can arrive here with only partial
+ * state retrieved from the hardware during setup.
+ *
+ * We can ditch the adjusted_mode.crtc_clock check as soon
+ * as Haswell has gained clock readout/fastboot support.
+ *
+ * We can ditch the crtc->primary->state->fb check as soon as we can
+ * properly reconstruct framebuffers.
+ *
+ * FIXME: The intel_crtc->active here should be switched to
+ * crtc->state->active once we have proper CRTC states wired up
+ * for atomic.
+ */
+ return crtc->active && crtc->base.primary->state->fb &&
+ crtc->config->hw.adjusted_mode.crtc_clock;
+}
+
static struct intel_crtc *single_enabled_crtc(struct drm_i915_private *dev_priv)
{
struct intel_crtc *crtc, *enabled = NULL;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 04/14] drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
We don't want to use the FBC hardware render tracking so let's not
enable it. To use the hw tracking properly we'd anyway need to
integrate this into the command submissing path as the register is
context saved, and if rendering happens via the ppgtt we'd have
to configure it with the ppgtt address instead of the ggtt address.
Easier to use software tracking instead.
Note that on pre-ilk we can't actually disable render tracking.
However we can't rely on it because it requires that DSPSURF to
match the render target address, and since we play tricks
with DSPSURF that may not be the case. Hence we shall rely on
software render tracking on all platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 2b64b172407d..eefa5a88b304 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -248,8 +248,6 @@ static void ilk_fbc_activate(struct drm_i915_private *dev_priv)
}
I915_WRITE(ILK_DPFC_FENCE_YOFF, params->crtc.fence_y_offset);
- I915_WRITE(ILK_FBC_RT_BASE,
- i915_ggtt_offset(params->vma) | ILK_FBC_RT_VALID);
/* enable it... */
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH v2 04/14] drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
We don't want to use the FBC hardware render tracking so let's not
enable it. To use the hw tracking properly we'd anyway need to
integrate this into the command submissing path as the register is
context saved, and if rendering happens via the ppgtt we'd have
to configure it with the ppgtt address instead of the ggtt address.
Easier to use software tracking instead.
Note that on pre-ilk we can't actually disable render tracking.
However we can't rely on it because it requires that DSPSURF to
match the render target address, and since we play tricks
with DSPSURF that may not be the case. Hence we shall rely on
software render tracking on all platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 2b64b172407d..eefa5a88b304 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -248,8 +248,6 @@ static void ilk_fbc_activate(struct drm_i915_private *dev_priv)
}
I915_WRITE(ILK_DPFC_FENCE_YOFF, params->crtc.fence_y_offset);
- I915_WRITE(ILK_FBC_RT_BASE,
- i915_ggtt_offset(params->vma) | ILK_FBC_RT_VALID);
/* enable it... */
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 05/14] drm/i915/fbc: Precompute gen9 cfb stride w/a
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Precompute the override cfb stride value so that we can check
it when determining if flip nuke can be used or not.
The hardware has 13 bits for this, so we can shrink the storage
to u16 while at it.
v2: Don't explode when crtc_state->enable_fbc lies to us
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 38 +++++++++++++++---------
drivers/gpu/drm/i915/i915_drv.h | 3 +-
2 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index eefa5a88b304..6a32f1eaefeb 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -283,8 +283,7 @@ static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
val &= ~(FBC_STRIDE_OVERRIDE | FBC_STRIDE_MASK);
- if (i915_gem_object_get_tiling(params->vma->obj) !=
- I915_TILING_X)
+ if (params->gen9_wa_cfb_stride)
val |= FBC_STRIDE_OVERRIDE | params->gen9_wa_cfb_stride;
I915_WRITE(CHICKEN_MISC_4, val);
@@ -414,8 +413,8 @@ static void intel_fbc_deactivate(struct drm_i915_private *dev_priv,
static int find_compression_threshold(struct drm_i915_private *dev_priv,
struct drm_mm_node *node,
- int size,
- int fb_cpp)
+ unsigned int size,
+ unsigned int fb_cpp)
{
int compression_threshold = 1;
int ret;
@@ -461,18 +460,15 @@ static int find_compression_threshold(struct drm_i915_private *dev_priv,
}
}
-static int intel_fbc_alloc_cfb(struct intel_crtc *crtc)
+static int intel_fbc_alloc_cfb(struct drm_i915_private *dev_priv,
+ unsigned int size, unsigned int fb_cpp)
{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = &dev_priv->fbc;
struct drm_mm_node *uninitialized_var(compressed_llb);
- int size, fb_cpp, ret;
+ int ret;
WARN_ON(drm_mm_node_allocated(&fbc->compressed_fb));
- size = intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache);
- fb_cpp = fbc->state_cache.fb.format->cpp[0];
-
ret = find_compression_threshold(dev_priv, &fbc->compressed_fb,
size, fb_cpp);
if (!ret)
@@ -823,9 +819,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
params->cfb_size = intel_fbc_calculate_cfb_size(dev_priv, cache);
- if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
- params->gen9_wa_cfb_stride = DIV_ROUND_UP(cache->plane.src_w,
- 32 * fbc->threshold) * 8;
+ params->gen9_wa_cfb_stride = cache->gen9_wa_cfb_stride;
}
void intel_fbc_pre_update(struct intel_crtc *crtc,
@@ -1054,6 +1048,8 @@ void intel_fbc_enable(struct intel_crtc *crtc,
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = &dev_priv->fbc;
+ struct intel_fbc_state_cache *cache = &fbc->state_cache;
+ const struct drm_framebuffer *fb = plane_state->hw.fb;
if (!fbc_supported(dev_priv))
return;
@@ -1076,11 +1072,25 @@ void intel_fbc_enable(struct intel_crtc *crtc,
WARN_ON(fbc->crtc != NULL);
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
- if (intel_fbc_alloc_cfb(crtc)) {
+
+ /* FIXME crtc_state->enable_fbc lies :( */
+ if (!cache->plane.visible)
+ goto out;
+
+ if (intel_fbc_alloc_cfb(dev_priv,
+ intel_fbc_calculate_cfb_size(dev_priv, cache),
+ fb->format->cpp[0])) {
fbc->no_fbc_reason = "not enough stolen memory";
goto out;
}
+ if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv) &&
+ fb->modifier != I915_FORMAT_MOD_X_TILED)
+ cache->gen9_wa_cfb_stride =
+ DIV_ROUND_UP(cache->plane.src_w, 32 * fbc->threshold) * 8;
+ else
+ cache->gen9_wa_cfb_stride = 0;
+
DRM_DEBUG_KMS("Enabling FBC on pipe %c\n", pipe_name(crtc->pipe));
fbc->no_fbc_reason = "FBC enabled but not active yet\n";
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0e00078fbce..ccde7eaf7dab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -417,6 +417,7 @@ struct intel_fbc {
const struct drm_format_info *format;
unsigned int stride;
} fb;
+ u16 gen9_wa_cfb_stride;
} state_cache;
/*
@@ -442,7 +443,7 @@ struct intel_fbc {
} fb;
int cfb_size;
- unsigned int gen9_wa_cfb_stride;
+ u16 gen9_wa_cfb_stride;
} params;
const char *no_fbc_reason;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 05/14] drm/i915/fbc: Precompute gen9 cfb stride w/a
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Precompute the override cfb stride value so that we can check
it when determining if flip nuke can be used or not.
The hardware has 13 bits for this, so we can shrink the storage
to u16 while at it.
v2: Don't explode when crtc_state->enable_fbc lies to us
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 38 +++++++++++++++---------
drivers/gpu/drm/i915/i915_drv.h | 3 +-
2 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index eefa5a88b304..6a32f1eaefeb 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -283,8 +283,7 @@ static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
val &= ~(FBC_STRIDE_OVERRIDE | FBC_STRIDE_MASK);
- if (i915_gem_object_get_tiling(params->vma->obj) !=
- I915_TILING_X)
+ if (params->gen9_wa_cfb_stride)
val |= FBC_STRIDE_OVERRIDE | params->gen9_wa_cfb_stride;
I915_WRITE(CHICKEN_MISC_4, val);
@@ -414,8 +413,8 @@ static void intel_fbc_deactivate(struct drm_i915_private *dev_priv,
static int find_compression_threshold(struct drm_i915_private *dev_priv,
struct drm_mm_node *node,
- int size,
- int fb_cpp)
+ unsigned int size,
+ unsigned int fb_cpp)
{
int compression_threshold = 1;
int ret;
@@ -461,18 +460,15 @@ static int find_compression_threshold(struct drm_i915_private *dev_priv,
}
}
-static int intel_fbc_alloc_cfb(struct intel_crtc *crtc)
+static int intel_fbc_alloc_cfb(struct drm_i915_private *dev_priv,
+ unsigned int size, unsigned int fb_cpp)
{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = &dev_priv->fbc;
struct drm_mm_node *uninitialized_var(compressed_llb);
- int size, fb_cpp, ret;
+ int ret;
WARN_ON(drm_mm_node_allocated(&fbc->compressed_fb));
- size = intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache);
- fb_cpp = fbc->state_cache.fb.format->cpp[0];
-
ret = find_compression_threshold(dev_priv, &fbc->compressed_fb,
size, fb_cpp);
if (!ret)
@@ -823,9 +819,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
params->cfb_size = intel_fbc_calculate_cfb_size(dev_priv, cache);
- if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
- params->gen9_wa_cfb_stride = DIV_ROUND_UP(cache->plane.src_w,
- 32 * fbc->threshold) * 8;
+ params->gen9_wa_cfb_stride = cache->gen9_wa_cfb_stride;
}
void intel_fbc_pre_update(struct intel_crtc *crtc,
@@ -1054,6 +1048,8 @@ void intel_fbc_enable(struct intel_crtc *crtc,
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = &dev_priv->fbc;
+ struct intel_fbc_state_cache *cache = &fbc->state_cache;
+ const struct drm_framebuffer *fb = plane_state->hw.fb;
if (!fbc_supported(dev_priv))
return;
@@ -1076,11 +1072,25 @@ void intel_fbc_enable(struct intel_crtc *crtc,
WARN_ON(fbc->crtc != NULL);
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
- if (intel_fbc_alloc_cfb(crtc)) {
+
+ /* FIXME crtc_state->enable_fbc lies :( */
+ if (!cache->plane.visible)
+ goto out;
+
+ if (intel_fbc_alloc_cfb(dev_priv,
+ intel_fbc_calculate_cfb_size(dev_priv, cache),
+ fb->format->cpp[0])) {
fbc->no_fbc_reason = "not enough stolen memory";
goto out;
}
+ if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv) &&
+ fb->modifier != I915_FORMAT_MOD_X_TILED)
+ cache->gen9_wa_cfb_stride =
+ DIV_ROUND_UP(cache->plane.src_w, 32 * fbc->threshold) * 8;
+ else
+ cache->gen9_wa_cfb_stride = 0;
+
DRM_DEBUG_KMS("Enabling FBC on pipe %c\n", pipe_name(crtc->pipe));
fbc->no_fbc_reason = "FBC enabled but not active yet\n";
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0e00078fbce..ccde7eaf7dab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -417,6 +417,7 @@ struct intel_fbc {
const struct drm_format_info *format;
unsigned int stride;
} fb;
+ u16 gen9_wa_cfb_stride;
} state_cache;
/*
@@ -442,7 +443,7 @@ struct intel_fbc {
} fb;
int cfb_size;
- unsigned int gen9_wa_cfb_stride;
+ u16 gen9_wa_cfb_stride;
} params;
const char *no_fbc_reason;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 06/14] drm/i915/fbc: Track plane visibility
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Currently the code (ab)uses cache->vma to indicate the plane
visibility. I want to nuke that so let's add a dedicated boolean
for this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 21 ++++++++++-----------
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 6a32f1eaefeb..54ed1a74d02b 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -634,8 +634,9 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
struct intel_fbc_state_cache *cache = &fbc->state_cache;
struct drm_framebuffer *fb = plane_state->hw.fb;
- cache->vma = NULL;
- cache->flags = 0;
+ cache->plane.visible = plane_state->uapi.visible;
+ if (!cache->plane.visible)
+ return;
cache->crtc.mode_flags = crtc_state->hw.adjusted_mode.flags;
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
@@ -649,16 +650,12 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
*/
cache->plane.src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
cache->plane.src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
- cache->plane.visible = plane_state->uapi.visible;
cache->plane.adjusted_x = plane_state->color_plane[0].x;
cache->plane.adjusted_y = plane_state->color_plane[0].y;
cache->plane.y = plane_state->uapi.src.y1 >> 16;
cache->plane.pixel_blend_mode = plane_state->hw.pixel_blend_mode;
- if (!cache->plane.visible)
- return;
-
cache->fb.format = fb->format;
cache->fb.stride = fb->pitches[0];
@@ -674,6 +671,11 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
struct intel_fbc *fbc = &dev_priv->fbc;
struct intel_fbc_state_cache *cache = &fbc->state_cache;
+ if (!cache->plane.visible) {
+ fbc->no_fbc_reason = "primary plane not visible";
+ return false;
+ }
+
/* We don't need to use a state cache here since this information is
* global for all CRTC.
*/
@@ -682,11 +684,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
- if (!cache->vma) {
- fbc->no_fbc_reason = "primary plane not visible";
- return false;
- }
-
if (cache->crtc.mode_flags & DRM_MODE_FLAG_INTERLACE) {
fbc->no_fbc_reason = "incompatible mode";
return false;
@@ -820,6 +817,8 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
params->cfb_size = intel_fbc_calculate_cfb_size(dev_priv, cache);
params->gen9_wa_cfb_stride = cache->gen9_wa_cfb_stride;
+
+ params->plane_visible = cache->plane.visible;
}
void intel_fbc_pre_update(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccde7eaf7dab..82dafef9ae10 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -444,6 +444,7 @@ struct intel_fbc {
int cfb_size;
u16 gen9_wa_cfb_stride;
+ bool plane_visible;
} params;
const char *no_fbc_reason;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 06/14] drm/i915/fbc: Track plane visibility
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Currently the code (ab)uses cache->vma to indicate the plane
visibility. I want to nuke that so let's add a dedicated boolean
for this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 21 ++++++++++-----------
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 6a32f1eaefeb..54ed1a74d02b 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -634,8 +634,9 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
struct intel_fbc_state_cache *cache = &fbc->state_cache;
struct drm_framebuffer *fb = plane_state->hw.fb;
- cache->vma = NULL;
- cache->flags = 0;
+ cache->plane.visible = plane_state->uapi.visible;
+ if (!cache->plane.visible)
+ return;
cache->crtc.mode_flags = crtc_state->hw.adjusted_mode.flags;
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
@@ -649,16 +650,12 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
*/
cache->plane.src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
cache->plane.src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
- cache->plane.visible = plane_state->uapi.visible;
cache->plane.adjusted_x = plane_state->color_plane[0].x;
cache->plane.adjusted_y = plane_state->color_plane[0].y;
cache->plane.y = plane_state->uapi.src.y1 >> 16;
cache->plane.pixel_blend_mode = plane_state->hw.pixel_blend_mode;
- if (!cache->plane.visible)
- return;
-
cache->fb.format = fb->format;
cache->fb.stride = fb->pitches[0];
@@ -674,6 +671,11 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
struct intel_fbc *fbc = &dev_priv->fbc;
struct intel_fbc_state_cache *cache = &fbc->state_cache;
+ if (!cache->plane.visible) {
+ fbc->no_fbc_reason = "primary plane not visible";
+ return false;
+ }
+
/* We don't need to use a state cache here since this information is
* global for all CRTC.
*/
@@ -682,11 +684,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
- if (!cache->vma) {
- fbc->no_fbc_reason = "primary plane not visible";
- return false;
- }
-
if (cache->crtc.mode_flags & DRM_MODE_FLAG_INTERLACE) {
fbc->no_fbc_reason = "incompatible mode";
return false;
@@ -820,6 +817,8 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
params->cfb_size = intel_fbc_calculate_cfb_size(dev_priv, cache);
params->gen9_wa_cfb_stride = cache->gen9_wa_cfb_stride;
+
+ params->plane_visible = cache->plane.visible;
}
void intel_fbc_pre_update(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ccde7eaf7dab..82dafef9ae10 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -444,6 +444,7 @@ struct intel_fbc {
int cfb_size;
u16 gen9_wa_cfb_stride;
+ bool plane_visible;
} params;
const char *no_fbc_reason;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 07/14] drm/i915/fbc: Store fence_id direction in fbc cache/params
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Rather than playing around with vma+flags let's just grab
the fence id from within and stash that directly in the fbc
cache/params.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 33 +++++++++++++-----------
drivers/gpu/drm/i915/i915_drv.h | 8 ++----
2 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 54ed1a74d02b..600565647f37 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -151,7 +151,7 @@ static void i8xx_fbc_activate(struct drm_i915_private *dev_priv)
if (IS_I945GM(dev_priv))
fbc_ctl |= FBC_CTL_C3_IDLE; /* 945 needs special SR handling */
fbc_ctl |= (cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
- fbc_ctl |= params->vma->fence->id;
+ fbc_ctl |= params->fence_id;
I915_WRITE(FBC_CONTROL, fbc_ctl);
}
@@ -171,8 +171,8 @@ static void g4x_fbc_activate(struct drm_i915_private *dev_priv)
else
dpfc_ctl |= DPFC_CTL_LIMIT_1X;
- if (params->flags & PLANE_HAS_FENCE) {
- dpfc_ctl |= DPFC_CTL_FENCE_EN | params->vma->fence->id;
+ if (params->fence_id >= 0) {
+ dpfc_ctl |= DPFC_CTL_FENCE_EN | params->fence_id;
I915_WRITE(DPFC_FENCE_YOFF, params->crtc.fence_y_offset);
} else {
I915_WRITE(DPFC_FENCE_YOFF, 0);
@@ -229,14 +229,14 @@ static void ilk_fbc_activate(struct drm_i915_private *dev_priv)
break;
}
- if (params->flags & PLANE_HAS_FENCE) {
+ if (params->fence_id >= 0) {
dpfc_ctl |= DPFC_CTL_FENCE_EN;
if (IS_GEN(dev_priv, 5))
- dpfc_ctl |= params->vma->fence->id;
+ dpfc_ctl |= params->fence_id;
if (IS_GEN(dev_priv, 6)) {
I915_WRITE(SNB_DPFC_CTL_SA,
SNB_CPU_FENCE_ENABLE |
- params->vma->fence->id);
+ params->fence_id);
I915_WRITE(DPFC_CPU_FENCE_OFFSET,
params->crtc.fence_y_offset);
}
@@ -309,11 +309,11 @@ static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
break;
}
- if (params->flags & PLANE_HAS_FENCE) {
+ if (params->fence_id >= 0) {
dpfc_ctl |= IVB_DPFC_CTL_FENCE_EN;
I915_WRITE(SNB_DPFC_CTL_SA,
SNB_CPU_FENCE_ENABLE |
- params->vma->fence->id);
+ params->fence_id);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, params->crtc.fence_y_offset);
} else {
I915_WRITE(SNB_DPFC_CTL_SA,0);
@@ -659,10 +659,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
cache->fb.format = fb->format;
cache->fb.stride = fb->pitches[0];
- cache->vma = plane_state->vma;
- cache->flags = plane_state->flags;
- if (WARN_ON(cache->flags & PLANE_HAS_FENCE && !cache->vma->fence))
- cache->flags &= ~PLANE_HAS_FENCE;
+ WARN_ON(plane_state->flags & PLANE_HAS_FENCE &&
+ !plane_state->vma->fence);
+
+ if (plane_state->flags & PLANE_HAS_FENCE &&
+ plane_state->vma->fence)
+ cache->fence_id = plane_state->vma->fence->id;
+ else
+ cache->fence_id = -1;
}
static bool intel_fbc_can_activate(struct intel_crtc *crtc)
@@ -707,7 +711,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
* For now this will effecively disable FBC with 90/270 degree
* rotation.
*/
- if (!(cache->flags & PLANE_HAS_FENCE)) {
+ if (cache->fence_id < 0) {
fbc->no_fbc_reason = "framebuffer not tiled or fenced";
return false;
}
@@ -804,8 +808,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
* zero. */
memset(params, 0, sizeof(*params));
- params->vma = cache->vma;
- params->flags = cache->flags;
+ params->fence_id = cache->fence_id;
params->crtc.pipe = crtc->pipe;
params->crtc.i9xx_plane = to_intel_plane(crtc->base.primary)->i9xx_plane;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82dafef9ae10..81556dc353b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -386,9 +386,6 @@ struct intel_fbc {
* these problems.
*/
struct intel_fbc_state_cache {
- struct i915_vma *vma;
- unsigned long flags;
-
struct {
unsigned int mode_flags;
u32 hsw_bdw_pixel_rate;
@@ -418,6 +415,7 @@ struct intel_fbc {
unsigned int stride;
} fb;
u16 gen9_wa_cfb_stride;
+ s8 fence_id;
} state_cache;
/*
@@ -428,9 +426,6 @@ struct intel_fbc {
* are supposed to read from it in order to program the registers.
*/
struct intel_fbc_reg_params {
- struct i915_vma *vma;
- unsigned long flags;
-
struct {
enum pipe pipe;
enum i9xx_plane_id i9xx_plane;
@@ -444,6 +439,7 @@ struct intel_fbc {
int cfb_size;
u16 gen9_wa_cfb_stride;
+ s8 fence_id;
bool plane_visible;
} params;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 07/14] drm/i915/fbc: Store fence_id direction in fbc cache/params
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Rather than playing around with vma+flags let's just grab
the fence id from within and stash that directly in the fbc
cache/params.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 33 +++++++++++++-----------
drivers/gpu/drm/i915/i915_drv.h | 8 ++----
2 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 54ed1a74d02b..600565647f37 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -151,7 +151,7 @@ static void i8xx_fbc_activate(struct drm_i915_private *dev_priv)
if (IS_I945GM(dev_priv))
fbc_ctl |= FBC_CTL_C3_IDLE; /* 945 needs special SR handling */
fbc_ctl |= (cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
- fbc_ctl |= params->vma->fence->id;
+ fbc_ctl |= params->fence_id;
I915_WRITE(FBC_CONTROL, fbc_ctl);
}
@@ -171,8 +171,8 @@ static void g4x_fbc_activate(struct drm_i915_private *dev_priv)
else
dpfc_ctl |= DPFC_CTL_LIMIT_1X;
- if (params->flags & PLANE_HAS_FENCE) {
- dpfc_ctl |= DPFC_CTL_FENCE_EN | params->vma->fence->id;
+ if (params->fence_id >= 0) {
+ dpfc_ctl |= DPFC_CTL_FENCE_EN | params->fence_id;
I915_WRITE(DPFC_FENCE_YOFF, params->crtc.fence_y_offset);
} else {
I915_WRITE(DPFC_FENCE_YOFF, 0);
@@ -229,14 +229,14 @@ static void ilk_fbc_activate(struct drm_i915_private *dev_priv)
break;
}
- if (params->flags & PLANE_HAS_FENCE) {
+ if (params->fence_id >= 0) {
dpfc_ctl |= DPFC_CTL_FENCE_EN;
if (IS_GEN(dev_priv, 5))
- dpfc_ctl |= params->vma->fence->id;
+ dpfc_ctl |= params->fence_id;
if (IS_GEN(dev_priv, 6)) {
I915_WRITE(SNB_DPFC_CTL_SA,
SNB_CPU_FENCE_ENABLE |
- params->vma->fence->id);
+ params->fence_id);
I915_WRITE(DPFC_CPU_FENCE_OFFSET,
params->crtc.fence_y_offset);
}
@@ -309,11 +309,11 @@ static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
break;
}
- if (params->flags & PLANE_HAS_FENCE) {
+ if (params->fence_id >= 0) {
dpfc_ctl |= IVB_DPFC_CTL_FENCE_EN;
I915_WRITE(SNB_DPFC_CTL_SA,
SNB_CPU_FENCE_ENABLE |
- params->vma->fence->id);
+ params->fence_id);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, params->crtc.fence_y_offset);
} else {
I915_WRITE(SNB_DPFC_CTL_SA,0);
@@ -659,10 +659,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
cache->fb.format = fb->format;
cache->fb.stride = fb->pitches[0];
- cache->vma = plane_state->vma;
- cache->flags = plane_state->flags;
- if (WARN_ON(cache->flags & PLANE_HAS_FENCE && !cache->vma->fence))
- cache->flags &= ~PLANE_HAS_FENCE;
+ WARN_ON(plane_state->flags & PLANE_HAS_FENCE &&
+ !plane_state->vma->fence);
+
+ if (plane_state->flags & PLANE_HAS_FENCE &&
+ plane_state->vma->fence)
+ cache->fence_id = plane_state->vma->fence->id;
+ else
+ cache->fence_id = -1;
}
static bool intel_fbc_can_activate(struct intel_crtc *crtc)
@@ -707,7 +711,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
* For now this will effecively disable FBC with 90/270 degree
* rotation.
*/
- if (!(cache->flags & PLANE_HAS_FENCE)) {
+ if (cache->fence_id < 0) {
fbc->no_fbc_reason = "framebuffer not tiled or fenced";
return false;
}
@@ -804,8 +808,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
* zero. */
memset(params, 0, sizeof(*params));
- params->vma = cache->vma;
- params->flags = cache->flags;
+ params->fence_id = cache->fence_id;
params->crtc.pipe = crtc->pipe;
params->crtc.i9xx_plane = to_intel_plane(crtc->base.primary)->i9xx_plane;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82dafef9ae10..81556dc353b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -386,9 +386,6 @@ struct intel_fbc {
* these problems.
*/
struct intel_fbc_state_cache {
- struct i915_vma *vma;
- unsigned long flags;
-
struct {
unsigned int mode_flags;
u32 hsw_bdw_pixel_rate;
@@ -418,6 +415,7 @@ struct intel_fbc {
unsigned int stride;
} fb;
u16 gen9_wa_cfb_stride;
+ s8 fence_id;
} state_cache;
/*
@@ -428,9 +426,6 @@ struct intel_fbc {
* are supposed to read from it in order to program the registers.
*/
struct intel_fbc_reg_params {
- struct i915_vma *vma;
- unsigned long flags;
-
struct {
enum pipe pipe;
enum i9xx_plane_id i9xx_plane;
@@ -444,6 +439,7 @@ struct intel_fbc {
int cfb_size;
u16 gen9_wa_cfb_stride;
+ s8 fence_id;
bool plane_visible;
} params;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 08/14] drm/i915/fbc: Make fence_id optional for i965gm
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
i965gm no longer needs the fence for scanout so we should be
do what we do for ctg+ and only configure a fence for FBC
when we have one.
In theory this should do nothing atm on account of
intel_fbc_can_activate() requiring the fence, but since
we do this for g4x+ let's do it for i965gm as well. We
may want to relax the requirements at some point and allow
FBC without a fence.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 600565647f37..c25e9ecb8506 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -138,8 +138,10 @@ static void i8xx_fbc_activate(struct drm_i915_private *dev_priv)
u32 fbc_ctl2;
/* Set it up... */
- fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM | FBC_CTL_CPU_FENCE;
+ fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM;
fbc_ctl2 |= FBC_CTL_PLANE(params->crtc.i9xx_plane);
+ if (params->fence_id >= 0)
+ fbc_ctl2 |= FBC_CTL_CPU_FENCE;
I915_WRITE(FBC_CONTROL2, fbc_ctl2);
I915_WRITE(FBC_FENCE_OFF, params->crtc.fence_y_offset);
}
@@ -151,7 +153,8 @@ static void i8xx_fbc_activate(struct drm_i915_private *dev_priv)
if (IS_I945GM(dev_priv))
fbc_ctl |= FBC_CTL_C3_IDLE; /* 945 needs special SR handling */
fbc_ctl |= (cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
- fbc_ctl |= params->fence_id;
+ if (params->fence_id >= 0)
+ fbc_ctl |= params->fence_id;
I915_WRITE(FBC_CONTROL, fbc_ctl);
}
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH v2 08/14] drm/i915/fbc: Make fence_id optional for i965gm
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
i965gm no longer needs the fence for scanout so we should be
do what we do for ctg+ and only configure a fence for FBC
when we have one.
In theory this should do nothing atm on account of
intel_fbc_can_activate() requiring the fence, but since
we do this for g4x+ let's do it for i965gm as well. We
may want to relax the requirements at some point and allow
FBC without a fence.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 600565647f37..c25e9ecb8506 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -138,8 +138,10 @@ static void i8xx_fbc_activate(struct drm_i915_private *dev_priv)
u32 fbc_ctl2;
/* Set it up... */
- fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM | FBC_CTL_CPU_FENCE;
+ fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM;
fbc_ctl2 |= FBC_CTL_PLANE(params->crtc.i9xx_plane);
+ if (params->fence_id >= 0)
+ fbc_ctl2 |= FBC_CTL_CPU_FENCE;
I915_WRITE(FBC_CONTROL2, fbc_ctl2);
I915_WRITE(FBC_FENCE_OFF, params->crtc.fence_y_offset);
}
@@ -151,7 +153,8 @@ static void i8xx_fbc_activate(struct drm_i915_private *dev_priv)
if (IS_I945GM(dev_priv))
fbc_ctl |= FBC_CTL_C3_IDLE; /* 945 needs special SR handling */
fbc_ctl |= (cfb_pitch & 0xff) << FBC_CTL_STRIDE_SHIFT;
- fbc_ctl |= params->fence_id;
+ if (params->fence_id >= 0)
+ fbc_ctl |= params->fence_id;
I915_WRITE(FBC_CONTROL, fbc_ctl);
}
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 09/14] drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Replace the 'gen9 && !glk' with the slightly more obvious
'gen9_bc || bxt'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index c25e9ecb8506..9a57ebc16c74 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -281,7 +281,7 @@ static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
int threshold = dev_priv->fbc.threshold;
/* Display WA #0529: skl, kbl, bxt. */
- if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) {
+ if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) {
u32 val = I915_READ(CHICKEN_MISC_4);
val &= ~(FBC_STRIDE_OVERRIDE | FBC_STRIDE_MASK);
@@ -1089,7 +1089,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
goto out;
}
- if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv) &&
+ if ((IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) &&
fb->modifier != I915_FORMAT_MOD_X_TILED)
cache->gen9_wa_cfb_stride =
DIV_ROUND_UP(cache->plane.src_w, 32 * fbc->threshold) * 8;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 09/14] drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Replace the 'gen9 && !glk' with the slightly more obvious
'gen9_bc || bxt'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index c25e9ecb8506..9a57ebc16c74 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -281,7 +281,7 @@ static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
int threshold = dev_priv->fbc.threshold;
/* Display WA #0529: skl, kbl, bxt. */
- if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) {
+ if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) {
u32 val = I915_READ(CHICKEN_MISC_4);
val &= ~(FBC_STRIDE_OVERRIDE | FBC_STRIDE_MASK);
@@ -1089,7 +1089,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
goto out;
}
- if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv) &&
+ if ((IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) &&
fb->modifier != I915_FORMAT_MOD_X_TILED)
cache->gen9_wa_cfb_stride =
DIV_ROUND_UP(cache->plane.src_w, 32 * fbc->threshold) * 8;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 10/14] drm/i915/fbc: Nuke fbc.enabled
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
fbc.enabled == (fbc.crtc != NULL), so let's just nuke fbc.enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 23 +++++++++--------------
drivers/gpu/drm/i915/i915_drv.h | 1 -
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 9a57ebc16c74..ccc1b5cc42d8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -840,7 +840,7 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
- if (!fbc->enabled || fbc->crtc != crtc)
+ if (fbc->crtc != crtc)
goto unlock;
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
@@ -864,14 +864,13 @@ static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
struct intel_crtc *crtc = fbc->crtc;
WARN_ON(!mutex_is_locked(&fbc->lock));
- WARN_ON(!fbc->enabled);
+ WARN_ON(!fbc->crtc);
WARN_ON(fbc->active);
DRM_DEBUG_KMS("Disabling FBC on pipe %c\n", pipe_name(crtc->pipe));
__intel_fbc_cleanup_cfb(dev_priv);
- fbc->enabled = false;
fbc->crtc = NULL;
}
@@ -882,7 +881,7 @@ static void __intel_fbc_post_update(struct intel_crtc *crtc)
WARN_ON(!mutex_is_locked(&fbc->lock));
- if (!fbc->enabled || fbc->crtc != crtc)
+ if (fbc->crtc != crtc)
return;
fbc->flip_pending = false;
@@ -922,7 +921,7 @@ void intel_fbc_post_update(struct intel_crtc *crtc)
static unsigned int intel_fbc_get_frontbuffer_bit(struct intel_fbc *fbc)
{
- if (fbc->enabled)
+ if (fbc->crtc)
return to_intel_plane(fbc->crtc->base.primary)->frontbuffer_bit;
else
return fbc->possible_framebuffer_bits;
@@ -944,7 +943,7 @@ void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
fbc->busy_bits |= intel_fbc_get_frontbuffer_bit(fbc) & frontbuffer_bits;
- if (fbc->enabled && fbc->busy_bits)
+ if (fbc->crtc && fbc->busy_bits)
intel_fbc_deactivate(dev_priv, "frontbuffer write");
mutex_unlock(&fbc->lock);
@@ -965,7 +964,7 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
goto out;
- if (!fbc->busy_bits && fbc->enabled &&
+ if (!fbc->busy_bits && fbc->crtc &&
(frontbuffer_bits & intel_fbc_get_frontbuffer_bit(fbc))) {
if (fbc->active)
intel_fbc_recompress(dev_priv);
@@ -1061,8 +1060,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
- if (fbc->enabled) {
- WARN_ON(fbc->crtc == NULL);
+ if (fbc->crtc) {
if (fbc->crtc == crtc) {
WARN_ON(!crtc_state->enable_fbc);
WARN_ON(fbc->active);
@@ -1074,7 +1072,6 @@ void intel_fbc_enable(struct intel_crtc *crtc,
goto out;
WARN_ON(fbc->active);
- WARN_ON(fbc->crtc != NULL);
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
@@ -1099,7 +1096,6 @@ void intel_fbc_enable(struct intel_crtc *crtc,
DRM_DEBUG_KMS("Enabling FBC on pipe %c\n", pipe_name(crtc->pipe));
fbc->no_fbc_reason = "FBC enabled but not active yet\n";
- fbc->enabled = true;
fbc->crtc = crtc;
out:
mutex_unlock(&fbc->lock);
@@ -1139,7 +1135,7 @@ void intel_fbc_global_disable(struct drm_i915_private *dev_priv)
return;
mutex_lock(&fbc->lock);
- if (fbc->enabled) {
+ if (fbc->crtc) {
WARN_ON(fbc->crtc->active);
__intel_fbc_disable(dev_priv);
}
@@ -1155,7 +1151,7 @@ static void intel_fbc_underrun_work_fn(struct work_struct *work)
mutex_lock(&fbc->lock);
/* Maybe we were scheduled twice. */
- if (fbc->underrun_detected || !fbc->enabled)
+ if (fbc->underrun_detected || !fbc->crtc)
goto out;
DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
@@ -1278,7 +1274,6 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
INIT_WORK(&fbc->underrun_work, intel_fbc_underrun_work_fn);
mutex_init(&fbc->lock);
- fbc->enabled = false;
fbc->active = false;
if (!drm_mm_initialized(&dev_priv->mm.stolen))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81556dc353b5..6fbfcaf4fb65 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -373,7 +373,6 @@ struct intel_fbc {
bool false_color;
- bool enabled;
bool active;
bool flip_pending;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 10/14] drm/i915/fbc: Nuke fbc.enabled
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
fbc.enabled == (fbc.crtc != NULL), so let's just nuke fbc.enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 23 +++++++++--------------
drivers/gpu/drm/i915/i915_drv.h | 1 -
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 9a57ebc16c74..ccc1b5cc42d8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -840,7 +840,7 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
- if (!fbc->enabled || fbc->crtc != crtc)
+ if (fbc->crtc != crtc)
goto unlock;
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
@@ -864,14 +864,13 @@ static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
struct intel_crtc *crtc = fbc->crtc;
WARN_ON(!mutex_is_locked(&fbc->lock));
- WARN_ON(!fbc->enabled);
+ WARN_ON(!fbc->crtc);
WARN_ON(fbc->active);
DRM_DEBUG_KMS("Disabling FBC on pipe %c\n", pipe_name(crtc->pipe));
__intel_fbc_cleanup_cfb(dev_priv);
- fbc->enabled = false;
fbc->crtc = NULL;
}
@@ -882,7 +881,7 @@ static void __intel_fbc_post_update(struct intel_crtc *crtc)
WARN_ON(!mutex_is_locked(&fbc->lock));
- if (!fbc->enabled || fbc->crtc != crtc)
+ if (fbc->crtc != crtc)
return;
fbc->flip_pending = false;
@@ -922,7 +921,7 @@ void intel_fbc_post_update(struct intel_crtc *crtc)
static unsigned int intel_fbc_get_frontbuffer_bit(struct intel_fbc *fbc)
{
- if (fbc->enabled)
+ if (fbc->crtc)
return to_intel_plane(fbc->crtc->base.primary)->frontbuffer_bit;
else
return fbc->possible_framebuffer_bits;
@@ -944,7 +943,7 @@ void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
fbc->busy_bits |= intel_fbc_get_frontbuffer_bit(fbc) & frontbuffer_bits;
- if (fbc->enabled && fbc->busy_bits)
+ if (fbc->crtc && fbc->busy_bits)
intel_fbc_deactivate(dev_priv, "frontbuffer write");
mutex_unlock(&fbc->lock);
@@ -965,7 +964,7 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
if (origin == ORIGIN_GTT || origin == ORIGIN_FLIP)
goto out;
- if (!fbc->busy_bits && fbc->enabled &&
+ if (!fbc->busy_bits && fbc->crtc &&
(frontbuffer_bits & intel_fbc_get_frontbuffer_bit(fbc))) {
if (fbc->active)
intel_fbc_recompress(dev_priv);
@@ -1061,8 +1060,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
- if (fbc->enabled) {
- WARN_ON(fbc->crtc == NULL);
+ if (fbc->crtc) {
if (fbc->crtc == crtc) {
WARN_ON(!crtc_state->enable_fbc);
WARN_ON(fbc->active);
@@ -1074,7 +1072,6 @@ void intel_fbc_enable(struct intel_crtc *crtc,
goto out;
WARN_ON(fbc->active);
- WARN_ON(fbc->crtc != NULL);
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
@@ -1099,7 +1096,6 @@ void intel_fbc_enable(struct intel_crtc *crtc,
DRM_DEBUG_KMS("Enabling FBC on pipe %c\n", pipe_name(crtc->pipe));
fbc->no_fbc_reason = "FBC enabled but not active yet\n";
- fbc->enabled = true;
fbc->crtc = crtc;
out:
mutex_unlock(&fbc->lock);
@@ -1139,7 +1135,7 @@ void intel_fbc_global_disable(struct drm_i915_private *dev_priv)
return;
mutex_lock(&fbc->lock);
- if (fbc->enabled) {
+ if (fbc->crtc) {
WARN_ON(fbc->crtc->active);
__intel_fbc_disable(dev_priv);
}
@@ -1155,7 +1151,7 @@ static void intel_fbc_underrun_work_fn(struct work_struct *work)
mutex_lock(&fbc->lock);
/* Maybe we were scheduled twice. */
- if (fbc->underrun_detected || !fbc->enabled)
+ if (fbc->underrun_detected || !fbc->crtc)
goto out;
DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
@@ -1278,7 +1274,6 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
INIT_WORK(&fbc->underrun_work, intel_fbc_underrun_work_fn);
mutex_init(&fbc->lock);
- fbc->enabled = false;
fbc->active = false;
if (!drm_mm_initialized(&dev_priv->mm.stolen))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81556dc353b5..6fbfcaf4fb65 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -373,7 +373,6 @@ struct intel_fbc {
bool false_color;
- bool enabled;
bool active;
bool flip_pending;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 11/14] drm/i915/fbc: Start using flip nuke
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The hardware automagically nukes the cfb on flip. We can use
that whenever the plane/crtc configuration doesn't change too
much. Let's hook that up.
We'll need this for glk+ since we need to introduce an extra
vblank wait after FBC disable. As we're currently disabling
FBC around all plane updates we'd slow them down by an extra
frame. Not a great user experience when your fps is always
capped at vrefres/2. With flip nuke we don't need the extra
vblank wait.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 50 ++++++++++++++++++------
1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index ccc1b5cc42d8..220fbe5bd919 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -68,7 +68,7 @@ static unsigned int get_crtc_fence_y_offset(struct intel_fbc *fbc)
* write to the PLANE_SIZE register. For BDW-, the hardware looks at the value
* we wrote to PIPESRC.
*/
-static void intel_fbc_get_plane_source_size(struct intel_fbc_state_cache *cache,
+static void intel_fbc_get_plane_source_size(const struct intel_fbc_state_cache *cache,
int *width, int *height)
{
if (width)
@@ -78,7 +78,7 @@ static void intel_fbc_get_plane_source_size(struct intel_fbc_state_cache *cache,
}
static int intel_fbc_calculate_cfb_size(struct drm_i915_private *dev_priv,
- struct intel_fbc_state_cache *cache)
+ const struct intel_fbc_state_cache *cache)
{
int lines;
@@ -827,6 +827,38 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
params->plane_visible = cache->plane.visible;
}
+static bool intel_fbc_can_flip_nuke(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct intel_fbc *fbc = &dev_priv->fbc;
+ const struct intel_fbc_state_cache *cache = &fbc->state_cache;
+ const struct intel_fbc_reg_params *params = &fbc->params;
+
+ if (drm_atomic_crtc_needs_modeset(&crtc_state->uapi))
+ return false;
+
+ if (!params->plane_visible)
+ return false;
+
+ if (!intel_fbc_can_activate(crtc))
+ return false;
+
+ if (params->fb.format != cache->fb.format)
+ return false;
+
+ if (params->fb.stride != cache->fb.stride)
+ return false;
+
+ if (params->cfb_size != intel_fbc_calculate_cfb_size(dev_priv, cache))
+ return false;
+
+ if (params->gen9_wa_cfb_stride != cache->gen9_wa_cfb_stride)
+ return false;
+
+ return true;
+}
+
void intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state)
@@ -846,7 +878,8 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
- intel_fbc_deactivate(dev_priv, reason);
+ if (!intel_fbc_can_flip_nuke(crtc_state))
+ intel_fbc_deactivate(dev_priv, reason);
unlock:
mutex_unlock(&fbc->lock);
}
@@ -885,7 +918,6 @@ static void __intel_fbc_post_update(struct intel_crtc *crtc)
return;
fbc->flip_pending = false;
- WARN_ON(fbc->active);
if (!i915_modparams.enable_fbc) {
intel_fbc_deactivate(dev_priv, "disabled at runtime per module param");
@@ -899,10 +931,9 @@ static void __intel_fbc_post_update(struct intel_crtc *crtc)
if (!intel_fbc_can_activate(crtc))
return;
- if (!fbc->busy_bits) {
- intel_fbc_deactivate(dev_priv, "FBC enabled (active or scheduled)");
+ if (!fbc->busy_bits)
intel_fbc_hw_activate(dev_priv);
- } else
+ else
intel_fbc_deactivate(dev_priv, "frontbuffer write");
}
@@ -1061,10 +1092,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
if (fbc->crtc) {
- if (fbc->crtc == crtc) {
- WARN_ON(!crtc_state->enable_fbc);
- WARN_ON(fbc->active);
- }
+ WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
goto out;
}
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 11/14] drm/i915/fbc: Start using flip nuke
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The hardware automagically nukes the cfb on flip. We can use
that whenever the plane/crtc configuration doesn't change too
much. Let's hook that up.
We'll need this for glk+ since we need to introduce an extra
vblank wait after FBC disable. As we're currently disabling
FBC around all plane updates we'd slow them down by an extra
frame. Not a great user experience when your fps is always
capped at vrefres/2. With flip nuke we don't need the extra
vblank wait.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 50 ++++++++++++++++++------
1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index ccc1b5cc42d8..220fbe5bd919 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -68,7 +68,7 @@ static unsigned int get_crtc_fence_y_offset(struct intel_fbc *fbc)
* write to the PLANE_SIZE register. For BDW-, the hardware looks at the value
* we wrote to PIPESRC.
*/
-static void intel_fbc_get_plane_source_size(struct intel_fbc_state_cache *cache,
+static void intel_fbc_get_plane_source_size(const struct intel_fbc_state_cache *cache,
int *width, int *height)
{
if (width)
@@ -78,7 +78,7 @@ static void intel_fbc_get_plane_source_size(struct intel_fbc_state_cache *cache,
}
static int intel_fbc_calculate_cfb_size(struct drm_i915_private *dev_priv,
- struct intel_fbc_state_cache *cache)
+ const struct intel_fbc_state_cache *cache)
{
int lines;
@@ -827,6 +827,38 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
params->plane_visible = cache->plane.visible;
}
+static bool intel_fbc_can_flip_nuke(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct intel_fbc *fbc = &dev_priv->fbc;
+ const struct intel_fbc_state_cache *cache = &fbc->state_cache;
+ const struct intel_fbc_reg_params *params = &fbc->params;
+
+ if (drm_atomic_crtc_needs_modeset(&crtc_state->uapi))
+ return false;
+
+ if (!params->plane_visible)
+ return false;
+
+ if (!intel_fbc_can_activate(crtc))
+ return false;
+
+ if (params->fb.format != cache->fb.format)
+ return false;
+
+ if (params->fb.stride != cache->fb.stride)
+ return false;
+
+ if (params->cfb_size != intel_fbc_calculate_cfb_size(dev_priv, cache))
+ return false;
+
+ if (params->gen9_wa_cfb_stride != cache->gen9_wa_cfb_stride)
+ return false;
+
+ return true;
+}
+
void intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state)
@@ -846,7 +878,8 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
- intel_fbc_deactivate(dev_priv, reason);
+ if (!intel_fbc_can_flip_nuke(crtc_state))
+ intel_fbc_deactivate(dev_priv, reason);
unlock:
mutex_unlock(&fbc->lock);
}
@@ -885,7 +918,6 @@ static void __intel_fbc_post_update(struct intel_crtc *crtc)
return;
fbc->flip_pending = false;
- WARN_ON(fbc->active);
if (!i915_modparams.enable_fbc) {
intel_fbc_deactivate(dev_priv, "disabled at runtime per module param");
@@ -899,10 +931,9 @@ static void __intel_fbc_post_update(struct intel_crtc *crtc)
if (!intel_fbc_can_activate(crtc))
return;
- if (!fbc->busy_bits) {
- intel_fbc_deactivate(dev_priv, "FBC enabled (active or scheduled)");
+ if (!fbc->busy_bits)
intel_fbc_hw_activate(dev_priv);
- } else
+ else
intel_fbc_deactivate(dev_priv, "frontbuffer write");
}
@@ -1061,10 +1092,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
if (fbc->crtc) {
- if (fbc->crtc == crtc) {
- WARN_ON(!crtc_state->enable_fbc);
- WARN_ON(fbc->active);
- }
+ WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
goto out;
}
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 12/14] drm/i915/fbc: Wait for vblank after FBC disable on glk+
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
On glk+ the hardware gets confused if we disable FBC while
it's recompressing and we perform a plane update during the
same frame. The result is that top of the screen gets corrupted.
We can avoid that by giving the hardware enough time to finish
the FBC disable before we touch the plane registers. Ie. we need
an extra vblank wait after FBC disable.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++-
drivers/gpu/drm/i915/display/intel_fbc.c | 26 +++++++++++++++++---
drivers/gpu/drm/i915/display/intel_fbc.h | 2 +-
3 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index d592b7284406..3210a0f00009 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6105,7 +6105,9 @@ static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
intel_atomic_get_new_plane_state(intel_state,
to_intel_plane(primary));
- intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
+ if (intel_fbc_pre_update(crtc, pipe_config, new_primary_state))
+ intel_wait_for_vblank(dev_priv, crtc->pipe);
+
/*
* Gen2 reports pipe underruns whenever all planes are disabled.
* So disable underrun reporting before all the planes get disabled.
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 220fbe5bd919..78fe4abb5a93 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -859,16 +859,17 @@ static bool intel_fbc_can_flip_nuke(const struct intel_crtc_state *crtc_state)
return true;
}
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = &dev_priv->fbc;
const char *reason = "update pending";
+ bool need_vblank_wait = false;
if (!fbc_supported(dev_priv))
- return;
+ return need_vblank_wait;
mutex_lock(&fbc->lock);
@@ -878,10 +879,29 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
- if (!intel_fbc_can_flip_nuke(crtc_state))
+ if (!intel_fbc_can_flip_nuke(crtc_state)) {
intel_fbc_deactivate(dev_priv, reason);
+
+ /*
+ * Display WA #1198: glk+
+ * Need an extra vblank wait between FBC disable and most plane
+ * updates. Bspec says this is only needed for plane disable, but
+ * that is not true. Touching most plane registers will cause the
+ * corruption to appear. Also SKL/derivatives do not seem to be
+ * affected.
+ *
+ * TODO: could optimize this a bit by sampling the frame
+ * counter when we disable FBC (if it was already done earlier)
+ * and skipping the extra vblank wait before the plane update
+ * if at least one frame has already passed.
+ */
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ need_vblank_wait = true;
+ }
unlock:
mutex_unlock(&fbc->lock);
+
+ return need_vblank_wait;
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h b/drivers/gpu/drm/i915/display/intel_fbc.h
index ba8eeefd4d9a..9a2f1094cbda 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -19,7 +19,7 @@ struct intel_plane_state;
void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv,
struct intel_atomic_state *state);
bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
void intel_fbc_post_update(struct intel_crtc *crtc);
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 12/14] drm/i915/fbc: Wait for vblank after FBC disable on glk+
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
On glk+ the hardware gets confused if we disable FBC while
it's recompressing and we perform a plane update during the
same frame. The result is that top of the screen gets corrupted.
We can avoid that by giving the hardware enough time to finish
the FBC disable before we touch the plane registers. Ie. we need
an extra vblank wait after FBC disable.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++-
drivers/gpu/drm/i915/display/intel_fbc.c | 26 +++++++++++++++++---
drivers/gpu/drm/i915/display/intel_fbc.h | 2 +-
3 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index d592b7284406..3210a0f00009 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6105,7 +6105,9 @@ static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
intel_atomic_get_new_plane_state(intel_state,
to_intel_plane(primary));
- intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
+ if (intel_fbc_pre_update(crtc, pipe_config, new_primary_state))
+ intel_wait_for_vblank(dev_priv, crtc->pipe);
+
/*
* Gen2 reports pipe underruns whenever all planes are disabled.
* So disable underrun reporting before all the planes get disabled.
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 220fbe5bd919..78fe4abb5a93 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -859,16 +859,17 @@ static bool intel_fbc_can_flip_nuke(const struct intel_crtc_state *crtc_state)
return true;
}
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = &dev_priv->fbc;
const char *reason = "update pending";
+ bool need_vblank_wait = false;
if (!fbc_supported(dev_priv))
- return;
+ return need_vblank_wait;
mutex_lock(&fbc->lock);
@@ -878,10 +879,29 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
- if (!intel_fbc_can_flip_nuke(crtc_state))
+ if (!intel_fbc_can_flip_nuke(crtc_state)) {
intel_fbc_deactivate(dev_priv, reason);
+
+ /*
+ * Display WA #1198: glk+
+ * Need an extra vblank wait between FBC disable and most plane
+ * updates. Bspec says this is only needed for plane disable, but
+ * that is not true. Touching most plane registers will cause the
+ * corruption to appear. Also SKL/derivatives do not seem to be
+ * affected.
+ *
+ * TODO: could optimize this a bit by sampling the frame
+ * counter when we disable FBC (if it was already done earlier)
+ * and skipping the extra vblank wait before the plane update
+ * if at least one frame has already passed.
+ */
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ need_vblank_wait = true;
+ }
unlock:
mutex_unlock(&fbc->lock);
+
+ return need_vblank_wait;
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h b/drivers/gpu/drm/i915/display/intel_fbc.h
index ba8eeefd4d9a..9a2f1094cbda 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -19,7 +19,7 @@ struct intel_plane_state;
void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv,
struct intel_atomic_state *state);
bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
void intel_fbc_post_update(struct intel_crtc *crtc);
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v3 12/14] drm/i915/fbc: Wait for vblank after FBC disable on glk+
@ 2019-11-28 15:03 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-28 15:03 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
On glk+ the hardware gets confused if we disable FBC while
it's recompressing and we perform a plane update during the
same frame. The result is that top of the screen gets corrupted.
We can avoid that by giving the hardware enough time to finish
the FBC disable before we touch the plane registers. Ie. we need
an extra vblank wait after FBC disable.
v2: Don't do the vblank wait if we never activated FBC in hw
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++-
drivers/gpu/drm/i915/display/intel_fbc.c | 29 ++++++++++++++++++--
drivers/gpu/drm/i915/display/intel_fbc.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
4 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index d592b7284406..3210a0f00009 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6105,7 +6105,9 @@ static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
intel_atomic_get_new_plane_state(intel_state,
to_intel_plane(primary));
- intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
+ if (intel_fbc_pre_update(crtc, pipe_config, new_primary_state))
+ intel_wait_for_vblank(dev_priv, crtc->pipe);
+
/*
* Gen2 reports pipe underruns whenever all planes are disabled.
* So disable underrun reporting before all the planes get disabled.
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 220fbe5bd919..dccdf4c01f5a 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -362,6 +362,7 @@ static void intel_fbc_hw_activate(struct drm_i915_private *dev_priv)
struct intel_fbc *fbc = &dev_priv->fbc;
fbc->active = true;
+ fbc->activated = true;
if (INTEL_GEN(dev_priv) >= 7)
gen7_fbc_activate(dev_priv);
@@ -859,16 +860,17 @@ static bool intel_fbc_can_flip_nuke(const struct intel_crtc_state *crtc_state)
return true;
}
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = &dev_priv->fbc;
const char *reason = "update pending";
+ bool need_vblank_wait = false;
if (!fbc_supported(dev_priv))
- return;
+ return need_vblank_wait;
mutex_lock(&fbc->lock);
@@ -878,10 +880,31 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
- if (!intel_fbc_can_flip_nuke(crtc_state))
+ if (!intel_fbc_can_flip_nuke(crtc_state)) {
intel_fbc_deactivate(dev_priv, reason);
+
+ /*
+ * Display WA #1198: glk+
+ * Need an extra vblank wait between FBC disable and most plane
+ * updates. Bspec says this is only needed for plane disable, but
+ * that is not true. Touching most plane registers will cause the
+ * corruption to appear. Also SKL/derivatives do not seem to be
+ * affected.
+ *
+ * TODO: could optimize this a bit by sampling the frame
+ * counter when we disable FBC (if it was already done earlier)
+ * and skipping the extra vblank wait before the plane update
+ * if at least one frame has already passed.
+ */
+ if (fbc->activated &&
+ (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)))
+ need_vblank_wait = true;
+ fbc->activated = false;
+ }
unlock:
mutex_unlock(&fbc->lock);
+
+ return need_vblank_wait;
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h b/drivers/gpu/drm/i915/display/intel_fbc.h
index ba8eeefd4d9a..9a2f1094cbda 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -19,7 +19,7 @@ struct intel_plane_state;
void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv,
struct intel_atomic_state *state);
bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
void intel_fbc_post_update(struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6fbfcaf4fb65..0d72609a3f6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -374,6 +374,7 @@ struct intel_fbc {
bool false_color;
bool active;
+ bool activated;
bool flip_pending;
bool underrun_detected;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v3 12/14] drm/i915/fbc: Wait for vblank after FBC disable on glk+
@ 2019-11-28 15:03 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-28 15:03 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
On glk+ the hardware gets confused if we disable FBC while
it's recompressing and we perform a plane update during the
same frame. The result is that top of the screen gets corrupted.
We can avoid that by giving the hardware enough time to finish
the FBC disable before we touch the plane registers. Ie. we need
an extra vblank wait after FBC disable.
v2: Don't do the vblank wait if we never activated FBC in hw
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++-
drivers/gpu/drm/i915/display/intel_fbc.c | 29 ++++++++++++++++++--
drivers/gpu/drm/i915/display/intel_fbc.h | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
4 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index d592b7284406..3210a0f00009 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6105,7 +6105,9 @@ static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
intel_atomic_get_new_plane_state(intel_state,
to_intel_plane(primary));
- intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
+ if (intel_fbc_pre_update(crtc, pipe_config, new_primary_state))
+ intel_wait_for_vblank(dev_priv, crtc->pipe);
+
/*
* Gen2 reports pipe underruns whenever all planes are disabled.
* So disable underrun reporting before all the planes get disabled.
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 220fbe5bd919..dccdf4c01f5a 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -362,6 +362,7 @@ static void intel_fbc_hw_activate(struct drm_i915_private *dev_priv)
struct intel_fbc *fbc = &dev_priv->fbc;
fbc->active = true;
+ fbc->activated = true;
if (INTEL_GEN(dev_priv) >= 7)
gen7_fbc_activate(dev_priv);
@@ -859,16 +860,17 @@ static bool intel_fbc_can_flip_nuke(const struct intel_crtc_state *crtc_state)
return true;
}
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_fbc *fbc = &dev_priv->fbc;
const char *reason = "update pending";
+ bool need_vblank_wait = false;
if (!fbc_supported(dev_priv))
- return;
+ return need_vblank_wait;
mutex_lock(&fbc->lock);
@@ -878,10 +880,31 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
- if (!intel_fbc_can_flip_nuke(crtc_state))
+ if (!intel_fbc_can_flip_nuke(crtc_state)) {
intel_fbc_deactivate(dev_priv, reason);
+
+ /*
+ * Display WA #1198: glk+
+ * Need an extra vblank wait between FBC disable and most plane
+ * updates. Bspec says this is only needed for plane disable, but
+ * that is not true. Touching most plane registers will cause the
+ * corruption to appear. Also SKL/derivatives do not seem to be
+ * affected.
+ *
+ * TODO: could optimize this a bit by sampling the frame
+ * counter when we disable FBC (if it was already done earlier)
+ * and skipping the extra vblank wait before the plane update
+ * if at least one frame has already passed.
+ */
+ if (fbc->activated &&
+ (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)))
+ need_vblank_wait = true;
+ fbc->activated = false;
+ }
unlock:
mutex_unlock(&fbc->lock);
+
+ return need_vblank_wait;
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h b/drivers/gpu/drm/i915/display/intel_fbc.h
index ba8eeefd4d9a..9a2f1094cbda 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -19,7 +19,7 @@ struct intel_plane_state;
void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv,
struct intel_atomic_state *state);
bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
-void intel_fbc_pre_update(struct intel_crtc *crtc,
+bool intel_fbc_pre_update(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
void intel_fbc_post_update(struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6fbfcaf4fb65..0d72609a3f6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -374,6 +374,7 @@ struct intel_fbc {
bool false_color;
bool active;
+ bool activated;
bool flip_pending;
bool underrun_detected;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 13/14] drm/i915/fbc: Enable fbc by default on glk+ once again
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Jian-Hong Pan, Paulo Zanoni, Daniel Drake
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Now that we have the glk+ w/a for back to back fbc disable + plane
update in place we can once more enable fbc on glk+ by default.
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 78fe4abb5a93..c976698b0729 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1288,10 +1288,6 @@ static int intel_sanitize_fbc_option(struct drm_i915_private *dev_priv)
if (!HAS_FBC(dev_priv))
return 0;
- /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
- return 0;
-
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
return 1;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [Intel-gfx] [PATCH v2 13/14] drm/i915/fbc: Enable fbc by default on glk+ once again
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Jian-Hong Pan, Paulo Zanoni, Daniel Drake
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Now that we have the glk+ w/a for back to back fbc disable + plane
update in place we can once more enable fbc on glk+ by default.
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index 78fe4abb5a93..c976698b0729 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1288,10 +1288,6 @@ static int intel_sanitize_fbc_option(struct drm_i915_private *dev_priv)
if (!HAS_FBC(dev_priv))
return 0;
- /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
- return 0;
-
if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
return 1;
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Jian-Hong Pan, Paulo Zanoni, Daniel Drake
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The code assumes we can omit the cfb allocation once fbc
has been enabled once. That's nonsense. Let's try to
reallocate it if we need to.
The code is still a mess, but maybe this is enough to get
fbc going in some cases where it initially underallocates
the cfb and there's no full modeset to fix it up.
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index c976698b0729..928059a5da80 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
cache->fence_id = -1;
}
+static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
+{
+ struct intel_fbc *fbc = &dev_priv->fbc;
+
+ return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
+ fbc->compressed_fb.size * fbc->threshold;
+}
+
static bool intel_fbc_can_activate(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
* we didn't get any invalidate/deactivate calls, but this would require
* a lot of tracking just for a specific case. If we conclude it's an
* important case, we can implement it later. */
- if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
- fbc->compressed_fb.size * fbc->threshold) {
+ if (intel_fbc_cfb_size_changed(dev_priv)) {
fbc->no_fbc_reason = "CFB requirements changed";
return false;
}
@@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
if (fbc->crtc) {
- WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
- goto out;
- }
+ if (fbc->crtc != crtc ||
+ !intel_fbc_cfb_size_changed(dev_priv))
+ goto out;
- if (!crtc_state->enable_fbc)
- goto out;
+ __intel_fbc_disable(dev_priv);
+ }
WARN_ON(fbc->active);
@@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
if (intel_fbc_alloc_cfb(dev_priv,
intel_fbc_calculate_cfb_size(dev_priv, cache),
fb->format->cpp[0])) {
+ cache->plane.visible = false;
fbc->no_fbc_reason = "not enough stolen memory";
goto out;
}
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* [Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-27 20:12 ` Ville Syrjala
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjala @ 2019-11-27 20:12 UTC (permalink / raw)
To: intel-gfx; +Cc: Jian-Hong Pan, Paulo Zanoni, Daniel Drake
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The code assumes we can omit the cfb allocation once fbc
has been enabled once. That's nonsense. Let's try to
reallocate it if we need to.
The code is still a mess, but maybe this is enough to get
fbc going in some cases where it initially underallocates
the cfb and there's no full modeset to fix it up.
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
index c976698b0729..928059a5da80 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
cache->fence_id = -1;
}
+static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
+{
+ struct intel_fbc *fbc = &dev_priv->fbc;
+
+ return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
+ fbc->compressed_fb.size * fbc->threshold;
+}
+
static bool intel_fbc_can_activate(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
* we didn't get any invalidate/deactivate calls, but this would require
* a lot of tracking just for a specific case. If we conclude it's an
* important case, we can implement it later. */
- if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
- fbc->compressed_fb.size * fbc->threshold) {
+ if (intel_fbc_cfb_size_changed(dev_priv)) {
fbc->no_fbc_reason = "CFB requirements changed";
return false;
}
@@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
mutex_lock(&fbc->lock);
if (fbc->crtc) {
- WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
- goto out;
- }
+ if (fbc->crtc != crtc ||
+ !intel_fbc_cfb_size_changed(dev_priv))
+ goto out;
- if (!crtc_state->enable_fbc)
- goto out;
+ __intel_fbc_disable(dev_priv);
+ }
WARN_ON(fbc->active);
@@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
if (intel_fbc_alloc_cfb(dev_priv,
intel_fbc_calculate_cfb_size(dev_priv, cache),
fb->format->cpp[0])) {
+ cache->plane.visible = false;
fbc->no_fbc_reason = "not enough stolen memory";
goto out;
}
--
2.23.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-28 15:48 ` Maarten Lankhorst
0 siblings, 0 replies; 54+ messages in thread
From: Maarten Lankhorst @ 2019-11-28 15:48 UTC (permalink / raw)
To: Ville Syrjala, intel-gfx; +Cc: Jian-Hong Pan, Paulo Zanoni, Daniel Drake
Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The code assumes we can omit the cfb allocation once fbc
> has been enabled once. That's nonsense. Let's try to
> reallocate it if we need to.
>
> The code is still a mess, but maybe this is enough to get
> fbc going in some cases where it initially underallocates
> the cfb and there's no full modeset to fix it up.
>
> Cc: Daniel Drake <drake@endlessm.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> index c976698b0729..928059a5da80 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> cache->fence_id = -1;
> }
>
> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
> +{
> + struct intel_fbc *fbc = &dev_priv->fbc;
> +
> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> + fbc->compressed_fb.size * fbc->threshold;
> +}
> +
> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> * we didn't get any invalidate/deactivate calls, but this would require
> * a lot of tracking just for a specific case. If we conclude it's an
> * important case, we can implement it later. */
> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> - fbc->compressed_fb.size * fbc->threshold) {
> + if (intel_fbc_cfb_size_changed(dev_priv)) {
> fbc->no_fbc_reason = "CFB requirements changed";
> return false;
> }
> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> mutex_lock(&fbc->lock);
>
> if (fbc->crtc) {
> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
> - goto out;
> - }
> + if (fbc->crtc != crtc ||
> + !intel_fbc_cfb_size_changed(dev_priv))
> + goto out;
>
> - if (!crtc_state->enable_fbc)
> - goto out;
> + __intel_fbc_disable(dev_priv);
> + }
>
> WARN_ON(fbc->active);
>
> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> if (intel_fbc_alloc_cfb(dev_priv,
> intel_fbc_calculate_cfb_size(dev_priv, cache),
> fb->format->cpp[0])) {
> + cache->plane.visible = false;
> fbc->no_fbc_reason = "not enough stolen memory";
> goto out;
> }
Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
For 1-11, 14
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
12 and 13 need more thought for now, kms_cursor_legacy is failing.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-28 15:48 ` Maarten Lankhorst
0 siblings, 0 replies; 54+ messages in thread
From: Maarten Lankhorst @ 2019-11-28 15:48 UTC (permalink / raw)
To: Ville Syrjala, intel-gfx; +Cc: Jian-Hong Pan, Paulo Zanoni, Daniel Drake
Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The code assumes we can omit the cfb allocation once fbc
> has been enabled once. That's nonsense. Let's try to
> reallocate it if we need to.
>
> The code is still a mess, but maybe this is enough to get
> fbc going in some cases where it initially underallocates
> the cfb and there's no full modeset to fix it up.
>
> Cc: Daniel Drake <drake@endlessm.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> index c976698b0729..928059a5da80 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> cache->fence_id = -1;
> }
>
> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
> +{
> + struct intel_fbc *fbc = &dev_priv->fbc;
> +
> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> + fbc->compressed_fb.size * fbc->threshold;
> +}
> +
> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> * we didn't get any invalidate/deactivate calls, but this would require
> * a lot of tracking just for a specific case. If we conclude it's an
> * important case, we can implement it later. */
> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> - fbc->compressed_fb.size * fbc->threshold) {
> + if (intel_fbc_cfb_size_changed(dev_priv)) {
> fbc->no_fbc_reason = "CFB requirements changed";
> return false;
> }
> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> mutex_lock(&fbc->lock);
>
> if (fbc->crtc) {
> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
> - goto out;
> - }
> + if (fbc->crtc != crtc ||
> + !intel_fbc_cfb_size_changed(dev_priv))
> + goto out;
>
> - if (!crtc_state->enable_fbc)
> - goto out;
> + __intel_fbc_disable(dev_priv);
> + }
>
> WARN_ON(fbc->active);
>
> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> if (intel_fbc_alloc_cfb(dev_priv,
> intel_fbc_calculate_cfb_size(dev_priv, cache),
> fb->format->cpp[0])) {
> + cache->plane.visible = false;
> fbc->no_fbc_reason = "not enough stolen memory";
> goto out;
> }
Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
For 1-11, 14
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
12 and 13 need more thought for now, kms_cursor_legacy is failing.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-28 15:59 ` Ville Syrjälä
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjälä @ 2019-11-28 15:59 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The code assumes we can omit the cfb allocation once fbc
> > has been enabled once. That's nonsense. Let's try to
> > reallocate it if we need to.
> >
> > The code is still a mess, but maybe this is enough to get
> > fbc going in some cases where it initially underallocates
> > the cfb and there's no full modeset to fix it up.
> >
> > Cc: Daniel Drake <drake@endlessm.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Jian-Hong Pan <jian-hong@endlessm.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
> > 1 file changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index c976698b0729..928059a5da80 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> > cache->fence_id = -1;
> > }
> >
> > +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
> > +{
> > + struct intel_fbc *fbc = &dev_priv->fbc;
> > +
> > + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> > + fbc->compressed_fb.size * fbc->threshold;
> > +}
> > +
> > static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> > {
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> > * we didn't get any invalidate/deactivate calls, but this would require
> > * a lot of tracking just for a specific case. If we conclude it's an
> > * important case, we can implement it later. */
> > - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> > - fbc->compressed_fb.size * fbc->threshold) {
> > + if (intel_fbc_cfb_size_changed(dev_priv)) {
> > fbc->no_fbc_reason = "CFB requirements changed";
> > return false;
> > }
> > @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> > mutex_lock(&fbc->lock);
> >
> > if (fbc->crtc) {
> > - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
> > - goto out;
> > - }
> > + if (fbc->crtc != crtc ||
> > + !intel_fbc_cfb_size_changed(dev_priv))
> > + goto out;
> >
> > - if (!crtc_state->enable_fbc)
> > - goto out;
> > + __intel_fbc_disable(dev_priv);
> > + }
> >
> > WARN_ON(fbc->active);
> >
> > @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> > if (intel_fbc_alloc_cfb(dev_priv,
> > intel_fbc_calculate_cfb_size(dev_priv, cache),
> > fb->format->cpp[0])) {
> > + cache->plane.visible = false;
> > fbc->no_fbc_reason = "not enough stolen memory";
> > goto out;
> > }
>
> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
>
> For 1-11, 14
>
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>
> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
How would we get rid of the disable there? By triggering nukes at some
predefined interval? Doesn't sound all that great.
>
> 12 and 13 need more thought for now, kms_cursor_legacy is failing.
Already posted the v2 that fixes it.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-28 15:59 ` Ville Syrjälä
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjälä @ 2019-11-28 15:59 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The code assumes we can omit the cfb allocation once fbc
> > has been enabled once. That's nonsense. Let's try to
> > reallocate it if we need to.
> >
> > The code is still a mess, but maybe this is enough to get
> > fbc going in some cases where it initially underallocates
> > the cfb and there's no full modeset to fix it up.
> >
> > Cc: Daniel Drake <drake@endlessm.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Jian-Hong Pan <jian-hong@endlessm.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
> > 1 file changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index c976698b0729..928059a5da80 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> > cache->fence_id = -1;
> > }
> >
> > +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
> > +{
> > + struct intel_fbc *fbc = &dev_priv->fbc;
> > +
> > + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> > + fbc->compressed_fb.size * fbc->threshold;
> > +}
> > +
> > static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> > {
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> > * we didn't get any invalidate/deactivate calls, but this would require
> > * a lot of tracking just for a specific case. If we conclude it's an
> > * important case, we can implement it later. */
> > - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> > - fbc->compressed_fb.size * fbc->threshold) {
> > + if (intel_fbc_cfb_size_changed(dev_priv)) {
> > fbc->no_fbc_reason = "CFB requirements changed";
> > return false;
> > }
> > @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> > mutex_lock(&fbc->lock);
> >
> > if (fbc->crtc) {
> > - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
> > - goto out;
> > - }
> > + if (fbc->crtc != crtc ||
> > + !intel_fbc_cfb_size_changed(dev_priv))
> > + goto out;
> >
> > - if (!crtc_state->enable_fbc)
> > - goto out;
> > + __intel_fbc_disable(dev_priv);
> > + }
> >
> > WARN_ON(fbc->active);
> >
> > @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> > if (intel_fbc_alloc_cfb(dev_priv,
> > intel_fbc_calculate_cfb_size(dev_priv, cache),
> > fb->format->cpp[0])) {
> > + cache->plane.visible = false;
> > fbc->no_fbc_reason = "not enough stolen memory";
> > goto out;
> > }
>
> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
>
> For 1-11, 14
>
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>
> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
How would we get rid of the disable there? By triggering nukes at some
predefined interval? Doesn't sound all that great.
>
> 12 and 13 need more thought for now, kms_cursor_legacy is failing.
Already posted the v2 that fixes it.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-29 8:48 ` Maarten Lankhorst
0 siblings, 0 replies; 54+ messages in thread
From: Maarten Lankhorst @ 2019-11-29 8:48 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
> On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
>> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> The code assumes we can omit the cfb allocation once fbc
>>> has been enabled once. That's nonsense. Let's try to
>>> reallocate it if we need to.
>>>
>>> The code is still a mess, but maybe this is enough to get
>>> fbc going in some cases where it initially underallocates
>>> the cfb and there's no full modeset to fix it up.
>>>
>>> Cc: Daniel Drake <drake@endlessm.com>
>>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
>>> 1 file changed, 15 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
>>> index c976698b0729..928059a5da80 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
>>> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
>>> cache->fence_id = -1;
>>> }
>>>
>>> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
>>> +{
>>> + struct intel_fbc *fbc = &dev_priv->fbc;
>>> +
>>> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
>>> + fbc->compressed_fb.size * fbc->threshold;
>>> +}
>>> +
>>> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>>> {
>>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>>> * we didn't get any invalidate/deactivate calls, but this would require
>>> * a lot of tracking just for a specific case. If we conclude it's an
>>> * important case, we can implement it later. */
>>> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
>>> - fbc->compressed_fb.size * fbc->threshold) {
>>> + if (intel_fbc_cfb_size_changed(dev_priv)) {
>>> fbc->no_fbc_reason = "CFB requirements changed";
>>> return false;
>>> }
>>> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>>> mutex_lock(&fbc->lock);
>>>
>>> if (fbc->crtc) {
>>> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
>>> - goto out;
>>> - }
>>> + if (fbc->crtc != crtc ||
>>> + !intel_fbc_cfb_size_changed(dev_priv))
>>> + goto out;
>>>
>>> - if (!crtc_state->enable_fbc)
>>> - goto out;
>>> + __intel_fbc_disable(dev_priv);
>>> + }
>>>
>>> WARN_ON(fbc->active);
>>>
>>> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>>> if (intel_fbc_alloc_cfb(dev_priv,
>>> intel_fbc_calculate_cfb_size(dev_priv, cache),
>>> fb->format->cpp[0])) {
>>> + cache->plane.visible = false;
>>> fbc->no_fbc_reason = "not enough stolen memory";
>>> goto out;
>>> }
>> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
>>
>> For 1-11, 14
>>
>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>
>> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
> How would we get rid of the disable there? By triggering nukes at some
> predefined interval? Doesn't sound all that great.
Not touching FBC on frontbuffer write at all, and forcing userspace to use the dirtyfb api. I think the whole implicit tracking should be removed.
>
>> 12 and 13 need more thought for now, kms_cursor_legacy is failing.
> Already posted the v2 that fixes it.
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-29 8:48 ` Maarten Lankhorst
0 siblings, 0 replies; 54+ messages in thread
From: Maarten Lankhorst @ 2019-11-29 8:48 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
> On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
>> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> The code assumes we can omit the cfb allocation once fbc
>>> has been enabled once. That's nonsense. Let's try to
>>> reallocate it if we need to.
>>>
>>> The code is still a mess, but maybe this is enough to get
>>> fbc going in some cases where it initially underallocates
>>> the cfb and there's no full modeset to fix it up.
>>>
>>> Cc: Daniel Drake <drake@endlessm.com>
>>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
>>> 1 file changed, 15 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
>>> index c976698b0729..928059a5da80 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
>>> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
>>> cache->fence_id = -1;
>>> }
>>>
>>> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
>>> +{
>>> + struct intel_fbc *fbc = &dev_priv->fbc;
>>> +
>>> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
>>> + fbc->compressed_fb.size * fbc->threshold;
>>> +}
>>> +
>>> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>>> {
>>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>>> * we didn't get any invalidate/deactivate calls, but this would require
>>> * a lot of tracking just for a specific case. If we conclude it's an
>>> * important case, we can implement it later. */
>>> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
>>> - fbc->compressed_fb.size * fbc->threshold) {
>>> + if (intel_fbc_cfb_size_changed(dev_priv)) {
>>> fbc->no_fbc_reason = "CFB requirements changed";
>>> return false;
>>> }
>>> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>>> mutex_lock(&fbc->lock);
>>>
>>> if (fbc->crtc) {
>>> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
>>> - goto out;
>>> - }
>>> + if (fbc->crtc != crtc ||
>>> + !intel_fbc_cfb_size_changed(dev_priv))
>>> + goto out;
>>>
>>> - if (!crtc_state->enable_fbc)
>>> - goto out;
>>> + __intel_fbc_disable(dev_priv);
>>> + }
>>>
>>> WARN_ON(fbc->active);
>>>
>>> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>>> if (intel_fbc_alloc_cfb(dev_priv,
>>> intel_fbc_calculate_cfb_size(dev_priv, cache),
>>> fb->format->cpp[0])) {
>>> + cache->plane.visible = false;
>>> fbc->no_fbc_reason = "not enough stolen memory";
>>> goto out;
>>> }
>> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
>>
>> For 1-11, 14
>>
>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>
>> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
> How would we get rid of the disable there? By triggering nukes at some
> predefined interval? Doesn't sound all that great.
Not touching FBC on frontbuffer write at all, and forcing userspace to use the dirtyfb api. I think the whole implicit tracking should be removed.
>
>> 12 and 13 need more thought for now, kms_cursor_legacy is failing.
> Already posted the v2 that fixes it.
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-29 11:37 ` Ville Syrjälä
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjälä @ 2019-11-29 11:37 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
On Fri, Nov 29, 2019 at 09:48:45AM +0100, Maarten Lankhorst wrote:
> Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
> > On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
> >> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> The code assumes we can omit the cfb allocation once fbc
> >>> has been enabled once. That's nonsense. Let's try to
> >>> reallocate it if we need to.
> >>>
> >>> The code is still a mess, but maybe this is enough to get
> >>> fbc going in some cases where it initially underallocates
> >>> the cfb and there's no full modeset to fix it up.
> >>>
> >>> Cc: Daniel Drake <drake@endlessm.com>
> >>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >>> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
> >>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
> >>> 1 file changed, 15 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> >>> index c976698b0729..928059a5da80 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> >>> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> >>> cache->fence_id = -1;
> >>> }
> >>>
> >>> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
> >>> +{
> >>> + struct intel_fbc *fbc = &dev_priv->fbc;
> >>> +
> >>> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> >>> + fbc->compressed_fb.size * fbc->threshold;
> >>> +}
> >>> +
> >>> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> >>> {
> >>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >>> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> >>> * we didn't get any invalidate/deactivate calls, but this would require
> >>> * a lot of tracking just for a specific case. If we conclude it's an
> >>> * important case, we can implement it later. */
> >>> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> >>> - fbc->compressed_fb.size * fbc->threshold) {
> >>> + if (intel_fbc_cfb_size_changed(dev_priv)) {
> >>> fbc->no_fbc_reason = "CFB requirements changed";
> >>> return false;
> >>> }
> >>> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> >>> mutex_lock(&fbc->lock);
> >>>
> >>> if (fbc->crtc) {
> >>> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
> >>> - goto out;
> >>> - }
> >>> + if (fbc->crtc != crtc ||
> >>> + !intel_fbc_cfb_size_changed(dev_priv))
> >>> + goto out;
> >>>
> >>> - if (!crtc_state->enable_fbc)
> >>> - goto out;
> >>> + __intel_fbc_disable(dev_priv);
> >>> + }
> >>>
> >>> WARN_ON(fbc->active);
> >>>
> >>> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> >>> if (intel_fbc_alloc_cfb(dev_priv,
> >>> intel_fbc_calculate_cfb_size(dev_priv, cache),
> >>> fb->format->cpp[0])) {
> >>> + cache->plane.visible = false;
> >>> fbc->no_fbc_reason = "not enough stolen memory";
> >>> goto out;
> >>> }
> >> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
> >>
> >> For 1-11, 14
> >>
> >> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>
> >> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
> > How would we get rid of the disable there? By triggering nukes at some
> > predefined interval? Doesn't sound all that great.
> Not touching FBC on frontbuffer write at all, and forcing userspace to use the dirtyfb api. I think the whole implicit tracking should be removed.
Perhaps. Not sure userspace is ready for that though.
I guess the only long lasting frontbuffer invalidate is the
one from set_domain. Everything else is bounded and so we
know the flush is going to come in a somewhat timely manner.
So for those cases I guess we could perhaps skip the invalidate.
Hmm. Also looks like ORIGIN_GTT has been neutered and now
we treat everyting as ORIGIN_CPU. That's maybe not so great.
Should probably reinstate ORIGIN_GTT so we can actually benefit
from the hw gtt tracking. Or we just try to kill that off as well.
Also I wonder where is the flush counterpart to the invalidate
in i915_gem_object_prepare_write()?
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-11-29 11:37 ` Ville Syrjälä
0 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjälä @ 2019-11-29 11:37 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
On Fri, Nov 29, 2019 at 09:48:45AM +0100, Maarten Lankhorst wrote:
> Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
> > On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
> >> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> The code assumes we can omit the cfb allocation once fbc
> >>> has been enabled once. That's nonsense. Let's try to
> >>> reallocate it if we need to.
> >>>
> >>> The code is still a mess, but maybe this is enough to get
> >>> fbc going in some cases where it initially underallocates
> >>> the cfb and there's no full modeset to fix it up.
> >>>
> >>> Cc: Daniel Drake <drake@endlessm.com>
> >>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >>> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
> >>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
> >>> 1 file changed, 15 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> >>> index c976698b0729..928059a5da80 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> >>> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> >>> cache->fence_id = -1;
> >>> }
> >>>
> >>> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
> >>> +{
> >>> + struct intel_fbc *fbc = &dev_priv->fbc;
> >>> +
> >>> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> >>> + fbc->compressed_fb.size * fbc->threshold;
> >>> +}
> >>> +
> >>> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> >>> {
> >>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >>> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> >>> * we didn't get any invalidate/deactivate calls, but this would require
> >>> * a lot of tracking just for a specific case. If we conclude it's an
> >>> * important case, we can implement it later. */
> >>> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> >>> - fbc->compressed_fb.size * fbc->threshold) {
> >>> + if (intel_fbc_cfb_size_changed(dev_priv)) {
> >>> fbc->no_fbc_reason = "CFB requirements changed";
> >>> return false;
> >>> }
> >>> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> >>> mutex_lock(&fbc->lock);
> >>>
> >>> if (fbc->crtc) {
> >>> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
> >>> - goto out;
> >>> - }
> >>> + if (fbc->crtc != crtc ||
> >>> + !intel_fbc_cfb_size_changed(dev_priv))
> >>> + goto out;
> >>>
> >>> - if (!crtc_state->enable_fbc)
> >>> - goto out;
> >>> + __intel_fbc_disable(dev_priv);
> >>> + }
> >>>
> >>> WARN_ON(fbc->active);
> >>>
> >>> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> >>> if (intel_fbc_alloc_cfb(dev_priv,
> >>> intel_fbc_calculate_cfb_size(dev_priv, cache),
> >>> fb->format->cpp[0])) {
> >>> + cache->plane.visible = false;
> >>> fbc->no_fbc_reason = "not enough stolen memory";
> >>> goto out;
> >>> }
> >> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
> >>
> >> For 1-11, 14
> >>
> >> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>
> >> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
> > How would we get rid of the disable there? By triggering nukes at some
> > predefined interval? Doesn't sound all that great.
> Not touching FBC on frontbuffer write at all, and forcing userspace to use the dirtyfb api. I think the whole implicit tracking should be removed.
Perhaps. Not sure userspace is ready for that though.
I guess the only long lasting frontbuffer invalidate is the
one from set_domain. Everything else is bounded and so we
know the flush is going to come in a somewhat timely manner.
So for those cases I guess we could perhaps skip the invalidate.
Hmm. Also looks like ORIGIN_GTT has been neutered and now
we treat everyting as ORIGIN_CPU. That's maybe not so great.
Should probably reinstate ORIGIN_GTT so we can actually benefit
from the hw gtt tracking. Or we just try to kill that off as well.
Also I wonder where is the flush counterpart to the invalidate
in i915_gem_object_prepare_write()?
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-12-03 8:45 ` Maarten Lankhorst
0 siblings, 0 replies; 54+ messages in thread
From: Maarten Lankhorst @ 2019-12-03 8:45 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
Op 29-11-2019 om 12:37 schreef Ville Syrjälä:
> On Fri, Nov 29, 2019 at 09:48:45AM +0100, Maarten Lankhorst wrote:
>> Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
>>> On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
>>>> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>
>>>>> The code assumes we can omit the cfb allocation once fbc
>>>>> has been enabled once. That's nonsense. Let's try to
>>>>> reallocate it if we need to.
>>>>>
>>>>> The code is still a mess, but maybe this is enough to get
>>>>> fbc going in some cases where it initially underallocates
>>>>> the cfb and there's no full modeset to fix it up.
>>>>>
>>>>> Cc: Daniel Drake <drake@endlessm.com>
>>>>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>>>> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
>>>>> 1 file changed, 15 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
>>>>> index c976698b0729..928059a5da80 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
>>>>> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
>>>>> cache->fence_id = -1;
>>>>> }
>>>>>
>>>>> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
>>>>> +{
>>>>> + struct intel_fbc *fbc = &dev_priv->fbc;
>>>>> +
>>>>> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
>>>>> + fbc->compressed_fb.size * fbc->threshold;
>>>>> +}
>>>>> +
>>>>> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>>>>> {
>>>>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>>>> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>>>>> * we didn't get any invalidate/deactivate calls, but this would require
>>>>> * a lot of tracking just for a specific case. If we conclude it's an
>>>>> * important case, we can implement it later. */
>>>>> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
>>>>> - fbc->compressed_fb.size * fbc->threshold) {
>>>>> + if (intel_fbc_cfb_size_changed(dev_priv)) {
>>>>> fbc->no_fbc_reason = "CFB requirements changed";
>>>>> return false;
>>>>> }
>>>>> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>>>>> mutex_lock(&fbc->lock);
>>>>>
>>>>> if (fbc->crtc) {
>>>>> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
>>>>> - goto out;
>>>>> - }
>>>>> + if (fbc->crtc != crtc ||
>>>>> + !intel_fbc_cfb_size_changed(dev_priv))
>>>>> + goto out;
>>>>>
>>>>> - if (!crtc_state->enable_fbc)
>>>>> - goto out;
>>>>> + __intel_fbc_disable(dev_priv);
>>>>> + }
>>>>>
>>>>> WARN_ON(fbc->active);
>>>>>
>>>>> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>>>>> if (intel_fbc_alloc_cfb(dev_priv,
>>>>> intel_fbc_calculate_cfb_size(dev_priv, cache),
>>>>> fb->format->cpp[0])) {
>>>>> + cache->plane.visible = false;
>>>>> fbc->no_fbc_reason = "not enough stolen memory";
>>>>> goto out;
>>>>> }
>>>> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
>>>>
>>>> For 1-11, 14
>>>>
>>>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>
>>>> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
>>> How would we get rid of the disable there? By triggering nukes at some
>>> predefined interval? Doesn't sound all that great.
>> Not touching FBC on frontbuffer write at all, and forcing userspace to use the dirtyfb api. I think the whole implicit tracking should be removed.
> Perhaps. Not sure userspace is ready for that though.
We have to audit that DirtyFB is called on all gen9+ userspace, because FBC is only enabled by default on those platforms.
I know the modesetting ddx does, I believe xf86-video-intel as well. So it should be safe to do. We could hide the old behavior behind a kernel parameter for now for 1 or 2 releases,
so we can chicken out if needed.
> I guess the only long lasting frontbuffer invalidate is the
> one from set_domain. Everything else is bounded and so we
> know the flush is going to come in a somewhat timely manner.
> So for those cases I guess we could perhaps skip the invalidate.
>
> Hmm. Also looks like ORIGIN_GTT has been neutered and now
> we treat everyting as ORIGIN_CPU. That's maybe not so great.
> Should probably reinstate ORIGIN_GTT so we can actually benefit
> from the hw gtt tracking. Or we just try to kill that off as well.
HW tracking has been buggy for a long time, and is no longer available on current hw because of those bugs.
> Also I wonder where is the flush counterpart to the invalidate
> in i915_gem_object_prepare_write()?
>
Not sure.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
@ 2019-12-03 8:45 ` Maarten Lankhorst
0 siblings, 0 replies; 54+ messages in thread
From: Maarten Lankhorst @ 2019-12-03 8:45 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
Op 29-11-2019 om 12:37 schreef Ville Syrjälä:
> On Fri, Nov 29, 2019 at 09:48:45AM +0100, Maarten Lankhorst wrote:
>> Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
>>> On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
>>>> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>
>>>>> The code assumes we can omit the cfb allocation once fbc
>>>>> has been enabled once. That's nonsense. Let's try to
>>>>> reallocate it if we need to.
>>>>>
>>>>> The code is still a mess, but maybe this is enough to get
>>>>> fbc going in some cases where it initially underallocates
>>>>> the cfb and there's no full modeset to fix it up.
>>>>>
>>>>> Cc: Daniel Drake <drake@endlessm.com>
>>>>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>>>> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
>>>>> 1 file changed, 15 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
>>>>> index c976698b0729..928059a5da80 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
>>>>> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
>>>>> cache->fence_id = -1;
>>>>> }
>>>>>
>>>>> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
>>>>> +{
>>>>> + struct intel_fbc *fbc = &dev_priv->fbc;
>>>>> +
>>>>> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
>>>>> + fbc->compressed_fb.size * fbc->threshold;
>>>>> +}
>>>>> +
>>>>> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>>>>> {
>>>>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>>>> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>>>>> * we didn't get any invalidate/deactivate calls, but this would require
>>>>> * a lot of tracking just for a specific case. If we conclude it's an
>>>>> * important case, we can implement it later. */
>>>>> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
>>>>> - fbc->compressed_fb.size * fbc->threshold) {
>>>>> + if (intel_fbc_cfb_size_changed(dev_priv)) {
>>>>> fbc->no_fbc_reason = "CFB requirements changed";
>>>>> return false;
>>>>> }
>>>>> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>>>>> mutex_lock(&fbc->lock);
>>>>>
>>>>> if (fbc->crtc) {
>>>>> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
>>>>> - goto out;
>>>>> - }
>>>>> + if (fbc->crtc != crtc ||
>>>>> + !intel_fbc_cfb_size_changed(dev_priv))
>>>>> + goto out;
>>>>>
>>>>> - if (!crtc_state->enable_fbc)
>>>>> - goto out;
>>>>> + __intel_fbc_disable(dev_priv);
>>>>> + }
>>>>>
>>>>> WARN_ON(fbc->active);
>>>>>
>>>>> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>>>>> if (intel_fbc_alloc_cfb(dev_priv,
>>>>> intel_fbc_calculate_cfb_size(dev_priv, cache),
>>>>> fb->format->cpp[0])) {
>>>>> + cache->plane.visible = false;
>>>>> fbc->no_fbc_reason = "not enough stolen memory";
>>>>> goto out;
>>>>> }
>>>> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
>>>>
>>>> For 1-11, 14
>>>>
>>>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>
>>>> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
>>> How would we get rid of the disable there? By triggering nukes at some
>>> predefined interval? Doesn't sound all that great.
>> Not touching FBC on frontbuffer write at all, and forcing userspace to use the dirtyfb api. I think the whole implicit tracking should be removed.
> Perhaps. Not sure userspace is ready for that though.
We have to audit that DirtyFB is called on all gen9+ userspace, because FBC is only enabled by default on those platforms.
I know the modesetting ddx does, I believe xf86-video-intel as well. So it should be safe to do. We could hide the old behavior behind a kernel parameter for now for 1 or 2 releases,
so we can chicken out if needed.
> I guess the only long lasting frontbuffer invalidate is the
> one from set_domain. Everything else is bounded and so we
> know the flush is going to come in a somewhat timely manner.
> So for those cases I guess we could perhaps skip the invalidate.
>
> Hmm. Also looks like ORIGIN_GTT has been neutered and now
> we treat everyting as ORIGIN_CPU. That's maybe not so great.
> Should probably reinstate ORIGIN_GTT so we can actually benefit
> from the hw gtt tracking. Or we just try to kill that off as well.
HW tracking has been buggy for a long time, and is no longer available on current hw because of those bugs.
> Also I wonder where is the flush counterpart to the invalidate
> in i915_gem_object_prepare_write()?
>
Not sure.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
2019-12-03 8:45 ` [Intel-gfx] " Maarten Lankhorst
(?)
@ 2019-12-03 13:04 ` Ville Syrjälä
-1 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjälä @ 2019-12-03 13:04 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
On Tue, Dec 03, 2019 at 09:45:19AM +0100, Maarten Lankhorst wrote:
> Op 29-11-2019 om 12:37 schreef Ville Syrjälä:
> > On Fri, Nov 29, 2019 at 09:48:45AM +0100, Maarten Lankhorst wrote:
> >> Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
> >>> On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
> >>>> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> >>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>>>
> >>>>> The code assumes we can omit the cfb allocation once fbc
> >>>>> has been enabled once. That's nonsense. Let's try to
> >>>>> reallocate it if we need to.
> >>>>>
> >>>>> The code is still a mess, but maybe this is enough to get
> >>>>> fbc going in some cases where it initially underallocates
> >>>>> the cfb and there's no full modeset to fix it up.
> >>>>>
> >>>>> Cc: Daniel Drake <drake@endlessm.com>
> >>>>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >>>>> Cc: Jian-Hong Pan <jian-hong@endlessm.com>
> >>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>>> ---
> >>>>> drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
> >>>>> 1 file changed, 15 insertions(+), 7 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> >>>>> index c976698b0729..928059a5da80 100644
> >>>>> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> >>>>> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> >>>>> @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> >>>>> cache->fence_id = -1;
> >>>>> }
> >>>>>
> >>>>> +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
> >>>>> +{
> >>>>> + struct intel_fbc *fbc = &dev_priv->fbc;
> >>>>> +
> >>>>> + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> >>>>> + fbc->compressed_fb.size * fbc->threshold;
> >>>>> +}
> >>>>> +
> >>>>> static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> >>>>> {
> >>>>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >>>>> @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> >>>>> * we didn't get any invalidate/deactivate calls, but this would require
> >>>>> * a lot of tracking just for a specific case. If we conclude it's an
> >>>>> * important case, we can implement it later. */
> >>>>> - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> >>>>> - fbc->compressed_fb.size * fbc->threshold) {
> >>>>> + if (intel_fbc_cfb_size_changed(dev_priv)) {
> >>>>> fbc->no_fbc_reason = "CFB requirements changed";
> >>>>> return false;
> >>>>> }
> >>>>> @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> >>>>> mutex_lock(&fbc->lock);
> >>>>>
> >>>>> if (fbc->crtc) {
> >>>>> - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
> >>>>> - goto out;
> >>>>> - }
> >>>>> + if (fbc->crtc != crtc ||
> >>>>> + !intel_fbc_cfb_size_changed(dev_priv))
> >>>>> + goto out;
> >>>>>
> >>>>> - if (!crtc_state->enable_fbc)
> >>>>> - goto out;
> >>>>> + __intel_fbc_disable(dev_priv);
> >>>>> + }
> >>>>>
> >>>>> WARN_ON(fbc->active);
> >>>>>
> >>>>> @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> >>>>> if (intel_fbc_alloc_cfb(dev_priv,
> >>>>> intel_fbc_calculate_cfb_size(dev_priv, cache),
> >>>>> fb->format->cpp[0])) {
> >>>>> + cache->plane.visible = false;
> >>>>> fbc->no_fbc_reason = "not enough stolen memory";
> >>>>> goto out;
> >>>>> }
> >>>> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
> >>>>
> >>>> For 1-11, 14
> >>>>
> >>>> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>>
> >>>> We should probably get rid of the FBC disable on frontbuffer disable as well. I had some patches but nothing upstream-worthy yet. :(
> >>> How would we get rid of the disable there? By triggering nukes at some
> >>> predefined interval? Doesn't sound all that great.
> >> Not touching FBC on frontbuffer write at all, and forcing userspace to use the dirtyfb api. I think the whole implicit tracking should be removed.
> > Perhaps. Not sure userspace is ready for that though.
>
> We have to audit that DirtyFB is called on all gen9+ userspace, because FBC is only enabled by default on those platforms.
I'll probably enable it across the board once I get it fixed.
>
> I know the modesetting ddx does, I believe xf86-video-intel as well. So it should be safe to do. We could hide the old behavior behind a kernel parameter for now for 1 or 2 releases,
>
> so we can chicken out if needed.
>
> > I guess the only long lasting frontbuffer invalidate is the
> > one from set_domain. Everything else is bounded and so we
> > know the flush is going to come in a somewhat timely manner.
> > So for those cases I guess we could perhaps skip the invalidate.
> >
> > Hmm. Also looks like ORIGIN_GTT has been neutered and now
> > we treat everyting as ORIGIN_CPU. That's maybe not so great.
> > Should probably reinstate ORIGIN_GTT so we can actually benefit
> > from the hw gtt tracking. Or we just try to kill that off as well.
> HW tracking has been buggy for a long time, and is no longer available on current hw because of those bugs.
Which bugs? We still enable it on all platforms so I don't know what
you mean by it not being available.
> > Also I wonder where is the flush counterpart to the invalidate
> > in i915_gem_object_prepare_write()?
> >
> Not sure.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH v2 14/14] drm/i915/fbc: Reallocate cfb if we need more of it
2019-11-28 15:48 ` [Intel-gfx] " Maarten Lankhorst
(?)
(?)
@ 2019-12-09 14:17 ` Ville Syrjälä
-1 siblings, 0 replies; 54+ messages in thread
From: Ville Syrjälä @ 2019-12-09 14:17 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni, Daniel Drake
On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
> Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The code assumes we can omit the cfb allocation once fbc
> > has been enabled once. That's nonsense. Let's try to
> > reallocate it if we need to.
> >
> > The code is still a mess, but maybe this is enough to get
> > fbc going in some cases where it initially underallocates
> > the cfb and there's no full modeset to fix it up.
> >
> > Cc: Daniel Drake <drake@endlessm.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Jian-Hong Pan <jian-hong@endlessm.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 22 +++++++++++++++-------
> > 1 file changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index c976698b0729..928059a5da80 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -672,6 +672,14 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
> > cache->fence_id = -1;
> > }
> >
> > +static bool intel_fbc_cfb_size_changed(struct drm_i915_private *dev_priv)
> > +{
> > + struct intel_fbc *fbc = &dev_priv->fbc;
> > +
> > + return intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> > + fbc->compressed_fb.size * fbc->threshold;
> > +}
> > +
> > static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> > {
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > @@ -757,8 +765,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> > * we didn't get any invalidate/deactivate calls, but this would require
> > * a lot of tracking just for a specific case. If we conclude it's an
> > * important case, we can implement it later. */
> > - if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> > - fbc->compressed_fb.size * fbc->threshold) {
> > + if (intel_fbc_cfb_size_changed(dev_priv)) {
> > fbc->no_fbc_reason = "CFB requirements changed";
> > return false;
> > }
> > @@ -1112,12 +1119,12 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> > mutex_lock(&fbc->lock);
> >
> > if (fbc->crtc) {
> > - WARN_ON(fbc->crtc == crtc && !crtc_state->enable_fbc);
> > - goto out;
> > - }
> > + if (fbc->crtc != crtc ||
> > + !intel_fbc_cfb_size_changed(dev_priv))
> > + goto out;
> >
> > - if (!crtc_state->enable_fbc)
> > - goto out;
> > + __intel_fbc_disable(dev_priv);
> > + }
> >
> > WARN_ON(fbc->active);
> >
> > @@ -1130,6 +1137,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
> > if (intel_fbc_alloc_cfb(dev_priv,
> > intel_fbc_calculate_cfb_size(dev_priv, cache),
> > fb->format->cpp[0])) {
> > + cache->plane.visible = false;
> > fbc->no_fbc_reason = "not enough stolen memory";
> > goto out;
> > }
>
> Makes sense, unfortunately kms_cursor_legacy starts failing on this series. :(
>
> For 1-11, 14
>
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Entire series pushed with Maarten's irc r-b for the rest (thanks).
I also tracked down the lag I'm seeing on my laptop. It's caused by
the intel ddx never issuing dirtyfb ioctls because it fails to
correctly detect the capability. I'll post fixes for that shortly.
I suspect it was working better before we got WC mmap because then
the hw gtt tracking should have dealt with it. But with WC mmap
that no longer works and we actually depend on dirtyfb to flush
things.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✗ Fi.CI.BAT: failure for drm/i915/fbc: Fix FBC for glk+ (rev4)
@ 2019-11-27 23:15 ` Patchwork
0 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2019-11-27 23:15 UTC (permalink / raw)
To: Ville Syrjala; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/fbc: Fix FBC for glk+ (rev4)
URL : https://patchwork.freedesktop.org/series/70062/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7434 -> Patchwork_15474
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_15474 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15474, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_15474:
### IGT changes ###
#### Possible regressions ####
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-y: [PASS][1] -> [FAIL][2] +7 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u3: [PASS][3] -> [FAIL][4] +7 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-u3/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
- fi-icl-dsi: [PASS][5] -> [FAIL][6] +7 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-dsi/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][7] -> [FAIL][8] +7 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-glk-dsi: [PASS][9] -> [FAIL][10] +7 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-glk-dsi/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-glk-dsi/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html
Known issues
------------
Here are the changes found in Patchwork_15474 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [PASS][11] -> [FAIL][12] ([fdo#109483])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
#### Possible fixes ####
* igt@gem_ctx_create@basic-files:
- {fi-tgl-u}: [INCOMPLETE][13] ([fdo#111735]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-tgl-u/igt@gem_ctx_create@basic-files.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-tgl-u/igt@gem_ctx_create@basic-files.html
* igt@i915_module_load@reload-no-display:
- fi-skl-lmem: [DMESG-WARN][15] ([fdo#112261]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-lmem/igt@i915_module_load@reload-no-display.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-skl-lmem/igt@i915_module_load@reload-no-display.html
* igt@i915_module_load@reload-with-fault-injection:
- fi-icl-u3: [INCOMPLETE][17] ([fdo#107713]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-icl-u3/igt@i915_module_load@reload-with-fault-injection.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-icl-u3/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [DMESG-WARN][19] ([fdo#112261]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live_blt:
- fi-hsw-peppy: [DMESG-FAIL][21] ([fdo#112147]) -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-hsw-peppy/igt@i915_selftest@live_blt.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-hsw-peppy/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gt_heartbeat:
- {fi-kbl-7560u}: [DMESG-FAIL][23] -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-kbl-7560u/igt@i915_selftest@live_gt_heartbeat.html
#### Warnings ####
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][25] ([fdo#103558] / [fdo#105602] / [fdo#105763]) -> [DMESG-WARN][26] ([fdo#103558] / [fdo#105602]) +4 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_suspend@basic-s0.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-kbl-x1275/igt@gem_exec_suspend@basic-s0.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275: [DMESG-WARN][27] ([fdo#103558] / [fdo#105602] / [fdo#107139]) -> [DMESG-WARN][28] ([fdo#103558] / [fdo#105602] / [fdo#105763] / [fdo#107139])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@gem_exec_suspend@basic-s4-devices.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-kbl-x1275/igt@gem_exec_suspend@basic-s4-devices.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][29] ([fdo#103558] / [fdo#105602]) -> [DMESG-WARN][30] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +7 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7434/fi-kbl-x1275/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/fi-kbl-x1275/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
[fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
[fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261
Participating hosts (52 -> 43)
------------------------------
Missing (9): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7434 -> Patchwork_15474
CI-20190529: 20190529
CI_DRM_7434: 1bbc4d30ca9fd950cbcb73f324e00d0bc357758e @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5312: 851c75531043cd906e028632b64b02b9312e9945 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15474: 6c744e802d1e9a2b214e90d5570f8b2b5d23d35e @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6c744e802d1e drm/i915/fbc: Reallocate cfb if we need more of it
c3ccc69fd3d9 drm/i915/fbc: Enable fbc by default on glk+ once again
e52d25bf73f1 drm/i915/fbc: Wait for vblank after FBC disable on glk+
ced7786215d2 drm/i915/fbc: Start using flip nuke
75a634a2c79b drm/i915/fbc: Nuke fbc.enabled
47751851fcb1 drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/
77b7d52d20c2 drm/i915/fbc: Make fence_id optional for i965gm
43061d739fa2 drm/i915/fbc: Store fence_id direction in fbc cache/params
03cdd41d801f drm/i915/fbc: Track plane visibility
369ede442098 drm/i915/fbc: Precompute gen9 cfb stride w/a
ad2fa0b57c1f drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB
e490b0c7ffcd drm/i915: Relocate intel_crtc_active()
726697a9e0fd drm/i915/fbc: Nuke bogus single pipe fbc1 restriction
ec10ac10b950 drm/i915/fbc: Disable fbc by default on all glk+
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15474/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 00/14] drm/i915/fbc: Fix FBC for glk+
@ 2019-11-28 1:33 ` Daniel Drake
0 siblings, 0 replies; 54+ messages in thread
From: Daniel Drake @ 2019-11-28 1:33 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni
On Thu, Nov 28, 2019 at 4:12 AM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
> I also slapped on an extra patch at the end which should hopefully
> avoid the problems with FBC not getting enabled with fastboot.
Retested Asus E406MA, default parameters (fastboot=1) and now FBC is
marked enabled in i915_fbc_status.
I can't reproduce the visual corruption using my original tests
(interacting with GNOME gdm login screen, frantically scrolling text
inside gnome-terminal).
Tested-by: Daniel Drake <drake@endlessm.com>
Thanks!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Intel-gfx] [PATCH v2 00/14] drm/i915/fbc: Fix FBC for glk+
@ 2019-11-28 1:33 ` Daniel Drake
0 siblings, 0 replies; 54+ messages in thread
From: Daniel Drake @ 2019-11-28 1:33 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Jian-Hong Pan, intel-gfx, Paulo Zanoni
On Thu, Nov 28, 2019 at 4:12 AM Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
> I also slapped on an extra patch at the end which should hopefully
> avoid the problems with FBC not getting enabled with fastboot.
Retested Asus E406MA, default parameters (fastboot=1) and now FBC is
marked enabled in i915_fbc_status.
I can't reproduce the visual corruption using my original tests
(interacting with GNOME gdm login screen, frantically scrolling text
inside gnome-terminal).
Tested-by: Daniel Drake <drake@endlessm.com>
Thanks!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/fbc: Fix FBC for glk+ (rev5)
@ 2019-11-28 18:02 ` Patchwork
0 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2019-11-28 18:02 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/fbc: Fix FBC for glk+ (rev5)
URL : https://patchwork.freedesktop.org/series/70062/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7438 -> Patchwork_15492
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/index.html
Known issues
------------
Here are the changes found in Patchwork_15492 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_module_load@reload-no-display:
- fi-skl-6770hq: [PASS][1] -> [DMESG-WARN][2] ([fdo#112261])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/fi-skl-6770hq/igt@i915_module_load@reload-no-display.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/fi-skl-6770hq/igt@i915_module_load@reload-no-display.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][3] -> [DMESG-WARN][4] ([fdo#102614])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/fi-hsw-peppy/igt@kms_frontbuffer_tracking@basic.html
#### Possible fixes ####
* igt@i915_pm_rpm@module-reload:
- fi-skl-lmem: [DMESG-WARN][5] ([fdo#112261]) -> [PASS][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/fi-skl-lmem/igt@i915_pm_rpm@module-reload.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/fi-skl-lmem/igt@i915_pm_rpm@module-reload.html
#### Warnings ####
* igt@kms_busy@basic-flip-pipe-b:
- fi-kbl-x1275: [DMESG-WARN][7] ([fdo#103558] / [fdo#105602] / [fdo#105763]) -> [DMESG-WARN][8] ([fdo#103558] / [fdo#105602]) +6 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-b.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/fi-kbl-x1275/igt@kms_busy@basic-flip-pipe-b.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-dsi: [INCOMPLETE][9] ([fdo#107713]) -> [DMESG-WARN][10] ([fdo#107724])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/fi-icl-dsi/igt@kms_flip@basic-flip-vs-dpms.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/fi-icl-dsi/igt@kms_flip@basic-flip-vs-dpms.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][11] ([fdo#103558] / [fdo#105602]) -> [DMESG-WARN][12] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +5 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/fi-kbl-x1275/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/fi-kbl-x1275/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
[fdo#112260]: https://bugs.freedesktop.org/show_bug.cgi?id=112260
[fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261
[fdo#112298]: https://bugs.freedesktop.org/show_bug.cgi?id=112298
Participating hosts (51 -> 46)
------------------------------
Additional (1): fi-tgl-y
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7438 -> Patchwork_15492
CI-20190529: 20190529
CI_DRM_7438: 8a2661592e79e48bcba9c24565b2b16edafbcbaa @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5313: 92caadb4e551ba05aa6e6e567ef69da96ca7e328 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15492: ec9b25c1bb782c19b3b2b3de7404d344e3a5d94d @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ec9b25c1bb78 drm/i915/fbc: Reallocate cfb if we need more of it
ff746b69cc5c drm/i915/fbc: Enable fbc by default on glk+ once again
8d8a176386f3 drm/i915/fbc: Wait for vblank after FBC disable on glk+
d73f0f5b8258 drm/i915/fbc: Start using flip nuke
cea5ba8c8dce drm/i915/fbc: Nuke fbc.enabled
6b49c5285a5d drm/i915/fbc: s/gen9 && !glk/gen9_bc || bxt/
41b4f2c30251 drm/i915/fbc: Make fence_id optional for i965gm
e95013fcfd1a drm/i915/fbc: Store fence_id direction in fbc cache/params
8d53002269b7 drm/i915/fbc: Track plane visibility
5233ae002be2 drm/i915/fbc: Precompute gen9 cfb stride w/a
b7fb0db9d284 drm/i915/fbc: Remove the FBC_RT_BASE setup for ILK/SNB
104712547dc7 drm/i915: Relocate intel_crtc_active()
33b974385b9b drm/i915/fbc: Nuke bogus single pipe fbc1 restriction
9a6daa1005d1 drm/i915/fbc: Disable fbc by default on all glk+
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread* ✓ Fi.CI.IGT: success for drm/i915/fbc: Fix FBC for glk+ (rev5)
@ 2019-11-29 23:51 ` Patchwork
0 siblings, 0 replies; 54+ messages in thread
From: Patchwork @ 2019-11-29 23:51 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/fbc: Fix FBC for glk+ (rev5)
URL : https://patchwork.freedesktop.org/series/70062/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7438_full -> Patchwork_15492_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_15492_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +6 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb2/igt@gem_busy@busy-vcs1.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb8/igt@gem_busy@busy-vcs1.html
* igt@gem_ctx_persistence@vcs1-hostile-preempt:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb2/igt@gem_ctx_persistence@vcs1-hostile-preempt.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb8/igt@gem_ctx_persistence@vcs1-hostile-preempt.html
* igt@gem_eio@in-flight-suspend:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#111832] / [fdo#111850] / [fdo#112081])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb1/igt@gem_eio@in-flight-suspend.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb1/igt@gem_eio@in-flight-suspend.html
* igt@gem_exec_await@wide-all:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111736])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb9/igt@gem_exec_await@wide-all.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb6/igt@gem_exec_await@wide-all.html
* igt@gem_exec_schedule@pi-ringfull-bsd2:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +3 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb2/igt@gem_exec_schedule@pi-ringfull-bsd2.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb8/igt@gem_exec_schedule@pi-ringfull-bsd2.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [PASS][11] -> [FAIL][12] ([fdo#112392])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-glk4/igt@gem_ppgtt@flink-and-close-vma-leak.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-glk9/igt@gem_ppgtt@flink-and-close-vma-leak.html
- shard-kbl: [PASS][13] -> [FAIL][14] ([fdo#112392])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-kbl3/igt@gem_ppgtt@flink-and-close-vma-leak.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-kbl4/igt@gem_ppgtt@flink-and-close-vma-leak.html
- shard-skl: [PASS][15] -> [FAIL][16] ([fdo#112392])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-skl3/igt@gem_ppgtt@flink-and-close-vma-leak.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-skl2/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gem_userptr_blits@sync-unmap-after-close:
- shard-hsw: [PASS][17] -> [DMESG-WARN][18] ([fdo#110789] / [fdo#111870])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-hsw6/igt@gem_userptr_blits@sync-unmap-after-close.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-hsw8/igt@gem_userptr_blits@sync-unmap-after-close.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111832] / [fdo#111850])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb9/igt@i915_suspend@fence-restore-tiled2untiled.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb8/igt@i915_suspend@fence-restore-tiled2untiled.html
* igt@i915_suspend@forcewake:
- shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +1 similar issue
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-kbl4/igt@i915_suspend@forcewake.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-kbl7/igt@i915_suspend@forcewake.html
* igt@kms_color@pipe-a-ctm-0-75:
- shard-skl: [PASS][23] -> [DMESG-WARN][24] ([fdo#106107])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-skl8/igt@kms_color@pipe-a-ctm-0-75.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-skl6/igt@kms_color@pipe-a-ctm-0-75.html
* igt@kms_draw_crc@draw-method-xrgb8888-render-untiled:
- shard-tglb: [PASS][25] -> [INCOMPLETE][26] ([fdo#111747])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb1/igt@kms_draw_crc@draw-method-xrgb8888-render-untiled.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb8/igt@kms_draw_crc@draw-method-xrgb8888-render-untiled.html
* igt@kms_flip@dpms-vs-vblank-race:
- shard-hsw: [PASS][27] -> [DMESG-WARN][28] ([fdo#102614])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-hsw8/igt@kms_flip@dpms-vs-vblank-race.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-hsw5/igt@kms_flip@dpms-vs-vblank-race.html
* igt@kms_plane@pixel-format-pipe-a-planes:
- shard-skl: [PASS][29] -> [INCOMPLETE][30] ([fdo#112347]) +2 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-skl10/igt@kms_plane@pixel-format-pipe-a-planes.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-skl9/igt@kms_plane@pixel-format-pipe-a-planes.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [PASS][31] -> [DMESG-WARN][32] ([fdo#108566]) +3 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-apl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][33] -> [FAIL][34] ([fdo#108145] / [fdo#110403])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [PASS][35] -> [SKIP][36] ([fdo#109441])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_rotation_crc@primary-rotation-270:
- shard-iclb: [PASS][37] -> [INCOMPLETE][38] ([fdo#107713] / [fdo#110026] / [fdo#110040])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb3/igt@kms_rotation_crc@primary-rotation-270.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb7/igt@kms_rotation_crc@primary-rotation-270.html
* igt@kms_setmode@basic:
- shard-kbl: [PASS][39] -> [FAIL][40] ([fdo#99912])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-kbl1/igt@kms_setmode@basic.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-kbl1/igt@kms_setmode@basic.html
#### Possible fixes ####
* igt@gem_ctx_persistence@rcs0-mixed-process:
- shard-apl: [FAIL][41] -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-apl7/igt@gem_ctx_persistence@rcs0-mixed-process.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-apl2/igt@gem_ctx_persistence@rcs0-mixed-process.html
* igt@gem_eio@unwedge-stress:
- shard-snb: [FAIL][43] ([fdo#109661]) -> [PASS][44]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-snb7/igt@gem_eio@unwedge-stress.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-snb5/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [SKIP][45] ([fdo#112146]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb2/igt@gem_exec_schedule@in-order-bsd.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb8/igt@gem_exec_schedule@in-order-bsd.html
* igt@gem_exec_schedule@preempt-queue-chain-render:
- shard-tglb: [INCOMPLETE][47] ([fdo#111606] / [fdo#111677]) -> [PASS][48]
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb6/igt@gem_exec_schedule@preempt-queue-chain-render.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb4/igt@gem_exec_schedule@preempt-queue-chain-render.html
* igt@gem_exec_schedule@smoketest-all:
- shard-tglb: [INCOMPLETE][49] ([fdo#111855]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb9/igt@gem_exec_schedule@smoketest-all.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb8/igt@gem_exec_schedule@smoketest-all.html
* igt@gem_sync@basic-store-each:
- shard-tglb: [INCOMPLETE][51] ([fdo#111747] / [fdo#111880]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb3/igt@gem_sync@basic-store-each.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb1/igt@gem_sync@basic-store-each.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-hsw: [DMESG-WARN][53] ([fdo#111870]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-hsw5/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-hsw4/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy.html
* igt@gem_userptr_blits@sync-unmap-after-close:
- shard-snb: [DMESG-WARN][55] ([fdo#111870]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-snb5/igt@gem_userptr_blits@sync-unmap-after-close.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-snb7/igt@gem_userptr_blits@sync-unmap-after-close.html
* igt@i915_pm_dc@dc5-dpms:
- shard-iclb: [FAIL][57] ([fdo#111795]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb3/igt@i915_pm_dc@dc5-dpms.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb6/igt@i915_pm_dc@dc5-dpms.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][59] ([fdo#111830]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb6/igt@i915_pm_dc@dc6-psr.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb3/igt@i915_pm_dc@dc6-psr.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [DMESG-WARN][61] ([fdo#108566]) -> [PASS][62] +1 similar issue
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-apl1/igt@i915_suspend@sysfs-reader.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-apl6/igt@i915_suspend@sysfs-reader.html
* igt@kms_draw_crc@draw-method-rgb565-render-untiled:
- shard-iclb: [INCOMPLETE][63] ([fdo#107713]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb7/igt@kms_draw_crc@draw-method-rgb565-render-untiled.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb7/igt@kms_draw_crc@draw-method-rgb565-render-untiled.html
* igt@kms_draw_crc@draw-method-xrgb8888-render-ytiled:
- shard-skl: [INCOMPLETE][65] -> [PASS][66] +1 similar issue
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-skl2/igt@kms_draw_crc@draw-method-xrgb8888-render-ytiled.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-skl7/igt@kms_draw_crc@draw-method-xrgb8888-render-ytiled.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: [FAIL][67] ([fdo#103167]) -> [PASS][68] +1 similar issue
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-tglb: [INCOMPLETE][69] ([fdo#111747] / [fdo#111884]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl: [DMESG-WARN][71] ([fdo#108566]) -> [PASS][72] +1 similar issue
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-kbl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-kbl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-kbl: [INCOMPLETE][73] ([fdo#103665]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-kbl3/igt@kms_plane@pixel-format-pipe-b-planes.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-kbl1/igt@kms_plane@pixel-format-pipe-b-planes.html
* igt@kms_setmode@basic:
- shard-hsw: [FAIL][75] ([fdo#99912]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-hsw7/igt@kms_setmode@basic.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-hsw7/igt@kms_setmode@basic.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs2-none:
- shard-tglb: [SKIP][77] ([fdo#112080]) -> [SKIP][78] ([fdo#111912] / [fdo#112080])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-tglb9/igt@gem_ctx_isolation@vcs2-none.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-tglb8/igt@gem_ctx_isolation@vcs2-none.html
* igt@gem_eio@kms:
- shard-snb: [INCOMPLETE][79] ([fdo#105411]) -> [DMESG-WARN][80] ([fdo#111781] / [fdo#112000])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7438/shard-snb1/igt@gem_eio@kms.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15492/shard-snb4/igt@gem_eio@kms.html
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661
[fdo#110026]: https://bugs.freedesktop.org/show_bug.cgi?id=110026
[fdo#110040]: https://bugs.freedesktop.org/show_bug.cgi?id=110040
[fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
[fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
[fdo#111606]: https://bugs.freedesktop.org/show_bug.cgi?id=111606
[fdo#111677]: https://bugs.freedesktop.org/show_bug.cgi?id=111677
[fdo#111736]: https://bugs.freedesktop.org/show_bug.cgi?id=111736
[fdo#111747]: https://bugs.freedesktop.org/show_bug.cgi?id=111747
[fdo#111781]: https://bugs.freedesktop.org/show_bug.cgi?id=111781
[fdo#111795]: https://bugs.freedesktop.org/show_bug.cgi?id=111795
[fdo#111830]: https://bugs.freedesktop.org/show_bug.cgi?id=111830
[fdo#111832]: https://bugs.freedesktop.org/show_bug.cgi?id=111832
[fdo#111850]: https://bugs.freedesktop.org/show_bug.cgi?id=111850
[fdo#111855]: https://bugs.freedesktop.org/show_bug.cgi?id=111855
[fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
[fdo#111880]: https://bugs.freedesktop.org/show_bug.cgi?id=111880
[fdo#111884]: https://bugs.freedesktop.org/show_bug.cgi?id=111884
[fdo#111912]: https://bugs.freedesktop.org/show_bug.cgi?id=111912
[fdo#112000]: https://bugs.freedesktop.org/show_bug.cgi?id=112000
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112081]: https://bugs.freedesktop.org/show_bug.cgi?id=112081
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112347]: https://bugs.freedesktop.org/show_bug.cgi?id=112347
[fdo#112392]: https://bugs.freedesktop.org/show_bug.cgi?id=112392
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (11 -> 11)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7438 -> Patchwork_15492
CI-20190529: 20190529
CI_DRM_7438: 8a2661592e79e48bcba9c24565b2b16edafbcbaa @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5313: 92caadb4e551ba05aa6e6e567ef69da96ca7e328 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15492: ec9b25c1bb782c19b3b2b3de7404d344e3a5d94d @ 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_15492/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 54+ messages in thread