== 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
> -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
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
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
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
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
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
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
== 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
-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 : 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
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
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
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
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
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
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(+)
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
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 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
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
== 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
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
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
== 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
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/
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
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 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
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
== 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
---
-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: 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
---
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: 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
==
>-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)
>>
>>
>> >
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
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
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
== 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
== 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
-
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
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:
> 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
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
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
> >>
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-
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
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
== 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
---
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
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)
> {
>
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
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
== 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
== 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
---
**
== 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
---
70 matches
Mail list logo
