[Intel-gfx] [PATCH 07/19] drm/i915: vma is always backed by an object.

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Fri Sep 3 10:48:15 UTC 2021


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


More information about the Intel-gfx mailing list