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

[Tapani Pälli]

On 07/26/2018 08:06 PM, Rob Herring wrote:
> 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...

FYI Android-IA was renamed as 'Celadon':

https://01.org/projectceladon/

but Mesa branch is still available in the old location:

https://github.com/intel/external-mesa


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