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

Implémenter Vulkan

Vulkan est un modèle à faible coût, API multiplate-forme pour la 3D hautes performances graphiques. Tout comme OpenGL ES (GLES), Vulkan fournit des outils pour créer, des graphiques en temps réel dans les applications. Les avantages de Vulkan incluent la réduction du nombre de processeurs et la prise en charge du langage SPIR-V Binary Intermediate.

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

Le chargeur Vulkan, fourni par Android.
Un pilote Vulkan, fourni par des SoC comme les IHV des GPU, qui met en œuvre API Vulkan : Pour prendre en charge la fonctionnalité Vulkan, l'application Android appareil a besoin d'un matériel GPU compatible avec Vulkan et du pilote associé. Le GPU doit également être compatible avec GLES 3.1 et versions ultérieures. Consultez votre fournisseur de SoC pour demander de l'aide à un conducteur.

Si un appareil inclut un pilote Vulkan, il doit déclarer FEATURE_VULKAN_HARDWARE_LEVEL et FEATURE_VULKAN_HARDWARE_VERSION, avec des versions qui refléter avec précision les capacités de l'appareil. Cela permet de s'assurer appareil est conforme aux le document de définition de compatibilité (CDD).

Chargeur Vulkan

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

Le NDK comprend une bibliothèque bouchon libvulkan.so pour de l'association. La bibliothèque exporte les mêmes symboles que le chargeur. Les applications appellent les fonctions exporté depuis la véritable bibliothèque libvulkan.so vers saisir des fonctions de trampoline dans le chargeur, qui les envoient d'une couche ou d'un pilote en fonction de leur premier argument. vkGet*ProcAddr() appelle renvoie les pointeurs de fonction vers lesquels les trampolines s'envoient (c'est-à-dire, l'appel directement dans le code de l'API principale). Appeler via la fonction que les symboles exportés, est plus efficace, car le trampoline et l'envoi.

É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 hardware.h pour détecter et charger le pilote. Les chemins privilégié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 Remplacement des <ro.product.platform> par la valeur du système de ce nom. Pour en savoir plus et connaître les autres emplacements pris en charge, consultez libhardware/hardware.c.

Dans Android 7.0 et versions ultérieures, la dérivée hw_module_t de Vulkan encapsule une seule structure hw_module_t ; un seul pilote est accepté, et la chaîne constante HWVULKAN_DEVICE_0 est transmis à open().

La dérivée hw_device_t de Vulkan correspond à un seul qui peut prendre en charge plusieurs périphériques physiques. La La structure hw_device_t peut s'étendre à l'exportation vkGetGlobalExtensionProperties(), vkCreateInstance() et Fonctions vkGetInstanceProcAddr(). Le chargeur peut détecter tous les autres VkInstance(), VkPhysicalDevice() et les fonctions vkGetDeviceProcAddr() en appelant le vkGetInstanceProcAddr() de la structure hw_device_t.

Découverte et chargement de couches

Le chargeur Vulkan prend en charge l'énumération et le chargement de couches qui peuvent exposer des extensions supplémentaires et intercepter les appels d'API principaux sur le chemin pilote. Android n'inclut pas de couches sur l'image système. Toutefois, applications peuvent inclure des calques dans leur APK.

Lorsque vous utilisez des couches, n'oubliez pas que le modèle et les règles de sécurité d'Android sont très différentes des autres plates-formes. En particulier, Android n'autorise pas Chargement de code externe dans un processus non débogable en production (sans mode root) et ne permet pas à un code externe d'inspecter ou de contrôler la mémoire, l'état, etc. Cela inclut l'interdiction de l'enregistrement des vidages de mémoire, les traces, etc. sur le disque pour une inspection ultérieure. Seuls les calques diffusés les applications non débogables sont activées sur les appareils de production, et les pilotes ne doivent pas fournir d'une fonctionnalité qui ne respecte pas ces règles.

Voici quelques cas d'utilisation des calques:

Couches au moment du développement : validation des couches et des shims pour les 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. Couches et shims de validation pour Les outils de traçage, de profilage et de débogage doivent pouvoir être mis à jour sans système l'image. Les développeurs qui souhaitent en utiliser un pendant le développement peuvent modifier le package de l'application. Par exemple, en ajoutant un fichier à leur répertoire de bibliothèques natif. des ingénieurs IHV et OEM qui pour diagnostiquer les échecs de livraison d'applications non modifiables. l'accès aux versions hors 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 d'utilitaire : elles exposent des extensions, telles qu'une couche qui implémente un gestionnaire de mémoire pour la mémoire de l'appareil. Les développeurs choisissent des couches et des versions de ces couches, à utiliser dans leurs app différentes applications utilisant le même calque peuvent toujours utiliser différentes versions. Les développeurs choisissent quelles couches ajouter dans leur package d'application.
Calques injectés (implicites) : incluent des calques tels 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 à son insu ou sans son consentement. Ces ne respectent pas les règles de sécurité d'Android et ne sont pas pris en charge.

Pour les applications non débogables, le chargeur ne recherche les calques que dans le répertoire de bibliothèque natif de l'application et tente de charger toute bibliothèque portant un nom correspondant à un modèle particulier (par exemple, libVKLayer_foo.so).

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

Android permet le portage des couches avec des changements d'environnement de compilation Android et d'autres plates-formes. Pour en savoir plus sur l'interface entre les couches et le chargeur, voir Architecture des interfaces du chargeur Vulkan. Le groupe Khronos entretenu les couches de validation sont hébergées 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. Une grande partie de cette fonctionnalité est incluse dans le but d'améliorer le contrôle et la précision l'interface de programmation Vulkan. Les instances de passe de rendu en un seul passage n'ont plus besoin des objets de passe de rendu ou des tampons de frames. le nombre total d'objets d'état de pipeline peut être réduit ; la synchronisation dans l'API est remaniée. Vulkan 1.3 a la même configuration matérielle que Vulkan 1.2, 1.1 et 1.0, la majeure partie de l'implémentation étant dans le pilote graphique spécifique au SoC, pas dans le cadre.

Les fonctionnalités Vulkan 1.3 les plus importantes pour Android sont les suivantes:

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

Vulkan 1.3 comprend également plusieurs fonctionnalités plus petites et une meilleure facilité d'utilisation des API. Toutes les modifications apportée à l'API Vulkan principale avec la révision mineure 1.3 est disponible à l'adresse 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 a la même configuration matérielle que Vulkan 1.0 et 1.1. toutes les la mise en œuvre est 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 compatibilité avec le stockage 8 bits.

Vulkan 1.2 comprend également plusieurs fonctionnalités plus petites et une meilleure facilité d'utilisation des API. Toutes les modifications apportées à l'API Vulkan principale avec la révision mineure 1.2 est disponible à l'adresse Révisions principales (Vulkan 1.2)

Présentation des fonctionnalités de Vulkan 1.1

Vulkan 1.1 prend en charge l'interopérabilité de la mémoire/de la synchronisation, ce qui permet aux OEM de prendre en charge Vulkan 1.1 sur les appareils. En outre, l'interopérabilité mémoire/synchronisation permet aux développeurs pour déterminer si Vulkan 1.1 est compatible avec un appareil et l'utiliser efficacement lorsqu'elle l'est. Vulkan 1.1 a la même configuration matérielle que Vulkan 1.0, mais la plupart des dans le pilote graphique spécifique au SOC, et non dans le framework.

Les fonctionnalités Vulkan 1.1 les plus importantes pour Android sont les suivantes:

Prise en charge de l'importation et de l'exportation de tampons de mémoire et de la synchronisation Objets extérieurs à Vulkan (pour l'interopérabilité avec l'appareil photo, les codecs et GLES)
Compatibilité avec les formats YCbCr

Vulkan 1.1 comprend également plusieurs fonctionnalités plus petites et une meilleure facilité d'utilisation des API. Toutes les modifications apportées à l'API Vulkan principale avec la révision mineure 1.1 est disponible à l'adresse Révisions principales (Vulkan 1.1)

Choisir la prise en charge de Vulkan

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

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

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

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

Assurer la compatibilité avec une version de Vulkan

Un appareil Android est compatible avec une version de 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 l'une des versions de Vulkan). 1.3, 1.1 ou 1.0) en plus des exigences de CDD supplémentaires Version d'Android Vous pouvez également mettre à jour un pilote Vulkan existant avec un numéro de version Vulkan inférieur.
Remarque:Pour Android 14 ou version ultérieure, Les appareils compatibles avec Vulkan doivent disposer de pilotes Vulkan 1.1. Découvrez Android 14 Exigences relatives au CDD des informations.
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 bonne version de Vulkan.
- 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 renvoie true pour Vulkan 1.3 et Vulkan 1.1 en ajoutant une règle, comme indiqué ci-dessous, dans 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 Android Baseline (ABP)

Nous encourageons tous les appareils Android à se conformer au dernier profil Android Baseline 2022 en tant que décrits dans le Guide des profils Android Baseline

Tous les appareils compatibles avec Android 14 ou version ultérieure et l'API Vulkan doivent pour qu'elles remplissent toutes les fonctionnalités définies dans Profil Android Baseline 2021 La liste complète des fonctionnalités requises énumérée dans le fichier json du profil Vulkan, mais un sous-ensemble de clé des comprend les fonctionnalités suivantes:

Textures compressées via ASTC et ETC
Espaces colorimétriques variables via VK_EXT_swapchain_colorspace.
Ombres d'échantillons et interpolation de plusieurs échantillons via sampleRateShading

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

Dans libvulkan.so, le pilote implémente les éléments suivants : Extensions d'intégration de systèmes de fenêtres (WSI) :

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 sur Android 10

Les objets VkSurfaceKHR et VkSwapchainKHR, ainsi que les interactions avec ANativeWindow sont gérées par la plate-forme et ne sont pas aux conducteurs. L'implémentation du WSI repose sur VK_ANDROID_native_buffer, qui doit être prises en charge par le pilote. cette extension n'est utilisée que par l'implémentation WSI et n'est pas exposé aux applications.

Indicateurs d'utilisation de Gralloc

Les implémentations Vulkan peuvent nécessiter d'allouer des tampons de chaîne de permutation options privées d'utilisation de Gralloc définies par l'implémentation. Lors de la création d'une chaîne d'échange, Android demande au pilote de traduire le format et l'utilisation de l'image demandés dans les 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 issus de la structure VkSwapchainCreateInfoKHR. Le conducteur doit remplir *grallocConsumerUsage et *grallocProducerUsage avec les indicateurs d'utilisation Gralloc requis pour le format et leur utilisation. Les indicateurs d'utilisation renvoyés par le pilote sont combinés indicateurs demandés par le consommateur de la chaîne de permutation lors de l'allocation des tampons.

Android 7.x appelle une version antérieure de VkSwapchainImageUsageFlagsANDROID(), nommée vkGetSwapchainGrallocUsageANDROID(). Abandon d'Android 8.0 ou version ultérieure vkGetSwapchainGrallocUsageANDROID(), mais continue d'appeler 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 l'utilisation de la chaîne d'échange ou d'utilisation étendue de Gralloc.

Images reposant sur Gralloc

VkNativeBufferANDROID est une extension vkCreateImage. pour créer une image reposant sur un tampon Gralloc. VkNativeBufferANDROID correspond à fourni à vkCreateImage() dans le VkImageCreateInfo la chaîne de structure. Des appels vers le vkCreateImage() avec VkNativeBufferANDROID sont effectués pendant l'appel à vkCreateSwapchainKHR. L'implémentation du WSI alloue le nombre de tampons natifs demandés pour la chaîne de permutation, puis crée VkImage pour chacune d'elles:

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 a : 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 Structure des extensions VkSwapchainImageCreateInfoKHR dans le Chaîne VkImageCreateInfo fournie à vkCreateImage Lorsque des indicateurs d'utilisation de l'image de la chaîne de permutation sont requis. La structure de l'extension contient les indicateurs d'utilisation de l'image de la chaîne de permutation:

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

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

Dans Android 10 et versions ultérieures, la plate-forme est compatible avec VK_KHR_swapchain v70. L'application Vulkan peut donc créer un VkImage reposant sur une mémoire de chaîne d'échange. L'application appelle d'abord vkCreateImage avec un VkImageSwapchainCreateInfoKHR est liée à la structure VkImageCreateInfo. Dans ce cas, l'application appelle vkBindImageMemory2(KHR) avec un Structure VkBindImageMemorySwapchainInfoKHR enchaînée à la Structure VkBindImageMemoryInfo. imageIndex spécifié dans la structure VkBindImageMemorySwapchainInfoKHR doit être un index d'image de chaîne d'échange valide. Dans le même temps, la plate-forme la structure de l'extension VkNativeBufferANDROID avec la Des informations sur le tampon Gralloc à la chaîne VkBindImageMemoryInfo, donc le pilote sait à quel tampon Gralloc lier le VkImage.

Récupérer des images

vkAcquireImageANDROID acquiert la propriété d'une image de chaîne d'échange et importe une clôture native signalée de manière externe dans une VkSemaphore 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 cloisonnement natif dans les objets VkSemaphore et VkFence fournis par l'application (les objets Semaphore et Fence sont tous deux facultatif dans cet appel). Le conducteur peut aussi profiter de cette opportunité et gérer toutes les modifications externes de l'état du tampon Gralloc ; de nombreux conducteurs ne pourront pas n'avez rien à faire ici. Cet appel place les VkSemaphore et VkFence dans le même état d'attente que s'il avait été signalé par vkQueueSubmit, afin que les files d'attente puissent attendre le sémaphore et que l'application reste privée.

Les deux objets sont signalés lorsque les signaux de cloisonnement natifs sous-jacents sont activés. si la clôture native a déjà signalé le sémaphore, alors le sémaphore se trouve dans le lorsque cette fonction s'affiche. Le conducteur s'approprie le fichier de clôture. et ferme le descripteur du fichier de clôture lorsqu'il n'est plus nécessaire. Le conducteur doit le faire même si aucun objet de sémaphore ou de clôture n'est fourni, ou même si vkAcquireImageANDROID échoue et renvoie une erreur. Si La valeur de fenceFd est -1, comme si la clôture native était déjà signalé.

Publier des images

vkQueueSignalReleaseImageANDROID prépare une image de chaîne d'échange pour une utilisation externe, crée une clôture native et planifie qu'elle soit signalée après 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() dans la file d'attente fournie. Le conducteur doit produire une clôture native qui ne signale jusqu'aux waitSemaphoreCount sémaphores de le signal pWaitSemaphores, et toute opération supplémentaire requise pour Préparer image pour la présentation

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

De nombreux pilotes peuvent ignorer le paramètre d'image, mais certains doivent être préparés Structures de données côté CPU associées à un tampon Gralloc pour une utilisation par des aux consommateurs d'images. Préparer le contenu du tampon en vue de son utilisation par des consommateurs externes doit être effectuées de manière asynchrone lors de la transition de l'image VK_IMAGE_LAYOUT_PRESENT_SRC_KHR

Si l'image a été créée avec VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID, le conducteur doit permet d'appeler vkQueueSignalReleaseImageANDROID() de manière répétée sans appeler vkAcquireImageANDROID() par intermittence.

Prise en charge des 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 de Vulkan pour minimiser la latence. Dans Android 9 et versions ultérieures, le chargeur annonce de manière conditionnelle le Extension VK_KHR_shared_presentable_image basée sur l'avis du conducteur à un appel à vkGetPhysicalDeviceProperties2.

Si le pilote n'est pas compatible avec Vulkan 1.1 ou VK_KHR_physical_device_properties2, le chargeur n'effectue pas annoncent la prise en charge des images présentables partagées. Sinon, le chargeur interroge les fonctionnalités du pilote en appelant vkGetPhysicalDeviceProperties2() en incluant la structure suivante dans le 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 conducteur peut partager la propriété d'une image avec l'écran il définit le membre sharedImage sur VK_TRUE.

Validation

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

Tests de conformité Khronos Vulkan 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 correctement configuré pour les fonctionnalités de Vulkan qu'il prend en charge.

Indicateur de fonctionnalité Vulkan

Un appareil compatible avec Android 11 ou version ultérieure et compatible avec l'API Vulkan est nécessaire pour exposer un flag de fonctionnalité, android.software.vulkan.deqp.level La valeur de ce flag de fonctionnalité est une date encodée sous forme de nombre entier. Il indique la date associée à les tests dEQP de Vulkan que l'appareil prétend réussir.

Une date au format AAAA-MM-JJ est encodée au format entier 32 bits comme suit:

Bits 0-15 stockent l'année
Les bits 16 à 23 stockent le mois
Bits 24-31 stockent la journée

La valeur minimale autorisée pour le flag de fonctionnalité est 0x07E30301. qui correspond à la date 2019-03-01, qui est la date associée au Tests dEQP Vulkan pour Android 10. Si le flag de fonctionnalité est au moins égal à 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, soit la date associée aux tests dEQP de Vulkan pour Android 11. Si la fonctionnalité a au moins cette valeur, l'appareil prétend réussir tous les tests d'Android 11 Tests dEQP Vulkan.

La valeur 0x07E60301 correspond à la date 2022-03-01, soit la date associée aux tests dEQP de Vulkan pour Android 13. Si le flag de fonctionnalité est au moins égal à cette valeur, l'appareil prétend réussir tous les tests Vulkan d'Android 13. dEQP.

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

Vulkan dEQP fait partie d'Android CTS. Sous Android 11, le lanceur de test dEQP de CTS connaît le android.software.vulkan.deqp.level et ignore tous les tests dEQP de Vulkan qui, selon ce principe, flag de fonctionnalité - l'appareil ne prétend pas être pris en charge. De tels tests sont signalé comme résolument réussi.