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. :)
