Re: [RFC PATCH] drm/ttm: get rid of ttm bo refcounting

[Thomas Hellstrom <thellstrom@vmware.com>]

On 11/13/2013 12:52 AM, Maarten Lankhorst wrote:
> op 12-11-13 22:49, Thomas Hellstrom schreef:
>> On 11/12/2013 07:26 PM, Maarten Lankhorst wrote:
>>> Most drivers have refcounting done in gem, so lets get rid of another refcounting layer. ;)
>>> It has been confusing to keep track of 2 refcounts, so lets just let the driver worry about
>>> refcounting, and keep it hidden from ttm entirely. The core doesn't need to know about the
>>> refcounting anywhere.
>>>
>>> Vmwgfx has 1 bo that doesn't use vmw_dma_buffer, but instead ttm_bo_create. Converting this call
>>> makes every bo use vmw_dma_buffer as base, which means I can simply add refcount to vmw_dma_buffer.
>>>
>>> Mostly meant as a RFC, so I only took effort into converting vmwgfx, radeon, nouveau. Thoughts?
>> Hmm. I don't really see the purpose of this?
> With the patches that embed a GEM object I think it's stupid to keep another refcount. When I was playing with
> TTM in nouveau it was very unclear for me when an object is truly dead due to the various not-dead stages.
> I want to get rid of this confusion and either have a ttm object in a alive state, with the gem object still alive too,
> or in a dying state when ttm_bo_release is called and delayed destroy is used

Vmwgfx embed a ttm base object in the exact same way, and it's working 
perfectly. If there is confusion about
whether the user-interface part is alive or not, that's might to being 
sloppy when passing object pointers around.
Better go fix that up by being strict with pointer types.

The fact is with this code you're going to duplicate a large amount of 
mmap code, and the vmwgfx driver will be uglified to save an IMO 
completely irrelevant amount of memory and cpu-resources.

I believe what you want to do with the gem drivers can be accomplished 
anyway, if needed, by simply not using the ttm bo refcount, but since 
IMO ttm buffer objects are intended to be used standalone and are used 
standalone, this is a NAK for vmwgfx and TTM.

Thanks,
/Thomas