On Thu, Aug 15, 2013 at 2:32 PM, David Herrmann <dh.herrmann@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
