On Wed, May 27, 2020 at 01:54:27PM -0700, Manasi Navare wrote:
> On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote:
> > First of all *_needs_link_retraining function should return
> > false is link_train is set to true but not false.
> >
> > Also if we detect channel eq problem w
Reduce the 3 relocation patches down to the single path that accommodates
all. The primary motivation for this is to guard the relocations with a
natural fence (derived from the i915_request used to write the
relocation from the GPU).
The tradeoff in using async gpu relocations is that it increase
If we get interrupted in the middle of chaining up the relocation
entries, we will fail to submit the relocation batch. However, we will
report having already completed some of the relocations, and so the
reloc.presumed_offset will no longer match the batch contents, causing
confusion and invalid f
If the real target for a proxy fence is known at the time we are
attaching our awaits, use the real target in preference to hooking up to
the proxy. If use the real target instead, we can optimize the awaits,
e.g. if it along the same engine, we can order the submission and avoid
the wait-for-compl
Although we may chide userspace for reusing the same batches
concurrently from multiple threads, at the same time we must be very
careful to only execute the batch and its relocations as supplied by the
user. If we are not careful, we may allow another thread to rewrite the
current batch with its o
One more list iterator variant, for when we want to unwind from inside
one list iterator with the intention of restarting from the current
entry as the new head of the list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_utils.h | 6 ++
1 file changed, 6 insertions(+)
diff --git
If the ring submission is stalled on an external request, nothing can be
submitted, not even the heartbeat in the kernel context. Since nothing
is running, resetting the engine/device does not unblock the system and
is pointless. We can see if the heartbeat is supposed to be running
before declarin
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
Since we have reduced the relocations paths to just use the async GPU,
we can lift the request allocation to the start of the relocations.
Knowing that we use one request for all relocations will simplify
tracking the relocation fence.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_ge
Over the next couple of patches, we will want to lock all the modified
vma for relocation processing under a single ww_mutex. We neither want
to have to include the vma that are skipped (due to no modifications
required) nor do we want those to be marked as written too. So separate
out the reloc va
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to
Asynchronous waits and signaling form a traditional semaphore with all
the usual ordering problems with taking multiple locks. If we want to
add more than one wait on a shared resource by the GPU, we must ensure
that all the associated timelines are advanced atomically, ergo we must
lock all the ti
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to
If the ring submission is stalled on an external request, nothing can be
submitted, not even the heartbeat in the kernel context. Since nothing
is running, resetting the engine/device does not unblock the system and
is pointless. We can see if the heartbeat is supposed to be running
before declarin
On 5/27/2020 7:48 PM, Jani Nikula wrote:
On Wed, 27 May 2020, Ankit Nautiyal wrote:
For testing and debugging each HDCP version separately, a debugfs
entry for requesting a specific version is required. The vesion
requested via debugfs needs to be stored in hdcp structure. This can
then be c
Hi Jani,
Thanks for the comments and suggestions. Please find my response inline.
On 5/27/2020 7:44 PM, Jani Nikula wrote:
On Wed, 27 May 2020, Ankit Nautiyal wrote:
As per the current HDCP design, the driver selects the highest
version of HDCP that can be used to satisfy the content-protecti
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
55a37e373e5e drm/i915/gt: Prevent timeslicing into unpreem
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won'
Hi Daniel,
On 2020-05-28 07:46, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
>> mxsfb has vblank support, is atomic, but doesn't call
>> drm_crtc_vblank_on/off as it should. Not good.
>>
>> With my next patch to add the drm_crtc_vblank_reset to helpers this
On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote:
>
> Hi Daniel,
>
> On 2020-05-28 07:46, Daniel Vetter wrote:
> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
> >> mxsfb has vblank support, is atomic, but doesn't call
> >> drm_crtc_vblank_on/off as it should. Not good.
> >>
>
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
*
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8545 -> Patchwork_17800
=
On 2020-05-28 10:06, Daniel Vetter wrote:
> On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote:
>>
>> Hi Daniel,
>>
>> On 2020-05-28 07:46, Daniel Vetter wrote:
>> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
>> >> mxsfb has vblank support, is atomic, but doesn't call
>> >> drm
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77730/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
006567321620 drm/i915/gt: Prevent timeslicing into unpreempt
Across suspend/resume, we clear the entire GGTT and rebuild from
scratch. In particular, we only preserve the global entries for use by
the HW, and delay reinstating the local binds until required by the
user. This means that we can evict and recover any local binds in the
global GTT, saving any ti
We should be able to skip restoing LOCAL (user) binds within the GGTT on
resume and let them be restored upon demand. However, our consistency
checks demand that the bind flags match the node state, and we cannot
simply clear the flags we need to evict as well. For now, make sure we
restore the bin
On Thu, May 28, 2020 at 10:19:46AM +0200, Stefan Agner wrote:
> On 2020-05-28 10:06, Daniel Vetter wrote:
> > On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote:
> >>
> >> Hi Daniel,
> >>
> >> On 2020-05-28 07:46, Daniel Vetter wrote:
> >> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77730/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8545 -> Patchwork_17801
===
On 27/05/2020 17:24, Chris Wilson wrote:
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pendin
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev3)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17799_full
Summary
---
On Wed, 2020-05-27 at 21:12 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-05-18 20:17:19)
> > GGTT including its scratch page is not cleaned up until driver release.
> > Since DMA mappings still exist before scratch page cleanup, unmapping
> > them on last device close after the
Hi Michał,
On Wed, 2020-05-27 at 21:15 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-05-18 20:17:20)
> > UC firmware is stored in a GEM object. Clean it up on driver remove to
>^ double whitespace
That's a result of my addiction to an o
Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
> +static void
> +mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
> +{
> + /*
> +* Give (temporary) special meaning to a pair requests with requested
> +* aligned start along the video engines.
> +*
>
On 18/05/2020 19:17, Janusz Krzysztofik wrote:
Contexts associated with open device file descriptors together with
their assigned address spaces are now closed on device file close. On
i915_gem_driver_remove looks like module unload to me, not device file
close. So..
address space closur
On 28/05/2020 10:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
+static void
+mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
+{
+ /*
+* Give (temporary) special meaning to a pair requests with requested
+* aligned start along
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Restore both GGTT bindings on
resume
URL : https://patchwork.freedesktop.org/series/77734/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8546 -> Patchwork_17802
==
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8545_full -> Patchwork_17800_full
===
Hi Dave, Daniel,
Here's this week drm-misc-fixes PR.
Thanks!
Maxime
drm-misc-fixes-2020-05-28:
Two ingenic fixes, one for a wrong cast, the other for a typo in a
comparison
The following changes since commit c54a8f1f329197d83d941ad84c4aa38bf282cbbd:
drm/meson: pm resume add return errno branc
Hi Tvrtko,
On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> On 18/05/2020 19:17, Janusz Krzysztofik wrote:
> > Contexts associated with open device file descriptors together with
> > their assigned address spaces are now closed on device file close. On
>
> i915_gem_driver_remove looks
Hi
Am 27.05.20 um 21:34 schrieb Daniel Vetter:
> On Wed, May 27, 2020 at 8:32 PM Thomas Zimmermann wrote:
>>
>> Hi Daniel,
>>
>> what's your plan for this patch set? I'd need this patch for the udl
>> shmem cleanup.
>
> I was pinging some people for a tested-by, I kinda don't want to push
> this
> -Original Message-
> From: Ashwin H
> Sent: Thursday, May 28, 2020 1:01 PM
> To: Greg KH
> Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@kernel.org;
> Srivatsa Bhat ; sriva...@csail.mit.edu;
> rost...@go
On 5/15/20 7:09 PM, Valentin Schneider wrote:
On 15/05/20 01:48, Francisco Jerez wrote:
Valentin Schneider writes:
(+Lukasz)
On 11/05/20 22:01, Francisco Jerez wrote:
What I'm missing is an explanation for why this isn't using the
infrastructure that was build for these kinds of things?
> -Original Message-
> From: Greg KH
> Sent: Wednesday, May 27, 2020 9:02 PM
> To: Ashwin H
> Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@kernel.org;
> Srivatsa Bhat ; sriva...@csail.mit.edu;
> rost...@
On 28/05/2020 13:10, Janusz Krzysztofik wrote:
Hi Tvrtko,
On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
On 18/05/2020 19:17, Janusz Krzysztofik wrote:
Contexts associated with open device file descriptors together with
their assigned address spaces are now closed on device file cl
Quoting Tvrtko Ursulin (2020-05-28 14:34:42)
>
> On 28/05/2020 13:10, Janusz Krzysztofik wrote:
> > Hi Tvrtko,
> >
> > On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> >> On 18/05/2020 19:17, Janusz Krzysztofik wrote:
> >>> Contexts associated with open device file descriptors together
On 2020-05-12 10:59, Daniel Vetter wrote:
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't go
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Restore both GGTT bindings on
resume
URL : https://patchwork.freedesktop.org/series/77734/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8546_full -> Patchwork_17802_full
Hi Chris,
On Thu, 2020-05-28 at 14:41 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2020-05-28 14:34:42)
> > On 28/05/2020 13:10, Janusz Krzysztofik wrote:
> > > Hi Tvrtko,
> > >
> > > On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> > > > On 18/05/2020 19:17, Janusz Krzysztofik
On Thu, May 28, 2020 at 3:37 PM Thomas Hellström (Intel)
wrote:
>
> On 2020-05-12 10:59, Daniel Vetter wrote:
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> >this explicit
Hi Dave & Daniel,
Two bigger fixes to corner case kernel access faults
and three workload scheduling fixups this week.
CI_DINF_191 at:
https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html?
I got gvt-next-fixes pull today, I'll pull it next week so it
has time to run through CI
If the execbuf is interrupted after building the cmdparser pipeline, and
before we commit to submitting the request to HW, we would attempt to
clean up the cmdparser early. While we held active references to the vma
being parsed and constructed, we did not hold an active reference for
the buffer po
On Thu, 28 May 2020 at 09:24, Chris Wilson wrote:
>
> We should be able to skip restoing LOCAL (user) binds within the GGTT on
> resume and let them be restored upon demand. However, our consistency
> checks demand that the bind flags match the node state, and we cannot
> simply clear the flags we
We should be able to skip restoing LOCAL (user) binds within the GGTT on
resume and let them be restored upon demand. However, our consistency
checks demand that the bind flags match the node state, and we cannot
simply clear the flags, we need to evict as well. For now, make sure we
restore the bi
On Thu, 28 May 2020 at 09:24, Chris Wilson wrote:
>
> Across suspend/resume, we clear the entire GGTT and rebuild from
> scratch. In particular, we only preserve the global entries for use by
> the HW, and delay reinstating the local binds until required by the
> user. This means that we can evict
== Series Details ==
Series: drm/i915/gem: Mark the buffer pool as active for the cmdparser
URL : https://patchwork.freedesktop.org/series/77749/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8547 -> Patchwork_17803
Summary
== Series Details ==
Series: drm/i915/gt: Restore both GGTT bindings on resume
URL : https://patchwork.freedesktop.org/series/77750/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8547 -> Patchwork_17804
Summary
---
*
Chris Wilson writes:
> If the ring submission is stalled on an external request, nothing can be
> submitted, not even the heartbeat in the kernel context. Since nothing
> is running, resetting the engine/device does not unblock the system and
> is pointless. We can see if the heartbeat is suppose
Quoting Mika Kuoppala (2020-05-28 17:23:18)
> Chris Wilson writes:
>
> > If the ring submission is stalled on an external request, nothing can be
> > submitted, not even the heartbeat in the kernel context. Since nothing
> > is running, resetting the engine/device does not unblock the system and
Quoting Chris Wilson (2020-05-28 17:50:55)
> Quoting Mika Kuoppala (2020-05-28 17:23:18)
> > Chris Wilson writes:
> >
> > > If the ring submission is stalled on an external request, nothing can be
> > > submitted, not even the heartbeat in the kernel context. Since nothing
> > > is running, reset
Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu:
> Without async flip support in the kernel, fullscreen apps where game
> resolution is equal to the screen resolution, must perform an extra blit
> per frame prior to flipping.
>
> Asynchronous page flips will also boost the FPS of Mesa benc
== Series Details ==
Series: drm/i915/gem: Mark the buffer pool as active for the cmdparser
URL : https://patchwork.freedesktop.org/series/77749/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8547_full -> Patchwork_17803_full
===
== Series Details ==
Series: drm/i915/gt: Restore both GGTT bindings on resume
URL : https://patchwork.freedesktop.org/series/77750/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8547_full -> Patchwork_17804_full
Summary
--
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
*
Hi Dave and Daniel,
Here goes drm-intel-fixes-2020-05-28:
couple compilation fixes for gcc-9+, and couple fixes for timeslicing,
one to respect I915_REQUEST_NOPREEMPT flag and another to incorporate
virtual engine into timeslicing.
Thanks,
Rodrigo.
The following changes since commit 9cb1fd0efd1
On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> While the current locking/serialization of the global state
> suffices for protecting the obj->state access and the actual
> hardware reprogramming, we do have a problem with accessing
> the old/new states du
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath". (rev2)
URL : https://patchwork.freedesktop.org/series/77472/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d9487c8b0b0d Revert "drm/i915/gem: Drop relocation slowpath".
-
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath". (rev2)
URL : https://patchwork.freedesktop.org/series/77472/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > While the current locking/serialization of the global state
> > suffices for protecting the obj->state access and the actual
> > h
Hours Of Battery Life is a new GEN12+ power-saving feature that allows
supported motherboards to use a special voltage swing table for eDP
panels that uses less power.
So here if supported by HW, OEM will set it in VBT and i915 will try
to train link with HOBL vswing table if link training fails i
HOBL worked in my TGL RVP even without the necessary HW support, also
it worked in more than half of the TGL machines in CI so it is worthy
to enable it by default.
Even if link training fails with this new vswing table it will only
cause one additional link training, that is worthy the try to get
It will be programed right before the link training, so no need to do
it twice.
It will not strictly follow BSpec sequences but most of this sequences
are not matching anyways.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 19 ---
1 file chan
HOBL means hours of battery life, it is a power-saving feature
were supported motherboards can use a special voltage swing table
that uses less power.
So here parsing the VBT to check if this feature is supported.
While at it already added the VRR parameter too.
BSpec: 20150
Signed-off-by: José R
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath". (rev2)
URL : https://patchwork.freedesktop.org/series/77472/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17805
==
== Series Details ==
Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the
same vswing entry twice
URL : https://patchwork.freedesktop.org/series/77758/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit w
Quoting Tvrtko Ursulin (2020-05-28 11:20:07)
>
> On 28/05/2020 10:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
> >> +static void
> >> +mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
> >> +{
> >> + /*
> >> +* Give (temporary) special
Randomly submit a paired spinner and its cancellation as a bonded
(submit fence) pair. Apply congestion to the engine with more bonded
pairs to see if the execution order fails. If we prevent a cancellation
from running, then the spinner will remain spinning forever.
v2: Test both immediate submis
== Series Details ==
Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the
same vswing entry twice
URL : https://patchwork.freedesktop.org/series/77758/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17806
==
== Series Details ==
Series: drm/i915: Special handling for bonded requests (rev2)
URL : https://patchwork.freedesktop.org/series/77688/
State : failure
== Summary ==
Applying: drm/i915: Special handling for bonded requests
error: sha1 information is lacking or useless
(drivers/gpu/drm/i915/g
We may choose to only submit ELSP[0], even though we have sufficient
requests to fill the whole ELSP. Normally, we only start timeslicing if
we fill more than one port, but in this case we need to start
timeslicing for the queue that we choose not to submit.
Signed-off-by: Chris Wilson
Cc: Tvrtko
Chris Wilson writes:
> We may choose to only submit ELSP[0], even though we have sufficient
> requests to fill the whole ELSP. Normally, we only start timeslicing if
> we fill more than one port, but in this case we need to start
> timeslicing for the queue that we choose not to submit.
If this
One more list iterator variant, for when we want to unwind from inside
one list iterator with the intention of restarting from the current
entry as the new head of the list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_utils.h | 6 ++
1 file changed, 6 insertions(+)
diff --git
Although we may chide userspace for reusing the same batches
concurrently from multiple threads, at the same time we must be very
careful to only execute the batch and its relocations as supplied by the
user. If we are not careful, we may allow another thread to rewrite the
current batch with its o
Over the next couple of patches, we will want to lock all the modified
vma for relocation processing under a single ww_mutex. We neither want
to have to include the vma that are skipped (due to no modifications
required) nor do we want those to be marked as written too. So separate
out the reloc va
Reduce the 3 relocation patches down to the single path that accommodates
all. The primary motivation for this is to guard the relocations with a
natural fence (derived from the i915_request used to write the
relocation from the GPU).
The tradeoff in using async gpu relocations is that it increase
We may choose to only submit ELSP[0], even though we have sufficient
requests to fill the whole ELSP. Normally, we only start timeslicing if
we fill more than one port, but in this case we need to start
timeslicing for the queue that we choose not to submit.
Signed-off-by: Chris Wilson
Cc: Tvrtko
Asynchronous waits and signaling form a traditional semaphore with all
the usual ordering problems with taking multiple locks. If we want to
add more than one wait on a shared resource by the GPU, we must ensure
that all the associated timelines are advanced atomically, ergo we must
lock all the ti
Since we have reduced the relocations paths to just use the async GPU,
we can lift the request allocation to the start of the relocations.
Knowing that we use one request for all relocations will simplify
tracking the relocation fence.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_ge
If the real target for a proxy fence is known at the time we are
attaching our awaits, use the real target in preference to hooking up to
the proxy. If use the real target instead, we can optimize the awaits,
e.g. if it along the same engine, we can order the submission and avoid
the wait-for-compl
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 we get interrupted in the middle of chaining up the relocation
entries, we will fail to submit the relocation batch. However, we will
report having already completed some of the relocations, and so the
reloc.presumed_offset will no longer match the batch contents, causing
confusion and invalid f
If the execbuf is interrupted after building the cmdparser pipeline, and
before we commit to submitting the request to HW, we would attempt to
clean up the cmdparser early. While we held active references to the vma
being parsed and constructed, we did not hold an active reference for
the buffer po
On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lock
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
*
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5472:
drivers/gpu/drm/i915/gt/selftest_lrc.c: In function 'live_timeslice_nopreempt':
drivers/gpu/drm/i915/gt/selftest_lrc.c:1
== Series Details ==
Series: drm/i915/gt: Start timeslice on partial submission
URL : https://patchwork.freedesktop.org/series/77761/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17808
Summary
---
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dc44da7a88e6 drm/i915/gt: Start timeslice on partial submission
af3a
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be check
== Series Details ==
Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the
same vswing entry twice
URL : https://patchwork.freedesktop.org/series/77758/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8549_full -> Patchwork_17806_full
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17809
===
== Series Details ==
Series: drm/i915: Track i915_vma with its own reference counter
URL : https://patchwork.freedesktop.org/series/77763/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
55980f47bd93 drm/i915: Track i915_vma with its own reference counter
-:2210: CHECK:UNCOMMENTE
1 - 100 of 113 matches
Mail list logo
