Hi,
Here's queued fixes from Jani for one useless inline and fix
CONFIG_DRM_I915_WERROR for gvt headers.
Thanks and Merry Christmas!
--
The following changes since commit 9a3a238b3de97b4210c6de66aa88b2d7021ac086:
drm/i915/gvt: treat intel_gvt_mpt as const in gvt code (2020-11-23 17:14:20
== Series Details ==
Series: series starting with drm/i915/gt: Cancel submitted requests upon
context reset (rev2)
URL : https://patchwork.freedesktop.org/series/85209/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9522 -> Patchwork_19215
Since we process schedule-in of a context after submitting the request,
if we decide to reset the context at that time, we also have to cancel
the requets we have marked for submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 8
We only need to evaluate the current status of the context when it is
scheduled in, we will force a reschedule when the context is closed
propagating the change to inflight contexts.
Signed-off-by: Chris Wilson
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4
If supported by the backend, we can quickly look at the context's
inflight engine rather than search along the active list to confirm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4
1 file changed, 4 insertions(+)
diff --git
Since we process schedule-in of a context after submitting the request,
if we decide to reset the context at that time, we also have to cancel
the requets we have marked for submission.
Signed-off-by: Chris Wilson
---
.../drm/i915/gt/intel_execlists_submission.c | 22 +--
== Series Details ==
Series: drm/i915/gt: Refactor heartbeat request construction and submission
URL : https://patchwork.freedesktop.org/series/85207/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9521_full -> Patchwork_19214_full
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: clear the shadow batch
URL : https://patchwork.freedesktop.org/series/85206/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9521_full -> Patchwork_19213_full
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: clear the shadow batch
URL : https://patchwork.freedesktop.org/series/85205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9521_full -> Patchwork_19212_full
== Series Details ==
Series: drm/i915/gt: Refactor heartbeat request construction and submission
URL : https://patchwork.freedesktop.org/series/85207/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9521 -> Patchwork_19214
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: clear the shadow batch
URL : https://patchwork.freedesktop.org/series/85206/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9521 -> Patchwork_19213
== Series Details ==
Series: series starting with [CI,1/9] drm/i915/gt: Replace direct submit with
direct call to tasklet
URL : https://patchwork.freedesktop.org/series/85203/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9520_full -> Patchwork_19210_full
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: clear the shadow batch
URL : https://patchwork.freedesktop.org/series/85205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9521 -> Patchwork_19212
== Series Details ==
Series: series starting with [1/2] drm/i915: clear the shadow batch
URL : https://patchwork.freedesktop.org/series/85204/
State : failure
== Summary ==
Applying: drm/i915: clear the shadow batch
Applying: drm/i915: clear the gpu reloc batch
Using index info to reconstruct
Pull the individual strands of creating a custom heartbeat requests into
a pair of common functions. This will reduce the number of changes we
will need to make in future.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 59
Quoting Matthew Auld (2020-12-24 15:13:58)
> The reloc batch is short lived but can exist in the user visible ppGTT,
> and since it's backed by an internal object, which lacks page clearing,
> we should take care to clear it upfront.
>
> Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
Quoting Matthew Auld (2020-12-24 15:13:57)
> The shadow batch is an internal object, which doesn't have any page
> clearing, and since the batch_len can be smaller than the object, we
> should take care to clear it.
>
> Testcase: igt/gen9_exec_parse/shadow-peek
> Fixes: 4f7af1948abc ("drm/i915:
The reloc batch is short lived but can exist in the user visible ppGTT,
and since it's backed by an internal object, which lacks page clearing,
we should take care to clear it upfront.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 +++-
1 file changed, 3
The shadow batch is an internal object, which doesn't have any page
clearing, and since the batch_len can be smaller than the object, we
should take care to clear it.
Testcase: igt/gen9_exec_parse/shadow-peek
Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow
buffers")
== Series Details ==
Series: series starting with [CI,1/9] drm/i915/gt: Replace direct submit with
direct call to tasklet
URL : https://patchwork.freedesktop.org/series/85203/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9520 -> Patchwork_19210
Quoting Matthew Auld (2020-12-24 14:34:54)
> The shadow batch is an internal object, which doesn't have any page
> clearing, and since the batch_len can be smaller than the object, we
> should take care to clear it.
>
> Testcase: igt/gen9_exec_parse/shadow-peek
> Fixes: 4f7af1948abc ("drm/i915:
The reloc batch is short lived but can exist in the user visible ppGTT,
and since it's backed by an internal object, which lacks page clearing,
we should take care to clear it upfront.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 +++-
1 file changed, 3
The shadow batch is an internal object, which doesn't have any page
clearing, and since the batch_len can be smaller than the object, we
should take care to clear it.
Testcase: igt/gen9_exec_parse/shadow-peek
Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow
buffers")
== Series Details ==
Series: series starting with [CI,1/9] drm/i915/gt: Replace direct submit with
direct call to tasklet
URL : https://patchwork.freedesktop.org/series/85203/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit
Quoting Matthew Auld (2020-12-24 14:34:55)
> The reloc batch is short lived but can exist in the user visible ppGTT,
> and since it's backed by an internal object, which lacks page clearing,
> we should take care to clear it upfront.
>
> Signed-off-by: Matthew Auld
> ---
>
On Thu, 24 Dec 2020 at 12:47, Chris Wilson wrote:
>
> Use pad-to-size to fill the entire GTT. Make sure we own it all!
>
> Suggested-by: Matthew Auld
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
Reviewed-by: Matthew Auld
___
Intel-gfx mailing
The reloc batch is short lived but can exist in the user visible ppGTT,
and since it's backed by an internal object, which lacks page clearing,
we should take care to clear it upfront.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 +++
1 file changed, 3
The shadow batch is an internal object, which doesn't have any page
clearing, and since the batch_len can be smaller than the object, we
should take care to clear it.
Testcase: igt/gen9_exec_parse/shadow-peek
Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow
buffers")
The issue with stale virtual breadcrumbs remain. Now we have the problem
that if the irq-signaler is still referencing the stale breadcrumb as we
transfer it to a new sibling, the list becomes spaghetti. This is a very
small window, but that doesn't stop it being hit infrequently. To
prevent the
Let's only wait for the list iterator when decoupling the virtual
breadcrumb, as the signaling of all the requests may take a long time,
during which we do not want to keep the tasklet spinning.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Brost
---
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
This improves our resilence in virtual engine scheduling, and should
eliminate the
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
This notably eliminates the race observed with intel_context_inflight in
__engine_unpark().
Closes:
On Wed, 23 Dec 2020 at 11:12, Chris Wilson wrote:
>
> Now that the tasklet completely controls scheduling of the requests, and
> we postpone scheduling out the old requests, we can keep a hanging
> virtual request bound to the engine on which it hung, and remove it from
> te queue. On release, it
On Wed, 23 Dec 2020 at 11:12, Chris Wilson wrote:
>
> Having recognised that we do not change the sibling until we schedule
> out, we can then defer the decision to resubmit the virtual engine from
> the unwind of the active queue to scheduling out of the virtual context.
> This improves our
On Wed, 23 Dec 2020 at 11:12, Chris Wilson wrote:
>
> Inside schedule_out, we do extra work upon idling the context, such as
> updating the runtime, kicking off retires, kicking virtual engines.
> However, if we are in a series of processing single requests per
> contexts, we may find ourselves
On Wed, 23 Dec 2020 at 11:12, Chris Wilson wrote:
>
> Once a virtual engine has been bound to a sibling, it will remain bound
> until we finally schedule out the last active request. We can not rebind
> the context to a new sibling while it is inflight as the context save
> will conflict, hence
Use pad-to-size to fill the entire GTT. Make sure we own it all!
Suggested-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
tests/i915/gem_softpin.c | 97 +++-
1 file changed, 85 insertions(+), 12 deletions(-)
diff --git
Use pad-to-size to fill the entire GTT. Make sure we own it all!
Suggested-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
tests/i915/gem_softpin.c | 96 +++-
1 file changed, 84 insertions(+), 12 deletions(-)
diff --git
== Series Details ==
Series: i915/tests: shadow peek (rev2)
URL : https://patchwork.freedesktop.org/series/85191/
State : failure
== Summary ==
Applying: i915/tests: shadow peek
error: sha1 information is lacking or useless (tests/i915/gen9_exec_parse.c).
error: could not build fake ancestor
On Wed, 23 Dec 2020 at 11:11, Chris Wilson wrote:
>
> Rather than going back and forth between the rb_node entry and the
> virtual_engine type, store the ve local and reuse it. As the
> container_of conversion from rb_node to virtual_engine requires a
> variable offset, performing that conversion
Use pad-to-size to fill the entire GTT. Make sure we own it all!
Suggested-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
tests/i915/gem_softpin.c | 89 ++--
1 file changed, 77 insertions(+), 12 deletions(-)
diff --git
Use pad-to-size to fill the entire GTT. Make sure we own it all!
Suggested-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
tests/i915/gem_softpin.c | 49
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git
Quoting Matthew Auld (2020-12-24 10:29:05)
> The shadow batch needs to be in the user visible ppGTT, so make sure we
> are not leaking anything, if we can guess where the shadow will be
> placed.
>
> Signed-off-by: Matthew Auld
> ---
> tests/i915/gen9_exec_parse.c | 129
The shadow batch needs to be in the user visible ppGTT, so make sure we
are not leaking anything, if we can guess where the shadow will be
placed.
Signed-off-by: Matthew Auld
---
tests/i915/gen9_exec_parse.c | 129 +++
1 file changed, 129 insertions(+)
diff
49 matches
Mail list logo
