#android #vulkan #standards-compliance
#Android #vulkan #соответствие стандартам
Вопрос:
Теоретически, на Android можно выполнить запрос FEATURE_VULKAN_HARDWARE_VERSION во время выполнения, чтобы определить, имеет ли устройство рабочую реализацию Vulkan, и на основе результата либо включить (более быстрый) путь кода Vulkan, либо вернуться к OpenGL ES 3.x. Однако на практике существует довольно длинный список устройств, которые имеют Присутствуют драйверы Vulkan, но качество драйверов которых находится где-то между глючным и сломанным — это означает, что на этих устройствах использование Vulkan либо приводит к визуальным артефактам, либо к явным сбоям.
Итак, какова наилучшая практика для надежного запуска приложения с Vulkan на как можно большем количестве устройств (т. Е. Возврата к OpenGL ES для как можно меньшего количества устройств) на Android, оставляя приложение непригодным для использования из-за ошибок драйвера Vulkan на как можно меньшем количестве устройств?
Мое решение состояло бы в том, чтобы
- включите Vulkan для устройств под управлением Android 10 и выше (где драйверы Vulkan должны быть достаточно зрелыми), за исключением тех, которые находятся в черном списке, поддерживаемом вручную
- отключите Vulkan на устройствах под управлением Android 9 и ниже, если они не включены в белый список, поддерживаемый вручную
Но мне интересно, есть ли лучшие подходы или существует ли существующая библиотека или онлайн-база данных устройств о практическом использовании Vulkan?
Комментарии:
1. Помимо черных / белых списков, мы автоматически возвращаемся к OpenGLES, если было несколько неудачных загрузок. Таким образом, пользователи с проблемами Vulkan, по крайней мере, в конечном итоге смогут запустить, программное обеспечение получит возможность загружать последние черные / белые списки, и пользователь может вручную отключить Vulkan.
2. @Columbo да, использование неудачных запусков приложений в качестве индикатора нерабочего драйвера Vulkan является еще одной хорошей мерой безопасности. Однако это не защитит от тех ошибок драйвера, которые просто приводят к визуальному мусору. И вам нужно было бы установить этот предел неудачного запуска довольно низким (вероятно, до одного), поскольку пользователи, как правило, отказываются от приложения после очень немногих неудачных запусков и просто удаляют его (плюс, оставляя плохой отзыв).
3. Мы рассматриваем неудачную загрузку как ту, при которой пользователь не нажимает кнопку, чтобы перейти к целевому экрану, что, надеюсь, эффективно для обнаружения визуального мусора / черного экрана, потому что трудно нажать кнопку, которую вы не видите. Такой подход выявляет больше проблем, но мы не устанавливаем наш лимит так низко, как вы предлагаете, потому что было бы слишком много ложных срабатываний от пользователей, которые просто работают в режиме многозадачности, прежде чем что-либо делать. Кроме того, графическая сложность интерфейса очень низкая по сравнению с более поздними версиями, поэтому все еще существует множество серьезных графических проблем, которые мы не улавливаем таким образом. Все это немного чересчур.