Op 03-09-2021 om 12:48 schreef Tvrtko Ursulin: > > On 03/09/2021 10:31, Maarten Lankhorst wrote: >> Op 31-08-2021 om 12:29 schreef Tvrtko Ursulin: >>> >>> On 31/08/2021 10:34, Maarten Lankhorst wrote: >>>> Op 31-08-2021 om 11:18 schreef Tvrtko Ursulin: >>>>> >>>>> On 30/08/2021 13:09, Maarten Lankhorst wrote: >>>>>> vma->obj and vma->resv are now never NULL, and some checks can be >>>>>> removed. >>>>> >>>>> Is the direction here compatible with SVM / VM_BIND? >>>> >>>> >>>> Yeah, it should be. The changes here make the obj->resv->lock the main >>>> lock, so it should at least simplify locking for VM_BIND. >>> >>> Hm but what will vma->obj point to in case of SVM, when there is no GEM BO? >> >> Probably to one of the bo's in i915_vm, or a dummy bo that least shares the >> vm_resv object, similar to the aliasing gtt handling. > > As a long term or short term solution? Worried that would waste a lot of SLAB > space just for convenience (whole struct drm_i915_gem_object just to store a > single pointer to a dma_resv object, if I got that right), while it should be > possible to come up with a cleaner design. > > Even for the upcoming page granularity work we will need multiple VMAs point > to single GEM bo in ppgtt and that, when SVM is considered, could for > instance mean that VMAs should instead be backed by some new backing store > objects, which in turn may (or may not) point to GEM BOs. > > Regards, > > Tvrtko
We could revisit this if it's required for SVM, since we can always optimize that code later, I don't think it's a problem to remove it for now, especially since it's a lot easier if VMA becomes a pointer to a memory slab for an object only, without its own lifetime rules. :)
