On 1 May 2016 at 11:33, Zhen Wu <wuz...@jidemail.com> wrote: > 2016-05-01 17:46 GMT+08:00 Emil Velikov <emil.l.veli...@gmail.com>: >> >> On 30 April 2016 at 18:36, Zhen Wu <wuz...@jidemail.com> wrote: >> > 2016-04-29 18:22 GMT+08:00 Emil Velikov <emil.l.veli...@gmail.com>: >> >> >> >> On 28 April 2016 at 08:34, Chih-Wei Huang <cwhu...@android-x86.org> >> >> wrote: >> >> > From: WuZhen <wuz...@jidemail.com> >> >> > >> >> > Support multilib compilation use runtime feature selection. >> >> > >> >> > NO_REF_TASK >> >> > tested: local run >> >> > >> >> > Change-Id: Iee7961effdecde09cfbdaf09455bfb0912699ae3 >> >> > Signed-off-by: Chih-Wei Huang <cwhu...@linux.org.tw> >> >> > --- >> >> > Android.common.mk | 21 ++++++++++++++++++--- >> >> > Android.mk | 5 ----- >> >> > src/mapi/Android.mk | 3 +++ >> >> > src/mesa/Android.gen.mk | 25 ++++++++++++++++++------- >> >> > src/mesa/Android.libmesa_dricore.mk | 20 +++++++++----------- >> >> > src/mesa/Android.libmesa_sse41.mk | 5 ++++- >> >> > src/mesa/Android.libmesa_st_mesa.mk | 20 +++++++++----------- >> >> > src/mesa/Android.mesa_gen_matypes.mk | 7 +++++-- >> >> > src/mesa/drivers/dri/i965/Android.mk | 5 ----- >> >> > 9 files changed, 66 insertions(+), 45 deletions(-) >> >> > >> >> >> >> Afact this patch does a few things: >> >> - Moves -DUSE_SSE41 to the top level - good idea [patch 1] >> >> - Consolidates -msse41 to libmesa_sse41.mk (effectively adding it to >> >> st_mesa) - good idea/bugfix. >> >> Take a look into configure.ac's add -mstackrealign (and the commit >> >> that introduced it). You might want the same/similar fix. [patch 2] >> >> >> >> - Forces SSE4.1 even if there is no support for it. I.e. >> >> ARCH_X86_HAVE_SSE4_1 checks were dropped - very bad idea, please >> >> don't. >> > >> > >> > mesa seems always check for SSE4.1 support before using any of sse4.1 >> > functions, if you are talking about compiler support for sse4.1, the >> > toolchain used in android should always support this. I only changed >> > that >> > into always generate sse4.1 and rely on those runtion checks to avoid >> > issues >> > on system without sse4.1 support, do you think this is a issue? >> > >> I'm thinking about a few things here: >> - If someone is to have a hacked kernel which always advertises >> SSE4.1, even if it's not done natively but via emulation. >> Thus the actual usefulness of these codepaths will be... limited. >> - The patch removes what seems to me a good approach only to replace >> it with a hacky version - the x86/x86-64 specific flags. > > > If someone were go to such length as to faking CPUID results, there is > really nothing we can do to stop them. The issue with > original flag is that it makes this feature test solely in build time, when > that flag is defined, it add -msse4.1 globally. but if undefined, we're > crippling users that do have SSE4.1 support. And I think this is the same > behavior as with autoconf builds, where USE_SSE41 is defined > if the compiler supports it. > ) As Android doesn't have the build time check, we fall back to the next best thing - the ARCH_X86_HAVE_SSE4_1 toggle. Does the [customised] profile set it - yes? let's use it.
Then again as the compiler is/should be ok with -msse4.1 code, an you prefer to have it for every x86/x86-64 so be it. Please include (some of) the justification in the commit message. Question - can we have single static library/cflags as opposed to the current _x86 and _x86_64 split ? If so please fold them. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
