Re: [Intel-gfx] [PATCH v5] drm/i915: Introduce refcounted sg-tables

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 01/11/2021 13:51, Thomas Hellström wrote:
> Hi, Tvrtko
> 
> On Mon, 2021-11-01 at 13:14 +0000, Tvrtko Ursulin wrote:
>>
>> On 01/11/2021 12:24, Thomas Hellström wrote:
>>> As we start to introduce asynchronous failsafe object migration,
>>> where we update the object state and then submit asynchronous
>>> commands we need to record what memory resources are actually used
>>> by various part of the command stream. Initially for three
>>> purposes:
>>>
>>> 1) Error capture.
>>> 2) Asynchronous migration error recovery.
>>> 3) Asynchronous vma bind.
>>
>> FWIW something like this may be interesting to me as well, although I
>> haven't looked much into details yet, for the purpose of allowing
>> delayed "put pages" via decoupling from the GEM bo.
>> Two questions after glancing over:
>>
>> 1)
>> I do wonder if abstracting "sgt" away from the name would make sense?
>> Like perhaps obj->mm.pages being the location of the new abstraction
>> so
>> naming it along the lines of i915_obj_pages or something.
> 
> Well it's not yet clear how this will end up. Really this should
> develop into something along the lines of "struct i915_async_obj", on

Whole gigantic object struct will be needed for async free or for 
something more than that?

> which the sg-list is a member only. Depending on how this turns out and
> if it remains an sg-list I think your suggestion makes sense, but is it
> something we can postpone for now?

...

> 
>>
>> 2)
>> And how come obj->mm.pages remains? Does it go away later in follow
>> up work?
> 
> For the non-ttm backends, it's not yet implemented, so once they are
> either moved to TTM or updated, we can completely replace obj-
>> mm.pages.

... sure, it's your project. I assume there is some time pressure then. 
I was just asking since it looked a bit outside of the usual patterns on 
a glance.

Oh one more question, how will it work for objects which migrate between 
system and local memory? Depending on current placement either 
obj->mm.pages or obj->mm.rsgt will be valid?

Regards,

Tvrtko