From: Matthew Auld <matthew.auld@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 4/6] drm/i915: Use vma resources for async unbinding
Date: Thu, 6 Jan 2022 12:13:32 +0000 [thread overview]
Message-ID: <367d85bb-aa50-d7c5-e219-e5773b7a295d@intel.com> (raw)
In-Reply-To: <20220104125132.35179-5-thomas.hellstrom@linux.intel.com>
On 04/01/2022 12:51, Thomas Hellström wrote:
> Implement async (non-blocking) unbinding by not syncing the vma before
> calling unbind on the vma_resource.
> Add the resulting unbind fence to the object's dma_resv from where it is
> picked up by the ttm migration code.
> Ideally these unbind fences should be coalesced with the migration blit
> fence to avoid stalling the migration blit waiting for unbind, as they
> can certainly go on in parallel, but since we don't yet have a
> reasonable data structure to use to coalesce fences and attach the
> resulting fence to a timeline, we defer that for now.
>
> Note that with async unbinding, even while the unbind waits for the
> preceding bind to complete before unbinding, the vma itself might have been
> destroyed in the process, clearing the vma pages. Therefore we can
> only allow async unbinding if we have a refcounted sg-list and keep a
> refcount on that for the vma resource pages to stay intact until
> binding occurs. If this condition is not met, a request for an async
> unbind is diverted to a sync unbind.
>
> v2:
> - Use a separate kmem_cache for vma resources for now to isolate their
> memory allocation and aid debugging.
> - Move the check for vm closed to the actual unbinding thread. Regardless
> of whether the vm is closed, we need the unbind fence to properly wait
> for capture.
> - Clear vma_res::vm on unbind and update its documentation.
> v4:
> - Take cache coloring into account when searching for vma resources
> pending unbind. (Matthew Auld)
> v5:
> - Fix timeout and error check in i915_vma_resource_bind_dep_await().
> - Avoid taking a reference on the object for async binding if
> async unbind capable.
> - Fix braces around a single-line if statement.
>
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
<snip>
> +
> +static void
> +i915_vma_resource_color_adjust_range(struct i915_address_space *vm,
> + unsigned long *start,
> + unsigned long *end)
Make these u64, below also? Just in case this is 32b?
> +{
> + if (i915_vm_has_cache_coloring(vm)) {
> + if (start)
> + start -= I915_GTT_PAGE_SIZE;
> + end += I915_GTT_PAGE_SIZE;
*start *end :)
> + }
else {
WARN_ON_ONCE(vm->color_adjust);
}
?
> +}
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Auld <matthew.auld@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 4/6] drm/i915: Use vma resources for async unbinding
Date: Thu, 6 Jan 2022 12:13:32 +0000 [thread overview]
Message-ID: <367d85bb-aa50-d7c5-e219-e5773b7a295d@intel.com> (raw)
In-Reply-To: <20220104125132.35179-5-thomas.hellstrom@linux.intel.com>
On 04/01/2022 12:51, Thomas Hellström wrote:
> Implement async (non-blocking) unbinding by not syncing the vma before
> calling unbind on the vma_resource.
> Add the resulting unbind fence to the object's dma_resv from where it is
> picked up by the ttm migration code.
> Ideally these unbind fences should be coalesced with the migration blit
> fence to avoid stalling the migration blit waiting for unbind, as they
> can certainly go on in parallel, but since we don't yet have a
> reasonable data structure to use to coalesce fences and attach the
> resulting fence to a timeline, we defer that for now.
>
> Note that with async unbinding, even while the unbind waits for the
> preceding bind to complete before unbinding, the vma itself might have been
> destroyed in the process, clearing the vma pages. Therefore we can
> only allow async unbinding if we have a refcounted sg-list and keep a
> refcount on that for the vma resource pages to stay intact until
> binding occurs. If this condition is not met, a request for an async
> unbind is diverted to a sync unbind.
>
> v2:
> - Use a separate kmem_cache for vma resources for now to isolate their
> memory allocation and aid debugging.
> - Move the check for vm closed to the actual unbinding thread. Regardless
> of whether the vm is closed, we need the unbind fence to properly wait
> for capture.
> - Clear vma_res::vm on unbind and update its documentation.
> v4:
> - Take cache coloring into account when searching for vma resources
> pending unbind. (Matthew Auld)
> v5:
> - Fix timeout and error check in i915_vma_resource_bind_dep_await().
> - Avoid taking a reference on the object for async binding if
> async unbind capable.
> - Fix braces around a single-line if statement.
>
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
<snip>
> +
> +static void
> +i915_vma_resource_color_adjust_range(struct i915_address_space *vm,
> + unsigned long *start,
> + unsigned long *end)
Make these u64, below also? Just in case this is 32b?
> +{
> + if (i915_vm_has_cache_coloring(vm)) {
> + if (start)
> + start -= I915_GTT_PAGE_SIZE;
> + end += I915_GTT_PAGE_SIZE;
*start *end :)
> + }
else {
WARN_ON_ONCE(vm->color_adjust);
}
?
> +}
next prev parent reply other threads:[~2022-01-06 12:13 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 12:51 [Intel-gfx] [PATCH v5 0/6] drm/i915: Asynchronous vma unbinding Thomas Hellström
2022-01-04 12:51 ` Thomas Hellström
2022-01-04 12:51 ` [Intel-gfx] [PATCH v5 1/6] drm/i915: Initial introduction of vma resources Thomas Hellström
2022-01-04 12:51 ` Thomas Hellström
2022-01-06 15:22 ` [Intel-gfx] " Matthew Auld
2022-01-06 15:22 ` Matthew Auld
2022-01-04 12:51 ` [Intel-gfx] [PATCH v5 2/6] drm/i915: Use the vma resource as argument for gtt binding / unbinding Thomas Hellström
2022-01-04 12:51 ` Thomas Hellström
2022-01-06 16:01 ` [Intel-gfx] " Matthew Auld
2022-01-06 16:01 ` Matthew Auld
2022-01-04 12:51 ` [Intel-gfx] [PATCH v5 3/6] drm/i915: Don't pin the object pages during pending vma binds Thomas Hellström
2022-01-04 12:51 ` Thomas Hellström
2022-01-06 16:08 ` [Intel-gfx] " Matthew Auld
2022-01-06 16:08 ` Matthew Auld
2022-01-04 12:51 ` [Intel-gfx] [PATCH v5 4/6] drm/i915: Use vma resources for async unbinding Thomas Hellström
2022-01-04 12:51 ` Thomas Hellström
2022-01-05 15:52 ` [Intel-gfx] " Matthew Auld
2022-01-05 15:52 ` Matthew Auld
2022-01-05 16:03 ` [Intel-gfx] " Thomas Hellström
2022-01-05 16:03 ` Thomas Hellström
2022-01-06 12:13 ` Matthew Auld [this message]
2022-01-06 12:13 ` Matthew Auld
2022-01-06 16:06 ` kernel test robot
2022-01-06 16:06 ` kernel test robot
2022-01-04 12:51 ` [Intel-gfx] [PATCH v5 5/6] drm/i915: Asynchronous migration selftest Thomas Hellström
2022-01-04 12:51 ` Thomas Hellström
2022-01-04 12:51 ` [Intel-gfx] [PATCH v5 6/6] drm/i915: Use struct vma_resource instead of struct vma_snapshot Thomas Hellström
2022-01-04 12:51 ` Thomas Hellström
2022-01-04 15:56 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Asynchronous vma unbinding (rev5) Patchwork
2022-01-04 15:58 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-04 16:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-04 17:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=367d85bb-aa50-d7c5-e219-e5773b7a295d@intel.com \
--to=matthew.auld@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.