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
