#
90a98720 |
| 13-Jul-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Only swap to a random sibling once upon creation
The danger in switching at random upon intel_context_pin is that the context may still actually be inflight, as it will not be scheduled
drm/i915/gt: Only swap to a random sibling once upon creation
The danger in switching at random upon intel_context_pin is that the context may still actually be inflight, as it will not be scheduled out until a context switch after it is complete -- that may be a long time after we do a final intel_context_unpin.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2118 Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713160549.17344-1-chris@chris-wilson.co.uk
show more ...
|
#
4fe6abb8 |
| 11-Jul-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Ignore irq enabling on the virtual engines
We do not use the virtual engines for interrupts (they have physical components), but we do use them to decouple the fence signaling during su
drm/i915/gt: Ignore irq enabling on the virtual engines
We do not use the virtual engines for interrupts (they have physical components), but we do use them to decouple the fence signaling during submission. Currently, when we submit a completed request, we try to enable the interrupt handler for the virtual engine, but we never disarm it. A quick fix is then to mark the irq as enabled, and it will then remain enabled -- and this prevents us from waking the device and never letting it sleep again.
Fixes: f8db4d051b5e ("drm/i915: Initialise breadcrumb lists on the virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711203236.12330-1-chris@chris-wilson.co.uk
show more ...
|
#
2730055d |
| 11-Jul-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Always reset the engine, even if inactive, on execlists failure
If something has gone awry with the CSB processing, we need to pause, unwind and restart the request submission and event
drm/i915/gt: Always reset the engine, even if inactive, on execlists failure
If something has gone awry with the CSB processing, we need to pause, unwind and restart the request submission and event processing. However, currently we skip the engine reset if we raise an error but discover no active context, in the mistaken belief that it was merely a glitch in the matrix. The glitches are real enough, and we do need to unwind even if the engine appears idle (as it has gone permanently idle!) The simplest way to unwind and recover is simply do the engine reset, which should be very fast and _safe_ as nothing is active.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200711091349.28865-1-chris@chris-wilson.co.uk
show more ...
|
#
b2295e2e |
| 10-Jul-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Be defensive in the face of false CS events
If the HW throws a curve ball and reports either en event before it is possible, or just a completely impossible event, we have to grin and b
drm/i915/gt: Be defensive in the face of false CS events
If the HW throws a curve ball and reports either en event before it is possible, or just a completely impossible event, we have to grin and bear it. The first few events, we will likely not notice as we would be expecting some event, but as soon as we stop expecting an event and yet they still keep coming, then we enter into undefined state territory. In which case, bail out, stop processing the events, and reset the engine and our set of queued requests to recover.
The sporadic hangs and warnings will continue to plague CI, but at least system stability should not be compromised.
v2: Commentary and force the reset-on-error. v3: Customised user facing message for forced resets from internal errors.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2045 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200710133125.30194-1-chris@chris-wilson.co.uk
show more ...
|
#
89d19b2b |
| 08-Jul-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Release shortlived maps of longlived objects
Some objects we map once during their construction, and then never access their mappings again, even if they are kept around for the duration o
drm/i915: Release shortlived maps of longlived objects
Some objects we map once during their construction, and then never access their mappings again, even if they are kept around for the duration of the driver. Keeping those pages mapped, often vmapped, is therefore wasteful and we should release the maps as soon as we no longer need them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708173748.32734-3-chris@chris-wilson.co.uk
show more ...
|
#
59c94b9d |
| 08-Jul-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
As we have a pin_map interface, that knows how to flush the data to the device, use it. The only downside is that we keep the kmap around, as
drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
As we have a pin_map interface, that knows how to flush the data to the device, use it. The only downside is that we keep the kmap around, as once acquired we keep the mapping cached until the object's backing store is released.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708173748.32734-2-chris@chris-wilson.co.uk
show more ...
|
#
0b6613c6 |
| 07-Jul-2020 |
Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> |
drm/i915/sseu: Move sseu_info under gt_info
SSEUs are a GT capability, so track them under gt_info.
Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by: Danie
drm/i915/sseu: Move sseu_info under gt_info
SSEUs are a GT capability, so track them under gt_info.
Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200708003952.21831-8-daniele.ceraolospurio@intel.com
show more ...
|
#
8ab3a381 |
| 09-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Incrementally check for rewinding
In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL"), we placed the check for rewinding a context on a
drm/i915/gt: Incrementally check for rewinding
In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL"), we placed the check for rewinding a context on actually submitting the next request in that context. This was so that we only had to check once, and could do so with precision avoiding as many forced restores as possible. For example, to ensure that we can resubmit the same request a couple of times, we include a small wa_tail such that on the next submission, the ring->tail will appear to move forwards when resubmitting the same request. This is very common as it will happen for every lite-restore to fill the second port after a context switch.
However, intel_ring_direction() is limited in precision to movements of upto half the ring size. The consequence being that if we tried to unwind many requests, we could exceed half the ring and flip the sense of the direction, so missing a force restore. As no request can be greater than half the ring (i.e. 2048 bytes in the smallest case), we can check for rollback incrementally. As we check against the tail that would be submitted, we do not lose any sensitivity and allow lite restores for the simple case. We still need to double check upon submitting the context, to allow for multiple preemptions and resubmissions.
Fixes: 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by: Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200609151723.12971-1-chris@chris-wilson.co.uk (cherry picked from commit e36ba817fa966f81fb1c8d16f3721b5a644b2fa9) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
Revision tags: v5.4.44, v5.7 |
|
#
4178b5a6 |
| 27-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Prevent timeslicing into unpreemptable requests
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
drm/i915/gt: Prevent timeslicing into unpreemptable requests
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 avoid preempting into the topmost priority band, leaving the unpreemptable requests in blissful peace running uninterrupted on the HW.
v2: Set the I915_PRIORITY_BARRIER to be less than I915_PRIORITY_UNPREEMPTABLE so that we never submit a request (heartbeat or barrier) that can legitimately preempt the current non-premptable request.
Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a request") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200527162418.24755-1-chris@chris-wilson.co.uk (cherry picked from commit b72f02d78e4f257761ed003444ae52083f962076) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
Revision tags: v5.4.43, v5.4.42 |
|
#
84973767 |
| 19-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Incorporate the virtual engine into timeslicing
It was quite the oversight to only factor in the normal queue to decide the timeslicing switch priority. By leaving out the next virtual
drm/i915/gt: Incorporate the virtual engine into timeslicing
It was quite the oversight to only factor in the normal queue to decide the timeslicing switch priority. By leaving out the next virtual request from the priority decision, we would not timeslice the current engine if there was an available virtual request.
Testcase: igt/gem_exec_balancer/sliced Fixes: 3df2deed411e ("drm/i915/execlists: Enable timeslice on partial virtual engine dequeue") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200519132046.22443-3-chris@chris-wilson.co.uk (cherry picked from commit 6ad249ba59badc7ff157d4db1f835748f0e2c9b6) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
3d09677a |
| 12-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/execlists: Lift opportunistic process_csb to before engine lock
Since the process_csb() does not require us to hold the engine->active.lock, we can move the opportunistic flush before direc
drm/i915/execlists: Lift opportunistic process_csb to before engine lock
Since the process_csb() does not require us to hold the engine->active.lock, we can move the opportunistic flush before direction submission to outside of the lock.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612221113.9129-1-chris@chris-wilson.co.uk
show more ...
|
#
e36ba817 |
| 09-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Incrementally check for rewinding
In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL"), we placed the check for rewinding a context on a
drm/i915/gt: Incrementally check for rewinding
In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL"), we placed the check for rewinding a context on actually submitting the next request in that context. This was so that we only had to check once, and could do so with precision avoiding as many forced restores as possible. For example, to ensure that we can resubmit the same request a couple of times, we include a small wa_tail such that on the next submission, the ring->tail will appear to move forwards when resubmitting the same request. This is very common as it will happen for every lite-restore to fill the second port after a context switch.
However, intel_ring_direction() is limited in precision to movements of upto half the ring size. The consequence being that if we tried to unwind many requests, we could exceed half the ring and flip the sense of the direction, so missing a force restore. As no request can be greater than half the ring (i.e. 2048 bytes in the smallest case), we can check for rollback incrementally. As we check against the tail that would be submitted, we do not lose any sensitivity and allow lite restores for the simple case. We still need to double check upon submitting the context, to allow for multiple preemptions and resubmissions.
Fixes: 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by: Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200609151723.12971-1-chris@chris-wilson.co.uk
show more ...
|
#
8733a063 |
| 07-Jun-2020 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Adjust the sentinel assert to match implementation
Sentinels are supposed to be last requests in the elsp queue, not the only one, so adjust the assert accordingly.
Signed-off-by: Tvrtko
drm/i915: Adjust the sentinel assert to match implementation
Sentinels are supposed to be last requests in the elsp queue, not the only one, so adjust the assert accordingly.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200607222108.14401-1-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
show more ...
|
#
12b67c2e |
| 05-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Always check to enable timeslicing if not submitting
We may choose not to submit for a number of reasons, yet not fill both ELSP. In which case we must start timeslicing (there will be
drm/i915/gt: Always check to enable timeslicing if not submitting
We may choose not to submit for a number of reasons, yet not fill both ELSP. In which case we must start timeslicing (there will be no ACK event on which to hook the start) if the queue would benefit from the currently active context being evicted.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605122334.2798-2-chris@chris-wilson.co.uk
show more ...
|
#
fdd4f941 |
| 05-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Set timeslicing priority from queue
If we only submit the first port, leaving the second empty yet have ready requests pending in the queue, use that to set the timeslicing priority (i.
drm/i915/gt: Set timeslicing priority from queue
If we only submit the first port, leaving the second empty yet have ready requests pending in the queue, use that to set the timeslicing priority (i.e. the priority at which we will decided to enabling timeslicing and evict the currently active context if the queue is of equal priority after its quantum expired).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605122334.2798-1-chris@chris-wilson.co.uk
show more ...
|
#
ac533c56 |
| 04-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Track if an engine requires forcewake w/a
Sometimes an engine might need to keep forcewake active while it is busy submitting requests for a particular workaround. Track such nuisance w
drm/i915/gt: Track if an engine requires forcewake w/a
Sometimes an engine might need to keep forcewake active while it is busy submitting requests for a particular workaround. Track such nuisance with engine->fw_domain.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200604153145.21068-1-chris@chris-wilson.co.uk
show more ...
|
#
5a833995 |
| 02-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Drop i915_request.i915 backpointer
We infrequently use the direct i915 backpointer from the i915_request, so do we really need to waste the space in the struct for it? 8 bytes from the mos
drm/i915: Drop i915_request.i915 backpointer
We infrequently use the direct i915 backpointer from the i915_request, so do we really need to waste the space in the struct for it? 8 bytes from the most frequently allocated struct vs an 3 bytes and pointer chasing in using rq->engine->i915?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200602220953.21178-1-chris@chris-wilson.co.uk
show more ...
|
#
2010b7f0 |
| 28-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Start timeslice on partial submission
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 fil
drm/i915/gt: Start timeslice on partial submission
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 <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200528205727.20309-1-chris@chris-wilson.co.uk
show more ...
|
#
b72f02d7 |
| 27-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Prevent timeslicing into unpreemptable requests
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
drm/i915/gt: Prevent timeslicing into unpreemptable requests
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 avoid preempting into the topmost priority band, leaving the unpreemptable requests in blissful peace running uninterrupted on the HW.
v2: Set the I915_PRIORITY_BARRIER to be less than I915_PRIORITY_UNPREEMPTABLE so that we never submit a request (heartbeat or barrier) that can legitimately preempt the current non-premptable request.
Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a request") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200527162418.24755-1-chris@chris-wilson.co.uk
show more ...
|
#
9ae6c4ef |
| 25-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/execlists: Shortcircuit queue_prio() for no internal levels
If there are no internal levels and the user priority-shift is zero, we can help the compiler eliminate some dead code:
Function
drm/i915/execlists: Shortcircuit queue_prio() for no internal levels
If there are no internal levels and the user priority-shift is zero, we can help the compiler eliminate some dead code:
Function old new delta start_timeslice 169 154 -15 __execlists_submission_tasklet 4696 4659 -37
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200525075347.582-4-chris@chris-wilson.co.uk
show more ...
|
#
6ad249ba |
| 19-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Incorporate the virtual engine into timeslicing
It was quite the oversight to only factor in the normal queue to decide the timeslicing switch priority. By leaving out the next virtual
drm/i915/gt: Incorporate the virtual engine into timeslicing
It was quite the oversight to only factor in the normal queue to decide the timeslicing switch priority. By leaving out the next virtual request from the priority decision, we would not timeslice the current engine if there was an available virtual request.
Testcase: igt/gem_exec_balancer/sliced Fixes: 3df2deed411e ("drm/i915/execlists: Enable timeslice on partial virtual engine dequeue") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200519132046.22443-3-chris@chris-wilson.co.uk
show more ...
|
#
1ee05f9e |
| 19-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Kick virtual siblings on timeslice out
If we decide to timeslice out the current virtual request, we will unsubmit it while it is still busy (ve->context.inflight == sibling[0]). If the
drm/i915/gt: Kick virtual siblings on timeslice out
If we decide to timeslice out the current virtual request, we will unsubmit it while it is still busy (ve->context.inflight == sibling[0]). If the virtual tasklet and then the other sibling tasklets run before we completely schedule out the active virtual request for the preemption, those other tasklets will see that the virtul request is still inflight on sibling[0] and leave it be. Therefore when we finally schedule-out the virtual request and if we see that we have passed it back to the virtual engine, reschedule the virtual tasklet so that it may be resubmitted on any of the siblings.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200519132046.22443-2-chris@chris-wilson.co.uk
show more ...
|
#
f5f7e790 |
| 18-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Reuse the tasklet priority for virtual as their siblings
In order to keep all the tasklets in the same execution lists and so fifo ordered, be consistent and use the same priority for a
drm/i915/gt: Reuse the tasklet priority for virtual as their siblings
In order to keep all the tasklets in the same execution lists and so fifo ordered, be consistent and use the same priority for all.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200518081440.17948-3-chris@chris-wilson.co.uk
show more ...
|
Revision tags: v5.4.41 |
|
#
0f4013fb |
| 13-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker
The second try at staging the transfer of the breadcrumb. In part one, we realised we could not simply move to the second engine as we wer
drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker
The second try at staging the transfer of the breadcrumb. In part one, we realised we could not simply move to the second engine as we were only holding the breadcrumb lock on the first. So in commit 6c81e21a4742 ("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we removed it from the first engine and marked up this request to reattach the signaling on the new engine. However, this failed to take into account that we only attach the breadcrumb if the new request is added at the start of the queue, which if we are transferring, it is because we know there to be a request to be signaled (and hence we would not be attached).
In this attempt, we try to transfer the completed requests to the irq_worker on its rq->engine->breadcrumbs. This preserves the coupling between the rq and its breadcrumbs, so that i915_request_cancel_breadcrumb() does not attempt to manipulate the list under the wrong lock.
v2: Code sharing is fun.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1862 Fixes: 6c81e21a4742 ("drm/i915/gt: Stage the transfer of the virtual breadcrumb") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200513074809.18194-1-chris@chris-wilson.co.uk
show more ...
|
#
18e4af04 |
| 13-May-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Drop no-semaphore boosting
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 semaphore to the next
drm/i915: Drop no-semaphore boosting
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 semaphore to the next in the queue. Previously with no timeslicing, blocking on the semaphore caused extremely bad scheduling with multiple clients utilising multiple rings. Now, there is no impact and we can remove the complication.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200513173504.28322-1-chris@chris-wilson.co.uk
show more ...
|