Vulkan es una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento. Al igual que OpenGL ES (GLES), Vulkan proporciona herramientas para crear gráficos de alta calidad en tiempo real en las apps. Las ventajas de usar Vulkan incluyen reducciones en la sobrecarga de la CPU y compatibilidad con el lenguaje SPIR-V Binary Intermediate.
Para implementar Vulkan correctamente, un dispositivo debe incluir lo siguiente:
- El cargador de Vulkan proporcionado por Android
- Un controlador de Vulkan, proporcionado por SoCs, como los IHV de GPU, que implementa la API de Vulkan. Para admitir la funcionalidad de Vulkan, el dispositivo Android necesita hardware de GPU compatible con Vulkan y el controlador asociado. La GPU también debe admitir GLES 3.1 y versiones posteriores. Consulta a tu proveedor de SoC para solicitar asistencia con el controlador.
Si un dispositivo incluye un controlador de Vulkan, debe declarar las funciones del sistema FEATURE_VULKAN_HARDWARE_LEVEL y FEATURE_VULKAN_HARDWARE_VERSION, con versiones que reflejen con precisión las capacidades del dispositivo. Esto ayuda a garantizar que el dispositivo cumpla con el Documento de definición de compatibilidad (CDD).
Cargador de Vulkan
El cargador de Vulkan platform/frameworks/native/vulkan es la interfaz principal entre las apps de Vulkan y el controlador de Vulkan de un dispositivo. El cargador de Vulkan se instala en /system/lib[64]/libvulkan.so. El cargador proporciona los puntos de entrada principales de la API de Vulkan, los puntos de entrada de las extensiones que requiere el CDD de Android y muchas extensiones opcionales adicionales. El cargador exporta las extensiones de integración del sistema Windows (WSI) y las implementa principalmente en el cargador en lugar del controlador. El cargador también admite la enumeración y carga de capas que pueden exponer extensiones adicionales y interceptar llamadas a la API principales en su camino al controlador.
El NDK incluye una biblioteca de stub libvulkan.so para la vinculación. La biblioteca exporta los mismos símbolos que el cargador. Las apps llaman a las funciones exportadas de la biblioteca libvulkan.so real para ingresar funciones de trampolín en el cargador, que se envían a la capa o al controlador adecuados según su primer argumento. La llamada vkGet*ProcAddr() muestra los punteros de función a los que se envían los trampolines (es decir, llama directamente al código principal de la API). Llamar a través de los punteros de función, en lugar de los símbolos exportados, es más eficiente, ya que omite el trampolín y el envío.
Enumeración y carga de controladores
Cuando se compila la imagen del sistema, Android espera que el sistema sepa qué GPU están disponibles. El cargador usa el mecanismo de HAL existente en hardware.h para descubrir y cargar el controlador. Las rutas de acceso preferidas para los controladores de Vulkan de 32 y 64 bits son las siguientes:
/vendor/lib/hw/vulkan.<ro.hardware.vulkan>.so /vendor/lib/hw/vulkan.<ro.product.platform>.so /vendor/lib64/hw/vulkan.<ro.hardware.vulkan>.so /vendor/lib64/hw/vulkan.<ro.product.platform>.so
En Android 7.0 y versiones posteriores, la derivada hw_module_t de Vulkan une una única struct hw_module_t. Solo se admite un controlador y la cadena constante HWVULKAN_DEVICE_0 se pasa a open().
La derivada hw_device_t de Vulkan corresponde a un solo controlador que puede admitir varios dispositivos físicos. La estructura hw_device_t se puede extender para exportar funciones vkGetGlobalExtensionProperties(), vkCreateInstance() y vkGetInstanceProcAddr(). El cargador puede encontrar todas las demás funciones VkInstance(), VkPhysicalDevice() y vkGetDeviceProcAddr() llamando al vkGetInstanceProcAddr() de la estructura hw_device_t.
Descubrimiento y carga de capas
El cargador de Vulkan admite la enumeración y carga de capas que pueden exponer extensiones adicionales y, además, interceptar llamadas a la API principales en su camino hacia el controlador. Android no incluye capas en la imagen del sistema. Sin embargo, las apps pueden incluir capas en su APK.
Cuando uses capas, ten en cuenta que el modelo de seguridad y las políticas de Android difieren significativamente de los de otras plataformas. En particular, Android no permite cargar código externo en un proceso no depurable en dispositivos de producción (no con permisos de administrador), ni permite que el código externo inspeccione o controle la memoria, el estado del proceso, etcétera. Esto incluye la prohibición de guardar volcados de memoria principal, seguimientos de API, etcétera, en el disco para su inspección posterior. Solo las capas que se entregan como parte de apps no depurables están habilitadas en los dispositivos de producción, y los controladores no deben proporcionar funciones que infrinjan estas políticas.
Estos son algunos casos de uso de las capas:
- Capas de tiempo de desarrollo: Las capas de validación y los adaptadores para herramientas de seguimiento, generación de perfiles y depuración no deben instalarse en la imagen del sistema de los dispositivos de producción. Las capas de validación y las correcciones de compatibilidad para herramientas de seguimiento, generación de perfiles y depuración deben poder actualizarse sin una imagen del sistema. Los desarrolladores que quieran usar una de estas capas durante el desarrollo pueden modificar el paquete de la app, por ejemplo, agregando un archivo a su directorio de bibliotecas nativas. Se supone que los ingenieros de IHV y OEM que desean diagnosticar fallas en el envío de apps no modificables tienen acceso a compilaciones no de producción (con permisos de administrador) de la imagen del sistema, a menos que esas apps sean depurables. Para obtener más información, consulta Capas de validación de Vulkan en Android.
- Capas de utilidad: Estas capas exponen extensiones, como una capa que implementa un administrador de memoria para la memoria del dispositivo. Los desarrolladores eligen las capas y las versiones de esas capas para usarlas en su app. Las diferentes apps que usan la misma capa pueden usar versiones diferentes. Los desarrolladores eligen cuál de estas capas enviar en el paquete de su app.
- Capas insertadas (implícitas): Incluye capas como la frecuencia de fotogramas, la red social y las superposiciones del selector de juegos que proporciona el usuario o alguna otra app sin el conocimiento o consentimiento de la app. Estos métodos infringen las políticas de seguridad de Android y no son compatibles.
En el caso de las apps que no se pueden depurar, el cargador busca capas solo en el directorio de bibliotecas nativas de la app y, luego, intenta cargar cualquier biblioteca con un nombre que coincida con un patrón en particular (por ejemplo, libVKLayer_foo.so).
En el caso de las apps depurables, el cargador busca capas en /data/local/debug/vulkan y, luego, intenta cargar cualquier biblioteca que coincida con un patrón en particular.
Android permite la portabilidad de capas con cambios de entorno de compilación entre Android y otras plataformas. Para obtener detalles sobre la interfaz entre las capas y el cargador, consulta Arquitectura de las interfaces del cargador de Vulkan. Las capas de validación que mantiene Khronos se alojan en capas de validación de Vulkan.
Versiones y funciones de la API de Vulkan
En la siguiente tabla, se muestran las versiones de la API de Vulkan para varias versiones de Android.| Versión de Android | Versión de Vulkan |
|---|---|
| Android 13 | Vulkan 1.3 |
| Android 9 | Vulkan 1.1 |
| Android 7 | Vulkan 1.0 |
Descripción general de las funciones de Vulkan 1.3
Vulkan 1.3 canoniza varias extensiones que antes eran opcionales en la funcionalidad principal de Vulkan. Gran parte de esta funcionalidad se incluye con la intención de aumentar el control y la granularidad sobre la interfaz de programación de Vulkan. Las instancias de paso de renderización de un solo paso ya no necesitan objetos ni búferes de renderización de paso. Se puede reducir la cantidad total de objetos de estado de la canalización y se revisa la sincronización dentro de la API. Vulkan 1.3 tiene los mismos requisitos de hardware que Vulkan 1.2, 1.1 y 1.0, con la mayor parte de la implementación en el controlador de gráficos específico del SoC, no en el framework.
Las funciones más importantes de Vulkan 1.3 para Android son las siguientes:
- Compatibilidad con instancias de paso de renderización de un solo pase
- Compatibilidad para finalizar de inmediato una invocación de sombreador
- Mayor nivel de detalle en la creación, el uso compartido y el control de las canalizaciones
Vulkan 1.3 también incluye varias funciones más pequeñas y mejoras en la usabilidad de la API. Todos los cambios que se realizaron en la API principal de Vulkan con la revisión menor 1.3 se pueden encontrar en Revisión principal (Vulkan 1.3).
Descripción general de las funciones de Vulkan 1.2
Vulkan 1.2 incorpora varias funciones y extensiones que simplifican la superficie de la API. Esto incluye un modelo de memoria unificado e información adicional que se puede consultar desde un controlador de dispositivo. Vulkan 1.2 tiene los mismos requisitos de hardware que Vulkan 1.0 y 1.1. Toda la implementación se encuentra en el controlador de gráficos específico del SoC, no en el framework.
La función más importante de Vulkan 1.2 para Android es la compatibilidad con el almacenamiento de 8 bits.
Vulkan 1.2 también incluye varias funciones más pequeñas y mejoras en la usabilidad de la API. Todos los cambios que se realizaron en la API principal de Vulkan con la revisión menor 1.2 se pueden encontrar en Revisión principal (Vulkan 1.2).
Descripción general de las funciones de Vulkan 1.1
Vulkan 1.1 incluye compatibilidad con la interoperabilidad de memoria o sincronización, lo que permite a los OEM admitir Vulkan 1.1 en los dispositivos. Además, la interoperabilidad de memoria y sincronización permite a los desarrolladores determinar si Vulkan 1.1 es compatible con un dispositivo y usarlo de manera eficaz cuando lo sea. Vulkan 1.1 tiene los mismos requisitos de hardware que Vulkan 1.0, pero la mayor parte de la implementación se encuentra en el controlador de gráficos específico del SoC, no en el framework.
Las funciones más importantes de Vulkan 1.1 para Android son las siguientes:
- Compatibilidad con la importación y exportación de búferes de memoria y objetos de sincronización desde fuera de Vulkan (para la interoperabilidad con la cámara, los códecs y GLES)
- Compatibilidad con formatos YCbCr
Vulkan 1.1 también incluye varias funciones más pequeñas y mejoras en la usabilidad de la API. Todos los cambios que se realizaron en la API principal de Vulkan con la revisión menor 1.1 se pueden encontrar en Revisión principal (Vulkan 1.1).
Elige la compatibilidad con Vulkan
Los dispositivos Android deben admitir el conjunto de funciones de Vulkan más avanzado disponible, siempre que admitan una ABI de 64 bits y no tengan poca memoria.
Los dispositivos que se lanzan con Android 13 y versiones posteriores deben ser compatibles con Vulkan 1.3.
Los dispositivos que se inician a través de Android 10 deben admitir Vulkan 1.1.
De manera opcional, otros dispositivos pueden admitir Vulkan 1.3, 1.2 y 1.1.
Cómo admitir una versión de Vulkan
Un dispositivo Android admite una versión de Vulkan si se cumplen las siguientes condiciones:
- Agrega un controlador de Vulkan que admita la versión de Vulkan de interés (debe ser una de las versiones 1.3, 1.1 o 1.0 de Vulkan) junto con los requisitos del CDD adicionales de la versión de Android. Como alternativa, actualiza un controlador de Vulkan existente de un número de versión anterior de Vulkan.
- Para Vulkan 1.3 o 1.1, asegúrate de que la función del sistema que muestra el administrador de paquetes muestre
truepara la versión correcta de Vulkan.- Para Vulkan 1.3, la función es
PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000). - Para Vulkan 1.1, la función es
PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000).
truepara Vulkan 1.3 y Vulkan 1.1 si agregas una regla, como se muestra a continuación, a un archivodevice.mkadecuado.- Agrega lo siguiente para Vulkan 1.3:
PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.vulkan.version-1_3.xml: $(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.vulkan.version.xml
- Para Vulkan 1.3, la función es
- Agrega lo siguiente para Vulkan 1.1:
PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.vulkan.version-1_1.xml: $(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.vulkan.version.xml
Perfil de Baseline de Android (ABP)
Recomendamos que todos los dispositivos Android cumplan con el perfil de Baseline de Android 2022 más reciente, como se describe en la guía del perfil de Baseline de Android.
Cualquier dispositivo que admita Android 14 o versiones posteriores y la API de Vulkan debe cumplir con todas las funciones definidas en el perfil de Android Baseline 2021. La lista completa de la funcionalidad requerida se enumera en el archivo json del perfil de Vulkan, pero un subconjunto clave de la funcionalidad requerida incluye lo siguiente:
- Texturas comprimidas mediante ASTC y ETC
- Espacios de color variables a través de
VK_EXT_swapchain_colorspace - Sombreado de muestra y también interpolación de varios ejemplos mediante
sampleRateShading.
Integración del sistema de ventanas (WSI)
En libvulkan.so, el controlador implementa las siguientes extensiones de integración del sistema de ventanas (WSI):
VK_KHR_surfaceVK_KHR_android_surfaceVK_KHR_swapchainVK_KHR_driver_properties, implementado para Vulkan 1.1 solo en Android 10VK_GOOGLE_display_timing, implementado para cualquier versión de Vulkan en Android 10
La plataforma controla los objetos VkSurfaceKHR y VkSwapchainKHR, y todas las interacciones con ANativeWindow, y no se exponen a los controladores. La implementación de WSI se basa en la extensión VK_ANDROID_native_buffer, que debe ser compatible con el controlador. Solo la implementación de WSI usa esta extensión y no se expone a las apps.
Marcas de uso de Gralloc
Es posible que las implementaciones de Vulkan necesiten que los búferes de la cadena de intercambio se asignen con marcas de uso de Gralloc privadas definidas por la implementación. Cuando se crea un grupo de intercambio, Android le pide al controlador que traduzca el formato solicitado y las marcas de uso de la imagen en marcas de uso de Gralloc mediante la llamada a lo siguiente:
typedef enum VkSwapchainImageUsageFlagBitsANDROID {
VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID = 0x00000001,
VK_SWAPCHAIN_IMAGE_USAGE_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF
} VkSwapchainImageUsageFlagBitsANDROID;
typedef VkFlags VkSwapchainImageUsageFlagsANDROID;
VkResult VKAPI vkGetSwapchainGrallocUsage2ANDROID(
VkDevice device,
VkFormat format,
VkImageUsageFlags imageUsage,
VkSwapchainImageUsageFlagsANDROID swapchainUsage,
uint64_t* grallocConsumerUsage,
uint64_t* grallocProducerUsage
);
Los parámetros format y imageUsage se toman de la estructura VkSwapchainCreateInfoKHR. El controlador debe completar *grallocConsumerUsage y *grallocProducerUsage con las marcas de uso de Gralloc necesarias para el formato y el uso. Las marcas de uso que muestra el controlador se combinan con las que solicita el consumidor de la cadena de intercambio cuando asigna búferes.
Android 7.x llama a una versión anterior de VkSwapchainImageUsageFlagsANDROID(), llamada vkGetSwapchainGrallocUsageANDROID(). Android 8.0 y versiones posteriores dejan de admitir vkGetSwapchainGrallocUsageANDROID(), pero aún llaman a vkGetSwapchainGrallocUsageANDROID() si el controlador no proporciona vkGetSwapchainGrallocUsage2ANDROID():
VkResult VKAPI vkGetSwapchainGrallocUsageANDROID(
VkDevice device,
VkFormat format,
VkImageUsageFlags imageUsage,
int* grallocUsage
);
vkGetSwapchainGrallocUsageANDROID() no admite marcas de uso de swapchain ni marcas de uso de Gralloc extendidas.
Imágenes con copia de seguridad de Gralloc
VkNativeBufferANDROID es una estructura de extensión vkCreateImage para crear una imagen respaldada por un búfer Gralloc. VkNativeBufferANDROID se proporciona a vkCreateImage() en la cadena de estructura VkImageCreateInfo. Las llamadas a vkCreateImage() con VkNativeBufferANDROID ocurren durante la llamada a vkCreateSwapchainKHR. La implementación de WSI asigna la cantidad de búferes nativos solicitados para el búfer de intercambio y, luego, crea un VkImage para cada uno:
typedef struct {
VkStructureType sType; // must be VK_STRUCTURE_TYPE_NATIVE_BUFFER_ANDROID
const void* pNext;
// Buffer handle and stride returned from gralloc alloc()
buffer_handle_t handle;
int stride;
// Gralloc format and usage requested when the buffer was allocated.
int format;
int usage;
// Beginning in Android 8.0, the usage field above is deprecated and the
// usage2 struct below was added. The usage field is still filled in for
// compatibility with Android 7.0 drivers. Drivers for Android 8.0
// should prefer the usage2 struct, especially if the
// android.hardware.graphics.allocator HAL uses the extended usage bits.
struct {
uint64_t consumer;
uint64_t producer;
} usage2;
} VkNativeBufferANDROID;
Cuando se crea una imagen respaldada por Gralloc, VkImageCreateInfo tiene los siguientes datos:
.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO .pNext = the above VkNativeBufferANDROID structure .imageType = VK_IMAGE_TYPE_2D .format = a VkFormat matching the format requested for the gralloc buffer .extent = the 2D dimensions requested for the gralloc buffer .mipLevels = 1 .arraySize = 1 .samples = 1 .tiling = VK_IMAGE_TILING_OPTIMAL .usage = VkSwapchainCreateInfoKHR::imageUsage .flags = 0 .sharingMode = VkSwapchainCreateInfoKHR::imageSharingMode .queueFamilyCount = VkSwapchainCreateInfoKHR::queueFamilyIndexCount .pQueueFamilyIndices = VkSwapchainCreateInfoKHR::pQueueFamilyIndices
En Android 8.0 y versiones posteriores, la plataforma proporciona una estructura de extensión VkSwapchainImageCreateInfoKHR en la cadena VkImageCreateInfo proporcionada a vkCreateImage cuando se requieren marcas de uso de imágenes de la cadena de intercambio.
La estructura de extensión contiene las marcas de uso de imágenes de la cadena de intercambio:
typedef struct {
VkStructureType sType; // must be VK_STRUCTURE_TYPE_SWAPCHAIN_IMAGE_CREATE_INFO_ANDROID
const void* pNext;
VkSwapchainImageUsageFlagsANDROID usage;
} VkSwapchainImageCreateInfoANDROID;
En Android 10 y versiones posteriores, la plataforma admite VK_KHR_swapchain versión 70, por lo que la app de Vulkan puede crear una VkImage respaldada por memoria de cadena de intercambio. Primero, la app llama a vkCreateImage con una estructura VkImageSwapchainCreateInfoKHR encadenada a la estructura VkImageCreateInfo. Luego, la app llama a vkBindImageMemory2(KHR) con una estructura VkBindImageMemorySwapchainInfoKHR encadenada a la estructura VkBindImageMemoryInfo. El imageIndex especificado en la estructura VkBindImageMemorySwapchainInfoKHR debe ser un índice de imagen de cadena de intercambio válido. Mientras tanto, la plataforma proporciona una estructura de extensión VkNativeBufferANDROID con la información correspondiente del búfer de Gralloc a la cadena VkBindImageMemoryInfo, de modo que el controlador sepa con qué búfer de Gralloc vincular VkImage.
Adquiere imágenes
vkAcquireImageANDROID adquiere la propiedad de una imagen de la cadena de intercambio y, luego, importa una cerca nativa señalizada de forma externa en un objeto VkSemaphore y un objeto VkFence existentes:
VkResult VKAPI vkAcquireImageANDROID(
VkDevice device,
VkImage image,
int nativeFenceFd,
VkSemaphore semaphore,
VkFence fence
);
Se llama a vkAcquireImageANDROID() durante vkAcquireNextImageKHR para importar una cerca nativa en los objetos VkSemaphore y VkFence que proporciona la app (sin embargo, los objetos de semáforo y cerca son opcionales en esta llamada). El controlador también puede aprovechar esta oportunidad para reconocer y controlar cualquier cambio externo en el estado del búfer de Gralloc. Muchos controladores no necesitarán hacer nada aquí. Esta llamada coloca a VkSemaphore y VkFence en el mismo estado pendiente que si lo indica vkQueueSubmit, por lo que las colas pueden esperar en el semáforo y la app puede esperar en la valla.
Ambos objetos se indican cuando la valla nativa subyacente lo indica. Si la valla nativa ya lo hizo, el semáforo está en el estado indicado cuando se muestra esta función. El controlador asume la propiedad del descriptor del archivo de valla y lo cierra cuando ya no es necesario. El controlador debe hacerlo incluso si no se proporciona un objeto de semáforo ni de cerca, o incluso si vkAcquireImageANDROID falla y muestra un error. Si fenceFd es -1, es como si el perímetro nativo ya se hubiera indicado.
Imágenes de lanzamiento
vkQueueSignalReleaseImageANDROID prepara una imagen de cadena de intercambio para el uso externo, crea una cerca nativa y programa que se envíe una señal a la cerca nativa después de que los semáforos de entrada hayan enviado una señal:
VkResult VKAPI vkQueueSignalReleaseImageANDROID(
VkQueue queue,
uint32_t waitSemaphoreCount,
const VkSemaphore* pWaitSemaphores,
VkImage image,
int* pNativeFenceFd
);
vkQueuePresentKHR() llama a vkQueueSignalReleaseImageANDROID()
en la cola proporcionada. El controlador debe producir una cerca nativa que no envíe indicadores hasta que se envíen todos los semáforos waitSemaphoreCount en el indicador pWaitSemaphores y se complete cualquier trabajo adicional necesario para preparar image para la presentación.
Si ya se indicaron los semáforos de espera (si los hay) y queue ya está inactivo, el controlador puede establecer *pNativeFenceFd en -1 en lugar de un descriptor de archivo de valla nativo real, lo que indica que no hay nada que esperar. El llamador es propietario del descriptor de archivo que se muestra en *pNativeFenceFd y lo cierra.
Muchos controladores pueden ignorar el parámetro de imagen, pero es posible que algunos deban preparar estructuras de datos del lado de la CPU asociadas con un búfer de Gralloc para que los consumidores de imágenes externos las usen. La preparación del contenido del búfer para que lo usen los consumidores externos debe realizarse de forma asíncrona como parte de la transición de la imagen a VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
Si la imagen se creó con VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID, el controlador debe permitir que se llame a vkQueueSignalReleaseImageANDROID() de forma reiterada sin intervenir en las llamadas a vkAcquireImageANDROID().
Compatibilidad con imágenes presentables compartidas
Algunos dispositivos pueden compartir la propiedad de una sola imagen entre la canalización de la pantalla y la implementación de Vulkan para minimizar la latencia.
En Android 9 y versiones posteriores, el cargador anuncia de forma condicional la extensión VK_KHR_shared_presentable_image según la respuesta del controlador a una llamada a vkGetPhysicalDeviceProperties2.
Si el controlador no admite Vulkan 1.1 ni la extensión VK_KHR_physical_device_properties2, el cargador no anuncia la compatibilidad con imágenes presentables compartidas. De lo contrario, el cargador consulta las capacidades del controlador llamando a vkGetPhysicalDeviceProperties2() e incluye la siguiente estructura en la cadena VkPhysicalDeviceProperties2::pNext:
typedef struct {
VkStructureType sType; // must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENTATION_PROPERTIES_ANDROID
const void* pNext;
VkBool32 sharedImage;
} VkPhysicalDevicePresentationPropertiesANDROID;
Si el controlador puede compartir la propiedad de una imagen con el sistema de visualización, establece el miembro sharedImage en VK_TRUE.
Validación
Los OEMs pueden probar su implementación de Vulkan con CTS, que incluye lo siguiente:
- Pruebas de conformidad de Khronos Vulkan en el módulo
CtsDeqpTestCases, que incluyen pruebas funcionales de API para Vulkan 1.0, 1.1, 1.2 y 1.3. - El módulo
CtsGraphicsTestCases, que prueba que el dispositivo esté configurado correctamente para las funciones de Vulkan que admite.
Marca de función de Vulkan
Se requiere un dispositivo que admita Android 11 o versiones posteriores y la API de Vulkan para exponer una marca de función, android.software.vulkan.deqp.level. El valor de esta marca de componente es una fecha, codificada como un valor de número entero. Especifica la fecha asociada con las pruebas de dEQP de Vulkan que el dispositivo afirma aprobar.
Una fecha con el formato AAAA-MM-DD se codifica como un número entero de 32 bits de la siguiente manera:
- Los bits del 0 al 15 almacenan el año.
- Los bits 16 a 23 almacenan el mes.
- Los bits 24 a 31 almacenan el día.
El valor mínimo permitido para la marca de función es 0x07E30301, que corresponde a la fecha 01/03/2019, que es la fecha asociada con las pruebas de dEQP de Vulkan para Android 10. Si la marca de función es de al menos este valor, el dispositivo afirma que pasa todas las pruebas de dEQP de Vulkan de Android 10.
El valor 0x07E40301 corresponde a la fecha 2020-03-01, que es la fecha asociada con las pruebas de dEQP de Vulkan para Android 11. Si la marca de función es de al menos este valor, el dispositivo afirma que pasa todas las pruebas de dEQP de Vulkan de Android 11.
El valor 0x07E60301 corresponde a la fecha 01/03/2022, que es la fecha asociada con las pruebas de dEQP de Vulkan para Android 13. Si la marca de función es de al menos este valor, el dispositivo afirma que pasa todas las pruebas de dEQP de Vulkan de Android 13.
Un dispositivo que expone una marca de función específica (es decir, 0x07E30301, 0x07E40301, 0x07E60301) afirma que pasa todas las pruebas de dEQP de Vulkan de Android de esa marca de función (Android 10, Android 11 y Android 13, respectivamente). Es posible que este dispositivo apruebe las pruebas de dEQP de Vulkan de una versión posterior de Android.
El dEQP de Vulkan forma parte de CTS de Android. A partir de Android 11, el componente del ejecutor de pruebas dEQP del CTS reconoce la marca de función android.software.vulkan.deqp.level y omite todas las pruebas de dEQP de Vulkan que, según esta marca de función, el dispositivo no afirma ser compatible. Estas pruebas se informan como aprobadas de forma trivial.