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
