Regards, Oak > -----Original Message----- > From: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx> > Sent: January 3, 2022 1:58 PM > To: Zeng, Oak <oak.zeng@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx > Cc: Auld, Matthew <matthew.auld@xxxxxxxxx> > Subject: Re: [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@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Thomas Hellström > >> Sent: January 3, 2022 7:00 AM > >> To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx > >> Cc: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>; Auld, Matthew <matthew.auld@xxxxxxxxx> > >> Subject: [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. >
