[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