[PATCH 6/8] drm: Add drm_gem_prime_fd_to_handle_obj

[Tvrtko Ursulin]

On 09/06/2023 18:09, Rob Clark wrote:
> On Fri, Jun 9, 2023 at 7:12 AM Tvrtko Ursulin
> <tvrtko.ursulin at linux.intel.com> wrote:
>>
>>
>> On 09/06/2023 13:44, Iddamsetty, Aravind wrote:
>>> On 09-06-2023 17:41, Tvrtko Ursulin wrote:
>>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>>
>>>> I need a new flavour of the drm_gem_prime_fd_to_handle helper, one which
>>>> will return a reference to a newly created GEM objects (if created), in
>>>> order to enable tracking of imported i915 GEM objects in the following
>>>> patch.
>>>
>>> instead of this what if we implement the open call back in i915
>>>
>>> struct drm_gem_object_funcs {
>>>
>>>           /**
>>>            * @open:
>>>            *
>>>            * Called upon GEM handle creation.
>>>            *
>>>            * This callback is optional.
>>>            */
>>>           int (*open)(struct drm_gem_object *obj, struct drm_file *file);
>>>
>>> which gets called whenever a handle(drm_gem_handle_create_tail) is
>>> created and in the open we can check if to_intel_bo(obj)->base.dma_buf
>>> then it is imported if not it is owned or created by it.
>>
>> I wanted to track as much memory usage as we have which is buffer object
>> backed, including page tables and contexts. And since those are not user
>> visible (they don't have handles), they wouldn't be covered by the
>> obj->funcs->open() callback.
>>
>> If we wanted to limit to objects with handles we could simply do what
>> Rob proposed and that is to walk the handles idr. But that does not feel
>> like the right direction to me. Open for discussion I guess.
> 
> I guess you just have a few special case objects per context?

Per context we have context image (register state etc) and ring buffer 
(command emission), per engine.

Then we have all the page table backing store per each VM/ppgtt/context 
allocated as GEM objects.

> Wouldn't it be easier to just track _those_ specially and append them
> to the results after doing the normal idr table walk?

In a way yes and in a way it is not as elegant. IMHO at least.
> (Also, doing something special for dma-buf smells a bit odd..
> considering that we also have legacy flink name based sharing as
> well.)

It's not really special, just needed to return a tuple of (object, 
handle) from the prime import helper. So it can plug into the very same 
tracking I use from other paths.

I was going for some kind of elegance with one loop - single tracking - 
as long as I had to add new list head to our buffer object.

Anyway, I can re-spin a simplified version (fewer patches) with two 
loops. Only downside is that the new list head will only be used for 
internal objects.

Regards,

Tvrtko

P.S.
Flink I indeed missed. Is that used nowadays btw?