[Mesa-dev] android: patches for upcoming mesa 17.0 release

[Mauro Rossi]

2017-01-18 17:40 GMT+01:00 Emil Velikov <emil.l.velikov at gmail.com>:
> On 10 January 2017 at 15:13, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 10 January 2017 at 00:52, Mauro Rossi <issor.oruam at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I'm sending a series of 12 patches for android,
>>> comprising fixes for build errors, LLVMInitializeAMDGPU* declarations,
>>> Android 7 fixes and a (small) i915 patch for feature parity with i965.
>>>
>>> Tested with nougat-x86 and marshmallow-x86
>>>
>> Nice work Mauro !
>>
>>> Mauro
>>>
>>>
>>> Changelog:
>>>
>>> [building errors/trailing whitespaces]
>>>
>>> android: st/mesa: fix building error in libmesa_st_mesa
>>> st/dri: remove trailing whitespace
>> These two
>> Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
>>
>>> android: define HAVE___BUILTIN_{FFS,FFSLL}
>>>
>> Tapani is spot on here. Patch is not needed.
>>
>>> [LLVMInitializeAMDGPU * functions declaration]
>>>
>>> android: radeon: fix LLVMInitializeAMDGPU* functions declaration
>>> android: radeonsi: fix LLVMInitializeAMDGPU* functions declaration
>>> android: amd/common: fix LLVMInitializeAMDGPU* functions declaration
>>>
>> IMHO this approach looks a lot better. Thank you !
>> Acked-by: Emil Velikov <emil.velikov at collabora.com>
>>
>> Marek, I hope you/others are OK with these ?
>>
> The above are sorted.
>
>>> [Android 7 - based on Chih-Wei single patch, now splitted for convenience]
>>>
>>> android: add support for Android 7.0 with llvm 3.8
>>> android: fix libelf include path for Android 7.0
>> As you can see from the patches things are getting very messy. Ideally
>> we won't have _all_ the Android version checks in one or two files.
>>
> Seems like I've made a few silly typos - s/won't/will/
>
>> I'm thinking of something like the following, but I'm sure you can
>> think other solutions.
>> For example:
>>
>> $ cat Android.mk // or the common.mk one if you think it's better
>>
>> case "$MESA_ANDROID_MAJOR_VERSION" in
>> 5)
>>    EGL_INCLUDES := external/elfutils/0.153
>>    OTHER_FANCY_VAR := ...
>>    ;;
>> 6)
>>    EGL_INCLUDES := external/elfutils/...
>>    OTHER_FANCY_VAR := ...
>>    ;;
>> ...
>> esac
>>
>> Then one can use $(EGL_INCLUDES) in src/amd/Android.common.mk and friends.
>>
> ... and s/EGL/ELF/
>
> Can you please rework these patches - be the in the above manner, or
> anything that helps us reach the overall goal of consolidating the
> checking/duplication.


As a first step I would keep the case/esac in the src/gallium/Android.common.mk
then it could be moved to upper Android.mk when needed by other components.
It's just that I don't completely know what would happen with mmm/mmma
build commands.

If agreed, I'll prepare "android: fix libelf include path for Android 7.0 (v2)"
with these changes and including the Android 6.0/Android 7.0 buidling rules

build test and submit in the specific mail thread.


>>> android: gallium/targets/dri: libz static dependency for Android 7.0
>> This indicates a bug in either the libelf package or the Android build
>> system itself.
>> Ideally we'll get that fixed, but we can merge this patch in as long
>> as it has a HACK XXX or similar tag + a comment.

If I understood correctly the build error, libz is a dependency needed
in Android 7.0
and Chih-Wei solved the issues by defining libz as static dependency

Is there some alternative way? How is the Automake build tackling with
the library dependency?

At the moment we don't have an alternative/better way,
so we are fine with mentioning the specific dependency/hack in the
final commit message.

Mauro



>>> [i915 functional aligment to i965 - resubmitted with changes requested]
>>>
>>> i915: add mock implementation of GL_OES_EGL_image_external (v2)
>> Did you had the change to test this wioth dEQP/other test suite ? Did
>> you notice any issues ?
>> If so please mention in the commit message.
>>
> Please follow up with the trivial comments on these two.
>
> Thanks
> Emil

Regarding dEQP we have some test sessions results for G33, performed
at the time of sync patches.

I'm running piglit run-all test sessions on i915 (i915G, gma3150, 946GZ)
unfortunately my cousin's G33 is not available at the moment.

I'll provide the result and summary package, but I may need your help
for the interpretation of the results.
Mauro