Cette page a été traduite par l'API Cloud Translation.

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, comme la réduction de la surcharge du processeur et la prise en charge du langage SPIR-V Binary Intermediate.

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

Chargeur Vulkan, fourni par Android.
Un pilote Vulkan, fourni par des SoC tels que des GPU IHV, qui met en œuvre l'API Vulkan. Pour prendre en charge la fonctionnalité Vulkan, l'appareil Android a besoin d'un matériel GPU compatible avec Vulkan et du pilote associé. Le GPU doit également prendre en charge GLES 3.1 ou version ultérieure. Consultez votre fournisseur de SoC pour demander l'assistance d'un pilote.

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 garantir 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é à /system/lib[64]/libvulkan.so. Le chargeur fournit les points d'entrée principaux de l'API Vulkan, les points d'entrée des extensions requises par le CDD Android et de nombreuses extensions facultatives supplémentaires. Les extensions d'intégration système de fenêtre (WSI) sont exportées par le chargeur et implémentées principalement dans le chargeur plutôt que dans le pilote. Le chargeur prend également en charge l'énumération et le chargement de couches pouvant exposer des extensions supplémentaires et intercepter les appels d'API principaux avant d'atteindre le pilote.

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

Énumération et chargement du pilote

Lorsque l'image système est créée, Android s'attend à ce que le système sache quels GPU sont disponibles. Le chargeur utilise le mécanisme HAL existant dans hardware.h pour découvrir et charger le pilote. Les chemins d'accès recommandé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.product.platform>.so
/vendor/lib64/hw/vulkan.<ro.hardware.vulkan>.so
/vendor/lib64/hw/vulkan.<ro.product.platform>.so

Remarque:<ro.hardware.vulkan> et <ro.product.platform> sont remplacés par la valeur de la propriété système de ce nom. Pour en savoir plus et connaître les autres emplacements compatibles, consultez libhardware/hardware.c.

Sous Android 7.0 et versions ultérieures, la dérivée hw_module_t Vulkan encapsule une seule struct hw_module_t. Un seul pilote est compatible et la chaîne constante HWVULKAN_DEVICE_0 est transmise à open().

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

Détection et chargement des calques

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 avant d'atteindre le pilote. Android n'inclut pas de calques sur l'image système. Toutefois, les applications peuvent inclure des calques 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. Plus particulièrement, Android n'autorise pas le chargement de code externe dans un processus non débogable sur les appareils de production (non en mode root), ni le code externe à inspecter ou à contrôler la mémoire, l'état, etc. du processus. Cela inclut l'interdiction de l'enregistrement des vidages de mémoire, des traces d'API, etc. sur le disque en vue d'une inspection ultérieure. Seules les couches fournies dans le cadre d'applications non débogables sont activées sur les appareils de production, et les pilotes ne doivent pas fournir de fonctionnalités qui enfreignent ces règles.

Voici quelques cas d'utilisation des calques:

Couches au moment du développement : les couches de validation et les shims des outils de traçage, de profilage et de débogage ne doivent pas être installés sur l'image système des appareils de production. Les couches de validation et les shims pour les outils de traçage, de profilage et de débogage doivent pouvoir être mis à jour sans image système. Les développeurs qui souhaitent utiliser l'une de ces couches pendant le développement peuvent modifier le package d'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 lors de l'expédition d'applications non modifiables sont censés avoir accès aux versions non de production (en mode root) 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, telles qu'une couche implémentant 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 néanmoins utiliser différentes versions. Les développeurs choisissent les couches à inclure dans le package de leur application.
Couches injectées (implicites) : incluent des couches telles que les superpositions de fréquence d'images, de réseaux sociaux et de lanceurs de jeux fournies par l'utilisateur ou une autre application à l'insu de l'application ou de son autorisation. Ils ne respectent pas les règles de sécurité d'Android et ne sont pas compatibles.

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

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

Android permet de porter des couches 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 la section Architecture des interfaces du chargeur Vulkan. Les couches de validation gérées par Khronos sont hébergées dans les couches de validation Vulkan.

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é de base de Vulkan. La plupart de ces fonctionnalités sont incluses dans le but d'augmenter le contrôle et la précision sur l'interface de programmation Vulkan. Les instances de passe de rendu en un seul passage n'ont plus besoin d'objets de passe de rendu ni de tampons de frames. Le nombre total d'objets d'état du pipeline peut être réduit, et la synchronisation au sein de l'API est réorganisé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 étant effectuée dans le pilote graphique spécifique au SoC, et non dans le framework.

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

Compatibilité avec les instances de passe de rendu en un seul passage
Possibilité d'arrêter immédiatement un appel de nuanceur
Contrôle plus précis de la création, du partage et du contrôle des pipelines

Vulkan 1.3 inclut également plusieurs petites fonctionnalités et améliorations de l'usabilité de l'API. Toutes les modifications apportées à 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 d'appareil. Vulkan 1.2 présente les mêmes exigences matérielles que Vulkan 1.0 et 1.1. L'implémentation se trouve dans le pilote graphique spécifique au SoC, et non dans le framework.

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

Vulkan 1.2 inclut également plusieurs petites fonctionnalités et améliorations de l'usabilité de l'API. Toutes les modifications apportées à 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 prend en charge l'interopérabilité entre la mémoire et la synchronisation, ce qui permet aux OEM de prendre en charge Vulkan 1.1 sur les appareils. De plus, l'interopérabilité mémoire/synchronisation permet aux développeurs de déterminer si Vulkan 1.1 est compatible avec un appareil et de l'utiliser efficacement lorsqu'il l'est. Vulkan 1.1 présente les mêmes exigences matérielles que Vulkan 1.0, mais la majeure partie 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 petites fonctionnalités et améliorations de l'usabilité de l'API. Toutes les modifications apportées à l'API Vulkan principale avec la révision mineure 1.1 sont disponibles sur la page Révisions principales (Vulkan 1.1).

Choisir la prise en charge de Vulkan

Les appareils Android doivent prendre en charge l'ensemble de fonctionnalités Vulkan le plus avancé disponible, à condition qu'ils acceptent une ABI 64 bits et qu'ils ne disposent pas de peu de mémoire.

Les appareils lancés avec Android 13 ou version ultérieure doivent être compatibles avec Vulkan 1.3.

Les appareils qui se lancent via Android 10 doivent être compatibles avec Vulkan 1.1.

D'autres appareils peuvent également être compatibles avec Vulkan 1.3, 1.2 et 1.1.

Prendre en charge une version de Vulkan

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

Ajoutez un pilote Vulkan compatible avec la version de 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 de la CDD supplémentaires de la version d'Android. Vous pouvez également mettre à jour un pilote Vulkan existant dont le numéro de version Vulkan est inférieur.
Remarque:Pour Android 14 et versions ultérieures, tous les appareils compatibles avec Vulkan doivent disposer de pilotes Vulkan 1.1. Pour en savoir plus, consultez les exigences du CDD pour Android 14.
Pour Vulkan 1.3 ou 1.1, assurez-vous que la fonctionnalité système renvoyée par le gestionnaire de paquets 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 paquets renvoie true pour Vulkan 1.3 et Vulkan 1.1 en ajoutant une règle, comme indiqué ci-dessous, à un fichier device.mk approprié.
- Ajoutez ce qui suit 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 ce qui suit 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 Android Baseline (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 disposer de 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 json du profil Vulkan, mais un sous-ensemble clé des fonctionnalités requises comprend les éléments suivants:

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êtrage (WSI)

Dans libvulkan.so, le pilote implémente les extensions d'intégration du système de fenêtre (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 n'importe quelle 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 du 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.

Options d'utilisation de Gralloc

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

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 issus de la structure VkSwapchainCreateInfoKHR. Le pilote doit remplir *grallocConsumerUsage et *grallocProducerUsage avec les indicateurs d'utilisation de 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(), appelé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 étendus de Gralloc.

Images basées sur Gralloc

VkNativeBufferANDROID est une structure d'extension vkCreateImage permettant de créer une image basée sur un tampon Gralloc. VkNativeBufferANDROID est fourni à vkCreateImage() dans la chaîne de structure VkImageCreateInfo. Les appels à vkCreateImage() avec VkNativeBufferANDROID se produisent 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;

Lors de la création d'une image basée sur 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

Sous 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 la chaîne de remplacement sont requis pour la chaîne de remplacement. La structure d'extension contient les indicateurs d'utilisation des images de la chaîne de remplacement:

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

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

Sous Android 10 ou version ultérieure, la plate-forme est compatible avec VK_KHR_swapchain v70. L'application Vulkan peut donc créer un VkImage reposant sur la mémoire de la chaîne de permutation. 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. L'imageIndex spécifié dans la structure VkBindImageMemorySwapchainInfoKHR doit être un index d'image de swapchain valide. Pendant ce temps, 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 swapchain et importe une barrière native signalée en externe dans un objet VkSemaphore et un objet VkFence existants:

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

vkAcquireImageANDROID() est appelé pendant vkAcquireNextImageKHR pour importer une barrière native dans les objets VkSemaphore et VkFence fournis par l'application (cependant, les objets sémaphore et barrière sont facultatifs dans cet appel). Le pilote peut également profiter de cette opportunité pour reconnaître et gérer toute modification externe de l'état du tampon Gralloc. De nombreux pilotes n'auront rien à faire ici. Cet appel place VkSemaphore et VkFence dans le même état d'attente que s'ils étaient signalés par vkQueueSubmit, de sorte que les files d'attente puissent attendre sur le sémaphore et que l'application puisse attendre sur la barrière.

Les deux objets sont signalés lorsque les signaux de cloisonnement natifs sous-jacents l'ont déjà fait. Le sémaphore est alors dans l'état signalé lorsque cette fonction est renvoyée. Le conducteur s'approprie le descripteur du fichier de clôture et le ferme lorsqu'il n'est plus nécessaire. Le pilote doit le faire même si aucun objet sémaphore ou barrière 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 était déjà signalée.

Publier des images

vkQueueSignalReleaseImageANDROID prépare une image de swapchain pour une utilisation externe, crée une barrière native et planifie la signalisation de la barrière native après que les sémaphores d'entrée ont signalé:

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

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

Si les sémaphores d'attente (le cas échéant) ont déjà été signalés et que queue est déjà inactif, le pilote peut définir *pNativeFenceFd sur -1 au lieu d'un véritable descripteur de fichier de clôture natif, ce qui indique qu'il n'y a rien à attendre. L'appelant est propriétaire 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é processeur associées à un tampon Gralloc pour être utilisées par des consommateurs d'images externes. La préparation du contenu du tampon pour être utilisé par les 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 répété de vkQueueSignalReleaseImageANDROID() sans appel intermédiaire à vkAcquireImageANDROID().

Compatibilité avec les images partageables

Certains appareils peuvent partager la propriété d'une seule image entre le pipeline d'affichage et l'implémentation Vulkan afin de réduire la latence. Dans Android 9 et versions ultérieures, le chargeur annonce de manière conditionnelle 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 prise en charge des images présentables partagées. Sinon, le chargeur interroge les fonctionnalité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:

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

Indicateur de fonctionnalité Vulkan

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

Une date au format AAAA-MM-JJ est encodée en tant qu'entier 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, ce qui correspond à la date 2019-03-01, qui correspond à la date associée aux tests Vulkan dEQP pour Android 10. Si l'indicateur de fonctionnalité correspond au moins à cette valeur, l'appareil prétend réussir tous les tests d'EQP Vulkan d'Android 10.

La valeur 0x07E40301 correspond à la date 2020-03-01, 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 prétend réussir tous les tests dEQP Vulkan Android 11.

La valeur 0x07E60301 correspond à la date 2022-03-01, 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 prétend réussir tous les tests dEQP Vulkan Android 13.

Un appareil qui expose un flag de fonctionnalité spécifique (par exemple 0x07E30301, 0x07E40301 ou 0x07E60301) prétend réussir tous les tests dEQP Android Vulkan de ce flag de fonctionnalité (Android 10, Android 11 et Android 13, respectivement). Cet appareil peut réussir les tests dEQP Vulkan à partir d'une version ultérieure d'Android.

Le dEQP Vulkan fait partie du CTS Android. À partir d'Android 11, le composant du lanceur de test dEQP de CTS est conscient du flag 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 ce flag de fonctionnalité. Ces tests sont signalés comme étant concluants.