Exa and dri

[Michel Dänzer]

On Tue, 2005-07-05 at 18:40 +0200, Thomas Hellström wrote:
> 
> What would be needed for the via driver is a callback struct 
> looking something like
> 
> struct _AllocatorCallbacks {
>   unsigned long (*fbGetOffset) (void *);
>   void * (*fbMalloc)(size_t);
>   void (*fbFree)(void *);
>   unsigned long fbChunkSizeHint;
> }
> 
> fbMalloc returns a pointer to an opaque type if successful, NULL otherwise.
> fbFree frees the memory associated with the pointer to the opaque type.
> fbGetAddress takes an opaque type as an argument and returns the 
> frame-buffer offset.
> fbChunkSizeHint is a hint to the exa memory manager to avoid allocating 
> smaller blocks than the value given.
> 
> Also I think the exa malloc should take a memory type argument:
> enum {mem_buffer, mem_cache};
> 
> So that if a exaMalloc(...,mem_buffer) would fail, exa would free up 
> some mem_cache memory.
> 
> Alternatively, The driver could be responsible for this logic and ask 
> exa to free up pixmap cache memory when needed.

I think that would be better indeed than having exa involved with other
allocations at all.


> >>Performance implications?
> >
> >I don't think the callbacks should have much of an impact, the external
> >memory manager may though.
> >
> I was a bit concerned for the case when exa is using the external memory 
> manager for every little pixmap. Then, even if the drm memory manager is 
> reasonably fast, doing a drm IOCTL for each allocation may not be.

True. If this turns out to be prohibitive, maybe a hybrid approach where
exa allocates large chunks (>= fbChunkSizeHint?) from the external
allocator and manages smaller allocations within these chunks internally
could be useful. Or maybe that's getting too complicated...


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer