On 18 January 2017 at 18:09, Mauro Rossi <issor.or...@gmail.com> wrote:
> 2017-01-18 17:40 GMT+01:00 Emil Velikov <emil.l.veli...@gmail.com>:
>> On 10 January 2017 at 15:13, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>>> On 10 January 2017 at 00:52, Mauro Rossi <issor.or...@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.veli...@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.veli...@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.
>
Ack. ty.
>
>>>> 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.
>
On Linux both libelf and libLLVM require/depend on libz. Former of
which is a shared library and correctly links against libz, while the
latter can be either shared or static.
In the shared case - the link is correctly done in the library itself,
while for static we fetch it (and others) via llvm-config
--system-libs.
> 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.
In general you want a run before and after the patches. This way you
can compare fixes/regressions.
./piglit summary console --diff result_path1 result_path2
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
