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

Implémenter Vulkan

Vulkan est une API multiplateforme à faible surcharge pour les 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. Les avantages de l'utilisation de Vulkan incluent des réductions de la surcharge du processeur et la prise en charge du langage SPIR-V Binary Intermediate .

Pour mettre en œuvre Vulkan avec succès, un appareil doit inclure :

Le chargeur Vulkan, fourni par Android.
Un pilote Vulkan, fourni par les SoC tels que les GPU IHV, qui implémente l' API Vulkan . Pour prendre en charge la fonctionnalité Vulkan, l'appareil Android a besoin d'un matériel GPU compatible Vulkan et du pilote associé. Le GPU doit également prendre en charge GLES 3.1 et supérieur. Consultez votre fournisseur SoC pour demander une assistance pour les pilotes.

Si un appareil inclut un pilote Vulkan, l'appareil doit déclarer les fonctionnalités système FEATURE_VULKAN_HARDWARE_LEVEL et FEATURE_VULKAN_HARDWARE_VERSION , avec des versions qui reflètent avec précision 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

La platform/frameworks/native/vulkan du chargeur Vulkan est l'interface principale entre les applications Vulkan et le pilote Vulkan d'un appareil. Le chargeur Vulkan est installé sur /system/lib[64]/libvulkan.so . Le chargeur fournit les points d'entrée de base 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 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 prend également en charge l'énumération et le chargement de couches qui peuvent exposer des extensions supplémentaires et intercepter les appels d'API principaux lorsqu'ils sont acheminés vers le pilote.

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

Énumération et chargement des pilotes

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 préférés pour les pilotes Vulkan 32 bits et 64 bits sont :

/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 plus de détails et les emplacements alternatifs pris en charge, reportez-vous à libhardware/hardware.c .

Dans Android 7.0 et versions ultérieures, le dérivé Vulkan hw_module_t 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é Vulkan hw_device_t correspond à un seul pilote pouvant prendre en charge plusieurs périphériques 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 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 lorsqu'ils sont acheminés vers le pilote. Android n'inclut pas de couches sur l'image système ; cependant, les applications peuvent inclure des couches dans leur APK.

Lorsque vous utilisez des couches, gardez à l’esprit que le modèle et les politiques de sécurité d’Android diffèrent considérablement de ceux des autres plates-formes. En particulier, Android ne permet pas de charger du code externe dans un processus non déboguable sur des appareils de production (non rootés), ni d'inspecter ou de contrôler la mémoire, l'état, etc. du processus. Cela inclut l’interdiction de sauvegarder les core dumps, les traces API, etc. sur le disque pour une inspection ultérieure. Seules les couches fournies dans le cadre d'applications non déboguables sont activées sur les appareils de production, et les pilotes ne doivent pas fournir de fonctionnalités qui enfreignent ces politiques.

Les cas d'utilisation des couches incluent :

Couches de temps 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 cales pour les outils de traçage/profilage/débogage doivent pouvoir être mises à jour 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 au répertoire de leurs bibliothèques natives. Les ingénieurs IHV et OEM qui souhaitent diagnostiquer les échecs lors de la livraison d'applications non modifiables sont supposés avoir accès aux versions de non-production (rootées) de l'image système, à moins que ces applications ne soient déboguables. Pour plus d'informations, consultez Couches de validation Vulkan sur Android .
Couches utilitaires — Ces couches 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 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 laquelle de ces couches inclure dans leur package d’application.
Couches injectées (implicites) : inclut des couches telles que les superpositions de fréquence d'images, de réseaux sociaux et de lanceur de jeu fournies par l'utilisateur ou une autre application à l'insu ou sans le consentement de l'application. Ceux-ci violent les politiques de sécurité d'Android et ne sont pas pris en charge.

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

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

Android permet de porter les couches avec les modifications de l'environnement de construction entre Android et d'autres plates-formes. Pour plus de détails sur l'interface entre les couches et le chargeur, voir Architecture des interfaces du chargeur Vulkan . Les couches de validation maintenues par Khronos sont hébergées dans Vulkan Validation Layers .

Versions et capacités de l'API Vulkan

Le tableau suivant répertorie les versions de l'API Vulkan pour plusieurs versions d'Android.

Version 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. Une grande partie de ces fonctionnalités est incluse dans le but d'augmenter le contrôle et la granularité de l'interface de programmation Vulkan. Les instances de passe de rendu en une seule passe n'ont plus besoin d'objets de passe de rendu ou de framebuffers. 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 a les mêmes exigences matérielles que Vulkan 1.2, 1.1 et 1.0, avec la majeure partie de l'implémentation dans le pilote graphique spécifique au SoC, et non dans le framework.

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

Prise en charge des instances de passe de rendu en un seul passage
Prise en charge de la fin immédiate d'un appel de shader
Granularité plus fine sur la création, le partage et le contrôle du pipeline

Vulkan 1.3 comprend également plusieurs fonctionnalités plus petites et des améliorations de la convivialité de l'API. Toutes les modifications apportées à l'API principale de Vulkan avec la révision mineure 1.3 peuvent être trouvées dans Core Revisions (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 qui peuvent être interrogées à partir d'un pilote de périphérique. Vulkan 1.2 a les mêmes exigences matérielles que Vulkan 1.0 et 1.1 ; toute 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 comprend également plusieurs fonctionnalités plus petites et des améliorations de la convivialité de l'API. Toutes les modifications apportées à l'API principale de Vulkan avec la révision mineure 1.2 peuvent être trouvées dans Core Revisions (Vulkan 1.2) .

Présentation des fonctionnalités de Vulkan 1.1

Vulkan 1.1 inclut la prise en charge de l'interopérabilité mémoire/synchronisation, 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 pris en charge sur un appareil et de l'utiliser efficacement lorsqu'il l'est. Vulkan 1.1 a 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.

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

Prise en charge de l'importation et de l'exportation de tampons de mémoire et d'objets de synchronisation depuis l'extérieur de Vulkan (pour l'interopérabilité avec la caméra, les codecs et GLES)
Prise en charge des formats YCbCr

Vulkan 1.1 comprend également plusieurs fonctionnalités plus petites et des améliorations de la convivialité de l'API. Toutes les modifications apportées à l'API Vulkan principale avec la révision mineure 1.1 peuvent être trouvées dans Core Revisions (Vulkan 1.1) .

Choisissez le support Vulkan

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

Les appareils lancés avec Android 13 et supérieur doivent prendre en charge Vulkan 1.3.

Les appareils lancés via Android 10 doivent prendre en charge Vulkan 1.1.

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

Supporte une version Vulkan

Un appareil Android prend en charge une version Vulkan si les conditions suivantes sont remplies :

Ajoutez un pilote Vulkan qui prend en charge la version Vulkan qui vous intéresse (il doit s'agir de l'une des versions Vulkan 1.3, 1.1 ou 1.0) ainsi que les exigences CDD supplémentaires de la version Android. Vous pouvez également mettre à jour un pilote Vulkan existant avec un numéro de version Vulkan inférieur.
Remarque : Pour Android 14 et versions ultérieures, tous les appareils compatibles Vulkan doivent disposer des pilotes Vulkan 1.1. Consultez les exigences CDD d’Android 14 pour plus d’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 version correcte 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 renverra true pour Vulkan 1.3 et Vulkan 1.1 en ajoutant une règle, illustrée comme suit, à 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 de base 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 prenant en charge Android 14 ou supérieur et l'API Vulkan doit remplir 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 :

Textures compressées via ASTC et ETC.
Espaces colorimétriques variables via VK_EXT_swapchain_colorspace .
Ombrage d’échantillons et interpolation multi-échantillons via sampleRateShading .

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

Dans libvulkan.so , le pilote implémente les extensions d'intégration de 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 et toutes les interactions avec ANativeWindow sont gérés par la plateforme et ne sont pas exposés aux pilotes. L'implémentation WSI repose sur l'extension VK_ANDROID_native_buffer , qui doit être prise en charge par le pilote ; cette extension est utilisée uniquement par l'implémentation WSI et n'est pas exposée aux applications.

Indicateurs d'utilisation de Gralloc

Les implémentations de Vulkan peuvent nécessiter que des tampons de swapchain soient alloués avec des indicateurs d'utilisation Gralloc privés définis par l'implémentation. Lors de la création d'une swapchain, Android demande au pilote de traduire les indicateurs d'utilisation du format et de l'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 avec les indicateurs d'utilisation demandés par le consommateur de la swapchain lors de l'allocation des tampons.

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

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

vkGetSwapchainGrallocUsageANDROID() ne prend pas en charge les indicateurs d'utilisation de swapchain ou les indicateurs d'utilisation étendus de Gralloc.

Images sauvegardées 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 se produisent lors de l'appel à vkCreateSwapchainKHR . L'implémentation WSI alloue le nombre de tampons natifs demandés pour la swapchain, puis crée une VkImage pour chacun :

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 sauvegardée 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 swapchain sont requis pour la swapchain. La structure de l'extension contient les indicateurs d'utilisation de l'image swapchain :

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

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

Sous Android 10 et versions ultérieures, la plate-forme prend en charge VK_KHR_swapchain v70, de sorte que l'application Vulkan est capable de créer une VkImage sauvegardée par la mémoire swapchain. L'application appelle d'abord vkCreateImage avec une structure VkImageSwapchainCreateInfoKHR chaînée à la structure VkImageCreateInfo . Ensuite, l'application appelle vkBindImageMemory2(KHR) avec une structure VkBindImageMemorySwapchainInfoKHR chaînée à la structure VkBindImageMemoryInfo . L' imageIndex spécifié dans la structure VkBindImageMemorySwapchainInfoKHR doit être un index d'image 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 avec quel tampon Gralloc lier le VkImage .

Acquérir des images

vkAcquireImageANDROID acquiert la propriété d'une image swapchain et importe une clôture native signalée en externe à la fois dans un objet VkSemaphore existant et dans 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 (cependant, les objets sémaphore et clôture 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 conducteurs n'auront rien à faire ici. Cet appel place VkSemaphore et VkFence dans le même état d'attente que s'il était signalé par vkQueueSubmit , afin que les files d'attente puissent attendre sur le sémaphore et que l'application puisse attendre sur la clôture.

Les deux objets sont signalés lorsque la clôture native sous-jacente le signale ; si la clôture native a déjà signalé, alors le sémaphore est dans l'état signalé lorsque cette fonction revient. Le pilote s'approprie le descripteur de fichier fence et ferme le descripteur de fichier fence lorsqu'il n'est plus nécessaire. Le pilote doit le faire même si aucun objet sémaphore ou fence n'est fourni, ou même si vkAcquireImageANDROID échoue et renvoie une erreur. Si fenceFd vaut -1, c'est comme si la clôture native était déjà signalée.

Libérer des images

vkQueueSignalReleaseImageANDROID prépare une image de swapchain pour un usage externe, crée une clôture native et planifie la signalisation native de la clôture après que les sémaphores d'entrée l'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 produire une clôture native qui ne signale pas jusqu'à ce que tous les sémaphores waitSemaphoreCount dans pWaitSemaphores signalent et que tout travail supplémentaire requis pour préparer image pour la présentation soit terminé.

Si les sémaphores d'attente (le cas échéant) ont déjà été signalés et queue est déjà inactive, le pilote peut définir *pNativeFenceFd sur -1 au lieu d'un véritable descripteur de fichier de clôture natif, indiquant 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 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 à utiliser par des consommateurs externes doit être effectuée de manière asynchrone dans le cadre 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 , alors le pilote doit autoriser l'appel de vkQueueSignalReleaseImageANDROID() à plusieurs reprises sans appels intermédiaires à vkAcquireImageANDROID() .

Prise en charge des images présentables partagées

Certains appareils peuvent partager la propriété d'une seule image entre le pipeline d'affichage et l'implémentation de Vulkan afin de minimiser la latence. Sous 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 ne prend en charge ni Vulkan 1.1 ni 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 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 comprend les éléments suivants :

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

Drapeau de fonctionnalité Vulkan

Un appareil prenant en charge Android 11 ou version ultérieure et prenant en charge l'API Vulkan doit exposer un indicateur de fonctionnalité, android.software.vulkan.deqp.level . La valeur de cet indicateur de fonctionnalité est une date, codée sous forme de valeur entière. Il précise la date associée aux tests Vulkan dEQP que l'appareil prétend réussir.

Une date au format AAAA-MM-JJ est codé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 la journée

La valeur minimale autorisée pour l'indicateur de fonctionnalité est 0x07E30301 , ce qui correspond à la date du 01/03/2019, qui est la date associée aux tests Vulkan dEQP pour Android 10. Si l'indicateur de fonctionnalité est au moins cette valeur, l'appareil prétend réussissez tous les tests Android 10 Vulkan dEQP.

La valeur 0x07E40301 correspond à la date 2020-03-01, qui est la date associée aux tests Vulkan dEQP pour Android 11. Si l'indicateur de fonctionnalité est au moins de cette valeur, l'appareil prétend réussir tous les tests Vulkan dEQP d'Android 11.

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

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

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