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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
