completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris
completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris
We emit a store on each GPU after loading the module to confirm the
basic liveness of command submission. Trim away some of the chaff.
Signed-off-by: Chris Wilson
Cc: Ramalingam C
---
tests/i915/i915_module_load.c | 146 ++
1 file changed, 58 insertions(+), 88
completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris
Wait for the GPU to wake up from the semaphore before measuring the
time, so that we coordinate the sampling on both the CPU and GPU for
more accurate comparisons.
Reported-by: Bruce Chang
Signed-off-by: Chris Wilson
Cc: CQ Tang
---
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 4 +++-
1
Check that we have actually passed the heartbeat interval since last
checking the request before resetting the device.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2780
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 11
Use the defaults we store on the engine when resetting the heartbeat as
we may have had to adjust it from the config value during initialisation.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
.../gpu/drm/i915/gt/selftest_engine_heartbeat.c| 14 ++
1 file changed
Quoting Tvrtko Ursulin (2021-02-04 15:28:30)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > Whether the scheduler depends on interrupt delivery for forward progress
> > is a property of the scheduler backend not of the underlying engine, so
> > move the fla
Quoting Tvrtko Ursulin (2021-02-04 15:18:31)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > Whether a scheduler chooses to implement timeslicing is up to it, and
> > not an underlying property of the HW engine. The scheduler does depend
> > on the HW supporting pr
Quoting Tvrtko Ursulin (2021-02-04 15:14:20)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > Start extracting the scheduling flags from the engine. We begin with its
> > own existence.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/
Quoting Tvrtko Ursulin (2021-02-04 14:30:18)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > Since finding the currently active request starts by walking the
> > scheduler lists under the scheduler lock, move the routine to the
> > scheduler.
> >
&
Quoting Tvrtko Ursulin (2021-02-04 14:13:17)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > @@ -28,6 +28,15 @@ struct i915_sched {
> >
> > unsigned long mask; /* available scheduling channels */
> >
> > + /*
> > + * Pass the re
Quoting Tvrtko Ursulin (2021-02-04 14:09:22)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > Kick the scheduler to allow it to see the timeslice duration change,
> > don't peek into execlists.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > dr
Quoting Mika Kuoppala (2021-02-04 12:57:46)
> Chris Wilson writes:
>
> > Check that we have actually passed the heartbeat interval since last
> > checking the request before resetting the device.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues
;
> Signed-off-by: Matthew Auld
That is a lot easier to read,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
y: Matthew Auld
Straightforward,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Register with /proc/gpu to provide the client runtimes for generic
top-like overview, e.g. gnome-system-monitor can use this information to
show the per-process multi-GPU usage.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gt/intel_gt.c
that would show the GPU% on/next the CPU overview.
Then we could have a futher expansion of a GPU% into per-channel
utilisation. That would be useful to check to see what is saturating a
particular channel, e.g. find the video decoder bottleneck.
Signed-off-by: Chris Wilson
---
fs/proc/Makefile
Use the pid to find associated clients, and report their runtime. This
will be used to provide the information via procfs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drm_client.c | 70 +++---
drivers/gpu/drm/i915/i915_drm_client.h | 12 +++--
2 files changed
Quoting Chris Wilson (2021-02-04 11:18:29)
> Quoting Tvrtko Ursulin (2021-02-04 11:07:07)
> >
> >
> > On 01/02/2021 08:56, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > > b/drivers/gpu/drm/i915/gt/i
Quoting Tvrtko Ursulin (2021-02-04 11:19:00)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > @@ -252,10 +242,6 @@ struct intel_engine_execlists {
> >*/
> > int queue_priority_hint;
> >
> > - /**
> > - * @q
Quoting Tvrtko Ursulin (2021-02-04 11:19:00)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > bool intel_engine_is_idle(struct intel_engine_cs *engine)
> > {
> > + struct i915_sched *se = intel_engine_get_scheduler(engine);
>
> What do you ha
Quoting Tvrtko Ursulin (2021-02-04 11:07:07)
>
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index b56e321ef003..280d84c4e4b7 100644
>
Check that we have actually passed the heartbeat interval since last
checking the request before resetting the device.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2780
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 11 ++-
1 file changed
completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris
Use the defaults we store on the engine when resetting the heartbeat as
we may have had to adjust it from the config value during initialisation.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/selftest_engine_heartbeat.c| 14 ++
1 file changed, 10 insertions(+), 4 deletions
Use the defaults we store on the engine when resetting the heartbeat as
we may have had to adjust it from the config value during initialisation.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/selftest_engine_heartbeat.c| 14 ++
1 file changed, 10 insertions(+), 4 deletions
completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris
completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris
Use the defaults we store on the engine when resetting the heartbeat as
we may have had to adjust it from the config value during initialisation.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/selftest_engine_heartbeat.c | 17 -
1 file changed, 12 insertions(+), 5 deletions
completion check to
accommodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
v2: Attach a callback to flush the work immediately upon the heartbeat
completion and insert the delay before the next.
Suggested-by: CQ Tang
Signed-off-by: Chris
completion check to
accomodate that and avoid checking too early (before we've had a chance
to handle any engine resets required).
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 32 +++
1 file changed, 32 insertions(+)
diff
Quoting Tvrtko Ursulin (2021-02-03 13:12:05)
>
> On 03/02/2021 11:00, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2021-02-03 10:31:04)
> >>
> >> On 01/02/2021 12:07, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2021-02-01 11:57:56)
> &g
,
the memoization of how far we had progressed down a branch was
forgotten. The result was that instead of running in linear time, it was
running in geometric time and could easily run for a few hundred
milliseconds given a wide enough graph, not the microseconds as required.
Signed-off-by: Chris Wilson
Reviewed
As a topological sort, we expect it to run in linear graph time,
O(V+E). In removing the recursion, it is no longer a DFS but rather a
BFS, and performs as O(VE). Let's demonstrate how bad this is with a few
examples, and build a few test cases to verify a potential fix.
Signed-off-by: Chris
the entire multi-engine priority inheritance depth-first search,
to a smaller lock on each engine around a single list on that engine.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3
In the process of preparing to reuse the request submission logic for
other backends, lift it out of the execlists backend. It already
operates on the common structs, so just a matter of moving and renaming.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt
In the process of preparing to reuse the request submission logic for
other backends, lift it out of the execlists backend.
While this operates on the common structs, we do have a bit of backend
knowledge, which is harmless for !lrc but still unsightly.
Signed-off-by: Chris Wilson
Reviewed
Make the ability to suspend and resume a request and its dependents
generic.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 167 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 8 +-
drivers/gpu/drm/i915
Lift the ability to defer a request until later from execlists into the
common layer.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 57 +++--
drivers/gpu/drm/i915/i915_scheduler.c | 63
oal.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_display.c | 5 ++-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 5 ++-
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 29 +---
drivers/gpu/drm/i915/gt/intel_engine_cs.c |
Exercise rescheduling priority inheritance around a sequence of requests
that wrap around all the engines.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/i915_scheduler.c | 215 ++
1 file changed, 215 insertions(+)
diff --git a/drivers
uld prefer to handle an EWOULDBLOCK error instead. In both
cases we need to propagate the flag to various blocking wait points, the
first and usually hit is intel_ring::wait_for_space().
Testcase: igt/gem_ctx_ringsize/spin
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffe
uld prefer to handle an EWOULDBLOCK error instead. In both
cases we need to propagate the flag to various blocking wait points, the
first and usually hit is intel_ring::wait_for_space().
Testcase: igt/gem_ctx_ringsize/spin
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffe
.c
> +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> @@ -90,8 +90,6 @@ region_lmem_init(struct intel_memory_region *mem)
> if (ret)
> io_mapping_fini(>iomap);
>
> - intel_memory_region_set_name(mem, "local");
Ok. So in gt_probe_lmem we set up the struct, a
1)
Too subtle. Leave a line between the different GTT.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
at
shouldn't be there :(
[Hmm. We broke alphabetical ordering.]
> #include "gen6_ppgtt.h"
> #include "gen8_ppgtt.h"
>
> @@ -192,6 +193,8 @@ void ppgtt_bind_vma(struct i915_address_space *vm,
> pte_flags = 0;
> if (i915_gem_object_is_readonly(vma->obj))
> pte_flags |= PTE_READ_ONLY;
> + if (i915_gem_object_is_lmem(vma->obj))
> + pte_flags |= PTE_LM;
>
> vm->insert_entries(vm, vma, cache_level, pte_flags);
> wmb();
Just nits,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
uld prefer to handle an EWOULDBLOCK error instead. In both
cases we need to propagate the flag to various blocking wait points, the
first and usually hit is intel_ring::wait_for_space().
Testcase: igt/gem_ctx_ringsize/spin
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffe
Quoting Matthew Auld (2021-02-03 12:11:18)
> The vm insert_page is useful to insert a vma-less page into the GGTT,
> which so far is always to map something through the mappable aperture,
> usually when the entire VMA doesn't fit, or if we specifically don't
> want to hog it, since it's generally
client_cmp = client_total_cmp;
> - header_msg = "Sorting clients by accummulated GPU usage.";
> - break;
> - case 2:
> - client_cmp = client_id_cmp;
> - header_msg = "Sorting clients by sysfs id.";
> - }
&g
printf(" >>> %s\n", header_msg);
> + header_msg = NULL;
I was just about to ask if we showed it once, then cleared it 1s later.
Reviewed-by: Chris Wilson
> + } else {
> +
ejas Upadhyay
We now have a system in CI and that appears quite promising,
Acked-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Since we setup the submission method for the engines once, it is easy to
assign an enum and use that instead of probing into the backends.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++-
drivers/gpu/drm/i915/gt
oal.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_display.c | 5 ++-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 5 ++-
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 29 +---
drivers/gpu/drm/i915/gt/intel_engine_cs.c |
is always justified; put a barrier on
updating the irq handler so that we know that the next interrupt will
be redirected towards ourselves.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 ++
drivers/gpu/drm/i915/gt
Make the ability to suspend and resume a request and its dependents
generic.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 167 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 8 +-
drivers/gpu/drm/i915
In the process of preparing to reuse the request submission logic for
other backends, lift it out of the execlists backend.
While this operates on the common structs, we do have a bit of backend
knowledge, which is harmless for !lrc but still unsightly.
Signed-off-by: Chris Wilson
Reviewed
As a topological sort, we expect it to run in linear graph time,
O(V+E). In removing the recursion, it is no longer a DFS but rather a
BFS, and performs as O(VE). Let's demonstrate how bad this is with a few
examples, and build a few test cases to verify a potential fix.
Signed-off-by: Chris
In the process of preparing to reuse the request submission logic for
other backends, lift it out of the execlists backend. It already
operates on the common structs, so just a matter of moving and renaming.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt
the entire multi-engine priority inheritance depth-first search,
to a smaller lock on each engine around a single list on that engine.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3
,
the memoization of how far we had progressed down a branch was
forgotten. The result was that instead of running in linear time, it was
running in geometric time and could easily run for a few hundred
milliseconds given a wide enough graph, not the microseconds as required.
Signed-off-by: Chris Wilson
Reviewed
Lift the ability to defer a request until later from execlists into the
common layer.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 57 +++--
drivers/gpu/drm/i915/i915_scheduler.c | 63
Exercise rescheduling priority inheritance around a sequence of requests
that wrap around all the engines.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/i915_scheduler.c | 215 ++
1 file changed, 215 insertions(+)
diff --git a/drivers
-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 46 -
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 --
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 50 ---
3 files changed, 44 insertions(+), 56 deletions
e only functional difference of
> eliminating two subsequent scans with no sort in between This closes a
> very short window there list iteration could get confused if sysfs clients
> would change rapidly and unfavourably during tool startup.
>
> Signed-off-by: Tvrtko
Quoting Tvrtko Ursulin (2021-02-03 10:31:04)
>
> On 01/02/2021 12:07, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2021-02-01 11:57:56)
> >> From: Tvrtko Ursulin
> >>
> >> Slight improvement with regards to wrapping header components to fit
> >
Quoting Ville Syrjälä (2021-02-03 09:00:54)
> On Wed, Feb 03, 2021 at 08:38:41AM +0000, Chris Wilson wrote:
> > Currently, we allocate exactly the VMA requested for the framebuffer and
> > rely on filling the whole of the GGTT with scratch pages to catch when
> > VT-d prefetc
Since the vma's backing store is flushed upon first creation, remove the
manual calls to set-to-gtt-domain.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/i915_gem_mman.c | 16
drivers/gpu/drm/i915/selftests/i915_vma.c| 6
Let's prefer to use explicit request tracking and bounded timeouts in
our selftests.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gt/selftest_workarounds.c| 106 +++---
1 file changed, 40 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm
In construction the rpcs_query batch we know that it is device coherent
and ready for execution, the set-to-gtt-domain here is redudant.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 --
1 file changed, 2 deletions(-)
diff
After the memory-region test completes, it flushes the test by calling
set-to-cpu-domain. Use the igt_flush_test as it includes a timeout,
recovery and reports and error for miscreant tests.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests
Instead of manipulating the object's cache domain, just use the device
coherent map to write the batch buffer.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../drm/i915/gem/selftests/i915_gem_context.c| 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff
Only perform the domain transition under the object lock, and push the
required waits to outside the lock.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 9 +-
drivers/gpu/drm/i915/gem/i915_gem_clflush.h | 2 -
drivers/gpu/drm
.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../i915/gem/selftests/i915_gem_client_blt.c | 26 ++-
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests
Set the cache coherency and status using the set-coherency helper.
Otherwise, we forget to mark the new pages as cache dirty.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 14 +-
1 file changed, 5 insertions(+), 9
-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 18 -
drivers/gpu/drm/i915/gt/intel_ggtt.c | 23 --
2 files changed, 13 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem
is always justified; put a barrier on
updating the irq handler so that we know that the next interrupt will
be redirected towards ourselves.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 ++
drivers/gpu/drm/i915/gt
Since we setup the submission method for the engines once, it is easy to
assign an enum and use that instead of probing into the backends.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++-
drivers/gpu/drm/i915/gt
is always justified; put a barrier on
updating the irq handler so that we know that the next interrupt will
be redirected towards ourselves.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 ++
drivers/gpu/drm/i915/gt
-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 46 -
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 --
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 50 ---
3 files changed, 44 insertions(+), 56 deletions
From: Takashi Iwai
On Tue, 02 Feb 2021 17:30:36 +0100,
Chris Wilson wrote:
>
> commit 2d670ea2bd53 ("ALSA: jack: implement software jack injection via
> debugfs") is causing issues for our CI as we see a use-after-free on
> module unload (on all machines):
>
> http
is always justified; put a barrier on
updating the irq handler so that we know that the next interrupt will
be redirected towards ourselves.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 ++
drivers/gpu/drm/i915/gt
In the process of preparing to reuse the request submission logic for
other backends, lift it out of the execlists backend. It already
operates on the common structs, so just a matter of moving and renaming.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt
-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 46 -
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 --
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 50 ---
3 files changed, 44 insertions(+), 56 deletions
Since we setup the submission method for the engines once, it is easy to
assign an enum and use that instead of probing into the backends.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 8 +++-
drivers/gpu/drm/i915/gt
In the process of preparing to reuse the request submission logic for
other backends, lift it out of the execlists backend.
While this operates on the common structs, we do have a bit of backend
knowledge, which is harmless for !lrc but still unsightly.
Signed-off-by: Chris Wilson
Reviewed
Exercise rescheduling priority inheritance around a sequence of requests
that wrap around all the engines.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/selftests/i915_scheduler.c | 225 ++
1 file changed, 225 insertions(+)
diff --git a/drivers
oal.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_display.c | 5 ++-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 5 ++-
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 29 +---
drivers/gpu/drm/i915/gt/intel_engine_cs.c |
As a topological sort, we expect it to run in linear graph time,
O(V+E). In removing the recursion, it is no longer a DFS but rather a
BFS, and performs as O(VE). Let's demonstrate how bad this is with a few
examples, and build a few test cases to verify a potential fix.
Signed-off-by: Chris
Make the ability to suspend and resume a request and its dependents
generic.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 167 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 8 +-
drivers/gpu/drm/i915
the entire multi-engine priority inheritance depth-first search,
to a smaller lock on each engine around a single list on that engine.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 3
,
the memoization of how far we had progressed down a branch was
forgotten. The result was that instead of running in linear time, it was
running in geometric time and could easily run for a few hundred
milliseconds given a wide enough graph, not the microseconds as required.
Signed-off-by: Chris Wilson
Reviewed
Lift the ability to defer a request until later from execlists into the
common layer.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../drm/i915/gt/intel_execlists_submission.c | 57 +++--
drivers/gpu/drm/i915/i915_scheduler.c | 63
Quoting Chris Wilson (2021-02-02 21:24:16)
> Quoting Chris Wilson (2021-02-02 21:14:35)
> > Quoting Chris Wilson (2021-02-02 17:43:53)
> > > Let's see how horrible it is to cycle elements on defer. (Curse the
> > > irqlock pollution.)
> >
> > While that did
Quoting Chris Wilson (2021-02-02 21:14:35)
> Quoting Chris Wilson (2021-02-02 17:43:53)
> > Let's see how horrible it is to cycle elements on defer. (Curse the
> > irqlock pollution.)
>
> While that did work. I do not have a good idea on how to do list
> rotation o
From: Takashi Iwai
On Tue, 02 Feb 2021 17:30:36 +0100,
Chris Wilson wrote:
>
> commit 2d670ea2bd53 ("ALSA: jack: implement software jack injection via
> debugfs") is causing issues for our CI as we see a use-after-free on
> module unload (on all machines):
>
> http
From: Takashi Iwai
On Tue, 02 Feb 2021 17:30:36 +0100,
Chris Wilson wrote:
>
> commit 2d670ea2bd53 ("ALSA: jack: implement software jack injection via
> debugfs") is causing issues for our CI as we see a use-after-free on
> module unload (on all machines):
>
> http
From: Joonas Lahtinen
---
integration-manifest | 40
1 file changed, 40 insertions(+)
create mode 100644 integration-manifest
diff --git a/integration-manifest b/integration-manifest
new file mode 100644
index ..d80099bceaa5
--- /dev/null
From: Jani Nikula
This reverts commit 211e5db19d15a721b2953ea54b8f26c2963720eb.
---
drivers/rtc/rtc-cmos.c | 8
drivers/rtc/rtc-mc146818-lib.c | 7 ---
2 files changed, 15 deletions(-)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index
Quoting Chris Wilson (2021-02-02 17:43:53)
> Let's see how horrible it is to cycle elements on defer. (Curse the
> irqlock pollution.)
While that did work. I do not have a good idea on how to do list
rotation on an RCU list. I can see that it must require a pair of
synchroni
201 - 300 of 40210 matches
Mail list logo
