Implémenter Vulkan

Vulkan est une API multiplate-forme simple permettant la création de graphiques 3D hautes performances. Comme OpenGL ES (GLES), Vulkan fournit des outils permettant de créer des graphiques en temps réel de haute qualité dans les applications. L'utilisation de Vulkan présente des avantages tels que la réduction de la surcharge du processeur et la compatibilité avec le langage SPIR-V Binary Intermediate.

Pour implémenter Vulkan, un appareil doit inclure les éléments suivants :

  • Chargeur Vulkan fourni par Android.
  • Pilote Vulkan fourni par les SoC tels que les IHV GPU, qui implémente l'API Vulkan. Pour prendre en charge les fonctionnalités Vulkan, l'appareil Android doit disposer d'un GPU compatible avec Vulkan et du pilote associé. Le GPU doit également être compatible avec GLES 3.1 ou version ultérieure. Contactez votre fournisseur de SoC pour demander une assistance pour les pilotes.

Si un appareil inclut un pilote Vulkan, il doit déclarer les fonctionnalités système FEATURE_VULKAN_HARDWARE_LEVEL et FEATURE_VULKAN_HARDWARE_VERSION, avec des versions qui reflètent précisément les capacités de l'appareil. Cela permet de s'assurer que l'appareil est conforme au document de définition de compatibilité (CDD).

Chargeur Vulkan

Le chargeur Vulkan platform/frameworks/native/vulkan est l'interface principale entre les applications Vulkan et le pilote Vulkan d'un appareil. Le chargeur Vulkan est installé à l'adresse /system/lib[64]/libvulkan.so. Le chargeur fournit les points d'entrée de l'API Vulkan de base, les points d'entrée des extensions requises par le CDD Android et de nombreuses extensions facultatives supplémentaires. Les extensions d'intégration du système de fenêtres (WSI, Window System Integration) sont exportées par le chargeur et principalement implémentées dans le chargeur plutôt que dans le pilote. Le chargeur permet également d'énumérer et de charger des couches qui peuvent exposer des extensions supplémentaires et intercepter les appels d'API principaux en route vers le pilote.

Le NDK inclut une bibliothèque libvulkan.so de stub pour l'association. La bibliothèque exporte les mêmes symboles que le chargeur. Les applications appellent les fonctions exportées à partir de la véritable bibliothèque libvulkan.so pour saisir les fonctions trampoline dans le chargeur, qui sont envoyées au pilote ou à la couche appropriés en fonction de leur premier argument. L'appel vkGet*ProcAddr() renvoie les pointeurs de fonction vers lesquels les trampolines distribuent (c'est-à-dire qu'il appelle directement le code de l'API Core). L'appel via les pointeurs de fonction, plutôt que via les symboles exportés, est plus efficace, car il ignore le trampoline et la répartition.

Énumération et chargement des pilotes

Lors de la création de l'image système, Android s'attend à ce que le système connaisse les GPU disponibles. Le chargeur utilise le mécanisme HAL existant dans hardware.h pour découvrir et charger le pilote. Les chemins d'accès préférés pour les pilotes Vulkan 32 bits et 64 bits sont les suivants :

/vendor/lib/hw/vulkan.<ro.hardware.vulkan>.so
/vendor/lib/hw/vulkan.<ro.board.platform>.so
/vendor/lib64/hw/vulkan.<ro.hardware.vulkan>.so
/vendor/lib64/hw/vulkan.<ro.board.platform>.so

Dans Android 7.0 et versions ultérieures, le dérivé hw_module_t de Vulkan encapsule une seule structure hw_module_t. Un seul pilote est pris en charge et la chaîne constante HWVULKAN_DEVICE_0 est transmise à open().

Le dérivé hw_device_t de Vulkan correspond à un seul pilote pouvant prendre en charge plusieurs appareils physiques. La structure hw_device_t peut s'étendre aux fonctions d'exportation vkGetGlobalExtensionProperties(), vkCreateInstance() et vkGetInstanceProcAddr(). Le chargeur peut trouver toutes les autres fonctions VkInstance(), VkPhysicalDevice() et vkGetDeviceProcAddr() en appelant vkGetInstanceProcAddr() de la structure hw_device_t.

Depuis Android 15, le chargeur est compatible avec APEX pour charger le pilote Vulkan. Définissez ro.vulkan.apex sur le nom de l'APEX Vulkan pour charger Vulkan à partir de l'APEX.

Découverte et chargement des couches

Le chargeur Vulkan permet d'énumérer et de charger des couches pouvant exposer des extensions supplémentaires et intercepter les appels d'API principaux en route vers le pilote. Android n'inclut pas de couches sur l'image système. Toutefois, les applications peuvent inclure des couches dans leur APK.

Lorsque vous utilisez des calques, gardez à l'esprit que le modèle de sécurité et les règles d'Android sont très différents de ceux des autres plates-formes. En particulier, Android n'autorise pas le chargement de code externe dans un processus non débogable sur des appareils de production (non rootés), ni le code externe à inspecter ou contrôler la mémoire, l'état, etc. du processus. Cela inclut l'interdiction d'enregistrer des vidages de mémoire, des traces d'API, etc. sur le disque pour une inspection ultérieure. Seules les couches fournies dans des applications non débogables sont activées sur les appareils de production. Les pilotes ne doivent pas fournir de fonctionnalités qui enfreignent ces règles.

Voici quelques cas d'utilisation des calques :

  • Couches d'exécution de développement : les couches de validation et les cales pour les outils de traçage/profilage/débogage ne doivent pas être installées sur l'image système des appareils de production. Les couches de validation et les shims pour les outils de traçage/profilage/débogage doivent être actualisables sans image système. Les développeurs qui souhaitent utiliser l'une de ces couches pendant le développement peuvent modifier le package de l'application, par exemple en ajoutant un fichier à leur répertoire de bibliothèques natives. Les ingénieurs IHV et OEM qui souhaitent diagnostiquer les échecs dans les applications non modifiables fournies sont censés avoir accès aux versions non destinées à la production (rootées) de l'image système, sauf si ces applications sont débogables. Pour en savoir plus, consultez Couches de validation Vulkan sur Android.
  • Couches utilitaires : ces couches exposent des extensions, comme une couche qui implémente un gestionnaire de mémoire pour la mémoire de l'appareil. Les développeurs choisissent les couches et les versions de ces couches à utiliser dans leur application. Différentes applications utilisant la même couche peuvent toujours utiliser des versions différentes. Les développeurs choisissent les couches à inclure dans le package de leur application.
  • Calques injectés (implicites) : incluent les calques tels que la fréquence d'images, les réseaux sociaux et les superpositions de lanceurs de jeux fournis par l'utilisateur ou une autre application à l'insu ou sans l'autorisation de l'application. Ces éléments ne respectent pas les règles de sécurité d'Android et ne sont pas acceptés.

Pour les applications non débogables, le chargeur recherche les couches uniquement dans le répertoire de la bibliothèque native de l'application et tente de charger toute bibliothèque dont le nom correspond à un modèle particulier (par exemple, libVKLayer_foo.so).

Pour les applications débogables, le chargeur recherche les couches dans /data/local/debug/vulkan et tente de charger toute bibliothèque correspondant à un modèle particulier.

Android permet de transférer des calques avec des modifications de l'environnement de compilation entre Android et d'autres plates-formes. Pour en savoir plus sur l'interface entre les couches et le chargeur, consultez Architecture des interfaces du chargeur Vulkan. Les couches de validation gérées par Khronos sont hébergées dans Vulkan Validation Layers.

Versions et fonctionnalités de l'API Vulkan

Le tableau suivant répertorie les versions de l'API Vulkan pour plusieurs versions d'Android.
Version d'Android Version Vulkan
Android 13 Vulkan 1.3
Android 9 Vulkan 1.1
Android 7 Vulkan 1.0

Présentation des fonctionnalités de Vulkan 1.3

Vulkan 1.3 canonise un certain nombre d'extensions auparavant facultatives dans la fonctionnalité principale de Vulkan. La plupart de ces fonctionnalités sont incluses dans le but d'accroître le contrôle et la précision de l'interface de programmation Vulkan. Les instances de passe de rendu à passe unique n'ont plus besoin d'objets de passe de rendu ni de tampons de frame. Le nombre total d'objets d'état du pipeline peut être réduit, et la synchronisation au sein de l'API est remaniée. Vulkan 1.3 présente les mêmes exigences matérielles que Vulkan 1.2, 1.1 et 1.0, la majeure partie de l'implémentation se trouvant dans le pilote graphique spécifique au SoC, et non dans le framework.

Voici les principales fonctionnalités de Vulkan 1.3 pour Android :

  • Prise en charge des instances de passe de rendu à un seul passage
  • Prise en charge de l'arrêt immédiat d'un appel de nuanceur
  • Granularité plus fine pour la création, le partage et le contrôle des pipelines

Vulkan 1.3 inclut également plusieurs fonctionnalités plus petites et des améliorations de l'usabilité de l'API. Tous les changements apportés à l'API Vulkan principale avec la révision mineure 1.3 sont disponibles sur la page Révisions principales (Vulkan 1.3).

Présentation des fonctionnalités de Vulkan 1.2

Vulkan 1.2 ajoute un certain nombre de fonctionnalités et d'extensions qui simplifient la surface de l'API. Cela inclut un modèle de mémoire unifié et des informations supplémentaires pouvant être interrogées à partir d'un pilote de périphérique. Vulkan 1.2 présente les mêmes exigences matérielles que Vulkan 1.0 et 1.1. L'ensemble de l'implémentation se trouve dans le pilote graphique spécifique au SoC, et non dans le framework.

La fonctionnalité Vulkan 1.2 la plus importante pour Android est la prise en charge du stockage 8 bits.

Vulkan 1.2 inclut également plusieurs fonctionnalités plus petites et des améliorations de l'usabilité de l'API. Tous les changements apportés à l'API Vulkan principale avec la révision mineure 1.2 sont disponibles sur la page Révisions principales (Vulkan 1.2).

Présentation des fonctionnalités de Vulkan 1.1

Vulkan 1.1 est compatible avec l'interopérabilité de la mémoire et de la synchronisation, ce qui permet aux OEM de prendre en charge Vulkan 1.1 sur les appareils. De plus, l'interopérabilité de la mémoire/synchronisation permet aux développeurs de déterminer si Vulkan 1.1 est compatible avec un appareil et de l'utiliser efficacement le cas échéant. Vulkan 1.1 a les mêmes exigences matérielles que Vulkan 1.0, mais la plupart de l'implémentation se trouve dans le pilote graphique spécifique au SOC, et non dans le framework.

Voici les principales fonctionnalités de Vulkan 1.1 pour Android :

  • Prise en charge de l'importation et de l'exportation de tampons de mémoire et d'objets de synchronisation en dehors de Vulkan (pour l'interopérabilité avec l'appareil photo, les codecs et GLES)
  • Prise en charge des formats YCbCr

Vulkan 1.1 inclut également plusieurs fonctionnalités plus petites et des améliorations de l'usabilité de l'API. Tous les changements apportés à l'API Vulkan principale avec la révision mineure 1.1 sont disponibles sur la page Révisions principales (Vulkan 1.1).

Choisir la compatibilité avec Vulkan

Les appareils Android doivent être compatibles avec l'ensemble de fonctionnalités Vulkan le plus avancé disponible, à condition qu'ils soient compatibles avec une ABI 64 bits et qu'ils ne soient pas à faible mémoire.

Les appareils lancés avec Android 13 et versions ultérieures doivent être compatibles avec Vulkan 1.3.

Les appareils lancés avec Android 10 doivent être compatibles avec Vulkan 1.1.

D'autres appareils peuvent éventuellement prendre en charge Vulkan 1.3, 1.2 et 1.1.

Prendre en charge une version de Vulkan

Un appareil Android est compatible avec une version de Vulkan si les conditions suivantes sont remplies :

  1. Ajoutez un pilote Vulkan compatible avec la version Vulkan qui vous intéresse (il doit s'agir de la version 1.3, 1.1 ou 1.0 de Vulkan) ainsi que les exigences CDD supplémentaires de la version d'Android. Vous pouvez également mettre à jour un pilote Vulkan existant dont le numéro de version est inférieur.
  2. Pour Vulkan 1.3 ou 1.1, assurez-vous que la fonctionnalité système renvoyée par le gestionnaire de packages renvoie true pour la version Vulkan appropriée.
    • Pour Vulkan 1.3, la fonctionnalité est PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000).
    • Pour Vulkan 1.1, la fonctionnalité est PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000).
    Le gestionnaire de packages renverra true pour Vulkan 1.3 et Vulkan 1.1 en ajoutant une règle, comme indiqué ci-dessous, à un fichier device.mk approprié.
    • Ajoutez les éléments suivants pour 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
    • Ajoutez les éléments suivants pour 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

Profil de référence Android (ABP)

Nous encourageons tous les appareils Android à se conformer au dernier profil Android Baseline 2022, comme indiqué dans le guide du profil Android Baseline.

Tout appareil compatible avec Android 14 ou version ultérieure et l'API Vulkan doit répondre à toutes les fonctionnalités définies dans le profil Android Baseline 2021. La liste complète des fonctionnalités requises est énumérée dans le fichier de profil Vulkan json, mais un sous-ensemble clé des fonctionnalités requises inclut :

  • Textures compressées via ASTC et ETC.
  • Espaces colorimétriques variables via VK_EXT_swapchain_colorspace.
  • Nuançage d'échantillon et interpolation de plusieurs échantillons via sampleRateShading.

Intégration du système de fenêtres (WSI)

Dans libvulkan.so, le pilote implémente les extensions d'intégration du système de fenêtres (WSI) suivantes :

  • VK_KHR_surface
  • VK_KHR_android_surface
  • VK_KHR_swapchain
  • VK_KHR_driver_properties, implémenté pour Vulkan 1.1 dans Android 10 uniquement
  • VK_GOOGLE_display_timing, implémenté pour toute version de Vulkan dans Android 10

Les objets VkSurfaceKHR et VkSwapchainKHR, ainsi que toutes les interactions avec ANativeWindow, sont gérés par la plate-forme et ne sont pas exposés aux pilotes. L'implémentation WSI repose sur l'extension VK_ANDROID_native_buffer, qui doit être compatible avec le pilote. Cette extension n'est utilisée que par l'implémentation WSI et n'est pas exposée aux applications.

Indicateurs d'utilisation de Gralloc

Les implémentations Vulkan peuvent nécessiter l'allocation de tampons de chaîne d'échange avec des indicateurs d'utilisation Gralloc privés définis par l'implémentation. Lors de la création d'une chaîne d'échange, Android demande au pilote de traduire le format et les indicateurs d'utilisation d'image demandés en indicateurs d'utilisation Gralloc en appelant :

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
);

Les paramètres format et imageUsage sont extraits de la structure VkSwapchainCreateInfoKHR. Le pilote doit remplir *grallocConsumerUsage et *grallocProducerUsage avec les indicateurs d'utilisation Gralloc requis pour le format et l'utilisation. Les indicateurs d'utilisation renvoyés par le pilote sont combinés aux indicateurs d'utilisation demandés par le consommateur de la chaîne d'échange lors de l'allocation des tampons.

Android 7.x appelle une version antérieure de VkSwapchainImageUsageFlagsANDROID(), nommée vkGetSwapchainGrallocUsageANDROID(). Android 8.0 et versions ultérieures abandonnent vkGetSwapchainGrallocUsageANDROID(), mais appellent toujours vkGetSwapchainGrallocUsageANDROID() si vkGetSwapchainGrallocUsage2ANDROID() n'est pas fourni par le pilote :

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

vkGetSwapchainGrallocUsageANDROID() n'est pas compatible avec les indicateurs d'utilisation de la chaîne d'échange ni avec les indicateurs d'utilisation Gralloc étendus.

Images soutenues par Gralloc

VkNativeBufferANDROID est une structure d'extension vkCreateImage permettant de créer une image soutenue par un tampon Gralloc. VkNativeBufferANDROID est fourni à vkCreateImage() dans la chaîne de structure VkImageCreateInfo. Les appels à vkCreateImage() avec VkNativeBufferANDROID ont lieu lors de l'appel à vkCreateSwapchainKHR. L'implémentation WSI alloue le nombre de tampons natifs demandés pour la chaîne d'échange, puis crée un VkImage pour chacun d'eux :

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;

Lorsque vous créez une image soutenue par Gralloc, VkImageCreateInfo contient les données suivantes :

  .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

Dans Android 8.0 et versions ultérieures, la plate-forme fournit une structure d'extension VkSwapchainImageCreateInfoKHR dans la chaîne VkImageCreateInfo fournie à vkCreateImage lorsque des indicateurs d'utilisation d'image de chaîne d'échange sont requis pour la chaîne d'échange. La structure d'extension contient les indicateurs d'utilisation des images de la chaîne d'échange :

typedef struct {
    VkStructureType                        sType; // must be VK_STRUCTURE_TYPE_SWAPCHAIN_IMAGE_CREATE_INFO_ANDROID
    const void*                            pNext;

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

Dans Android 10 et les versions ultérieures, la plate-forme est compatible avec VK_KHR_swapchain v70. L'application Vulkan peut donc créer un VkImage soutenu par la mémoire de la chaîne d'échange. L'application appelle d'abord vkCreateImage avec une structure VkImageSwapchainCreateInfoKHR enchaînée à la structure VkImageCreateInfo. L'application appelle ensuite vkBindImageMemory2(KHR) avec une structure VkBindImageMemorySwapchainInfoKHR enchaînée à la structure VkBindImageMemoryInfo. Le imageIndex spécifié dans la structure VkBindImageMemorySwapchainInfoKHR doit être un index d'image de chaîne d'échange valide. En parallèle, la plate-forme fournit une structure d'extension VkNativeBufferANDROID avec les informations de tampon Gralloc correspondantes à la chaîne VkBindImageMemoryInfo, afin que le pilote sache à quel tampon Gralloc lier le VkImage.

Acquérir des images

vkAcquireImageANDROID acquiert la propriété d'une image de chaîne d'échange et importe une clôture native signalée en externe dans un objet VkSemaphore existant et un objet VkFence existant :

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

vkAcquireImageANDROID() est appelé pendant vkAcquireNextImageKHR pour importer une clôture native dans les objets VkSemaphore et VkFence fournis par l'application (toutefois, les objets sémaphore et clôture sont facultatifs dans cet appel). Le pilote peut également profiter de cette occasion pour reconnaître et gérer les modifications externes apportées à l'état du tampon Gralloc. De nombreux pilotes n'ont pas besoin d'effectuer d'opération ici. Cet appel place VkSemaphore et VkFence dans le même état en attente que s'ils avaient été signalés par vkQueueSubmit. Les files d'attente peuvent donc attendre le sémaphore et l'application peut attendre la clôture.

Les deux objets sont signalés lorsque la barrière native sous-jacente est signalée. Si la barrière native a déjà été signalée, le sémaphore est dans l'état signalé lorsque cette fonction renvoie une valeur. Le pilote devient propriétaire du descripteur de fichier de clôture et le ferme lorsqu'il n'en a plus besoin. Le pilote doit le faire même si aucun sémaphore ni objet de clôture n'est fourni, ou même si vkAcquireImageANDROID échoue et renvoie une erreur. Si fenceFd est défini sur -1, cela signifie que la clôture native a déjà été signalée.

Libérer des images

vkQueueSignalReleaseImageANDROID prépare une image de chaîne d'échange pour une utilisation externe, crée une barrière native et planifie la signalisation de la barrière native après la signalisation des sémaphores d'entrée :

VkResult VKAPI vkQueueSignalReleaseImageANDROID(
    VkQueue             queue,
    uint32_t            waitSemaphoreCount,
    const VkSemaphore*  pWaitSemaphores,
    VkImage             image,
    int*                pNativeFenceFd
);

Appels vkQueuePresentKHR() vkQueueSignalReleaseImageANDROID() sur la file d'attente fournie. Le pilote doit produire une clôture native qui ne signale pas tant que tous les sémaphores waitSemaphoreCount dans pWaitSemaphores ne signalent pas et que tout travail supplémentaire requis pour préparer image à la présentation n'est pas terminé.

Si les sémaphores d'attente (le cas échéant) ont déjà signalé et que queue est déjà inactif, le pilote peut définir *pNativeFenceFd sur -1 au lieu d'un descripteur de fichier de clôture natif réel, ce qui indique qu'il n'y a rien à attendre. L'appelant possède et ferme le descripteur de fichier renvoyé dans *pNativeFenceFd.

De nombreux pilotes peuvent ignorer le paramètre d'image, mais certains peuvent avoir besoin de préparer des structures de données côté CPU associées à un tampon Gralloc pour une utilisation par des consommateurs d'images externes. La préparation du contenu du tampon pour une utilisation par des consommateurs externes doit être effectuée de manière asynchrone lors de la transition de l'image vers VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.

Si l'image a été créée avec VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID, le pilote doit autoriser l'appel de vkQueueSignalReleaseImageANDROID() à plusieurs reprises sans appels intermédiaires à vkAcquireImageANDROID().

Compatibilité avec les images présentables partagées

Certains appareils peuvent partager la propriété d'une même image entre le pipeline d'affichage et l'implémentation Vulkan pour minimiser la latence. Dans Android 9 et versions ultérieures, le chargeur annonce conditionnellement l'extension VK_KHR_shared_presentable_image en fonction de la réponse du pilote à un appel à vkGetPhysicalDeviceProperties2.

Si le pilote n'est pas compatible avec Vulkan 1.1 ni avec l'extension VK_KHR_physical_device_properties2, le chargeur n'annonce pas la compatibilité avec les images présentables partagées. Sinon, le chargeur interroge les capacités du pilote en appelant vkGetPhysicalDeviceProperties2() et en incluant la structure suivante dans la chaîne VkPhysicalDeviceProperties2::pNext :

typedef struct {
    VkStructureType sType; // must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENTATION_PROPERTIES_ANDROID
    const void*     pNext;
    VkBool32        sharedImage;
} VkPhysicalDevicePresentationPropertiesANDROID;

Si le pilote peut partager la propriété d'une image avec le système d'affichage, il définit le membre sharedImage sur VK_TRUE.

Validation

Les OEM peuvent tester leur implémentation Vulkan à l'aide de CTS, qui inclut les éléments suivants :

  • Les tests de conformité Khronos Vulkan dans le module CtsDeqpTestCases, qui incluent des tests fonctionnels de l'API pour Vulkan 1.0, 1.1, 1.2 et 1.3.
  • Le module CtsGraphicsTestCases, qui vérifie que l'appareil est correctement configuré pour les fonctionnalités Vulkan qu'il prend en charge.

Flag de fonctionnalité Vulkan

Un appareil compatible avec Android 11 ou version ultérieure et avec l'API Vulkan est nécessaire pour exposer un indicateur de fonctionnalité, android.software.vulkan.deqp.level. La valeur de ce flag de fonctionnalité est une date, encodée sous forme de valeur entière. Elle spécifie la date associée aux tests dEQP Vulkan que l'appareil affirme avoir réussi.

Une date au format AAAA-MM-JJ est encodée sous la forme d'un entier de 32 bits comme suit :

  • Les bits 0 à 15 stockent l'année.
  • Les bits 16 à 23 stockent le mois.
  • Les bits 24 à 31 stockent le jour.

La valeur minimale autorisée pour le flag de fonctionnalité est 0x07E30301, qui correspond à la date du 1er mars 2019, associée aux tests dEQP Vulkan pour Android 10. Si le flag de fonctionnalité est au moins égal à cette valeur, l'appareil affirme réussir tous les tests dEQP Vulkan d'Android 10.

La valeur 0x07E40301 correspond à la date du 1er mars 2020, qui est la date associée aux tests dEQP Vulkan pour Android 11. Si l'indicateur de fonctionnalité est au moins égal à cette valeur, l'appareil affirme réussir tous les tests dEQP Vulkan d'Android 11.

La valeur 0x07E60301 correspond à la date du 1er mars 2022, qui est la date associée aux tests dEQP Vulkan pour Android 13. Si le flag de fonctionnalité est au moins égal à cette valeur, l'appareil affirme réussir tous les tests dEQP Vulkan d'Android 13.

Un appareil qui expose un indicateur de fonctionnalité spécifique (c'est-à-dire 0x07E30301, 0x07E40301, 0x07E60301) affirme réussir tous les tests dEQP Android Vulkan de cet indicateur de fonctionnalité (Android 10, Android 11, Android 13 respectivement). Cet appareil peut réussir les tests dEQP Vulkan d'une version ultérieure d'Android.

Vulkan dEQP fait partie du CTS Android. À partir d'Android 11, le composant d'exécution des tests dEQP du CTS est conscient de l'indicateur de fonctionnalité android.software.vulkan.deqp.level et ignore tous les tests dEQP Vulkan que l'appareil ne prétend pas prendre en charge, selon cet indicateur de fonctionnalité. Ces tests sont signalés comme réussis de manière triviale.