Exa and dri

[Thomas Hellström]

Hi!

Michel Dänzer wrote:

>On Tue, 2005-07-05 at 09:35 +0200, Thomas Hellström wrote:
>  
>
>>2) The via driver has a drm memory manager for the frame-buffer. 
>>Currently it gets all framebuffer memory
>>except screen, cursor, virtual queue and pixmap cache at startup. Having 
>>the memory manager discussion in mind, Would it be possible to hand all 
>>memory to the drm memory manager and make Exa call that one through the 
>>driver when dri is present?  
>>    
>>
>
>I suggested using driver callbacks for memory allocation precisely for
>situations like this. Zack seems to like the idea, your input on what
>the API should look like is much appreciated. :)
>  
>
Fine. 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. Don't really know which 
is the best option, though.

>  
>
>>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.

/Thomas