[Mesa-dev] [RFC][PATCH 4/5] Android.mk: Add option to use vendor version of mesa

[Rob Herring]

On Wed, Jul 25, 2018 at 1:52 PM John Stultz <john.stultz at linaro.org> wrote:
>
> On Wed, Jul 25, 2018 at 5:42 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> > On 25 July 2018 at 00:21, John Stultz <john.stultz at linaro.org> wrote:
> >> From: Yong Yao <yong.yao at intel.com>
> >>
> >> This is a forward port of a patch from the AOSP/master branch:
> >> https://android.googlesource.com/platform/external/mesa3d/+/b1e5fad1db4c1d51c7ae3a033b100a8429ae5415%5E%21/
> >>
> >> Which allows boards to provide their own custom copy of mesa.
> >>
> > Thanks for sorting these out John.
> >
> > My understanding was that when a custom project repo is used one
> > handles that in the device manifest. Roughly as:
> >  - foo.xml -> contains vast majority of the git repos with associated tags/etc
> >  - local.xml -> removes any repo/project from ^^, adds new one
> >
> > Is that no longer the case, or I simply misremember how Android does things?
>
> So, I'm not aware of the specific history behind this patch.

I think it is quite simple. Intel needed mesa and put it into their
device repo(s) rather than updating external/mesa3d/. I would point to
the repo, but it seems android-ia is gone...

> And I
> can't speak for Google, there has been a general push via the Treble
> efforts to standardize the Android system image, and to push vendors
> to keep any device specific bits into their own device directory.  So
> there is a strong disincentive to modify projects in AOSP and in order
> to include things like devboards into AOSP, the push has been to limit
> any device specific changes to only the device directory git tree.

I can't imagine that mesa would ever be part of the system image so
why would there be any common repository. Maybe a s/w rendering build,
but that may still be in the vendor partition and SwiftShader seems to
be preferred anyways. There seems to be little incentive to not have a
fork per device.

> So while one can technically still replace projects with local repos
> (and this is very useful for development!), I think they do not want
> folks doing this for shipping devices.
>
> We are trying to make sure device support is pushed upstream to fdo,

A fork in every device is not encouraging that. I think anyone working
on h/w support in mesa is targeting upstream anyways regardless of
what happens in AOSP.

> and then align AOSP's mesa to that, but one could imagine a board that
> doesn't have support upstream in mesa, and provides its own copy of
> mesa in the device directory. This patch allows the build to override
> the default mesa project with the vendor provided mesa.
>
> One concrete example here, which unfortunately I've not had time to
> work on, might be if we try to integrate the revived lima work to
> support HiKey's mali utgard gpu. That would require a local mesa tree
> along with the developmental kernel driver.

I'm pretty sure lima will be merged to mesa master well before either
it works with Android or anyone cares about supporting it in AOSP.

Rob