| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
We only emit the renderstate once now during module load, it is no
longer a concern that we are delaying context creation and so do not
need to so eagerly optimise. Since the last time we have looked at the
renderstate, we have a pin_map / flush_map facility that supports simple
single mappings, replacing the open-coded kmap_atomic() and
prepare_write. As it should be a single page, of which we only write a
small portion, we stick to a simple WB [kmap] and use clflush on !llc
platforms, rather than creating a temporary WC vmapping for the single
page.
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/20200619234543.17499-2-chris@chris-wilson.co.uk
|
|
Be consistent and ensure that we always emit the asynchronous waits
prior to issuing instructions that use the address. This ensures that if
we do emit GPU commands to do the await, they are before our use!
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200510102431.21959-1-chris@chris-wilson.co.uk
|
|
The history of i915_vma_close() is confusing, as is its use. As the
lifetime of the i915_vma is currently bounded by the object it is
attached to, we needed a means of identify when a vma was no longer in
use by userspace (via the user's fd). This is further complicated by
that only ppgtt vma should be closed at the user's behest, as the ggtt
were always shared.
Now that we attach the vma to a lut on the user's context, the open
count does indicate how many unique and open context/vm are referencing
this vma from the user. As such, we can and should just use the
open_count to track when the vma is still in use by userspace.
It's a poor man's replacement for reference counting.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1193
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200422190558.30509-1-chris@chris-wilson.co.uk
|
|
Replace the use of the printk based drm logging macros with the struct
drm_device based logging macros.
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314183344.17603-5-wambui.karugax@gmail.com
|
|
Once inside a request, inside the timeline->mutex, pinning is verboten.
<4> [896.032829] ======================================================
<4> [896.032831] WARNING: possible circular locking dependency detected
<4> [896.032835] 5.4.0-rc8-CI-Patchwork_15533+ #1 Tainted: G U
<4> [896.032838] ------------------------------------------------------
<4> [896.032841] gem_exec_parall/3720 is trying to acquire lock:
<4> [896.032844] ffff888401863270 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915]
<4> [896.032915]
but task is already holding lock:
<4> [896.032917] ffff8883ec1c93c0 (&vm->mutex){+.+.}, at: i915_vma_pin+0xf3/0x11c0 [i915]
<4> [896.032952]
which lock already depends on the new lock.
<4> [896.032954]
the existing dependency chain (in reverse order) is:
<4> [896.032956]
-> #1 (&vm->mutex){+.+.}:
<4> [896.032961] __mutex_lock+0x9a/0x9d0
<4> [896.032995] i915_vma_pin+0xf3/0x11c0 [i915]
<4> [896.033033] intel_renderstate_emit+0xb9/0x9e0 [i915]
<4> [896.033081] i915_gem_init+0x5a9/0xa50 [i915]
<4> [896.033112] i915_driver_probe+0xb00/0x15f0 [i915]
<4> [896.033144] i915_pci_probe+0x43/0x1c0 [i915]
<4> [896.033149] pci_device_probe+0x9e/0x120
<4> [896.033154] really_probe+0xea/0x420
<4> [896.033158] driver_probe_device+0x10b/0x120
<4> [896.033161] device_driver_attach+0x4a/0x50
<4> [896.033164] __driver_attach+0x97/0x130
<4> [896.033168] bus_for_each_dev+0x74/0xc0
<4> [896.033171] bus_add_driver+0x142/0x220
<4> [896.033174] driver_register+0x56/0xf0
<4> [896.033178] do_one_initcall+0x58/0x2ff
<4> [896.033183] do_init_module+0x56/0x1f8
<4> [896.033187] load_module+0x243e/0x29f0
<4> [896.033190] __do_sys_finit_module+0xe9/0x110
<4> [896.033194] do_syscall_64+0x4f/0x210
<4> [896.033197] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [896.033200]
-> #0 (&kernel#2){+.+.}:
<4> [896.033206] __lock_acquire+0x1328/0x15d0
<4> [896.033209] lock_acquire+0xa7/0x1c0
<4> [896.033213] __mutex_lock+0x9a/0x9d0
<4> [896.033255] i915_request_create+0x16/0x1c0 [i915]
<4> [896.033287] intel_engine_flush_barriers+0x4c/0x100 [i915]
<4> [896.033327] ggtt_flush+0x37/0x60 [i915]
<4> [896.033366] i915_gem_evict_something+0x46b/0x5a0 [i915]
<4> [896.033407] i915_gem_gtt_insert+0x21d/0x6a0 [i915]
<4> [896.033449] i915_vma_pin+0xb36/0x11c0 [i915]
<4> [896.033488] gen6_ppgtt_pin+0xd5/0x170 [i915]
<4> [896.033523] ring_context_pin+0x2e/0xc0 [i915]
<4> [896.033554] __intel_context_do_pin+0x6b/0x190 [i915]
<4> [896.033591] i915_gem_do_execbuffer+0x1814/0x26c0 [i915]
<4> [896.033627] i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915]
<4> [896.033632] drm_ioctl_kernel+0xa7/0xf0
<4> [896.033635] drm_ioctl+0x2e1/0x390
<4> [896.033638] do_vfs_ioctl+0xa0/0x6f0
<4> [896.033641] ksys_ioctl+0x35/0x60
<4> [896.033644] __x64_sys_ioctl+0x11/0x20
<4> [896.033647] do_syscall_64+0x4f/0x210
<4> [896.033650] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Lift the object allocation and pin prior to the request construction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202204316.2665847-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
|
|
Make sure that when submitting requests, we always serialize against
potential vma moves and clflushes.
Time for a i915_request_await_vma() interface!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819112033.30638-1-chris@chris-wilson.co.uk
|
|
We only use the init_context vfunc once while recording the default
context state, and we use the same sequence in each backend (eliding
steps that do not apply). Remove the vfunc for simplicity and
de-duplication.
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/20190729113720.24830-1-chris@chris-wilson.co.uk
|
|
The render state is used to initialise the default RCS context, and only
used during early setup from within the gt code. As such, it makes a
good candidate for placing within gt/, even if it is not yet entirely
clean of our GEM heritage.
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/20190704091925.7391-1-chris@chris-wilson.co.uk
|
