Vulkan es una solución de baja sobrecarga, API multiplataforma para 3D de alto rendimiento gráficos. Al igual que OpenGL ES (GLES), Vulkan proporciona herramientas para crear imágenes de alta calidad gráficos en tiempo real en las apps. Las ventajas de usar Vulkan incluyen reducciones en el uso de CPU y compatibilidad con el lenguaje SPIR-V Binary init.
Para implementar Vulkan correctamente, un dispositivo debe incluir lo siguiente:
- El cargador de Vulkan proporcionado por Android
- Un controlador de Vulkan, proporcionado por SoC, como IHV de GPU, que implementa API de Vulkan: Para admitir la funcionalidad de Vulkan, el sistema operativo El dispositivo necesita hardware de GPU compatible con Vulkan y el controlador asociado. La GPU también debe ser compatible con GLES 3.1 y versiones posteriores. Consulta a tu proveedor de SoC para solicitar asistencia del conductor.
Si un dispositivo incluye un controlador de Vulkan, este debe declarar
FEATURE_VULKAN_HARDWARE_LEVEL y
funciones del sistema de FEATURE_VULKAN_HARDWARE_VERSION, con versiones que
las capacidades del dispositivo. Esto ayuda a garantizar que la
dispositivo cumple con
el Documento de definición de compatibilidad (CDD).
Cargador de Vulkan
El cargador de Vulkan platform/frameworks/native/vulkan es el
Es la interfaz principal entre las apps de Vulkan y el controlador de Vulkan de un dispositivo. La biblioteca de Vulkan
El cargador está instalado en /system/lib[64]/libvulkan.so. El cargador
proporciona los principales puntos de entrada de la API de Vulkan, los puntos de entrada de extensiones
que requiere el CDD de Android y muchas extensiones opcionales adicionales. Ventana
El cargador exporta las extensiones de integración de sistemas (WSI) y, principalmente,
que se implementan en el cargador,
en lugar del controlador. El cargador también admite
enumeración y carga de capas que pueden exponer extensiones adicionales e interceptar
llamadas a la API principales
en camino al controlador.
El NDK incluye una biblioteca libvulkan.so de stub para
la vinculación. La biblioteca exporta los mismos símbolos que el cargador. Las apps llaman a las funciones
se exportan de la biblioteca real de libvulkan.so a
ingresar funciones disparadoras en el cargador, que envían el código al
o un controlador basado en su primer argumento. El vkGet*ProcAddr()
muestra los punteros de función a los que envían los trampolines (es decir,
llama directamente al código principal de la API). Llama a través de la función
punteros de video, en lugar de los símbolos exportados, es más eficiente, ya que
omita el trampolín y salga de la oficina.
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 un solo 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
que admite varios dispositivos físicos. El
La estructura hw_device_t se puede extender para exportar
vkGetGlobalExtensionProperties(), vkCreateInstance() y
vkGetInstanceProcAddr(). El cargador puede encontrar todas las demás
VkInstance(), VkPhysicalDevice() y
funciones vkGetDeviceProcAddr() llamando a
el 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 e interceptar llamadas a la API principal 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 Carga de código externo en un proceso no depurable en producción (sin permisos de administrador) ni permite que un código externo inspeccione o controle la información memoria, estado, etcétera. Esto incluye la prohibición de guardar volcados de núcleo, API registros, y así sucesivamente, en el disco para su posterior inspección. Solo las capas entregadas como parte de las apps no depurables están habilitadas en los dispositivos de producción y los controladores no deben funcionalidades que incumplan estas políticas.
Los casos de uso de las capas incluyen los siguientes:
- Capas de tiempo de desarrollo: Validación capas y correcciones de compatibilidad 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. Capas de validación y corrección de compatibilidad Las herramientas de seguimiento, generación de perfiles y depuración deben poder actualizarse sin un sistema. imagen. Los desarrolladores que quieran usar uno de estas capas durante el desarrollo puede modificar el paquete de la app, por ejemplo, agregando un archivo a su directorio de bibliotecas nativas. Ingenieros de IHV y OEM que si quieres diagnosticar fallas en el envío de apps que no se pueden modificar, se supone que acceso a compilaciones de la imagen del sistema que no son de producción (con permisos de administrador), a menos que esas apps son depurables. Para obtener más información, consulta Capas de validación de Vulkan en Android.
- Capas de utilidad: Estas capas exponen como una capa que implementa un administrador de memoria para la memoria del dispositivo. Los desarrolladores eligen capas, y versiones de esas capas, para usar en sus aplicación; las diferentes aplicaciones que usan la misma capa aún pueden usar en diferentes versiones. Los desarrolladores eligen cuál de estas capas enviar en su paquete de app.
- Capas inyectadas (implícitas): Incluye capas como las siguientes: superposiciones de velocidad de fotogramas, redes sociales y selectores de juegos que proporciona el usuario o alguna otra app sin el conocimiento o consentimiento de la app. Estos Incumplen las políticas de seguridad de Android y no se admiten.
Para apps no depurables, el cargador solo busca capas en el
directorio de bibliotecas nativas de la app y, luego, intenta cargar cualquier biblioteca con un nombre.
que coinciden con un patrón en particular (por ejemplo, libVKLayer_foo.so).
En apps depurables, el cargador busca capas en
/data/local/debug/vulkan y, luego, intenta cargar cualquier biblioteca que coincida
un patrón 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 la cargador, consulta Arquitectura de las interfaces del cargador de Vulkan. La infraestructura administrada por Khronos capas de validación se alojan en Capas de validación de Vulkan.
Versiones y capacidades de la API de Vulkan
En la siguiente tabla, se enumeran 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 la funcionalidad 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 el nivel de detalle en la interfaz de programación de Vulkan. Las instancias de pase de renderización de un solo pase ya no necesitan objetos de pase de renderización o búferes de fotogramas. Se puede reducir la cantidad total de objetos de estado de canalización. y 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 gráfico específico para SoC, en el framework.
Las funciones más importantes de Vulkan 1.3 para Android son las siguientes:
- Compatibilidad con instancias de pase de renderización de un solo paso
- Compatibilidad con la finalización inmediata de una invocación del sombreador
- Mayor nivel de detalle en la creación, el uso compartido y el control de canalizaciones
Vulkan 1.3 también incluye varias funciones más pequeñas y mejoras en la usabilidad de la API. Todos los cambios a la API principal de Vulkan con la revisión menor 1.3 puede encontrarse en Revisiones principales (Vulkan 1.3).
Descripción general de la funcionalidad 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. todos los o la implementación está en el controlador gráfico específico de 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 a la API principal de Vulkan con la revisión menor 1.2 puede encontrarse en Revisiones principales (Vulkan 1.2).
Descripción general de la funcionalidad de Vulkan 1.1
Vulkan 1.1 incluye compatibilidad con interoperabilidad de memoria/sincronización, que permite que los OEMs admitan Vulkan 1.1 en dispositivos. Además: de memoria/sincronización permite a los desarrolladores para determinar si un dispositivo admite Vulkan 1.1 y usarlo de manera eficaz. cuando lo es. Vulkan 1.1 tiene los mismos requisitos de hardware que Vulkan 1.0, pero la mayoría de las la implementación está en el controlador gráfico específico del SOC, no en el marco.
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 sincronización objetos externos a 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 a la API principal de Vulkan con la revisión menor 1.1 puede encontrarse en Revisiones principales (Vulkan 1.1).
Elige la compatibilidad con Vulkan
Los dispositivos Android deben admitir el conjunto de funciones de Vulkan más avanzado, siempre y cuando admiten una ABI de 64 bits y no requieren poca memoria.
Los dispositivos que se lanzan con Android 13 y versiones posteriores deben ser compatibles con Vulkan 1.3.
Los dispositivos que se lanzan mediante Android 10 deben ser compatibles con 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 que te interesa (debe ser una de la versión de Vulkan) 1.3, 1.1 o 1.0) junto con los requisitos adicionales del CDD de las 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 agregando 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 Android Baseline (ABP)
Recomendamos que todos los dispositivos Android cumplan con el perfil de Android Baseline 2022 más reciente, como descritos en las Guía de perfil del modelo de referencia de Android
Todos los dispositivos compatibles con Android 14 o versiones posteriores y la API de Vulkan deben
cumplir con todas las funcionalidades definidas en el
Perfil de Android Baseline 2021. Puedes encontrar la lista completa de las funciones requeridas
enumerados en el archivo json del perfil de Vulkan, pero un subconjunto clave de la
incluye lo siguiente:
- Texturas comprimidas a través de ASTC y ETC
- Espacios de color variables a través de
VK_EXT_swapchain_colorspace. - Sombreado de muestra e interpolación de varios ejemplos a través de
sampleRateShading
Integración del sistema de ventanas (WSI)
En libvulkan.so, el controlador implementa lo siguiente:
Extensiones de integración de sistemas de ventanas (WSI):
VK_KHR_surfaceVK_KHR_android_surfaceVK_KHR_swapchainVK_KHR_driver_properties, implementado para Vulkan 1.1 en Solo para Android 10VK_GOOGLE_display_timing, implementado para cualquier versión de Vulkan en Android 10
Los objetos VkSurfaceKHR y VkSwapchainKHR, y todos
Las interacciones con ANativeWindow son administradas por la plataforma y no
a los conductores. La implementación de WSI se basa en el
VK_ANDROID_native_buffer, que debe tener
compatibles con el conductor; solo la implementación de WSI usa esta extensión
y no está expuesta a apps.
Marcas de uso de Gralloc
Es posible que las implementaciones de Vulkan necesiten que se asignen búferes de cadena de intercambio marcas de uso privadas de Gralloc definidas por la implementación. Cuando creas una cadena de intercambio, Android le solicita al controlador que traduzca el formato solicitado y el uso de imágenes. marca en marcas de uso de Gralloc llamando al siguiente comando:
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 debería completar
*grallocConsumerUsage y *grallocProducerUsage con
las marcas de uso de Gralloc necesarias para el formato
y uso. Las marcas de uso que muestra el controlador se combinan con el uso.
marcas solicitadas por el consumidor de la cadena de intercambio cuando se asignan los búferes.
Android 7.x llama a una versión anterior de VkSwapchainImageUsageFlagsANDROID(),
llamado vkGetSwapchainGrallocUsageANDROID(). Android 8.0 y versiones posteriores dejarán de estar disponibles
vkGetSwapchainGrallocUsageANDROID(), pero aún llama
vkGetSwapchainGrallocUsageANDROID() si
El conductor no proporcionó vkGetSwapchainGrallocUsage2ANDROID():
VkResult VKAPI vkGetSwapchainGrallocUsageANDROID(
VkDevice device,
VkFormat format,
VkImageUsageFlags imageUsage,
int* grallocUsage
);
vkGetSwapchainGrallocUsageANDROID() no admite el uso de cadenas de intercambio
o marcas de uso extendidos de Gralloc.
Imágenes respaldadas por Gralloc
VkNativeBufferANDROID es una extensión de vkCreateImage
para crear una imagen respaldada por un búfer Gralloc. VkNativeBufferANDROID es
proporcionado a vkCreateImage() en VkImageCreateInfo
de la cadena de estructura. Las llamadas al vkCreateImage() con VkNativeBufferANDROID se realizan
durante la llamada a vkCreateSwapchainKHR. La implementación de WSI asigna
la cantidad de búferes nativos solicitados para la cadena 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 un
Estructura de extensión de VkSwapchainImageCreateInfoKHR en el
Se proporcionó una cadena de VkImageCreateInfo a vkCreateImage
cuando se requiera cualquier marca de uso de imagen de cadena de intercambio para la cadena de intercambio.
La estructura de la extensión contiene las marcas de uso de imagen 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 v70, por lo que la app de Vulkan puede crear una
VkImage respaldada por memoria de cadena de intercambio. Primero la app llama
vkCreateImage con un VkImageSwapchainCreateInfoKHR
encadenada a la estructura VkImageCreateInfo. Luego, la
La app llama a vkBindImageMemory2(KHR) con un
VkBindImageMemorySwapchainInfoKHR encadenada a la
VkBindImageMemoryInfo. El imageIndex
especificados en la estructura VkBindImageMemorySwapchainInfoKHR deben
ser un índice de imagen de cadena de intercambio válido Mientras tanto, la plataforma proporciona
Estructura de extensión VkNativeBufferANDROID con el correspondiente
Gralloc información del búfer en la cadena VkBindImageMemoryInfo, de modo que
el controlador sabe con qué búfer de Gralloc debe vincularse el VkImage.
Adquirir imágenes
vkAcquireImageANDROID adquiere la propiedad de una imagen de cadena de intercambio
e importa una valla nativa
indicada externamente en una red
VkSemaphore y un objeto VkFence existente:
VkResult VKAPI vkAcquireImageANDROID(
VkDevice device,
VkImage image,
int nativeFenceFd,
VkSemaphore semaphore,
VkFence fence
);
Se llama a vkAcquireImageANDROID() durante
vkAcquireNextImageKHR para importar un
valla nativa a los objetos VkSemaphore y VkFence
(sin embargo, los objetos del semáforo y de la cerca están
opcional en esta llamada). Es posible que el conductor aproveche esta oportunidad para dar un reconocimiento a
y controlar cualquier cambio externo en el estado del búfer de Gralloc muchos conductores no
no tendrán que hacer nada. Esta llamada coloca los elementos VkSemaphore y
VkFence al 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 cerca.
Ambos objetos se indican cuando la valla nativa subyacente lo indica; si
la barrera nativa ya indicó, entonces el semáforo está en la zona
cuando se muestre esta función. El conductor será el propietario del archivo de valla.
de protección y cierra el descriptor del archivo de valla cuando ya no es necesario. El conductor
incluso si no se proporciona un objeto de semáforo o valla, o aunque
vkAcquireImageANDROID falla y muestra un error. Si
fenceFd es -1, es como si la valla nativa ya estuviera
señalados.
Imágenes de lanzamiento
vkQueueSignalReleaseImageANDROID prepara una imagen de la cadena de intercambio para
uso externo, crea una valla nativa y programa que se señale después
los semáforos de entrada indicaron lo siguiente:
VkResult VKAPI vkQueueSignalReleaseImageANDROID(
VkQueue queue,
uint32_t waitSemaphoreCount,
const VkSemaphore* pWaitSemaphores,
VkImage image,
int* pNativeFenceFd
);
vkQueuePresentKHR() llama a vkQueueSignalReleaseImageANDROID()
en la cola proporcionada. El conductor debe producir una valla nativa que no señale
hasta los waitSemaphoreCount semáforos de
pWaitSemaphores y cualquier trabajo adicional necesario para
preparar a image para que se complete la presentación.
Si los semáforos de espera (si los hay) ya se indicaron y queue es
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 posee y cierra el descriptor de archivos
que se devuelven en *pNativeFenceFd.
Muchos controladores pueden ignorar el parámetro de la imagen, pero es posible que algunos deban prepararse.
Estructuras de datos del lado de la CPU asociadas con un búfer Gralloc para que las use
consumidores de imágenes. Se debe preparar el contenido del búfer para que lo usen los consumidores externos.
se realice 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 conductor debe
permitir que se llame a vkQueueSignalReleaseImageANDROID() repetidamente
sin intervenir llamadas a vkAcquireImageANDROID().
Compatibilidad con imágenes presentables compartidas
Algunos dispositivos pueden compartir la propiedad de una sola imagen entre
la canalización de pantalla y la implementación de Vulkan para minimizar la latencia.
En Android 9 y versiones posteriores, el cargador anuncia condicionalmente el
VK_KHR_shared_presentable_image extensión según el nombre del conductor
respuesta a una llamada a vkGetPhysicalDeviceProperties2.
Si el controlador no es compatible con Vulkan 1.1 ni con
VK_KHR_physical_device_properties2, el cargador no
anuncian la compatibilidad
con imágenes presentables compartidas. De lo contrario, el cargador consulta
las capacidades del controlador llamando a vkGetPhysicalDeviceProperties2()
e incluir la siguiente estructura en el
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 conductor puede compartir la propiedad de una imagen con la pantalla
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 cumplimiento de Khronos Vulkan
En el módulo
CtsDeqpTestCases, que incluyen pruebas de API funcionales para Vulkan 1.0, 1.1, 1.2 y 1.3. - El módulo
CtsGraphicsTestCases, que comprueba que el dispositivo sea correctamente para las capacidades de Vulkan que admite.
Marca de función de Vulkan
Un dispositivo compatible con Android 11 o versiones posteriores y la API de Vulkan
se requiere para exponer una marca de función,
android.software.vulkan.deqp.level El valor de esta marca de función
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 superar
Una fecha con el formato AAAA-MM-DD se codifica como un número entero de 32 bits de la siguiente manera:
- Los bits 0-15 almacenan el año
- Los bits 16-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 2019-03-01, que es la fecha asociada con el
Pruebas de dEQP de Vulkan para Android 10 Si la marca de función tiene al menos este valor,
El dispositivo afirma superar 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 el atributo
es, al menos, este valor, el dispositivo declara que aprueba todos los
Pruebas de dEQP de Vulkan.
El valor 0x07E60301 corresponde a la fecha 2022-03-01, que es
la fecha asociada con las pruebas de dEQP de Vulkan para
Android 13 Si la marca de función tiene al menos este valor,
el dispositivo declara que pasa todos los atributos
Pruebas de dEQP.
Un dispositivo que expone una marca de función específica (p. ej.
0x07E30301, 0x07E40301 y 0x07E60301)
declara superar todas las pruebas de dEQP de Android Vulkan para esa marca de función (Android 10,
Android 11 y Android 13, respectivamente). Este dispositivo
podría superar las pruebas de dEQP de Vulkan de una versión posterior de Android.
Vulkan dEQP forma parte del CTS de Android. A partir de Android 11, el ejecutor de pruebas de dEQP
de CTS conoce el android.software.vulkan.deqp.level
marca de función y omite todas las pruebas de dEQP de Vulkan que, según este
marca de función: El dispositivo no afirma ser compatible. Estas pruebas son
se informa como pase trivial.