== Series Details ==
Series: series starting with [01/22] drm/i915: Allow some leniency in PCU reads
URL : https://patchwork.freedesktop.org/series/76885/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8415 -> Patchwork_17561
== Series Details ==
Series: series starting with [01/22] drm/i915: Allow some leniency in PCU reads
URL : https://patchwork.freedesktop.org/series/76885/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5d6d17a06111 drm/i915: Allow some leniency in PCU reads
90bde0818b4c drm/i915
In preparation for making eb_vma bigger and heavy to run inn parallel,
we need to stop apply an in-place swap() to reorder around ww_mutex
deadlocks. Keep the array intact and reorder the locks using a dedicated
list.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the async binding pipeline.
Signed-off-by: Chris
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
We only need the device wakeref on freeing the objects if we have to
unbind the object from the global GTT, or otherwise update device
information. If the objects are clean, we never need the wakeref, so
avoid taking until required.
Signed-off-by: Chris Wilson
Cc: Janusz Krzysztofik
---
drivers
It is reasonably common for userspace (even modern drivers like iris) to
reuse an active address for a new buffer. This would cause the
application to stall under its mutex (originally struct_mutex) until the
old batches were idle and it could synchronously remove the stale PTE.
However, we can que
Repeat the measurement of the clock frequency a few times and use the
median to try and reduce the systematic measurement error.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 54 +++---
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a
As we only restore the default context state upon banning a context, we
only need enough of the state to run the ring and nothing more. That is
we only need our bare protocontext.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel
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
Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig
option, primarily to allow brave systems to disable the timeout and
solely rely on correct signaling.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.profile | 12
dri
The older arches did not convert MI_STORE_DATA_IMM to using the GTT, but
left them writing to a physical address. The notes suggest that the
primary reason would be so that the writes were cache coherent, as the
CPU cache uses physical tagging. As such we did not implement the
legacy variant of MI_
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
Currently, if an error is raised we always call the cleanup locally
[and skip the main work callback]. However, some future users may need
to take a mutex to cleanup and so we cannot immediately execute the
cleanup as we may still be in interrupt context.
With the execute-immediate flag, for most
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
Allocate a few dma fence context id that we can use to associate async work
[for the CPU] launched on behalf of this context. For extra fun, we allow
a configurable concurrency width.
A current example would be that we spawn an unbound worker for every
userptr get_pages. In the future, we wish to
It is required that a chained batch be in the same address domain as its
parent, and also that must be specified in the command for earlier gen
as it is not inferred from the chaining until gen6.
Fixes: 964a9b0f611e ("drm/i915/gem: Use chained reloc batches")
Signed-off-by: Chris Wilson
---
driv
Use a local to shrink a line under 80 columns, and refactor the common
emit_xcs_breadcrumb() wrapper of ggtt-write.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 +
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/
Extend the timeout for pcode reads to 10ms as they should not be
performed along critical paths, and succeeding after a short delay is
better than failing entirely.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1800
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_sideb
Sometimes we have to be very careful not to allocate underneath a mutex
(or spinlock) and yet still want to track activity. Enter
i915_active_acquire_for_context(). This raises the activity counter on
i915_active prior to use and ensures that the fence-tree contains a slot
for the context.
Signed-
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in paral
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
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
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
== Series Details ==
Series: series starting with [01/14] drm/i915/gem: Specify address type for
chained reloc batches (rev2)
URL : https://patchwork.freedesktop.org/series/76876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8414_full -> Patchwork_17556_full
Quoting Mika Kuoppala (2020-04-30 16:47:35)
> Request boundary is a global observation point for
> all operations. Thus flush the LLC too.
>
> Signed-off-by: Mika Kuoppala
This one always concerned me for being unbounded in cost: flush all the
LLC lines that might be framebuffer.
We don't mix s
Quoting Mika Kuoppala (2020-04-30 16:47:34)
> Treat media state as any other state and invalidate it.
>
> Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop
Quoting Mika Kuoppala (2020-04-30 16:47:33)
> Flush enable bit is a sync point which makes this
> pipecontrol to wait that everything on a previous
> pipe control are flushed. Enable it to make
> sure that our invalidates doesn't overlap.
Not sold. We terminated the previous context with a seriali
Quoting Mika Kuoppala (2020-04-30 16:47:32)
> Aim for completeness for invalidating everything
> and mark state pointers stale.
>
> Signed-off-by: Mika Kuoppala
There's a confusing mention that the indirect state pointers are not
saved in the context... But we still need to invalidate if we rebi
Quoting Mika Kuoppala (2020-04-30 16:47:31)
> To ensure that we have global observation point wrt to
> all data, flush amfs.
>
> Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
Quoting Mika Kuoppala (2020-04-30 16:47:30)
> Flush TDL and L3.
>
> Signed-off-by: Mika Kuoppala
That's very misnamed bit!
There's a comment that this must be paired with the corresponding pc in
the same HW dispatch.
-Chris
___
Intel-gfx mailing list
Quoting Mika Kuoppala (2020-04-30 16:47:29)
> Do a l3 fabric flush when emitting flush.
It's quoted as being a debug bit, and that the L3 flush is a part of the
post-sync op.
Not sure if we want this without being told we must, or reason to
believe we do.
> Signed-off-by: Mika Kuoppala
> ---
>
== Series Details ==
Series: drm/i915: Avoid using simd from interrupt context
URL : https://patchwork.freedesktop.org/series/76882/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8415 -> Patchwork_17560
Summary
---
*
Quoting Mika Kuoppala (2020-04-30 16:47:28)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index b3cf09657fb2..534e435f20bc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands
Quoting Mika Kuoppala (2020-04-30 16:47:27)
> This reverts commit 62037229b7d94f1db5ef8d2e2ec819832ef3.
>
> L3 ro cache invalidation is part of the dword0 of pipe
> control.
True.
> Also it is not relevant to this gen.
?
> Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
-Chris
___
== Series Details ==
Series: series starting with [1/3] drm/i915: Remove trace_i915_gem_object_fault
URL : https://patchwork.freedesktop.org/series/76881/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8415 -> Patchwork_17559
Query whether or not we are in a legal context for using SIMD, before
using SSE4.2 registers.
Suggested-by: Jason A. Donenfeld
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_memcpy.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c
b/drivers
Quoting Jason A. Donenfeld (2020-04-30 23:10:16)
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something slower in the unlikely
Quoting Christoph Hellwig (2020-05-01 19:07:31)
> On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for ma
These pair provide no insight into the driver, are extremely rare in
userspace and only capture the same information as can be gathered from
looking at the syscalls [ioctl].
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4
drivers/gpu/drm/i915/i915_trace.h | 40 --
The tracepoint is only covering one of the possible fault handlers;
clearly no longer of interest.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 --
drivers/gpu/drm/i915/i915_trace.h| 25
2 files changed, 27 deletions(-)
diff --gi
The eviction tracepoints are an odd mismash in the middle of the
bind/unbind sequence. I added them primarily to try and tell why a spate
of unbinds occurred, but in reality they were just noise and not
information or instrumental in refining code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm
== Series Details ==
Series: drm/i915/display: Warn if the FBC is still writing to stolen on removal
URL : https://patchwork.freedesktop.org/series/76880/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8414 -> Patchwork_17558
Quoting Mika Kuoppala (2020-04-30 16:47:28)
> HDC pipeline flush is bit on the first dword of
> the PIPE_CONTROL, not the second. Make it so.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 23 +++
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h
== Series Details ==
Series: drm/i915/gem: Lazily acquire the device wakeref for freeing objects
(rev2)
URL : https://patchwork.freedesktop.org/series/76440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8414 -> Patchwork_17557
If the FBC is still writing into stolen, it will overwrite any future
users of that stolen region. Check before release.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1635
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_fbc.c | 3 +++
1 file changed, 3 insertio
We only need the device wakeref on freeing the objects if we have to
unbind the object from the global GTT, or otherwise update device
information. If the objects are clean, we never need the wakeref, so
avoid taking until required.
Signed-off-by: Chris Wilson
Cc: Janusz Krzysztofik
---
drivers
== Series Details ==
Series: series starting with [01/14] drm/i915/gem: Specify address type for
chained reloc batches (rev2)
URL : https://patchwork.freedesktop.org/series/76876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8414 -> Patchwork_17556
==
== Series Details ==
Series: series starting with [01/14] drm/i915/gem: Specify address type for
chained reloc batches (rev2)
URL : https://patchwork.freedesktop.org/series/76876/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
02c8f810d643 drm/i915/gem: Specify address type for
The older arches did not convert MI_STORE_DATA_IMM to using the GTT, but
left them writing to a physical address. The notes suggest that the
primary reason would be so that the writes were cache coherent, as the
CPU cache uses physical tagging. As such we did not implement the
legacy variant of MI_
Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig
option, primarily to allow brave systems to disable the timeout and
solely rely on correct signaling.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.profile | 12
dri
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
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
From: Chris Wilson
It is required that a chained batch be in the same address domain as its
parent, and also that must be specified in the command for earlier gen
as it is not inferred from the chaining until gen6.
Fixes: 964a9b0f611e ("drm/i915/gem: Use chained reloc batches")
Signed-off-by: Ch
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
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in paral
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
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 | 6 --
1 file changed, 6 deletions(-)
diff --gi
Use a local to shrink a line under 80 columns, and refactor the common
emit_xcs_breadcrumb() wrapper of ggtt-write.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 +
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/
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
Repeat the measurement of the clock frequency a few times and use the
median to try and reduce the systematic measurement error.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 54 +++---
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a
As we only restore the default context state upon banning a context, we
only need enough of the state to run the ring and nothing more. That is
we only need our bare protocontext.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel
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
The older arches did not convert MI_STORE_DATA_IMM to using the GTT, but
left them writing to a physical address. The notes suggest that the
primary reason would be so that the writes were cache coherent, as the
CPU cache uses physical tagging. As such we did not implement the
legacy variant of MI_
64 matches
Mail list logo
