From: "Zeng, Oak" <oak.zeng@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Cc: "Auld, Matthew" <matthew.auld@intel.com>
Subject: RE: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
Date: Mon, 3 Jan 2022 23:08:59 +0000 [thread overview]
Message-ID: <BN6PR11MB1633BB7DDA0486B79F6B6C2492499@BN6PR11MB1633.namprd11.prod.outlook.com> (raw)
In-Reply-To: <c501276b-58f4-9764-30d2-5da2ae00e7e9@linux.intel.com>
Regards,
Oak
> -----Original Message-----
> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Sent: January 3, 2022 1:58 PM
> To: Zeng, Oak <oak.zeng@intel.com>; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Auld, Matthew <matthew.auld@intel.com>
> Subject: Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
>
> Hi, Oak.
>
> On 1/3/22 19:17, Zeng, Oak wrote:
> >
> > Regards,
> > Oak
> >
> >> -----Original Message-----
> >> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Thomas Hellström
> >> Sent: January 3, 2022 7:00 AM
> >> To: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> >> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>; Auld, Matthew <matthew.auld@intel.com>
> >> Subject: [Intel-gfx] [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding
> >>
> >> When introducing asynchronous unbinding, the vma itself may no longer
> >> be alive when the actual binding or unbinding takes place.
> > Can we take an extra reference counter of the vma to keep the vma alive, until the actual binding/unbinding takes place?
>
> The point here is that that's not needed, and should be avoided.
Can you explain more why "keeping vma alive until unbinding takes place" should be avoided?
As I understand it, your series introduce asynchronized unbinding. But since vma might be no longer alive at the time of unbinding. To overcome this difficulty, you introduce a vma resource structure and you guarantee vma resource is alive at bind/unbind time. So you can use vma resource for the bind/unbind operation. My question is, can we achieve the asynchronized unbinding still using vma structure by keeping vma structure alive ( by ref count it). This way the change should be much smaller (compared to this series). Why it is harmful to keep the vma alive? Maybe you have other reasons to introduce vma resource that I don't see.
Regards,
Oak
If the
> vma is no longer alive, that means nobody uses it anymore, but the GPU
> may still have work in the pipe that references the GPU virtual address.
>
> /Thomas.
>
next prev parent reply other threads:[~2022-01-03 23:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-03 11:59 [PATCH v4 0/4] drm/i915: Asynchronous vma unbinding Thomas Hellström
2022-01-03 11:59 ` [PATCH v4 1/4] drm/i915: Initial introduction of vma resources Thomas Hellström
2022-01-03 11:59 ` [PATCH v4 2/4] drm/i915: Use the vma resource as argument for gtt binding / unbinding Thomas Hellström
2022-01-03 18:17 ` [Intel-gfx] " Zeng, Oak
2022-01-03 18:57 ` Thomas Hellström
2022-01-03 23:08 ` Zeng, Oak [this message]
2022-01-04 8:29 ` Thomas Hellström
2022-01-04 15:35 ` Zeng, Oak
2022-01-04 16:07 ` Thomas Hellström
2022-01-05 13:44 ` Thomas Hellström
2022-01-05 17:59 ` Zeng, Oak
2022-01-03 11:59 ` [PATCH v4 3/4] drm/i915: Use vma resources for async unbinding Thomas Hellström
2022-01-03 11:59 ` [PATCH v4 4/4] drm/i915: Use struct vma_resource instead of struct vma_snapshot Thomas Hellström
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=BN6PR11MB1633BB7DDA0486B79F6B6C2492499@BN6PR11MB1633.namprd11.prod.outlook.com \
--to=oak.zeng@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).