[PATCH 6/7] drm/nouveau: embed gem object in nouveau_bo

[Daniel Vetter]

On Thu, Aug 15, 2013 at 2:32 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
>> This would allow ttm to do kref_put((kref_t*)(bo +1), driver->releasefn), where driver->releasefn has to call ttm_bo_release again.
>> Unfortunately unless drm is fixed dma-buf is still going to be as buggy as before, not much I can do about that. :/
>> But this is something for a future where dma-buf in drm doesn't suck..
>
> This same issue came up with the vma-access-management patches. I
> dislike adding hacks to TTM to allow accessing the surrounding GEM
> object only to keep TTM gem-agnostic. We could fix all this with a
> simple gem_object* pointer in the ttm-bo (or a flag indicating
> container_of is valid).
>
> Or we make gem TTM-aware by optionally embedding either a ttm_bo or a
> kref object. Hm. Ideas welcome!

Imo embedding a gem bo into a ttm bo should be too harmful. I think we
already have funny lifetime issues around
ttm_bo->presistent_swap_storage, so this would imo be a win. Four
downsides afaik:
- gem shows up in drm/ttm/ ;-)
- i915 gem crap like the read/write domains get splattered even more
around. We could just move them to the i915 gem object struct and call
it a day I think.
- vmwgfx doesn't expose a gem interface. Imo this doesn't apply any
more since we have support for driver private gem objects since a
while. So shouldn't be too hard to do the final untangling and allow
non-gem drivers to init gem objects, but not link them up anywhere.
- gem_object_unref uses dev->struct_mutex. The last reason for that is
the vma manager (which can be fixed to use the same
kref_get_unless_zero trick ttm uses) and then the locking pushed down
into drivers (probably needs a deferred free list to get going).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch