HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Технические вопросы (https://hlfx.ru/forum/forumdisplay.php?forumid=20)
-- [iOS, Android] Нубские вопросы от XaeroX (https://hlfx.ru/forum/showthread.php?threadid=5064)
Отправлено XaeroX 26-04-2019 в 11:52:
Цитата:
a1batross писал:
Для Ксаша было быстрее.
Насколько быстрее, в процентах?
И пробовали ли вы включать автоматическую генерацию неона компилятором? Или может быть, интринсики юзали?
Вам в ксаше хорошо, у вас физики нет, а меня Ньютон в этом плане очень беспокоит. В нём нет поддержки неона (только altivec и sse), а тут ещё softfp...
Добавлено 26-04-2019 в 18:52:
Цитата:
a1batross писал:
Да, пример где надо aapcs атрибут добавлять -- вызовы OpenGL. libGLES он всё же в softfp.
Спасибо, буду иметь в виду.
Если не добавить, там что будет? Ошибка компиляции или сегфолт в рантайме?__________________
Отправлено Дядя Миша 26-04-2019 в 13:35:
в андроеде еще и сегфолты есть? очуметь можно. Я и думаю, ну откуда на джаве сегфолты.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено EXL 26-04-2019 в 13:44:
Цитата:
Дядя Миша писал:
в андроеде еще и сегфолты есть? очуметь можно. Я и думаю, ну откуда на джаве сегфолты.
Так же как и в Windows или Linux. Сегфолты они в нативном коде.
Отправлено XaeroX 26-04-2019 в 14:34:
Цитата:
Дядя Миша писал:
в андроеде еще и сегфолты есть? очуметь можно.
Я бы сказал, что там почти всё состоит из сегфолтов. А задача опытного андроид-разработчика - аккуратно между ними пробираться.__________________
Отправлено a1batross 26-04-2019 в 18:55:
XaeroX давно замеры были. Я даже не помню.
Но автовекторизацией пользуемся: https://github.com/FWGS/xash3d-andr...lication.mk#L19
Ни ошибки в рантайме, ни сегфолта не будет. Это call convention. Просто в таком случае регистры где хранятся флоаты будут другие.
Добавлено 26-04-2019 в 21:55:
Softfp/hardfp это просто ABI и на использование неона оно не влияет. Оно влияет на запись/чтение из neon регистров флоатов. В softfp для neon кода соответствующие load/store будет генерироваться, а в hardfp это не нужно -- всё изначально там где надо.
Поэтому и польза hardfp сомнительна в общем случае. Но движки где float на float-е это важно.
Отправлено XaeroX 27-04-2019 в 09:40:
Цитата:
EXL писал:
То есть если ты соберёшь с API_LEVEL=26 (Android 8.0), это не значит что у тебя приложение не будет работать на 5.1; можешь проверить сам. По-крайней мере у меня приложение с высоким уровнем NDK API работает без проблем на древнем Android 2.3.3.
Собрал бинарники с апи левел 21, код не трогал.
На эмуляторе, созданном с имиджем 16 левела, имеем:
Цитата:
INFO: Running: "base_unittest"...
base_unittest: 1 file pushed. 3.9 MB/s (960740 bytes in 0.233s)
reloc_library[1306]: 785 cannot locate 'uselocale'...
CANNOT LINK EXECUTABLE
ERROR: Unit tests in bundle "base_unittest" failed!
INFO: Running: "platform_unittest"...
platform_unittest: 1 file pushed. 3.5 MB/s (847324 bytes in 0.231s)
reloc_library[1306]: 809 cannot locate 'uselocale'...
CANNOT LINK EXECUTABLE
ERROR: Unit tests in bundle "platform_unittest" failed!
И далее в таком духе.
Это вообще норма? 
Добавлено 27-04-2019 в 16:40:
Я понимаю, что могу пересоздать эмулятор с левелом 21, но разве это не означает, что на устройствах с левелом ниже 21 ничего работать не будет? __________________
Отправлено a1batross 27-04-2019 в 11:46:
XaeroX таки я ошибся, прости. Это минимальный.
Но NDK сильно не меняется. В целом, android-9 достаточно для всего, именно в этой версии добавили OpenSL ES, чтобы выводить звук не через JNI.
GLES 3 хоть и с позже API "доступен", с android-9 можно использовать с eglGetProcAddress или dlsym-ать по libGLESv2.
Кстати, как у тебя движок как GL вызовы инициализирует? Напрямую линкуется к библиотеке или все вызовы получает через *GetProcAddress? И почему именно такой вариант? Просто собираю мнения.
Отправлено XaeroX 27-04-2019 в 12:16:
Цитата:
a1batross писал:
Кстати, как у тебя движок как GL вызовы инициализирует? Напрямую линкуется к библиотеке или все вызовы получает через *GetProcAddress?
Динамически, через GPA, да.
Цитата:
a1batross писал:
И почему именно такой вариант?
Гм... Ну так исторически сложилось. Под всеми осями местная библиотека OpenGL грузится динамически, и андроид не исключение.
Я больше скажу - у нас и Direct3D динамически грузится, вот это по-настоящему весело. 
__________________
Отправлено Дядя Миша 27-04-2019 в 12:55:
XaeroX ставь сразу левел 1488, чёб наподольше хватило, ну или хотя бы 666.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено XaeroX 27-04-2019 в 15:57:
Цитата:
a1batross писал:
таки я ошибся, прости. Это минимальный.
Причём тут всё интереснее. Я сделал тулчейн 21-го левела, и sysroot там, получается, 21-й. Но при этом собирал с --target=armv7a-linux-androideabi16. И вот такая ошибка вылезает. Это никак не побороть?__________________
Отправлено a1batross 27-04-2019 в 16:42:
XaeroX не вгляделся.
А ты пробовал убрать uselocale? У Android нестандартная библиотека и локалей например там нет.
Отправлено XaeroX 27-04-2019 в 17:36:
a1batross
В том-то и дело, что я не использую никаких uselocale. Может, оно как-то неявно появляется из-за GTest/GMock. Но на 16-м тулчейне как-то работает же?
__________________
Отправлено EXL 27-04-2019 в 20:22:
Цитата:
XaeroX писал:
Собрал бинарники с апи левел 21, код не трогал.
Сейчас посмотрел, оказывается Google как раз сломал всю совместимость начиная именно с API Level 21:
https://stackoverflow.com/a/27338365
https://stackoverflow.com/a/27093163
Цитата:
For basic C functions, it shouldn't matter which target version between android-3 and android-20 you use, it should work on all of them, but if you use android-21 it only works on that version and newer.
Видимо тебе придётся собирать какие-то два тулчейна для твоей самосборной сборочной системы. Которые для 64-битных архитектур armv8-a и x86_64 будут брать android-21, а для 32-битных -- android-16. Именно этим и занимаются стандартные утилиты сборки в Android NDK (ndk-build и приправленный Google'ом CMake).
Отправлено XaeroX 28-04-2019 в 06:57:
EXL
Спасибо, помогло.
Ещё один вопрос: можно ли создать эмулятор, который может выполнять одновременно и armv8, и armv7a код?
__________________
Отправлено a1batross 28-04-2019 в 18:58:
XaeroX можно. Нужен эмулятор, который будет исполнять armv8 код.
И чтобы он исполнял armv7a код, нужен такой APK в котором 64-битного кода нет.
