== Series Details ==
Series: drm/i915: Peel dma-fence-chains for await (rev3)
URL : https://patchwork.freedesktop.org/series/77081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8453_full -> Patchwork_17613_full
Summary
---
== Series Details ==
Series: drm/i915: Peel dma-fence-chains for await (rev3)
URL : https://patchwork.freedesktop.org/series/77081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8453 -> Patchwork_17613
Summary
---
**
From: Lionel Landwerlin
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915_request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads
== Series Details ==
Series: drm/i915/gt: Replace zero-length array with flexible-array
URL : https://patchwork.freedesktop.org/series/77080/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8453_full -> Patchwork_17612_full
S
From: Lionel Landwerlin
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915_request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads
From: Lionel Landwerlin
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915_request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads
On Fri, May 8, 2020 at 3:56 PM Alexey Brodkin
wrote:
>
> Hi Daniel,
>
> > > Looking at this patch series, feels a bit like hand-rolling of bridge
> > > code, badly. We should get away from that.
> > >
> > > Once you have that I think the end result is tiny enough that it can
> > > stay, bridges in
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,
> - unsigned long *out)
> + unsigned long *count)
> {
>
Quoting Janusz Krzysztofik (2020-05-08 14:56:30)
> Commit 870c774b866c ("igt/gem_exec_nop: Add expectancy of independent
> execution between engines") extended a "basic" subtest (now
> "basic-series") with a pass/fail metric based on comparison of parallel
> execution time to be less than an averag
== Series Details ==
Series: drm/i915/gt: Replace zero-length array with flexible-array
URL : https://patchwork.freedesktop.org/series/77080/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8453 -> Patchwork_17612
Summary
---
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 Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Apr 17, 2020 at 05:23:10PM +0200, Daniel Vetter wrote:
> > > > On Thu, Apr 16, 2020 at 08
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
Quoting Mika Kuoppala (2020-05-08 16:50:22)
> 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-
Quoting Mika Kuoppala (2020-05-08 16:44:48)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-05-08 16:37:15)
> >> Chris Wilson writes:
> >>
> >> > The downside of using semaphores is that we lose metadata passing
> >> > along the signaling chain. This is particularly nasty when we
> >>
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
> ---
> drivers/gpu/drm/i915/i915_s
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-05-08 16:37:15)
>> Chris Wilson writes:
>>
>> > The downside of using semaphores is that we lose metadata passing
>> > along the signaling chain. This is particularly nasty when we
>> > need to pass along a fatal error such as EFAULT or EDEADLK
Quoting Mika Kuoppala (2020-05-08 16:37:15)
> Chris Wilson writes:
>
> > The downside of using semaphores is that we lose metadata passing
> > along the signaling chain. This is particularly nasty when we
> > need to pass along a fatal error such as EFAULT or EDEADLK. For
> > fatal errors we want
Chris Wilson writes:
> The downside of using semaphores is that we lose metadata passing
> along the signaling chain. This is particularly nasty when we
> need to pass along a fatal error such as EFAULT or EDEADLK. For
> fatal errors we want to scrub the request before it is executed,
> which mea
== Series Details ==
Series: dma-buf: Use atomic_fetch_add() for the context id
URL : https://patchwork.freedesktop.org/series/77076/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8451_full -> Patchwork_17611_full
Summary
-
== Series Details ==
Series: drm/i915/gt: Improve precision on defer_request assert
URL : https://patchwork.freedesktop.org/series/77074/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8451_full -> Patchwork_17610_full
Summa
Commit 870c774b866c ("igt/gem_exec_nop: Add expectancy of independent
execution between engines") extended a "basic" subtest (now
"basic-series") with a pass/fail metric based on comparison of parallel
execution time to be less than an average * 2. Since then, that limit
has been raised quite a fe
Execbuf requests are now submitted by subtests in batches of 1024
repetitions. That may be too many under some circumstances (e.g.,
intensive logging output) and subtests may take far more time than
expected.
Kill obsolete showcase for an old GuC failure, then remove submission
batching from subt
Execbuf requests are now submitted by subtests in batches of 1024
repetitions. That may be too many under some circumstances (e.g.,
intensive logging output) and subtests may take far more time than
expected.
The reason standing behind that batching was unacceptable microsecond
imprecision of get
Hi Daniel,
> > Looking at this patch series, feels a bit like hand-rolling of bridge
> > code, badly. We should get away from that.
> >
> > Once you have that I think the end result is tiny enough that it can
> > stay, bridges intergrate quite well into simple display pipe drivers.
> >
> > > BTW s
>-Original Message-
>From: Chris Wilson
>Sent: Thursday, May 7, 2020 9:57 AM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded
>I915_FENCE_TIMEOUT
>
>Quoting Ruhl, Michael J (2020-05-07 14:53:00)
>>
>>
>> >
== Series Details ==
Series: series starting with [1/9] drm/i915: Ignore submit-fences on the same
timeline
URL : https://patchwork.freedesktop.org/series/77072/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8450_full -> Patchwork_17609_full
==
On Fri, May 08, 2020 at 01:59:17PM +0200, Yves-Alexis Perez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Fri, 2020-05-08 at 11:54 +0200, Greg KH wrote:
> > > Hi Daniel and Greg (especially). It seems that this patch was never
> > > applied to
> > > stable, maybe it fell throug
== Series Details ==
Series: dma-buf: Use atomic_fetch_add() for the context id
URL : https://patchwork.freedesktop.org/series/77076/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8451 -> Patchwork_17611
Summary
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2020-05-08 at 11:54 +0200, Greg KH wrote:
> > Hi Daniel and Greg (especially). It seems that this patch was never
> > applied to
> > stable, maybe it fell through the cracks?
>
> What patch is "this patch"?
Sorry, the patch was in the mail
== Series Details ==
Series: drm/i915/gt: Improve precision on defer_request assert
URL : https://patchwork.freedesktop.org/series/77074/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8451 -> Patchwork_17610
Summary
---
Op 06-05-2020 om 15:11 schreef Animesh Manna:
> Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
> function which also includes pinning and map in cpu domain.
>
> No change is dsb write/commit functions.
>
> Now dsb get/put function is refactored and currently used only for
> re
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-05-08 10:57:37)
>> Chris Wilson writes:
>>
>> > While we ordinarily do not skip submit-fences due to the accompanying
>> > hook that we want to callback on execution, a submit-fence on the same
>> > timeline is meaningless.
>> >
>> > Signed-off
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(
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-05-08 11:19:25)
>> Chris Wilson writes:
>>
>> > As a means for a small code consolidation, but primarily to start
>> > thinking more carefully about internal-vs-external linkage, pull the
>> > pair of i915_sw_fence_await_dma_fence() calls into
The kernel_context does not use initial-breadcrumbs, so when we ask if
its requests have started we do so by comparing against the completion
seqno of the previous request. This is very imprecise, not precise
enough for the defer_request assertion.
Closes: https://gitlab.freedesktop.org/drm/intel/
== Series Details ==
Series: series starting with [1/9] drm/i915: Ignore submit-fences on the same
timeline
URL : https://patchwork.freedesktop.org/series/77072/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8450 -> Patchwork_17609
Quoting Mika Kuoppala (2020-05-08 11:19:25)
> Chris Wilson writes:
>
> > As a means for a small code consolidation, but primarily to start
> > thinking more carefully about internal-vs-external linkage, pull the
> > pair of i915_sw_fence_await_dma_fence() calls into a common routine.
> >
> > Sign
Quoting Mika Kuoppala (2020-05-08 11:19:25)
> Chris Wilson writes:
>
> > As a means for a small code consolidation, but primarily to start
> > thinking more carefully about internal-vs-external linkage, pull the
> > pair of i915_sw_fence_await_dma_fence() calls into a common routine.
> >
> > Sign
Chris Wilson writes:
> As a means for a small code consolidation, but primarily to start
> thinking more carefully about internal-vs-external linkage, pull the
> pair of i915_sw_fence_await_dma_fence() calls into a common routine.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i91
== Series Details ==
Series: series starting with [1/9] drm/i915: Ignore submit-fences on the same
timeline
URL : https://patchwork.freedesktop.org/series/77072/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3db130b5548c drm/i915: Ignore submit-fences on the same timeline
d176
Quoting Mika Kuoppala (2020-05-08 10:57:37)
> Chris Wilson writes:
>
> > While we ordinarily do not skip submit-fences due to the accompanying
> > hook that we want to callback on execution, a submit-fence on the same
> > timeline is meaningless.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtk
On Fri, May 08, 2020 at 11:06:56AM +0200, Yves-Alexis Perez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Thu, 2019-09-05 at 20:53 +0200, Daniel Vetter wrote:
> > The -modesetting ddx has a totally broken idea of how atomic works:
> > - doesn't disable old connectors, assuming
Chris Wilson writes:
> While we ordinarily do not skip submit-fences due to the accompanying
> hook that we want to callback on execution, a submit-fence on the same
> timeline is meaningless.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_request.c | 3
On Thu, May 07, 2020 at 11:05:33AM -0700, Matt Roper wrote:
> On Thu, May 07, 2020 at 03:04:30PM +0300, Ville Syrjälä wrote:
> > On Mon, May 04, 2020 at 03:52:19PM -0700, Matt Roper wrote:
> > > From: Lucas De Marchi
> > >
> > > RKL uses the DDI A, DDI B, DDI USBC1, DDI USBC2 from the DE point of
While we ordinarily do not skip submit-fences due to the accompanying
hook that we want to callback on execution, a submit-fence on the same
timeline is meaningless.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 +++
1 file changed, 3 insertions(+)
As a means for a small code consolidation, but primarily to start
thinking more carefully about internal-vs-external linkage, pull the
pair of i915_sw_fence_await_dma_fence() calls into a common routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16 ++--
1
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
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
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 downside of using semaphores is that we lose metadata passing
along the signaling chain. This is particularly nasty when we
need to pass along a fatal error such as EFAULT or EDEADLK. For
fatal errors we want to scrub the request before it is executed,
which means that we cannot preload the req
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
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
== Series Details ==
Series: series starting with [01/11] drm/i915: Ignore submit-fences on the same
timeline
URL : https://patchwork.freedesktop.org/series/77060/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8450 -> Patchwork_17608
==
== Series Details ==
Series: series starting with [01/11] drm/i915: Ignore submit-fences on the same
timeline
URL : https://patchwork.freedesktop.org/series/77060/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/genera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, 2019-09-05 at 20:53 +0200, Daniel Vetter wrote:
> The -modesetting ddx has a totally broken idea of how atomic works:
> - doesn't disable old connectors, assuming they get auto-disable like
> with the legacy setcrtc
> - assumes ASYNC_FLIP i
== Series Details ==
Series: series starting with [01/11] drm/i915: Ignore submit-fences on the same
timeline
URL : https://patchwork.freedesktop.org/series/77060/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9fb07acb437e drm/i915: Ignore submit-fences on the same timeline
15
As a means for a small code consolidation, but primarily to start
thinking more carefully about internal-vs-external linkage, pull the
pair of i915_sw_fence_await_dma_fence() calls into a common routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16 ++--
1
While we ordinarily do not skip submit-fences due to the accompanying
hook that we want to callback on execution, a submit-fence on the same
timeline is meaningless.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 +++
1 file changed, 3 insertions(+)
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
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
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
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
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
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
The downside of using semaphores is that we lose metadata passing
along the signaling chain. This is particularly nasty when we
need to pass along a fatal error such as EFAULT or EDEADLK. For
fatal errors we want to scrub the request before it is executed,
which means that we cannot preload the req
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
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
> -Original Message-
> From: Jani Nikula
> Sent: 08 May 2020 12:19
> To: Laxminarayan Bharadiya, Pankaj
> ; dan...@ffwll.ch; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Ville Syrjälä
> ; Chris
> Wilson ; Dea
== Series Details ==
Series: linux-next: build failure after merge of the drm tree
URL : https://patchwork.freedesktop.org/series/77056/
State : failure
== Summary ==
Applying: linux-next: build failure after merge of the drm tree
error: sha1 information is lacking or useless
(drivers/gpu/drm
70 matches
Mail list logo
