On 09/06/2023 18:09, Rob Clark wrote:
On Fri, Jun 9, 2023 at 7:12 AM Tvrtko Ursulin
<tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
On 09/06/2023 13:44, Iddamsetty, Aravind wrote:
On 09-06-2023 17:41, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
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?
