android: pull gbm_gralloc in-tree
Just capturing some notes from an idea that @krh and I chatted about earlier about how to better deal with multiple different grallocs, and refining on it a bit:
- Since we pulled in enough android headers to build mesa for android in CI (!6112 (merged)), we could probably extend that to building gbm_gralloc in-tree. So why don't we pull gbm_gralloc into the mesa tree and build it as part of mesa?
- Add gbm_gralloc support for !6055 (f88b9eb9) to catch it up to date with platform_android.c
- Going forward, if we need to add new gralloc interfaces to platform_android.c, then first add it to gbm_gralloc (in mesa tree) and make $other_gralloc compatible with that interface.. making the in-tree gbm_gralloc essentially the reference gralloc implementation for mesa.
Open issues:
- What about
perform()
interfaces added to $other_gralloc for things other than mesa?- Not sure if this is much more than a theoretical concern? But I guess it isn't much of a hardship to add placeholder
#define
s for those in gbm_gralloc?
- Not sure if this is much more than a theoretical concern? But I guess it isn't much of a hardship to add placeholder
- What about drm_gralloc?
- This is kind of orthogonal.. we should treat drm_gralloc as legacy, and not add new
perform()
interfaces specific to drm_gralloc. In general it would be a nice cleanup to remove the dri2/flink (ie. drm_gralloc) support from platform_android.c, but I think we can give the drm_gralloc users a bit of time to migrate. See also #3415 (closed).. updating drm_gralloc to use dri3 exclusively (rendernodes and dmabuf) is ofc an option, but at that point why not just switch to gbm_gralloc?
- This is kind of orthogonal.. we should treat drm_gralloc as legacy, and not add new
/cc @roman.stratiienko, @tpalli, @gurchetansingh, @john.stultz, @issor.oruam,