On 06/06/18 10:02, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
A miminal hack to parse the new tracepoint format and invent new "ring
id's" based on engine class and instance.
v2:
* Make it a bit more future proof. (Lionel, Chris)
* Some assorted fixups to show forgotten engines.
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: e2ea2db1734a0e38b89e4d706b5f9ad9f73b1543
commit: 72041f9847abb05b9d4d7dea17631b579191ca99 [7/8] RFC: debugobjects:
capture stack traces at _init() time
config: alpha-allyesconfig (attached as .config)
compiler:
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,
== 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
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)
== Series Details ==
Series: series starting with [01/17] drm/i915/gtt: Invalidate GGTT caches after
writing the gen6 page directories (rev3)
URL : https://patchwork.freedesktop.org/series/44328/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4282_full ->
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: 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:
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 All,
So I'm working on making Linux boot in a complete
flickerfree manner (no modesets, no black
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],
>
Hi All,
So I'm working on making Linux boot in a complete
flickerfree manner (no modesets, no black screens).
I have this working on various machines with Intel
gfx, but I need to pass i915.fastboot=1 on the kernel
commandline.
I know there was some talk about enabling this by
default a while
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.
The idea was
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
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
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
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
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
Op 06-06-18 om 11:09 schreef Hans de Goede:
> Hi All,
>
> So I'm working on making Linux boot in a complete
> flickerfree manner (no modesets, no black screens).
>
> I have this working on various machines with Intel
> gfx, but I need to pass i915.fastboot=1 on the kernel
> commandline.
>
> I know
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 All,
>>>
>>> So I'm working on making Linux boot in a complete
>>> flickerfree manner (no modesets, no black screens).
>>>
>>> I have this working
On Thursday, May 17, 2018 3:21:13 PM PDT José Roberto de Souza wrote:
> This reduces the spaghetti that intel_dp_aux_xfer() and reuses code.
> The only difference is that now it will wait up to 10ms instead of
> 3ms.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto
== 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 -> Patchwork_9214 =
== Summary - WARNING ==
Minor unknown changes
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
Hi,
On 06-06-18 11:36, Maarten Lankhorst wrote:
Op 06-06-18 om 11:09 schreef Hans de Goede:
Hi All,
So I'm working on making Linux boot in a complete
flickerfree manner (no modesets, no black screens).
I have this working on various machines with Intel
gfx, but I need to pass i915.fastboot=1
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.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Imre Deak
Cc:
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
== 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.
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
On 06/06/2018 11:29, Lionel Landwerlin wrote:
On 06/06/18 10:02, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
A miminal hack to parse the new tracepoint format and invent new "ring
id's" based on engine class and instance.
v2:
* Make it a bit more future proof. (Lionel, Chris)
* Some
== Series Details ==
Series: drm/i915: Export number of fail injection checkpoints through debugfs
URL : https://patchwork.freedesktop.org/series/44347/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Export number of fail injection checkpoints through debugfs
== 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
---
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
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ł
== 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
== Series Details ==
Series: series starting with [01/17] drm/i915/gtt: Invalidate GGTT caches after
writing the gen6 page directories (rev3)
URL : https://patchwork.freedesktop.org/series/44328/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b4c3a32216a8 drm/i915/gtt:
== Series Details ==
Series: series starting with [01/17] drm/i915/gtt: Invalidate GGTT caches after
writing the gen6 page directories (rev3)
URL : https://patchwork.freedesktop.org/series/44328/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Invalidate GGTT
== Series Details ==
Series: series starting with [01/17] drm/i915/gtt: Invalidate GGTT caches after
writing the gen6 page directories (rev3)
URL : https://patchwork.freedesktop.org/series/44328/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9213 =
==
Hi Jani,
On Tue, Jun 05, 2018 at 11:18:46AM +0300, Jani Nikula wrote:
> On Tue, 05 Jun 2018, Feng Tang wrote:
> > Hi Jani,
> >
> > On Tue, Jun 05, 2018 at 10:41:04AM +0300, Jani Nikula wrote:
> >> On Mon, 04 Jun 2018, Feng Tang wrote:
> >> > i915 driver's probe is one of the longest of pci
Op 06-06-18 om 05:37 schreef Dave Airlie:
> On 26 April 2018 at 20:53, Maarten Lankhorst
> wrote:
>> Hi Dave,
>>
>> This is my first pull request for v4.18. Only UAPI change is adding a
>> generic plane
>> alpha property, which replaces the driver specific ones in sun4i, rcar-du
>> and
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 for me.
>
> Thanks
> --
Looks this one got missed for
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ++-
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
2 files changed, 7
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) free the unused ptes.
Signed-off-by: Chris Wilson
In order to be able to evict the gen6 ppgtt, we have to unpin it at some
point. We can simply use our context activity tracking to know when the
ppgtt is no longer in use by hardware, and so only keep it pinned while
being used a request.
For the kernel_context (and thus aliasing_ppgtt), it
Let's see if we have all the kinks worked out and full-ppgtt now works
reliably on gen7 (Ivybridge, Valleyview/Baytrail and Haswell). If we can
let userspace have full control over their own ppgtt, it makes softpinning
far more effective, in turn making GPU dispatch far more efficient and
more
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 as i915_vma_pin/insert/bind/unbind) to work
If we interrupt the context switch and unwind, we leave the to_mm
believing that we have cleared the dirty bit for this engine (but the
LRI will never take place). Just in case we immediately reload the same
context, mark this engine as dirty so that we force the LRI to reload
the PD.
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 directory into a first class and
unbindable vma. Hence, the
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 Lahtinen
Cc: Mika Kuoppala
Cc: Matthew Auld
---
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: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
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 contexts, we need to be more prudent
in our allocations,
If we know that the user cannot access the GGTT, by virtue of having a
segregated memory area, we can skip clearing the unused entries as they
cannot be accessed.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4
When we update the gen6 ppgtt page directories, we do so by writing the
new address into a reserved slot in the GGTT. It appears that when the
GPU reads that entry from the gsm, it uses its small cache and that we
need to invalidate that cache after writing. We don't see an issue
currently as we
The legacy gen6 ppgtt needs a little more hand holding than gen8+, and
so requires a larger structure. As I intend to make this slightly more
complicated in the future, separate the gen6 from the core gen8 hw
struct by subclassing. This patch moves the gen6 only features out to
gen6_hw_ppgtt and
To allow for future non-object backed vma, we need to be able to
specialise the callbacks for binding, et al, the vma. For example,
instead of calling vma->vm->bind_vma(), we now call
vma->ops->bind_vma(). This gives us the opportunity to later override the
operation for a custom vma.
v2: flip
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
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 Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Matthew
== Series Details ==
Series: series starting with [01/17] drm/i915/gtt: Invalidate GGTT caches after
writing the gen6 page directories
URL : https://patchwork.freedesktop.org/series/44328/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Invalidate GGTT caches
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 directory into a first class and
unbindable vma. Hence, the
== Series Details ==
Series: series starting with [01/17] drm/i915/gtt: Invalidate GGTT caches after
writing the gen6 page directories
URL : https://patchwork.freedesktop.org/series/44328/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4282 -> Patchwork_9212 =
== Summary -
In the next patch, we will subclass the gen6 hw_ppgtt. In order, for the
two different generations of hw ppgtt stucts to be of different size,
push the allocation down to the constructor.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Matthew Auld
Reviewed-by: Joonas
In today's edition, IGT should be happy; meaning we should have most of
the resource allocation issues licked, and that the gpu is indeed
switching mm between each context. Running piglit through it though, the
picture is a little more murky, as there are a few GPU hangs...
-Chris
== Series Details ==
Series: series starting with [01/17] drm/i915/gtt: Invalidate GGTT caches after
writing the gen6 page directories
URL : https://patchwork.freedesktop.org/series/44328/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a380c2fdd48d drm/i915/gtt: Invalidate
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 directory into a first class and
unbindable vma. Hence, the
On Wed, 06 Jun 2018, Feng Tang wrote:
> Hi Jani,
>
> On Tue, Jun 05, 2018 at 11:18:46AM +0300, Jani Nikula wrote:
>> On Tue, 05 Jun 2018, Feng Tang wrote:
>> > Hi Jani,
>> >
>> > On Tue, Jun 05, 2018 at 10:41:04AM +0300, Jani Nikula wrote:
>> >> On Mon, 04 Jun 2018, Feng Tang wrote:
>> >> >
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-06-05 17:03:57)
>> There is a problem with kbl up to rev E0 where a heavy
>> memory/fabric traffic from adjacent engine(s) can cause an engine
>> reset to fail. This traffic can be from normal memory accesses
>> or it can be from heavy polling
Quoting Mika Kuoppala (2018-06-06 09:40:11)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-06-05 17:03:57)
> >> There is a problem with kbl up to rev E0 where a heavy
> >> memory/fabric traffic from adjacent engine(s) can cause an engine
> >> reset to fail. This traffic can be from
From: Tvrtko Ursulin
A miminal hack to parse the new tracepoint format and invent new "ring
id's" based on engine class and instance.
v2:
* Make it a bit more future proof. (Lionel, Chris)
* Some assorted fixups to show forgotten engines.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
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 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: 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
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
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
== 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:
== 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
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: 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
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
== 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
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)
>
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
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: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
== 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:
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: 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
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
1 - 100 of 147 matches
Mail list logo
