== Series Details ==
Series: gpu: drm: i915: Change return type to vm_fault_t (rev5)
URL : https://patchwork.freedesktop.org/series/41893/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4283_full -> Patchwork_9225_full =
== Summary - FAILURE ==
Serious unknown changes
On 6 June 2018 at 07:27, Chris Wilson wrote:
> To allow ourselves to use a first class vma for the aliasing_ppgtt page
> directory, we have to reorder the shutdown on module unload to remove
> and unpin the aliasing_ppgtt before complaining about any objects left
> in the GGTT.
>
> Signed-off-by:
On 7 June 2018 at 00:24, Matthew Auld wrote:
> On 6 June 2018 at 07:26, Chris Wilson wrote:
>> Pull the empty stubs together into the top level gen6_ppgtt_create, and
>> tear each one down on error in proper onion order (rather than use
>> Joonas' pet hate of calling the cleanup function in
On 6 June 2018 at 07:26, Chris Wilson wrote:
> Pull the empty stubs together into the top level gen6_ppgtt_create, and
> tear each one down on error in proper onion order (rather than use
> Joonas' pet hate of calling the cleanup function in indeterminable
> state).
>
> Signed-off-by: Chris
On 6 June 2018 at 07:26, Chris Wilson wrote:
> In order to allow ourselves to use VMA to wrap other entities other than
> GEM objects, we need to allow for the vma->obj backpointer to be NULL.
> In most cases, we know we are operating on a GEM object and its vma, but
> we need the core code (such
== Series Details ==
Series: drm/i915/gtt: Fix typo in fill_px() macro
URL : https://patchwork.freedesktop.org/series/44373/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4283_full -> Patchwork_9224_full =
== Summary - FAILURE ==
Serious unknown changes coming with
On 6 June 2018 at 07:51, Chris Wilson wrote:
> Currently all page directories are bound at creation using an
> unevictable node in the GGTT. This severely limits us as we cannot
> remove any inactive ppgtt for new contexts, or under aperture pressure.
> To fix this we need to make the page
On 6 June 2018 at 22:45, Chris Wilson wrote:
> In preparation for vm_fault_t becoming a distinct type, convert the
> fault handler (i915_gem_fault()) over to the new interface.
>
> Based on a patch by Souptick Joarder
>
> References: 1c8f422059ae ("mm: change return type to vm_fault_t")
>
On 6 June 2018 at 07:27, Chris Wilson wrote:
> We can stop asserting using WARN_ON as given sufficient CI coverage, we
> can rely on using GEM_BUG_ON() to catch problems before merging.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> Cc: Matthew Auld
Reviewed-by:
On 6 June 2018 at 07:27, Chris Wilson wrote:
> As the most frequent PTE encoding is for the scratch page, cache it upon
> creation.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> Cc: Matthew Auld
Reviewed-by: Matthew Auld
On 6 June 2018 at 07:27, Chris Wilson wrote:
> As we cannot reliably change used page tables while the context is
> active, the earliest opportunity we have to recover excess pages is when
> the context becomes idle. So whenever we unbind the context (it must be
> idle, and indeed being evicted)
On 6 June 2018 at 07:27, Chris Wilson wrote:
> If we will completely overwrite the PT with PTEs for the object, we can
> forgo filling it with scratch entries.
>
> References: 14826673247e ("drm/i915: Only initialize partially filled
> pagetables")
> Signed-off-by: Chris Wilson
> Cc: Joonas
On 6 June 2018 at 07:27, Chris Wilson wrote:
> As we were only supporting aliasing_ppgtt on gen7 for some time, we
> saved a few checks by preallocating the page directories on creation.
> However, since we need 2MiB of page directories for each ppgtt, to
> support arbitrary numbers of user
== Series Details ==
Series: gpu: drm: i915: Change return type to vm_fault_t (rev5)
URL : https://patchwork.freedesktop.org/series/41893/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4283 -> Patchwork_9225 =
== Summary - WARNING ==
Minor unknown changes coming with
== Series Details ==
Series: gpu: drm: i915: Change return type to vm_fault_t (rev5)
URL : https://patchwork.freedesktop.org/series/41893/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Change i915_gem_fault() to return vm_fault_t
Quoting Matthew Auld (2018-06-06 21:56:07)
> On 6 June 2018 at 21:51, Chris Wilson wrote:
> > The macro declare the ppgtt parameter but implicitly used the local vm
> > instead.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > Cc: Mika Kuoppala
> > Cc: Matthew Auld
>
== Series Details ==
Series: gpu: drm: i915: Change return type to vm_fault_t (rev5)
URL : https://patchwork.freedesktop.org/series/41893/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8fdaea4385cb drm/i915: Change i915_gem_fault() to return vm_fault_t
-:11:
== Series Details ==
Series: drm/i915/gtt: Fix typo in fill_px() macro
URL : https://patchwork.freedesktop.org/series/44373/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4283 -> Patchwork_9224 =
== Summary - SUCCESS ==
No regressions found.
External URL:
In preparation for vm_fault_t becoming a distinct type, convert the
fault handler (i915_gem_fault()) over to the new interface.
Based on a patch by Souptick Joarder
References: 1c8f422059ae ("mm: change return type to vm_fault_t")
Signed-off-by: Chris Wilson
Cc: Souptick Joarder
Cc: Joonas
On 6 June 2018 at 21:51, Chris Wilson wrote:
> The macro declare the ppgtt parameter but implicitly used the local vm
> instead.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> Cc: Matthew Auld
Reviewed-by: Matthew Auld
Quoting Antonio Argenziano (2018-06-06 21:48:22)
>
>
> On 06/06/18 10:42, Chris Wilson wrote:
> > The current method of checking for a failed module load is flawed, as we
> > only report the error on probing it is not being reported back by
> > modprobe. So we have to dig inside the
Hi Lionel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.17 next-20180605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
The macro declare the ppgtt parameter but implicitly used the local vm
instead.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 06/06/18 10:42, Chris Wilson wrote:
The current method of checking for a failed module load is flawed, as we
only report the error on probing it is not being reported back by
modprobe. So we have to dig inside the module_parameters while the
module is still loaded to discover the error.
== Series Details ==
Series: series starting with [v6,1/2] drm/i915: update cursors asynchronously
through atomic
URL : https://patchwork.freedesktop.org/series/44366/
State : failure
== Summary ==
Applying: drm/i915: update cursors asynchronously through atomic
error: Failed to merge in the
Hi Lionel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.17 next-20180605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
== Series Details ==
Series: drm/i915: Use GEM suspend when aborting initialisation
URL : https://patchwork.freedesktop.org/series/44359/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282_full -> Patchwork_9222_full =
== Summary - WARNING ==
Minor unknown changes
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
Signed-off-by: Enric Balletbo i Serra
---
Changes in v6: None
Changes in v5: None
Changes in
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Gustavo Padovan
Hi Lionel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180605]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Wed, Jun 06, 2018 at 07:04:47PM +0100, Chris Wilson wrote:
> Quoting Imre Deak (2018-06-06 19:00:52)
> > On Wed, Jun 06, 2018 at 06:42:14PM +0100, Chris Wilson wrote:
> > > The current method of checking for a failed module load is flawed, as we
> > > only report the error on probing it is not
On Wed, Jun 06, 2018 at 02:12:36PM +0200, Hans de Goede wrote:
> Hi,
>
> On 06-06-18 12:43, Maarten Lankhorst wrote:
> > Op 06-06-18 om 11:54 schreef Hans de Goede:
> > > Hi,
> > >
> > > On 06-06-18 11:36, Maarten Lankhorst wrote:
> > > > Op 06-06-18 om 11:09 schreef Hans de Goede:
> > > > > Hi
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.17 next-20180605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
== Series Details ==
Series: drm/i915: Mark i915.inject_load_failure as being hit (rev3)
URL : https://patchwork.freedesktop.org/series/44354/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282_full -> Patchwork_9221_full =
== Summary - WARNING ==
Minor unknown changes
Quoting Imre Deak (2018-06-06 19:00:52)
> On Wed, Jun 06, 2018 at 06:42:14PM +0100, Chris Wilson wrote:
> > The current method of checking for a failed module load is flawed, as we
> > only report the error on probing it is not being reported back by
> > modprobe. So we have to dig inside the
On Wed, Jun 06, 2018 at 06:42:14PM +0100, Chris Wilson wrote:
> The current method of checking for a failed module load is flawed, as we
> only report the error on probing it is not being reported back by
> modprobe. So we have to dig inside the module_parameters while the
> module is still loaded
The current method of checking for a failed module load is flawed, as we
only report the error on probing it is not being reported back by
modprobe. So we have to dig inside the module_parameters while the
module is still loaded to discover the error.
v2: Expect i915.inject_load_failure to be
Quoting Michal Wajdeczko (2018-06-06 15:54:47)
> On Wed, 06 Jun 2018 16:50:09 +0200, Michał Winiarski
> wrote:
>
> > On Wed, Jun 06, 2018 at 03:41:53PM +0100, Chris Wilson wrote:
> >> When we reach the magic value and do inject a fault into our module
> >> load,
> >> mark the module option
== Series Details ==
Series: Queued/runnable/running engine stats (rev11)
URL : https://patchwork.freedesktop.org/series/36926/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282_full -> Patchwork_9220_full =
== Summary - WARNING ==
Minor unknown changes coming with
== Series Details ==
Series: ctx-sync
URL : https://patchwork.freedesktop.org/series/44353/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282_full -> Patchwork_9217_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9217_full need to be verified
== Series Details ==
Series: Queued/runnable/running engine stats (rev8)
URL : https://patchwork.freedesktop.org/series/36926/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4282_full -> Patchwork_9216_full =
== Summary - FAILURE ==
Serious unknown changes coming with
== Series Details ==
Series: drm/i915: Use GEM suspend when aborting initialisation
URL : https://patchwork.freedesktop.org/series/44359/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9222 =
== Summary - WARNING ==
Minor unknown changes coming with
== Series Details ==
Series: drm/i915: Apply batch location restrictions before pinning
URL : https://patchwork.freedesktop.org/series/44349/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4282_full -> Patchwork_9215_full =
== Summary - FAILURE ==
Serious unknown changes
== Series Details ==
Series: drm/i915: Export number of fail injection checkpoints through debugfs
URL : https://patchwork.freedesktop.org/series/44347/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282_full -> Patchwork_9214_full =
== Summary - WARNING ==
Minor
On 06/06/2018 16:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-06 15:40:10)
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests currently executing
on the GPU.
This is useful to analyze the overall load of the system.
v2:
* Rebase.
* Drop floating point
== Series Details ==
Series: drm/i915: Mark i915.inject_load_failure as being hit (rev3)
URL : https://patchwork.freedesktop.org/series/44354/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9221 =
== Summary - WARNING ==
Minor unknown changes coming
Quoting Tvrtko Ursulin (2018-06-06 15:40:10)
> From: Tvrtko Ursulin
>
> We add a PMU counter to expose the number of requests currently executing
> on the GPU.
>
> This is useful to analyze the overall load of the system.
>
> v2:
> * Rebase.
> * Drop floating point constant. (Chris Wilson)
>
== Series Details ==
Series: drm/i915: Mark i915.inject_load_failure as being hit (rev3)
URL : https://patchwork.freedesktop.org/series/44354/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
741a311327ce drm/i915: Mark i915.inject_load_failure as being hit
-:12:
== Series Details ==
Series: Queued/runnable/running engine stats (rev11)
URL : https://patchwork.freedesktop.org/series/36926/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9220 =
== Summary - WARNING ==
Minor unknown changes coming with
== Series Details ==
Series: drm/i915: Update preproduction steppings
URL : https://patchwork.freedesktop.org/series/44355/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9219 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9219
Quoting Michał Winiarski (2018-06-06 15:50:09)
> On Wed, Jun 06, 2018 at 03:41:53PM +0100, Chris Wilson wrote:
> > When we reach the magic value and do inject a fault into our module load,
> > mark the module option as being hit. Since we fail from inside pci
> > probe, the module load isn't
As part of our GEM initialisation now, we send a request to the hardware
in order to record the initial GPU state. This coupled with deferred
idle workers, makes aborting on error tricky. We already have the
mechanism in place to wait on the GPU and cancel all the deferred
workers for suspend, so
On Wed, 06 Jun 2018 16:50:09 +0200, Michał Winiarski
wrote:
On Wed, Jun 06, 2018 at 03:41:53PM +0100, Chris Wilson wrote:
When we reach the magic value and do inject a fault into our module
load,
mark the module option as being hit. Since we fail from inside pci
probe, the module load
On Wed, Jun 06, 2018 at 03:41:53PM +0100, Chris Wilson wrote:
> When we reach the magic value and do inject a fault into our module load,
> mark the module option as being hit. Since we fail from inside pci
> probe, the module load isn't actually aborted and the module (and
> paramters) are left
When we reach the magic value and do inject a fault into our module load,
mark the module option as being hit. Since we fail from inside pci
probe, the module load isn't actually aborted and the module (and
paramters) are left lingering. igt can then inspect the parameter on its
synchronous
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests currently executing
on the GPU.
This is useful to analyze the overall load of the system.
v2:
* Rebase.
* Drop floating point constant. (Chris Wilson)
v3:
* Change scale to 1024 for faster arithmetics. (Chris
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests with resolved
dependencies waiting for a slot on the GPU to run.
This is useful to analyze the overall load of the system.
v2: Don't limit to gen8+.
v3:
* Rebase for dynamic sysfs.
* Drop currently executing
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests which have been
submitted from userspace but are not yet runnable due dependencies and
unsignaled fences.
This is useful to analyze the overall load of the system.
v2:
* Rebase for name change and re-order.
* Drop
== Series Details ==
Series: drm/i915: Update preproduction steppings
URL : https://patchwork.freedesktop.org/series/44355/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Update preproduction steppings
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3668:16:
Just a few suggestions below. Otherwise looks good to me.
On 06/06/18 13:49, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Basic tests to cover engine queued/runnable/running metric as reported
by the DRM_I915_QUERY_ENGINE_QUEUES query.
v2:
* Update ABI for i915 changes.
* Use
Quoting Michał Winiarski (2018-06-06 15:18:14)
> On Wed, Jun 06, 2018 at 02:09:16PM +0100, Chris Wilson wrote:
> > The current method of checking for a failed module load is flawed, as we
> > only report the error on probing it is not being reported back by
> > modprobe. So we have to dig inside
Quoting Mika Kuoppala (2018-06-06 15:18:24)
> Update preproduction steppings detection so that
> we get the warning and taint correctly for more
> recent platforms.
Before crying foul, I suggest we check INTEL_INFO()->is_alpha_support.
We don't want to taint SDP boxes as we work on them for
On Wed, 06 Jun 2018 16:19:29 +0200, Chris Wilson
wrote:
Quoting Chris Wilson (2018-06-06 14:33:19)
Quoting Michal Wajdeczko (2018-06-06 14:25:34)
> On Wed, 06 Jun 2018 15:09:37 +0200, Chris Wilson
> wrote:
>
> > When we reach the magic value and do inject a fault into our module
load,
>
When we reach the magic value and do inject a fault into our module load,
mark the module option as being hit. Since we fail from inside pci
probe, the module load isn't actually aborted and the module (and
paramters) are left lingering. igt can then inspect the parameter on its
synchronous
Quoting Chris Wilson (2018-06-06 14:33:19)
> Quoting Michal Wajdeczko (2018-06-06 14:25:34)
> > On Wed, 06 Jun 2018 15:09:37 +0200, Chris Wilson
> > wrote:
> >
> > > When we reach the magic value and do inject a fault into our module load,
> > > mark the module option as being hit. Since we
Update preproduction steppings detection so that
we get the warning and taint correctly for more
recent platforms.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_drv.h | 3 +++
2 files changed, 7 insertions(+)
diff --git
On Wed, Jun 06, 2018 at 02:09:16PM +0100, Chris Wilson wrote:
> The current method of checking for a failed module load is flawed, as we
> only report the error on probing it is not being reported back by
> modprobe. So we have to dig inside the module_parameters while the
> module is still loaded
== Series Details ==
Series: drm/i915: Mark i915.inject_load_failure as being hit
URL : https://patchwork.freedesktop.org/series/44354/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9218 =
== Summary - FAILURE ==
Serious unknown changes coming with
== Series Details ==
Series: drm/i915: Mark i915.inject_load_failure as being hit
URL : https://patchwork.freedesktop.org/series/44354/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a17a013ca1ef drm/i915: Mark i915.inject_load_failure as being hit
-:12: WARNING:TYPO_SPELLING:
== Series Details ==
Series: ctx-sync
URL : https://patchwork.freedesktop.org/series/44353/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9217 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9217 need to be verified
manually.
== Series Details ==
Series: ctx-sync
URL : https://patchwork.freedesktop.org/series/44353/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
21dfbf8ac009 ctx-sync
-:42: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 0 warnings, 0 checks, 31 lines checked
Quoting Michal Wajdeczko (2018-06-06 14:25:34)
> On Wed, 06 Jun 2018 15:09:37 +0200, Chris Wilson
> wrote:
>
> > When we reach the magic value and do inject a fault into our module load,
> > mark the module option as being hit. Since we fail from inside pci
> > probe, the module load isn't
== Series Details ==
Series: Queued/runnable/running engine stats (rev8)
URL : https://patchwork.freedesktop.org/series/36926/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9216 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9216
On Wed, 06 Jun 2018 15:09:37 +0200, Chris Wilson
wrote:
When we reach the magic value and do inject a fault into our module load,
mark the module option as being hit. Since we fail from inside pci
probe, the module load isn't actually aborted and the module (and
paramters) are left
On 06/06/2018 14:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-06 13:48:45)
@@ -204,6 +211,12 @@ engines_sample(struct drm_i915_private *dev_priv, unsigned
int period_ns)
if (val & RING_WAIT_SEMAPHORE)
Quoting Tvrtko Ursulin (2018-06-06 13:48:45)
> @@ -204,6 +211,12 @@ engines_sample(struct drm_i915_private *dev_priv,
> unsigned int period_ns)
> if (val & RING_WAIT_SEMAPHORE)
> add_sample(>pmu.sample[I915_SAMPLE_SEMA],
>
Quoting Zhenyu Wang (2018-06-06 10:49:54)
> On 2018.04.19 15:39:48 +0800, Zhenyu Wang wrote:
> >
> > Hi,
> >
> > Here's current gvt fixes for 4.17 with several kernel warning
> > and other misc fixes as detailed below.
> >
> > p.s: I'll be on vacation from next week till May 2, Zhi will cover
When we reach the magic value and do inject a fault into our module load,
mark the module option as being hit. Since we fail from inside pci
probe, the module load isn't actually aborted and the module (and
paramters) are left lingering. igt can then inspect the parameter on its
synchronous
== Series Details ==
Series: drm/i915: Apply batch location restrictions before pinning
URL : https://patchwork.freedesktop.org/series/44349/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9215 =
== Summary - WARNING ==
Minor unknown changes coming with
Wrong branch,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
The current method of checking for a failed module load is flawed, as we
only report the error on probing it is not being reported back by
modprobe. So we have to dig inside the module_parameters while the
module is still loaded to discover the error.
Signed-off-by: Chris Wilson
Cc: Michał
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b06088bd644c..12db7212d643 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
== Series Details ==
Series: drm/i915: Apply batch location restrictions before pinning
URL : https://patchwork.freedesktop.org/series/44349/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
724b818cad83 drm/i915: Apply batch location restrictions before pinning
-:30:
From: Tvrtko Ursulin
With the driver now exporting various request queue depths for each
engine, we can display this information here. Both as raw counters,
and by adding a load average like metrics composed from number of
runnable and running requests in a given time period. 1s, 30s and 5m
From: Tvrtko Ursulin
Basic tests to cover engine queued/runnable/running metric as reported
by the DRM_I915_QUERY_ENGINE_QUEUES query.
v2:
* Update ABI for i915 changes.
* Use igt_spin_busywait_until_running.
* Support no hardware contexts.
* More comments. (Lionel Landwerlin)
Chris
From: Tvrtko Ursulin
Simple tests to check reported queue depths are correct.
v2:
* Improvements similar to ones from i915_query.c.
Signed-off-by: Tvrtko Ursulin
---
tests/perf_pmu.c | 258 +++
1 file changed, 258 insertions(+)
diff --git
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests which have been
submitted from userspace but are not yet runnable due dependencies and
unsignaled fences.
This is useful to analyze the overall load of the system.
v2:
* Rebase for name change and re-order.
* Drop
From: Tvrtko Ursulin
Show total GPU loads in the window banner.
Engine load is defined as total of runnable and running requests on an
engine.
Total, non-normalized, load is display. In other words if N engines are
busy with exactly one request, the load will be shown as N.
v2:
* Different
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests currently executing
on the GPU.
This is useful to analyze the overall load of the system.
v2:
* Rebase.
* Drop floating point constant. (Chris Wilson)
v3:
* Change scale to 1024 for faster arithmetics. (Chris
From: Tvrtko Ursulin
Keep a count of requests submitted from userspace and not yet runnable due
unresolved dependencies.
v2: Rename and move under the container struct. (Chris Wilson)
v3: Rebase.
v4: Move decrement site to the backend to shrink the window of double-
accounting as much as
From: Tvrtko Ursulin
Use new PMU engine queue stats (queued, runnable and running) and display
them per engine.
v2:
* Compact per engine stats. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
---
overlay/gpu-top.c | 42 ++
overlay/gpu-top.h | 11
From: Tvrtko Ursulin
Temporary up to date uAPI headers.
Signed-off-by: Tvrtko Ursulin
---
include/drm-uapi/i915_drm.h | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index
From: Tvrtko Ursulin
Keep a per-engine number of runnable (waiting for GPU time) requests.
We choose to mange the runnable counter at the backend level instead of at
the request submit_notify callback. The latter would be more consolidated
and less code, but it would require making the counter
From: Tvrtko Ursulin
As well as exposing active requests on engines via PMU, we can also export
the current raw values (as tracked by i915 command submission) via a
dedicated query.
This is to satisfy customers who have userspace load balancing solutions
implemented on top of their custom
From: Tvrtko Ursulin
Tests for new PMU counters, new query and adding support to intel_gpu_top and
intel_gpu_overlay to show queue depths and GPU load average metric.
Tvrtko Ursulin (6):
include: i915 uAPI headers
intel-gpu-overlay: Add engine queue stats
intel-gpu-overlay: Show 1s, 30s
From: Tvrtko Ursulin
We add a PMU counter to expose the number of requests with resolved
dependencies waiting for a slot on the GPU to run.
This is useful to analyze the overall load of the system.
v2: Don't limit to gen8+.
v3:
* Rebase for dynamic sysfs.
* Drop currently executing
From: Tvrtko Ursulin
Per-engine queue depths are an interesting metric for analyzing the system load
and also for users who wish to use it to load balance their submissions based
on it.
In this version I have split the metrics into three separate counters:
1. QUEUED - From execbuf time to
From: Tvrtko Ursulin
Enable count array is supposed to have one counter for each possible
engine sampler. As such array sizing and bounds checking is not
correct when more engine samplers are added.
At the same time tidy the assert for readability and robustness.
Signed-off-by: Tvrtko Ursulin
We special case the position of the batch within the GTT to prevent
negative self-relocation deltas from underflowing. However, that
restriction is being applied after a trial pin of the batch in its
current position. Thus we are not rejecting an invalid location if the
batch has been before,
Quoting Michał Winiarski (2018-06-06 12:33:56)
> We'd like to start testing module load with fault injection. To avoid
> making any asumptions on number of available fault injection
> checkpoints (either in IGT or in i915), we can compute it at runtime and
> export it in debugfs.
Michał pointed
1 - 100 of 147 matches
Mail list logo
