When we introduced the saturated workload detection to tell us to back
off from semaphore usage [semaphores have a noticeable impact on
contended bus cycles with the CPU for some heavy workloads], we first
introduced it as a per-context tracker. This allows individual contexts
to try and optimise t
Now that atomic64_fetch_add() exists we can use it to return the base
context id, rather than the atomic64_add_return(N) - N concoction.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/dma-buf/dma-fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Now that we have fast timeslicing on semaphores, we no longer need to
prioritise none-semaphore work as we will yield any work blocked on a
sempahore to the next in the queue. Previously with no timeslicing,
blocking on the semaphore caused extremely bad scheduling with multiple
clients utilising m
This timeout is only used in one place, to provide a tiny bit of grace
for slow igt to cleanup after themselves. If we are a bit stricter and
opt to kill outstanding requsts rather than wait, we can speed up igt by
not waiting for 200ms after a hang.
Signed-off-by: Chris Wilson
---
drivers/gpu/d
Since there can only be one of in_fence/exec_fence, just use the single
in_fence local.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 24 ---
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbu
Be consistent, and even when we know we had used a WC, flush the mapped
object after writing into it. The flush understands the mapping type and
will only flush the WCB if I915_MAP_WC.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 8 ++--
drivers/g
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
Since we are using bitops on context_tag to allow us to reserve and
release inflight tags concurrently, the scan for the next bit is
intentionally racy.
[ 516.446854] BUG: KCSAN: data-race in execlists_schedule_in.isra.0 [i915] /
execlists_schedule_out [i915]
[ 516.446874]
[ 516.446886] write
Could our scheduling now be good enough that we avoid unnecessary
semaphores and do not waste bus cycles checking old results? Judging by
local runs of the examples from last year, possibly!
References: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated
systems")
Signed-off-by: Chr
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Link: https://gitlab.freed
The initial-breadcrumb is used to mark the end of the awaiting and the
beginning of the user payload. We verify that we do not start the user
payload before all signaler are completed, checking our semaphore setup
by looking for the initial breadcrumb being written too early. We also
want to ensure
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we
removed it from the
While this does not appear to fix any issues, the backend itself knows
when it wants to emit a breadcrumb, so let it make the final call.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 3 +--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 3 +--
2 files changed, 2
Just tidy up the return handling for completed dma-fences. While it may
return errors for invalid fence, we already know that we have a good
fence and the only error will be an already signaled fence.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 10 --
1 file ch
Since a few rearragements ago, we have an explicit reference to the
containing intel_context from inside the active reference and can drop
our own reference handling dancing around releasing the i915_active.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 8
1
We allow exported sync_file fences to be used as submit fences, but they
are not the only source of user fences. We also accept an array of
syncobj, and as with sync_file these are dma_fences underneath and so
feature the same set of controls. The submit-fence allows for a request
to be scheduled a
Be consistent and ensure that we always emit the asynchronous waits
prior to issuing instructions that use the address. This ensures that if
we do emit GPU commands to do the await, they are before our use!
Signed-off-by: Chris Wilson
---
.../drm/i915/gem/selftests/i915_gem_context.c | 49 ++
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854
Signe
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
These were used to set various timeouts for the reset procedure
(deciding when the engine was dead, and even if the reset itself was not
making forward progress). No longer used.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
1 file changed, 7 deletions(-)
diff --g
== Series Details ==
Series: series starting with [01/20] drm/i915/gt: Mark up the racy read of
execlists->context_tag
URL : https://patchwork.freedesktop.org/series/77141/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e9cce902ea86 drm/i915/gt: Mark up the racy read of execlis
My laptop (core m5-6y54) starts flickering after returning from Suspend
(to RAM) or other commands touching the video driver (xrandr, powertop
--calibrate, ...)
From kernel (tested with up to 5.7) I get the message:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO
underru
Change the basic pre-mergetest to do a single pass over all engines
simultaneously. This should take no longer than checking a single
engine, while providing just the right amount of stress regardless of
machine size.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ringfill.c | 10 +++
== Series Details ==
Series: series starting with [01/20] drm/i915/gt: Mark up the racy read of
execlists->context_tag
URL : https://patchwork.freedesktop.org/series/77141/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8461 -> Patchwork_17620
=
On Mon, 11 May 2020, "Manna, Animesh" wrote:
> On 08-05-2020 16:44, Maarten Lankhorst wrote:
>> Op 06-05-2020 om 15:11 schreef Animesh Manna:
>>> - struct intel_dsb *dsb = intel_dsb_get(crtc);
>>> + struct intel_dsb *dsb = (struct intel_dsb *)&crtc_state->dsb;
>> Why the cast? Unconstify crtc_
Hi Chris,
On Fri, 2020-05-08 at 18:54 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
> > static double nop_on_ring(int fd, uint32_t handle,
> > const struct intel_execution_engine2 *e, int
> > timeout,
> > - unsigne
Chris Wilson writes:
> Since we are using bitops on context_tag to allow us to reserve and
> release inflight tags concurrently, the scan for the next bit is
> intentionally racy.
Now it truely sinks in why you started with a full mask.
Reviewed-by: Mika Kuoppala
-Mika
>
> [ 516.446854] BU
No need to micro-optmize when we're waiting in a mocked object ...
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/st-dma-fence.c | 41 --
1 file changed, 41 deletions(-)
diff -
It's the default.
Also so much for "we're not going to tell the graphics people how to
review their code", dma_fence is a pretty core piece of gpu driver
infrastructure. And it's very much uapi relevant, including piles of
corresponding userspace protocols and libraries for how to pass these
aroun
It's the default.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_writeback.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeb
== Series Details ==
Series: series starting with [1/3] drm/writeback: don't set fence->ops to
default
URL : https://patchwork.freedesktop.org/series/77144/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9634e3eb3729 drm/writeback: don't set fence->ops to default
-:26: WARNING:
On 11-05-2020 14:19, Jani Nikula wrote:
On Mon, 11 May 2020, "Manna, Animesh" wrote:
On 08-05-2020 16:44, Maarten Lankhorst wrote:
Op 06-05-2020 om 15:11 schreef Animesh Manna:
- struct intel_dsb *dsb = intel_dsb_get(crtc);
+ struct intel_dsb *dsb = (struct intel_dsb *)&crtc_stat
We were using dev_*() to avoid having the drm subsystem impose it's
non-conventional and completely false '[drm]' tagging. Undo the damage.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 29 +++
d
Quoting Janusz Krzysztofik (2020-05-11 09:51:12)
> Hi Chris,
>
> On Fri, 2020-05-08 at 18:54 +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
> > > static double nop_on_ring(int fd, uint32_t handle,
> > > const struct intel_execution_engine
On Mon, May 11, 2020 at 09:21:41AM +0100, Chris Wilson wrote:
> Change the basic pre-mergetest to do a single pass over all engines
> simultaneously. This should take no longer than checking a single
> engine, while providing just the right amount of stress regardless of
> machine size.
>
> Signed
Hi all,
I've started this a while ago, with the idea to move shmem helpers over
to dma_resv_lock. Big prep work for that was to untangle the layering
between functions called by drivers, and functions used to implement
drm_gem_object_funcs.
I didn't ever get to the locking part, but I think the c
No real functional change, since this just converts an annoying Oops
into a more harmless WARNING backtrace. It's still a driver bug.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm
- Ditch the ->pages array
- Make it a private gem bo, which means no shmem object, which means
fireworks if anyone calls drm_gem_object_get_pages. But we've just
made sure that's all covered.
Cc: Gerd Hoffmann
Cc: Rob Herring
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu
Just a bit of light paranoia. Also sprinkle this check over
drm_gem_shmem_get_sg_table, which should only be called when
exporting, same for the pin/unpin functions, on which it relies to
work correctly.
Cc: Gerd Hoffmann
Cc: Rob Herring
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
dri
There's no direct harm, because for the shmem helpers these are noops
on imported buffers. The trouble is in the locks these take - I want
to change dma_buf_vmap locking, and so need to make sure that we only
ever take certain locks on one side of the dma-buf interface: Either
for exporters, or for
- Move the shmem helper section to the drm-mm.rst file, next to the
vram helpers. Makes a lot more sense there with the now wider scope.
Also, that's where the all the other backing storage stuff resides.
It's just the framebuffer helpers that should be in the kms helper
section.
- Try to
There's no direct harm, because for the shmem helpers these are noops
on imported buffers. The trouble is in the locks these take - I want
to change dma_buf_vmap locking, and so need to make sure that we only
ever take certain locks on one side of the dma-buf interface: Either
for exporters, or for
drm_gem_shmem_get_sg_table is meant to implement
obj->funcs->get_sg_table, for prime exporting. The one we want is
drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not
just native objects.
v2: Rebase, this stuff moved around in
commit 2f2aa13724d56829d910b2fa8e80c502d388f106
Auth
I honestly don't exactly understand what's going on here, but the
current code is wrong for sure: It calls dma_buf_vunmap without ever
calling dma_buf_vmap.
What I'm not sure about is whether the WARN_ON is correct:
- msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
a pretty
Currently this seems to work by converting the sgt into a pages array,
and then treating it like a native object. Do the right thing and
redirect mmap to the exporter.
With this nothing is calling get_pages anymore on imported dma-buf,
and we can start to remove the use of the ->pages array for th
On Mon, May 11, 2020 at 12:11 PM Daniel Vetter wrote:
>
> It's the default.
Thanks for catching that.
>
> Also so much for "we're not going to tell the graphics people how to
> review their code", dma_fence is a pretty core piece of gpu driver
> infrastructure. And it's very much uapi relevant, i
Quoting Petri Latvala (2020-05-11 10:31:49)
> On Mon, May 11, 2020 at 09:21:41AM +0100, Chris Wilson wrote:
> > Change the basic pre-mergetest to do a single pass over all engines
> > simultaneously. This should take no longer than checking a single
> > engine, while providing just the right amount
Change the basic pre-mergetest to do a single pass over all engines
simultaneously. This should take no longer than checking a single
engine, while providing just the right amount of stress regardless of
machine size.
v2: Move around the quiescence and requires to avoid calling them from
the child
Quoting Daniel Vetter (2020-05-11 10:11:41)
> No need to micro-optmize when we're waiting in a mocked object ...
It's setting up the expected return values for the test.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.free
== Series Details ==
Series: series starting with [1/3] drm/writeback: don't set fence->ops to
default
URL : https://patchwork.freedesktop.org/series/77144/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8461 -> Patchwork_17621
=
And just FYI, the driver was written internally at 2016-17, where the
dma-buf module didn't check the .wait ops before calling it and that's
why the initialization of the default wait was there in the first
place.
I should have removed it when I upstreamed it but it missed my review.
Thanks,
Oded
== Series Details ==
Series: drm/i915/gt: Restore pristine per-device user messages
URL : https://patchwork.freedesktop.org/series/77145/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9e3c95d954fd drm/i915/gt: Restore pristine per-device user messages
-:202: CHECK:PARENTHESIS_A
On Mon, May 11, 2020 at 10:39:24AM +0100, Chris Wilson wrote:
> Change the basic pre-mergetest to do a single pass over all engines
> simultaneously. This should take no longer than checking a single
> engine, while providing just the right amount of stress regardless of
> machine size.
>
> v2: Mo
Quoting Petri Latvala (2020-05-11 10:49:10)
> On Mon, May 11, 2020 at 10:39:24AM +0100, Chris Wilson wrote:
> > Change the basic pre-mergetest to do a single pass over all engines
> > simultaneously. This should take no longer than checking a single
> > engine, while providing just the right amount
On Mon, May 11, 2020 at 10:53:58AM +0100, Chris Wilson wrote:
> Quoting Petri Latvala (2020-05-11 10:49:10)
> > On Mon, May 11, 2020 at 10:39:24AM +0100, Chris Wilson wrote:
> > > Change the basic pre-mergetest to do a single pass over all engines
> > > simultaneously. This should take no longer th
On Mon, May 11, 2020 at 10:41:03AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-11 10:11:41)
> > No need to micro-optmize when we're waiting in a mocked object ...
>
> It's setting up the expected return values for the test.
Drat, I suspect something like that but didn't spot it. K
Change the basic pre-mergetest to do a single pass over all engines
simultaneously. This should take no longer than checking a single
engine, while providing just the right amount of stress regardless of
machine size.
v2: Move around the quiescence and requires to avoid calling them from
the child
Commit fb5970da1b42 ("drm/i915/gt: Use the kernel_context to measure the
breadcrumb size") removed the last external user for intel_timeline_init.
Mark it static.
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 8
drivers/gpu/drm/i9
On Mon, Apr 27, 2020 at 08:22:47PM -0700, Francisco Jerez wrote:
> This addresses the technical concerns people brought up about my
> previous v2 revision of this series. Other than a few bug fixes, the
> only major change relative to v2 is that the controller is now exposed
> as a new CPUFREQ gen
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> - Move the shmem helper section to the drm-mm.rst file, next to the
> vram helpers. Makes a lot more sense there with the now wider scope.
> Also, that's where the all the other backing storage stuff resides.
> It's just the framebuffer helpers
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> There's no direct harm, because for the shmem helpers these are noops
> on imported buffers. The trouble is in the locks these take - I want
> to change dma_buf_vmap locking, and so need to make sure that we only
> ever take certain locks on one sid
Chris Wilson writes:
> The initial-breadcrumb is used to mark the end of the awaiting and the
> beginning of the user payload. We verify that we do not start the user
> payload before all signaler are completed, checking our semaphore setup
> by looking for the initial breadcrumb being written to
Quoting Mika Kuoppala (2020-05-11 12:21:55)
> Chris Wilson writes:
>
> > The initial-breadcrumb is used to mark the end of the awaiting and the
> > beginning of the user payload. We verify that we do not start the user
> > payload before all signaler are completed, checking our semaphore setup
>
== Series Details ==
Series: shmem helper untangling
URL : https://patchwork.freedesktop.org/series/77146/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
28f8f1b12090 drm/msm: Don't call dma_buf_vunmap without _vmap
-:47: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line b
Chris Wilson writes:
> Just tidy up the return handling for completed dma-fences. While it may
> return errors for invalid fence, we already know that we have a good
> fence and the only error will be an already signaled fence.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
On Mon, May 11, 2020 at 01:23:38PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > There's no direct harm, because for the shmem helpers these are noops
> > on imported buffers. The trouble is in the locks these take - I want
> > to change dma_buf_vmap lock
On Thu, May 07, 2020 at 05:41:25PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The correct sequence according to bspec is to wait for the ACT sent
> status before we turn on the pipe. Make it so.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/
== Series Details ==
Series: shmem helper untangling
URL : https://patchwork.freedesktop.org/series/77146/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8462 -> Patchwork_17623
Summary
---
**SUCCESS**
No regressio
Hi
Am 11.05.20 um 13:37 schrieb Daniel Vetter:
> On Mon, May 11, 2020 at 01:23:38PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
>>> There's no direct harm, because for the shmem helpers these are noops
>>> on imported buffers. The trouble is in the locks
On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi wrote:
> >
> > On Fri, Apr 17, 2020 at 09:28:34PM +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 17, 2020 at 08:10:26PM +0200, Daniel Vetter wrote:
> > > > On Fri, Apr 17, 2020 at 5:43 PM Vi
On Mon, May 11, 2020 at 2:37 PM Ville Syrjälä
wrote:
>
> On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> > On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi wrote:
> > >
> > > On Fri, Apr 17, 2020 at 09:28:34PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Apr 17, 2020 at 08:10:26PM +020
On Thu, May 07, 2020 at 06:46:17PM -0400, Lyude Paul wrote:
> On Thu, 2020-04-30 at 02:37 +, Lee, Shawn C wrote:
> > On Sat, 2020-04-25, Lyude Paul wrote:
> > > Hi! Sorry this took me a little while to get back to, I had a couple of
> > > MST regressions that I had to look into
> > >
> > > On
On Mon, May 11, 2020 at 02:41:13PM +0200, Daniel Vetter wrote:
> On Mon, May 11, 2020 at 2:37 PM Ville Syrjälä
> wrote:
> >
> > On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> > > On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi
> > > wrote:
> > > >
> > > > On Fri, Apr 17, 2020 at 09
== Series Details ==
Series: drm/i915: Make intel_timeline_init static
URL : https://patchwork.freedesktop.org/series/77149/
State : failure
== Summary ==
Applying: drm/i915: Make intel_timeline_init static
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/gt/intel_ti
Be consistent, and even when we know we had used a WC, flush the mapped
object after writing into it. The flush understands the mapping type and
will only clflush if !I915_MAP_WC, but will always insert a wmb [sfence]
so that we can be sure that all writes are visible.
v2: Add the unconditional wm
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rend
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 70f5f82da288..68f503cf6284 100644
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
The lock here should be interruptible, so we can backoff if needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i91
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
[mlankhorst: Adjusted for reloc_gpu_flush() changes]
Cc: Chris Wilson
Cc: Matthew
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
== Series Details ==
Series: shmem helper untangling
URL : https://patchwork.freedesktop.org/series/77146/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8462_full -> Patchwork_17623_full
Summary
---
**SUCCESS**
No
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/g
My laptop (core m5-6y54) starts flickering after returning from Suspend
(to RAM) or other commands touching the video driver (xrandr ...)
From kernel (tested with up to 5.7) I get the message:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO
underrun
I added a bug with m
1 - 100 of 138 matches
Mail list logo
