Exa and dri
Michel Dänzer
michel at daenzer.net
Tue Jul 5 13:22:31 PDT 2005
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
More information about the xorg
mailing list