Сборка обычного и неонового ARMv7a одновременно

Поскольку у меня очень интенсивное приложение, я хотел бы создать вариант с поддержкой NEON / Advanced SIMD. Также у меня есть несколько исходных файлов с алгоритмами, поэтому я не хочу включать неон для каждого файла отдельно. После важной части Android.mk:

ifeq ($(TARGET_ARCH_ABI),armeabi-v7a)

include $(CLEAR_VARS)
# Build Advanced SIMD variant
LOCAL_MODULE            := mymod-neon
LOCAL_ARM_NEON          := true
LOCAL_ARM_MODE          := $(MY_ARM_MODE)
LOCAL_SRC_FILES         := $(MY_SRC_FILES)
LOCAL_C_INCLUDES        := $(MY_C_INCLUDES)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_SHARED_LIBRARIES  := $(MY_SHARED_LIBRARIES)
include $(BUILD_SHARED_LIBRARY)

endif

include $(CLEAR_VARS)
# Build regular variant
LOCAL_MODULE            := mymod
LOCAL_ARM_MODE          := $(MY_ARM_MODE)
LOCAL_SRC_FILES         := $(MY_SRC_FILES)
LOCAL_C_INCLUDES        := $(MY_C_INCLUDES)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_SHARED_LIBRARIES  := $(MY_SHARED_LIBRARIES)
include $(BUILD_SHARED_LIBRARY)

Я попытался собрать 2 библиотеки для ARMv7a, но, к сожалению, с помощью «расширенного» инструмента Makefile не получается, что я компилирую 2 разные библиотеки.

Он переопределяет цель .o:

/android-ndk/build/core/build-binary.mk:272: warning: overriding commands for target `obj/local/armeabi-v7a/objs/myalg.o'

К сожалению, я не нашел способа принудительно построить неоновые объекты в objs-neon вместо obj.

Есть ли способ решить это в элегантном вопросе?


android-ndk makefile neon
person abergmeier    schedule 07.04.2013    source источник
comment
для меня ваш Android.mk где-то собирает obj/local/armeabi-v7a/objs/mymod/myalg.o и obj/local/armeabi-v7a/objs/mymod-neon/myalg.o. Maybe you override NDK_APP_OUT`?   -  person Alex Cohn    schedule 07.04.2013
comment
.. или, может быть, $(MY_SRC_FILES) дважды перечисляет myalg.c?   -  person Alex Cohn    schedule 07.04.2013
comment
NEON — это опция времени выполнения в Android. Потребуется много дополнительной работы, чтобы заставить два двоичных файла ARMv7A жить вместе. Я создаю полные двоичные файлы с ARMv5 и ARMv7A, а в сборке ARMV7A я тестирую параметр времени выполнения NEON и использую его, если он есть. если (android_getCpuFamily() == ANDROID_CPU_FAMILY_ARM && (android_getCpuFeatures() & ANDROID_CPU_ARM_FEATURE_NEON) != 0)   -  person BitBank    schedule 08.04.2013
comment
@AlexCohn Но это работает, только если у вас есть два разных каталога src. Для меня они оба указывают на $(MY_SRC_FILES).   -  person abergmeier    schedule 08.04.2013
comment
@LCIDFire: нет, я использовал те же каталоги src   -  person Alex Cohn    schedule 08.04.2013
comment
Может быть, вы используете древнюю версию NDK? Сегодняшний выбор r8e! Обратите внимание, что в моем случае объект находится в подкаталоге $(LOCAL_MODULE) каталога obj/local.   -  person Alex Cohn    schedule 08.04.2013
comment
@AlexCohn Я AM использую r8e!   -  person abergmeier    schedule 08.04.2013

Ответы (2)


arrow_upward
1
arrow_downward

В итоге я сделал символическую ссылку на наш каталог src на src-neon и получил доступ ко всем источникам неона через src-neon:

ifeq ($(TARGET_ARCH_ABI),armeabi-v7a)

include $(CLEAR_VARS)
# Build Advanced SIMD variant
LOCAL_MODULE            := mymod-neon
LOCAL_ARM_NEON          := true
LOCAL_ARM_MODE          := $(MY_ARM_MODE)
LOCAL_SRC_FILES         := $(call get_sources,`src-neon`)
LOCAL_C_INCLUDES        := $(MY_C_INCLUDES)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_SHARED_LIBRARIES  := $(MY_SHARED_LIBRARIES)
include $(BUILD_SHARED_LIBRARY)

endif

include $(CLEAR_VARS)
# Build regular variant
LOCAL_MODULE            := mymod
LOCAL_ARM_MODE          := $(MY_ARM_MODE)
LOCAL_SRC_FILES         := $(call get_sources,`src`)
LOCAL_C_INCLUDES        := $(MY_C_INCLUDES)
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)
LOCAL_SHARED_LIBRARIES  := $(MY_SHARED_LIBRARIES)
include $(BUILD_SHARED_LIBRARY)

К счастью для нас, мы с самого начала решили работать только на машинах с Unix, поэтому для нас это приемлемый вариант.

person abergmeier    schedule 08.04.2013

arrow_upward
0
arrow_downward

Да, ndk-build должен разделять промежуточные объекты на отладочные и неотладочные и ISA, поэтому на самом деле я думаю, как указывали другие люди, что у вас может быть ошибка где-то еще. Обратите внимание, что ndk-build будет разделять промежуточные объекты по ISA и отладке/не отладке, но не по имени модуля. Поэтому, если несколько модулей попытаются создать один и тот же файл, у вас, вероятно, возникнут проблемы.

Сказав это, я хотел бы указать, что вы можете немного ошибиться, поскольку armeabi-v7a не подразумевает поддержку NEON. Хотя ARM представила NEON с v7a, это необязательный сопроцессор для поставщиков, поэтому процессоры v7a могут не иметь сопроцессора NEON. Так что, к сожалению, с этой информацией вы вернулись на круги своя...

У этого вопроса есть немного дубликата, здесь:

Система сборки Android, сборки NEON и не-NEON

Кроме того, в документации по сборке NDK этому посвящена целая страница. Посмотрите в своем android-ndk-r8e/documentation.html, слева есть ссылка на "CPU ARM Neon"

Одна вещь, на которую они указывают, заключается в том, что лучший способ сделать это — через диспетчеризацию ЦП, но они также показывают вам, как пометить ваши исходные файлы как неоновые или не-неоновые, используя дополнительное расширение файла .neon. ИМХО, всегда полезно помещать разный код процессора в разные исходные файлы, независимо от системы сборки, потому что вы можете удалить много уродливого препроцессора. Я думаю, это своего рода лучшая практика, и именно ее поддерживает NDK.

После всего этого, я вижу, вы остановились на решении LCID Fire. Вы создаете разные библиотеки с немного разными исходными файлами. На самом деле у вас должно быть 3 разные библиотеки: одна для не v7a, одна для v7a с неоном и одна для v7a без неона.

person Peter M    schedule 09.05.2013