[Mesa-dev] GBM and the Device Memory Allocator Proposals

Nicolai Hähnle nhaehnle at gmail.com
Thu Nov 30 09:29:19 UTC 2017


On 30.11.2017 07:28, James Jones wrote:
> This is all a really long-winded way of saying yeah I think it would be 
> technically feasible to implement GBM on top of the generic allocator 
> mechanisms, but I don't think that's a very interesting undertaking. 
> It'd just be an ABI-compatibility thing for a bunch of open-source apps, 
> which seems unnecessary in the long run since the apps can just be 
> patched instead.  Maybe it's useful as a transition mechanism though.
> 
> However, if the generic allocator is going to be something separate from 
> GBM, I think the idea of modernizing & adapting the existing GBM backend 
> infrastructure in Mesa to serve as a backend for the allocator is a good 
> idea.  Maybe it's easier to just let GBM sit on that same updated 
> backend beside the allocator API.  For GBM, all the interesting stuff 
> happens in the backend anyway.

That's precisely why I brought up the libgalloc <-> driver interface in 
another mail. If the libgalloc <-> driver interface uses the same 
extension mechanism that is in place for libgbm <-> driver today, just 
with different extensions, the transition can be made very seamless.

For example, I think we could let whatever "device handle" we use in 
that interface simply be an alias for __DRIscreen as far as drivers from 
Mesa are concerned. Other drivers (which won't implement the DRI_XXX 
extensions) won't have to concern themselves with that if they don't 
want to.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.


More information about the mesa-dev mailing list