| Age | Commit message (Collapse) | Author |
|---|
|
If we pipeline the PTE updates and then do the copy of those pages
within a single unpreemptible command packet, we can submit the copies
and leave them to be scheduled without having to synchronously wait
under a global lock. In order to manage migration, we need to
preallocate the page tables (and keep them pinned and available for use
at any time), causing a bottleneck for migrations as all clients must
contend on the limited resources. By inlining the ppGTT updates and
performing the blit atomically, each client only owns the PTE while in
use, and so we can reschedule individual operations however we see fit.
And most importantly, we do not need to take a global lock on the shared
vm, and wait until the operation is complete before releasing the lock
for others to claim the PTE for themselves.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210617063018.92802-8-thomas.hellstrom@linux.intel.com
|
|
Trivial checkpatch cleanup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122192913.4518-2-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Clean up the SPDX licence declarations to comply with checkpatch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122192913.4518-1-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass ww at a point where we could still handle -EDEADLK safely.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200819140904.1708856-15-maarten.lankhorst@linux.intel.com
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
The intel_ring.head is updated as the requests are retired, but is
sampled at any time as we submit requests. Furthermore, it tracks
RING_HEAD which is inherently asynchronous.
[ 148.630314] BUG: KCSAN: data-race in execlists_dequeue [i915] / i915_request_retire [i915]
[ 148.630349]
[ 148.630374] write to 0xffff8881f4e28ddc of 4 bytes by task 90 on cpu 2:
[ 148.630752] i915_request_retire+0xed/0x770 [i915]
[ 148.631123] retire_requests+0x7a/0xd0 [i915]
[ 148.631491] engine_retire+0xa6/0xe0 [i915]
[ 148.631523] process_one_work+0x3af/0x640
[ 148.631552] worker_thread+0x80/0x670
[ 148.631581] kthread+0x19a/0x1e0
[ 148.631609] ret_from_fork+0x1f/0x30
[ 148.631629]
[ 148.631652] read to 0xffff8881f4e28ddc of 4 bytes by task 14288 on cpu 3:
[ 148.632019] execlists_dequeue+0x1300/0x1680 [i915]
[ 148.632384] __execlists_submission_tasklet+0x48/0x60 [i915]
[ 148.632770] execlists_submit_request+0x38e/0x3c0 [i915]
[ 148.633146] submit_notify+0x8f/0xc0 [i915]
[ 148.633512] __i915_sw_fence_complete+0x5d/0x3e0 [i915]
[ 148.633875] i915_sw_fence_complete+0x58/0x80 [i915]
[ 148.634238] i915_sw_fence_commit+0x16/0x20 [i915]
[ 148.634613] __i915_request_queue+0x60/0x70 [i915]
[ 148.634985] i915_gem_do_execbuffer+0x2de0/0x42b0 [i915]
[ 148.635366] i915_gem_execbuffer2_ioctl+0x2ab/0x580 [i915]
[ 148.635400] drm_ioctl_kernel+0xe9/0x130
[ 148.635429] drm_ioctl+0x27d/0x45e
[ 148.635456] ksys_ioctl+0x89/0xb0
[ 148.635482] __x64_sys_ioctl+0x42/0x60
[ 148.635510] do_syscall_64+0x6e/0x2c0
[ 148.635542] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 645.071436] BUG: KCSAN: data-race in gen8_emit_fini_breadcrumb [i915] / i915_request_retire [i915]
[ 645.071456]
[ 645.071467] write to 0xffff8881efe403dc of 4 bytes by task 14668 on cpu 3:
[ 645.071647] i915_request_retire+0xed/0x770 [i915]
[ 645.071824] i915_request_create+0x6c/0x160 [i915]
[ 645.072000] i915_gem_do_execbuffer+0x206d/0x42b0 [i915]
[ 645.072177] i915_gem_execbuffer2_ioctl+0x2ab/0x580 [i915]
[ 645.072194] drm_ioctl_kernel+0xe9/0x130
[ 645.072208] drm_ioctl+0x27d/0x45e
[ 645.072222] ksys_ioctl+0x89/0xb0
[ 645.072235] __x64_sys_ioctl+0x42/0x60
[ 645.072248] do_syscall_64+0x6e/0x2c0
[ 645.072263] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 645.072275]
[ 645.072285] read to 0xffff8881efe403dc of 4 bytes by interrupt on cpu 2:
[ 645.072458] gen8_emit_fini_breadcrumb+0x158/0x300 [i915]
[ 645.072636] __i915_request_submit+0x204/0x430 [i915]
[ 645.072809] execlists_dequeue+0x8e1/0x1680 [i915]
[ 645.072982] __execlists_submission_tasklet+0x48/0x60 [i915]
[ 645.073154] execlists_submit_request+0x38e/0x3c0 [i915]
[ 645.073330] submit_notify+0x8f/0xc0 [i915]
[ 645.073499] __i915_sw_fence_complete+0x5d/0x3e0 [i915]
[ 645.073668] i915_sw_fence_wake+0xc2/0x130 [i915]
[ 645.073836] __i915_sw_fence_complete+0x2cf/0x3e0 [i915]
[ 645.074006] i915_sw_fence_complete+0x58/0x80 [i915]
[ 645.074175] dma_i915_sw_fence_wake+0x3e/0x80 [i915]
[ 645.074344] signal_irq_work+0x62f/0x710 [i915]
[ 645.074360] irq_work_run_list+0xd7/0x110
[ 645.074373] irq_work_run+0x1d/0x50
[ 645.074386] smp_irq_work_interrupt+0x21/0x30
[ 645.074400] irq_work_interrupt+0xf/0x20
[ 645.074414] _raw_spin_unlock_irqrestore+0x34/0x40
[ 645.074585] execlists_submission_tasklet+0xde/0x170 [i915]
[ 645.074602] tasklet_action_common.isra.0+0x42/0x90
[ 645.074617] __do_softirq+0xc8/0x206
[ 645.074629] irq_exit+0xcd/0xe0
[ 645.074642] do_IRQ+0x44/0xc0
[ 645.074654] ret_from_intr+0x0/0x1c
[ 645.074667] finish_task_switch+0x73/0x230
[ 645.074679] __schedule+0x1c5/0x4c0
[ 645.074691] schedule+0x45/0xb0
[ 645.074704] worker_thread+0x194/0x670
[ 645.074716] kthread+0x19a/0x1e0
[ 645.074729] ret_from_fork+0x1f/0x30
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200407221832.15465-1-chris@chris-wilson.co.uk
|
|
If we rewind the RING_TAIL on a context, due to a preemption event, we
must force the context restore for the RING_TAIL update to be properly
handled. Rather than note which preemption events may cause us to rewind
the tail, compare the new request's tail with the previously submitted
RING_TAIL, as it turns out that timeslicing was causing unexpected
rewinds.
<idle>-0 0d.s2 1280851190us : __execlists_submission_tasklet: 0000:00:02.0 rcs0: expired last=130:4698, prio=3, hint=3
<idle>-0 0d.s2 1280851192us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 66:119966, current 119964
<idle>-0 0d.s2 1280851195us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4698, current 4695
<idle>-0 0d.s2 1280851198us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4696, current 4695
^---- Note we unwind 2 requests from the same context
<idle>-0 0d.s2 1280851208us : __i915_request_submit: 0000:00:02.0 rcs0: fence 130:4696, current 4695
<idle>-0 0d.s2 1280851213us : __i915_request_submit: 0000:00:02.0 rcs0: fence 134:1508, current 1506
^---- But to apply the new timeslice, we have to replay the first request
before the new client can start -- the unexpected RING_TAIL rewind
<idle>-0 0d.s2 1280851219us : trace_ports: 0000:00:02.0 rcs0: submit { 130:4696*, 134:1508 }
synmark2-5425 2..s. 1280851239us : process_csb: 0000:00:02.0 rcs0: cs-irq head=5, tail=0
synmark2-5425 2..s. 1280851240us : process_csb: 0000:00:02.0 rcs0: csb[0]: status=0x00008002:0x00000000
^---- Preemption event for the ELSP update; note the lite-restore
synmark2-5425 2..s. 1280851243us : trace_ports: 0000:00:02.0 rcs0: preempted { 130:4698, 66:119966 }
synmark2-5425 2..s. 1280851246us : trace_ports: 0000:00:02.0 rcs0: promote { 130:4696*, 134:1508 }
synmark2-5425 2.... 1280851462us : __i915_request_commit: 0000:00:02.0 rcs0: fence 130:4700, current 4695
synmark2-5425 2.... 1280852111us : __i915_request_commit: 0000:00:02.0 rcs0: fence 130:4702, current 4695
synmark2-5425 2.Ns1 1280852296us : process_csb: 0000:00:02.0 rcs0: cs-irq head=0, tail=2
synmark2-5425 2.Ns1 1280852297us : process_csb: 0000:00:02.0 rcs0: csb[1]: status=0x00000814:0x00000000
synmark2-5425 2.Ns1 1280852299us : trace_ports: 0000:00:02.0 rcs0: completed { 130:4696!, 134:1508 }
synmark2-5425 2.Ns1 1280852301us : process_csb: 0000:00:02.0 rcs0: csb[2]: status=0x00000818:0x00000040
synmark2-5425 2.Ns1 1280852302us : trace_ports: 0000:00:02.0 rcs0: completed { 134:1508, 0:0 }
synmark2-5425 2.Ns1 1280852313us : process_csb: process_csb:2336 GEM_BUG_ON(!i915_request_completed(*execlists->active) && !reset_in_progress(execlists))
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Referenecs: 82c69bf58650 ("drm/i915/gt: Detect if we miss WaIdleLiteRestore")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.4+
Link: https://patchwork.freedesktop.org/patch/msgid/20200207211452.2860634-1-chris@chris-wilson.co.uk
|
|
Split the legacy submission backend from the common CS ring buffer
handling.
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/20191024100344.5041-1-chris@chris-wilson.co.uk
|
