Esta página se ha traducido con Cloud Translation API.

Implementar Vulkan

Vulkan es una API multiplataforma de bajo costo 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 aplicaciones. Las ventajas de usar Vulkan incluyen reducciones en la sobrecarga de la CPU y compatibilidad con el lenguaje intermedio binario SPIR-V .

Para implementar Vulkan con éxito, un dispositivo debe incluir:

El cargador Vulkan, proporcionado por Android.
Un controlador Vulkan, proporcionado por SoC como GPU IHV, que implementa la API de Vulkan . Para admitir la funcionalidad de Vulkan, el dispositivo Android necesita hardware GPU compatible con Vulkan y el controlador asociado. La GPU también debe ser compatible con GLES 3.1 y superior. Consulte a su proveedor de SoC para solicitar asistencia para el controlador.

Si un dispositivo incluye un controlador Vulkan, el dispositivo debe declarar las características 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 vulcano

La platform/frameworks/native/vulkan del cargador Vulkan es la interfaz principal entre las aplicaciones Vulkan y el controlador Vulkan de un dispositivo. El cargador Vulkan está instalado 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 requeridas por el CDD de Android y muchas extensiones opcionales adicionales. Las extensiones de integración de sistemas de ventanas (WSI) las exporta el cargador y se implementan principalmente en el cargador en lugar de en el controlador. El cargador también admite la enumeración y carga de capas que pueden exponer extensiones adicionales e interceptar llamadas API principales en su camino hacia el controlador.

El NDK incluye una biblioteca libvulkan.so para vincular. La biblioteca exporta los mismos símbolos que el cargador. Las aplicaciones llaman a las funciones exportadas desde la biblioteca libvulkan.so real para ingresar funciones de trampolín en el cargador, que se envían a la capa o controlador apropiado según su primer argumento. La llamada vkGet*ProcAddr() devuelve los punteros de función a los que se envían los trampolines (es decir, llama directamente al código API principal). Llamar a través de los punteros de función, en lugar de los símbolos exportados, es más eficiente ya que se salta el trampolín y el envío.

Enumeración y carga de controladores.

Cuando se crea la imagen del sistema, Android espera que el sistema sepa qué GPU están disponibles. El cargador utiliza el mecanismo HAL existente en hardware.h para descubrir y cargar el controlador. Las rutas preferidas para los controladores Vulkan de 32 y 64 bits son:

/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

Nota: <ro.hardware.vulkan> y <ro.product.platform> se reemplazan por el valor de la propiedad del sistema con ese nombre. Para obtener detalles y ubicaciones alternativas admitidas, consulte libhardware/hardware.c .

En Android 7.0 y superiores, el derivado Vulkan hw_module_t envuelve una única estructura hw_module_t ; solo se admite un controlador y la cadena constante HWVULKAN_DEVICE_0 se pasa a open() .

El derivado de Vulkan hw_device_t corresponde a un único controlador que puede admitir múltiples dispositivos físicos. La estructura hw_device_t puede extenderse para exportar funciones vkGetGlobalExtensionProperties() , vkCreateInstance() y vkGetInstanceProcAddr() . El cargador puede encontrar todas las demás funciones VkInstance() , VkPhysicalDevice() y vkGetDeviceProcAddr() llamando a vkGetInstanceProcAddr() de la estructura hw_device_t .

Descubrimiento y carga de capas

El cargador Vulkan admite la enumeración y carga de capas que pueden exponer extensiones adicionales e interceptar llamadas API principales en su camino hacia el controlador. Android no incluye capas en la imagen del sistema; sin embargo, las aplicaciones pueden incluir capas en su APK.

Al utilizar capas, tenga en cuenta que el modelo y las políticas de seguridad de Android difieren significativamente de otras plataformas. En particular, Android no permite cargar código externo en un proceso no depurable en dispositivos de producción (no rooteados), ni permite que el código externo inspeccione o controle la memoria, el estado, etc. del proceso. Esto incluye la prohibición de guardar volcados de núcleo, seguimientos de API, etc. en el disco para su posterior inspección. En los dispositivos de producción solo se habilitan las capas entregadas como parte de aplicaciones no depurables y los controladores no deben proporcionar funciones que infrinjan estas políticas.

Los casos de uso de capas incluyen:

Capas de tiempo de desarrollo : las capas de validación y las correcciones para herramientas de seguimiento, creació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 para las herramientas de seguimiento, creación de perfiles y depuración deben poder actualizarse sin una imagen del sistema. Los desarrolladores que quieran utilizar una de estas capas durante el desarrollo pueden modificar el paquete de la aplicación, 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 aplicaciones no modificables tienen acceso a compilaciones que no son de producción (rooteadas) de la imagen del sistema, a menos que esas aplicaciones se puedan depurar. Para obtener más información, consulte 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 capas y versiones de esas capas para usar en su aplicación; diferentes aplicaciones que usan la misma capa aún pueden usar versiones diferentes. Los desarrolladores eligen cuál de estas capas incluir en el paquete de su aplicación.
Capas inyectadas (implícitas) : incluye capas como velocidad de fotogramas, redes sociales y superposiciones de inicio de juegos proporcionadas por el usuario o alguna otra aplicación sin el conocimiento o consentimiento de la aplicación. Estos violan las políticas de seguridad de Android y no son compatibles.

Para aplicaciones no depurables, el cargador busca capas solo en el directorio de la biblioteca nativa de la aplicación e intenta cargar cualquier biblioteca con un nombre que coincida con un patrón particular (por ejemplo, libVKLayer_foo.so ).

Para aplicaciones depurables, el cargador busca capas en /data/local/debug/vulkan e intenta cargar cualquier biblioteca que coincida con un patrón particular.

Android permite portar capas con cambios en el entorno de compilación entre Android y otras plataformas. Para obtener detalles sobre la interfaz entre capas y el cargador, consulte Arquitectura de las interfaces del cargador Vulkan . Las capas de validación mantenidas por Khronos están alojadas en Vulkan Validation Layers .

Versiones y capacidades de la API de Vulkan

La siguiente tabla enumera las versiones de la API de Vulkan para varias versiones de Android.

Versión de Android	Versión vulcana
androide 13	Vulcano 1.3
androide 9	Vulcano 1.1
androide 7	Vulcano 1.0

Descripción general de la funcionalidad de Vulkan 1.3

Vulkan 1.3 canoniza una serie de extensiones previamente 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 pase de renderizado de una sola pasada ya no necesitan objetos de paso de renderizado ni framebuffers. Se puede reducir el número total de objetos de estado de 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 de SoC, no en el marco.

Las características más importantes de Vulkan 1.3 para Android son:

Soporte para instancias de pase de renderizado de una sola pasada
Soporte para finalizar inmediatamente una invocación de sombreador
Mayor granularidad sobre la creación, el intercambio y el control de canalizaciones

Vulkan 1.3 también incluye varias funciones más pequeñas y mejoras de usabilidad de API. Todos los cambios realizados en la API principal de Vulkan con la revisión menor 1.3 se pueden encontrar en Revisiones principales (Vulkan 1.3) .

Descripción general de la funcionalidad de Vulkan 1.2

Vulkan 1.2 agrega una serie de características y extensiones que simplifican la superficie 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 está en el controlador de gráficos específico de SoC, no en el marco.

La característica más importante de Vulkan 1.2 para Android es la compatibilidad con almacenamiento de 8 bits.

Vulkan 1.2 también incluye varias funciones más pequeñas y mejoras de usabilidad de API. Todos los cambios realizados en la API principal de Vulkan con la revisión menor 1.2 se pueden encontrar en Revisiones principales (Vulkan 1.2) .

Descripción general de la funcionalidad de Vulkan 1.1

Vulkan 1.1 incluye soporte para interoperabilidad de memoria/sincronización, lo que permite a los OEM admitir Vulkan 1.1 en dispositivos. Además, la interoperabilidad de memoria/sincronización permite a los desarrolladores determinar si Vulkan 1.1 es compatible con un dispositivo y usarlo de manera efectiva 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 realiza en el controlador de gráficos específico de SOC, no en el marco.

Las características más importantes de Vulkan 1.1 para Android son:

Soporte para importar y exportar buffers de memoria y objetos de sincronización desde fuera de Vulkan (para interoperabilidad con cámara, códecs y GLES)
Soporte para formatos YCbCr

Vulkan 1.1 también incluye varias funciones más pequeñas y mejoras de usabilidad de API. Todos los cambios realizados en la API principal de Vulkan con la revisión menor 1.1 se pueden encontrar en Revisiones principales (Vulkan 1.1) .

Elija el soporte de Vulkan

Los dispositivos Android deben admitir el conjunto de funciones Vulkan más avanzado disponible, siempre que admitan una ABI de 64 bits y no tengan poca memoria.

Los dispositivos que se inician con Android 13 y superior deben ser compatibles con Vulkan 1.3.

Los dispositivos que se inician con Android 10 deben ser compatibles con Vulkan 1.1.

Otros dispositivos pueden admitir opcionalmente Vulkan 1.3, 1.2 y 1.1.

Admite una versión de Vulkan

Un dispositivo Android admite una versión de Vulkan si se cumplen las siguientes condiciones:

Agregue 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 de CDD adicionales de la versión de Android. Alternativamente, actualice un controlador Vulkan existente con un número de versión inferior de Vulkan.
Nota: Para Android 14 y versiones posteriores, todos los dispositivos compatibles con Vulkan deben tener controladores Vulkan 1.1. Consulte los requisitos de CDD de Android 14 para obtener más información.
Para Vulkan 1.3 o 1.1, asegúrese de que la función del sistema devuelta por el administrador de paquetes sea true para la versión correcta de vulkan.
- Para Vulkan 1.3, la característica es PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000) .
- Para Vulkan 1.1, la característica es PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000) .
El administrador de paquetes devolverá true para Vulkan 1.3 y Vulkan 1.1 agregando una regla, como se muestra a continuación, a un archivo device.mk apropiado.
- Agregue 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
```
- Agregue 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 referencia de Android (ABP)

Alentamos a todos los dispositivos Android a que cumplan con el último perfil de Android Baseline 2022, como se describe en la guía de perfiles de Android Baseline .

Cualquier dispositivo que admita Android 14 o superior y la API Vulkan debe cumplir con todas las funciones definidas en el perfil Android Baseline 2021 . La lista completa de funcionalidades requeridas se enumera en el archivo json del perfil de Vulkan, pero un subconjunto clave de la funcionalidad requerida incluye:

Texturas comprimidas mediante ASTC y ETC.
Espacios de color variables a través de VK_EXT_swapchain_colorspace .
Sombreado de muestras e interpolación multimuestra 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_surface
VK_KHR_android_surface
VK_KHR_swapchain
VK_KHR_driver_properties , implementado para Vulkan 1.1 solo en Android 10
VK_GOOGLE_display_timing , implementado para cualquier versión de Vulkan en Android 10

Los objetos VkSurfaceKHR y VkSwapchainKHR y todas las interacciones con ANativeWindow son manejados por la plataforma y no están expuestos 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; esta extensión solo la usa la implementación WSI y no está expuesta a las aplicaciones.

Banderas de uso de gralloc

Las implementaciones de Vulkan pueden necesitar que se asignen buffers de cadena de intercambio con indicadores de uso de Gralloc privados definidos por la implementación. Al crear una cadena de intercambio, Android le pide al controlador que traduzca el formato solicitado y los indicadores de uso de imágenes en indicadores de uso de Gralloc llamando a:

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 e imageUsage se toman de la estructura VkSwapchainCreateInfoKHR . El controlador debe completar *grallocConsumerUsage y *grallocProducerUsage con los indicadores de uso de Gralloc necesarios para el formato y el uso. Los indicadores de uso devueltos por el controlador se combinan con los indicadores de uso solicitados por el consumidor de la cadena de intercambio al asignar buffers.

Android 7.x llama a una versión anterior de VkSwapchainImageUsageFlagsANDROID() , denominada vkGetSwapchainGrallocUsageANDROID() . Android 8.0 y versiones posteriores desaprueban vkGetSwapchainGrallocUsageANDROID() pero aún llama a vkGetSwapchainGrallocUsageANDROID() si el controlador no proporciona vkGetSwapchainGrallocUsage2ANDROID() :

VkResult VKAPI vkGetSwapchainGrallocUsageANDROID(
    VkDevice            device,
    VkFormat            format,
    VkImageUsageFlags   imageUsage,
    int*                grallocUsage
);

vkGetSwapchainGrallocUsageANDROID() no admite indicadores de uso de swapchain ni indicadores de uso extendido de Gralloc.

Imágenes respaldadas por 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 buffers nativos solicitados para la cadena de intercambio y luego crea una 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;

Al crear 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 indicadores de uso de imágenes de la cadena de intercambio para la cadena de intercambio. La estructura de la extensión contiene los indicadores 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 es compatible con VK_KHR_swapchain v70, por lo que la aplicación Vulkan puede crear una VkImage respaldada por la memoria de la cadena de intercambio. La aplicación primero llama vkCreateImage con una estructura VkImageSwapchainCreateInfoKHR encadenada a la estructura VkImageCreateInfo . Luego, la aplicación llama 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 del búfer Gralloc correspondiente a la cadena VkBindImageMemoryInfo , para que el controlador sepa con qué búfer Gralloc vincular el VkImage .

Adquirir imágenes

vkAcquireImageANDROID adquiere la propiedad de una imagen de la cadena de intercambio e importa una valla nativa señalizada externamente tanto en un objeto VkSemaphore existente como en un objeto VkFence existente:

VkResult VKAPI vkAcquireImageANDROID(
    VkDevice            device,
    VkImage             image,
    int                 nativeFenceFd,
    VkSemaphore         semaphore,
    VkFence             fence
);

Se llama vkAcquireImageANDROID() durante vkAcquireNextImageKHR para importar una valla nativa en los objetos VkSemaphore y VkFence proporcionados por la aplicación (sin embargo, tanto los objetos de semáforo como de valla son opcionales en esta llamada). El conductor también puede aprovechar esta oportunidad para reconocer y manejar cualquier cambio externo en el estado del búfer de Gralloc; muchos conductores no necesitarán hacer nada aquí. Esta llamada coloca a VkSemaphore y VkFence en el mismo estado pendiente como si lo indicara vkQueueSubmit , por lo que las colas pueden esperar en el semáforo y la aplicación puede esperar en la valla.

Ambos objetos se señalizan cuando la valla nativa subyacente lo hace; Si la valla nativa ya ha señalado, entonces el semáforo está en el estado señalado cuando regresa esta función. El controlador toma posesión del descriptor del archivo de valla y lo cierra cuando ya no es necesario. El controlador debe hacerlo incluso si no se proporciona un semáforo ni un objeto de valla, o incluso si vkAcquireImageANDROID falla y devuelve un error. Si fenceFd es -1, es como si la valla nativa ya estuviera señalizada.

Publicar imágenes

vkQueueSignalReleaseImageANDROID prepara una imagen de cadena de intercambio para uso externo, crea una valla nativa y programa la valla nativa para que se señalice después de que los semáforos de entrada hayan señalado:

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 valla nativa que no señalice hasta que todos los semáforos waitSemaphoreCount en pWaitSemaphores señalen y se complete cualquier trabajo adicional requerido para preparar image para la presentación.

Si los semáforos de espera (si los hay) ya están señalados y queue ya está inactiva, el controlador puede configurar *pNativeFenceFd en -1 en lugar de un descriptor de archivo de valla nativo real, lo que indica que no hay nada que esperar. La persona que llama posee y cierra el descriptor de archivo devuelto en *pNativeFenceFd .

Muchos controladores pueden ignorar el parámetro de imagen, pero es posible que algunos necesiten preparar estructuras de datos del lado de la CPU asociadas con un búfer Gralloc para que las utilicen consumidores de imágenes externos. La preparación del contenido del búfer para uso de consumidores externos debe realizarse de forma asincrónica 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 , entonces el controlador debe permitir que vkQueueSignalReleaseImageANDROID() se llame repetidamente sin intervenir llamadas a vkAcquireImageANDROID() .

Compatibilidad con imágenes presentables compartidas

Algunos dispositivos pueden compartir la propiedad de una única imagen entre el proceso de visualización y la implementación de Vulkan para minimizar la latencia. En Android 9 y versiones posteriores, el cargador anuncia condicionalmente la extensión VK_KHR_shared_presentable_image según la respuesta del conductor a una llamada a vkGetPhysicalDeviceProperties2 .

Si el controlador no es compatible con Vulkan 1.1 o la extensión VK_KHR_physical_device_properties2 , el cargador no anuncia soporte para imágenes presentables compartidas. De lo contrario, el cargador consulta las capacidades del controlador llamando a vkGetPhysicalDeviceProperties2() e incluyendo 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 OEM pueden probar su implementación de Vulkan utilizando CTS, que incluye lo siguiente:

Pruebas de conformidad 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 prueba que el dispositivo esté configurado correctamente para las capacidades de Vulkan que admite.

Bandera de característica de Vulkan

Se requiere un dispositivo que admita Android 11 o superior y que admita la API de Vulkan para exponer un indicador de función, android.software.vulkan.deqp.level . El valor de este indicador de característica es una fecha, codificada como un valor entero. Especifica la fecha asociada con las pruebas Vulkan dEQP que el dispositivo afirma pasar.

Una fecha con el formato AAAA-MM-DD se codifica como un 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-31 almacenan el día.

El valor mínimo permitido para el indicador de función es 0x07E30301 , que corresponde a la fecha 2019-03-01, que es la fecha asociada con las pruebas Vulkan dEQP para Android 10. Si el indicador de función tiene al menos este valor, el dispositivo afirma pasar todas las pruebas de Android 10 Vulkan dEQP.

El valor 0x07E40301 corresponde a la fecha 2020-03-01, que es la fecha asociada con las pruebas de Vulkan dEQP para Android 11. Si el indicador de función tiene al menos este valor, el dispositivo afirma pasar todas las pruebas de Android 11 Vulkan dEQP.

El valor 0x07E60301 corresponde a la fecha 2022-03-01, que es la fecha asociada con las pruebas de Vulkan dEQP para Android 13. Si el indicador de función tiene al menos este valor, el dispositivo afirma pasar todas las pruebas de Android 13 Vulkan dEQP.

Un dispositivo que expone un indicador de función específico ( es decir 0x07E30301 , 0x07E40301 , 0x07E60301 ) afirma pasar todas las pruebas dEQP de Android Vulkan de ese indicador de función (Android 10, Android 11, Android 13 respectivamente). Este dispositivo puede pasar las pruebas Vulkan dEQP de una versión posterior de Android.

Vulkan dEQP forma parte de Android CTS. A partir de Android 11, el componente de ejecución de pruebas dEQP de CTS conoce el indicador de función android.software.vulkan.deqp.level y omite cualquier prueba de Vulkan dEQP que, según este indicador de función, el dispositivo no afirma admitir. Se informa que estas pruebas son trivialmente aprobadas.