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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
