Implementare Vulkan

Vulkan è un'API multipiattaforma a basso overhead per grafica 3D ad alte prestazioni. Come OpenGL ES (GLES), Vulkan fornisce strumenti per creare grafica in tempo reale di alta qualità nelle app. I vantaggi dell'utilizzo di Vulkan includono la riduzione del sovraccarico della CPU e il supporto del linguaggio SPIR-V Binary Intermediate.

Per implementare Vulkan correttamente, un dispositivo deve includere:

  • Il caricatore Vulkan, fornito da Android.
  • Un driver Vulkan, fornito da SoC come GPU IHV, che implementa l'API Vulkan. Per supportare la funzionalità Vulkan, il dispositivo Android deve disporre di hardware GPU compatibile con Vulkan e del driver associato. La GPU deve supportare anche GLES 3.1 e versioni successive. Contatta il fornitore del SoC per richiedere l'assistenza per i driver.

Se un dispositivo include un driver Vulkan, deve dichiarare le funzionalità di sistema FEATURE_VULKAN_HARDWARE_LEVEL e FEATURE_VULKAN_HARDWARE_VERSION, con versioni che riflettono accuratamente le funzionalità del dispositivo. In questo modo si garantisce che il dispositivo sia conforme al Compatibility Definition Document (CDD).

Loader Vulkan

Il caricatore Vulkan platform/frameworks/native/vulkan è l'interfaccia principale tra le app Vulkan e il driver Vulkan di un dispositivo. Il caricatore Vulkan è installato in /system/lib[64]/libvulkan.so. Il caricatore fornisce i punti di ingresso principali dell'API Vulkan, i punti di ingresso delle estensioni richieste dalla CDD di Android e molte estensioni facoltative aggiuntive. Le estensioni di integrazione del sistema di finestre (WSI) vengono esportate dal caricatore e implementate principalmente nel caricatore anziché nel driver. Il caricatore supporta anche l'enumerazione e il caricamento di livelli che possono esporre estensioni aggiuntive e intercettare le chiamate API principali mentre vengono inviate al driver.

L'NDK include una libreria libvulkan.so stub per il collegamento. La libreria esporta gli stessi simboli del caricatore. Le app chiamano le funzioni esportate dalla libreria libvulkan.so reale per inserire le funzioni trampoline nel caricatore, che vengono inviate al livello o al driver appropriato in base al primo argomento. La chiamata vkGet*ProcAddr() restituisce i puntatori di funzione a cui vengono inviati i trampolini (ovvero, chiama direttamente il codice dell'API principale). La chiamata tramite i puntatori di funzione, anziché i simboli esportati, è più efficiente in quanto salta il trampolino e l'invio.

Enumerazione e caricamento dei driver

Quando viene creata l'immagine di sistema, Android si aspetta che il sistema sappia quali GPU sono disponibili. Il caricatore utilizza il meccanismo HAL esistente in hardware.h per rilevare e caricare il driver. I percorsi preferiti per i driver Vulkan a 32 bit e 64 bit sono:

/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

In Android 7.0 e versioni successive, il derivato Vulkan hw_module_t contiene una singola struttura hw_module_t; è supportato un solo driver e la stringa costante HWVULKAN_DEVICE_0 viene passata a open().

Il derivato Vulkan hw_device_t corrisponde a un singolo driver che può supportare più dispositivi fisici. La struttura hw_device_t può estendersi alle funzioni vkGetGlobalExtensionProperties(), vkCreateInstance() e vkGetInstanceProcAddr(). Il caricatore può trovare tutte le altre funzioni VkInstance(), VkPhysicalDevice() e vkGetDeviceProcAddr() chiamando vkGetInstanceProcAddr() della struttura hw_device_t.

A partire da Android 15, il caricatore supporta APEX per caricare il driver Vulkan. Imposta ro.vulkan.apex sul nome dell'APEX Vulkan per caricare Vulkan dall'APEX.

Rilevamento e caricamento dei livelli

Il caricatore Vulkan supporta l'enumerazione e il caricamento di livelli che possono esporre estensioni aggiuntive e intercettare le chiamate API di base durante il loro percorso verso il driver. Android non include livelli nell'immagine di sistema, ma le app possono includerli nel proprio APK.

Quando utilizzi i livelli, tieni presente che il modello di sicurezza e le norme di Android differiscono in modo significativo da altre piattaforme. In particolare, Android non consente il caricamento di codice esterno in un processo non eseguibile in modalità debug su dispositivi di produzione (non rooted), né consente al codice esterno di ispezionare o controllare la memoria, lo stato e così via del processo. Ciò include il divieto di salvare dump di memoria, tracce API e così via su disco per un'ispezione successiva. Sui dispositivi di produzione sono abilitati solo i livelli forniti come parte di app non eseguibili in modalità di debug e i driver non devono fornire funzionalità che violano queste norme.

I casi d'uso per i livelli includono:

  • Livelli in fase di sviluppo: i livelli di convalida e gli shim per gli strumenti di tracciamento/profilazione/debug non devono essere installati sull'immagine di sistema dei dispositivi di produzione. I livelli di convalida e gli shim per gli strumenti di tracciamento/profilazione/debug devono essere aggiornabili senza un'immagine di sistema. Gli sviluppatori che vogliono utilizzare uno di questi livelli durante lo sviluppo possono modificare il pacchetto dell'app, ad esempio, aggiungendo un file alla directory delle librerie native. Si presume che gli ingegneri IHV e OEM che vogliono diagnosticare gli errori nella spedizione di app non modificabili abbiano accesso alle build non di produzione (con accesso root) dell'immagine di sistema, a meno che queste app non siano eseguibili in modalità di debug. Per maggiori informazioni, consulta Livelli di convalida Vulkan su Android.
  • Livelli di utilità: questi livelli espongono estensioni, ad esempio un livello che implementa un gestore della memoria per la memoria del dispositivo. Gli sviluppatori scelgono i livelli e le relative versioni da utilizzare nella propria app; app diverse che utilizzano lo stesso livello potrebbero comunque utilizzare versioni diverse. Gli sviluppatori scelgono quali di questi livelli includere nel pacchetto dell'app.
  • Livelli inseriti (impliciti): include livelli come frequenza dei fotogrammi, social network e overlay di avvio giochi forniti dall'utente o da un'altra app all'insaputa o senza il consenso dell'app. Questi violano le norme di sicurezza di Android e non sono supportati.

Per le app non eseguibili in modalità di debug, il caricatore cerca i livelli solo nella directory della libreria nativa dell'app e tenta di caricare qualsiasi libreria con un nome che corrisponde a un determinato pattern (ad esempio, libVKLayer_foo.so).

Per le app di cui è possibile eseguire il debug, il caricatore cerca i livelli in /data/local/debug/vulkan e tenta di caricare qualsiasi libreria che corrisponda a un determinato pattern.

Android consente di trasferire i livelli con modifiche all'ambiente di compilazione tra Android e altre piattaforme. Per informazioni dettagliate sull'interfaccia tra i livelli e il caricatore, consulta Architettura delle interfacce del caricatore Vulkan. I livelli di convalida gestiti da Khronos sono ospitati in Vulkan Validation Layers.

Versioni e funzionalità dell'API Vulkan

La tabella seguente elenca le versioni dell'API Vulkan per diverse release di Android.
Versione di Android Versione Vulkan
Android 13 Vulkan 1.3
Android 9 Vulkan 1.1
Android 7 Vulkan 1.0

Panoramica delle funzionalità di Vulkan 1.3

Vulkan 1.3 canonizza una serie di estensioni precedentemente facoltative nelle funzionalità principali di Vulkan. Gran parte di questa funzionalità è inclusa con l'intento di aumentare il controllo e la granularità dell'interfaccia di programmazione Vulkan. Le istanze di pass di rendering a singola passata non richiedono più oggetti pass di rendering o frame buffer. Il numero totale di oggetti di stato della pipeline può essere ridotto e la sincronizzazione all'interno dell'API viene rivista. Vulkan 1.3 ha gli stessi requisiti hardware di Vulkan 1.2, 1.1 e 1.0, con la maggior parte dell'implementazione nel driver grafico specifico per il SoC, non nel framework.

Le funzionalità più importanti di Vulkan 1.3 per Android sono:

  • Supporto per le istanze di pass di rendering a singola passata
  • Supporto per l'interruzione immediata di una chiamata di shader
  • Maggiore granularità nella creazione, nella condivisione e nel controllo delle pipeline

Vulkan 1.3 include anche diverse funzionalità più piccole e miglioramenti dell'usabilità delle API. Tutte le modifiche apportate all'API Vulkan di base con la revisione secondaria 1.3 sono disponibili all'indirizzo Revisioni principali (Vulkan 1.3).

Panoramica delle funzionalità di Vulkan 1.2

Vulkan 1.2 aggiunge una serie di funzionalità ed estensioni che semplificano la superficie dell'API. Ciò include un modello di memoria unificato e ulteriori informazioni che possono essere interrogate da un driver del dispositivo. Vulkan 1.2 ha gli stessi requisiti hardware di Vulkan 1.0 e 1.1; tutta l'implementazione si trova nel driver grafico specifico per il SoC, non nel framework.

La funzionalità più importante di Vulkan 1.2 per Android è il supporto dell'archiviazione a 8 bit.

Vulkan 1.2 include anche diverse funzionalità più piccole e miglioramenti dell'usabilità dell'API. Tutte le modifiche apportate all'API Vulkan di base con la revisione secondaria 1.2 sono disponibili all'indirizzo Revisioni principali (Vulkan 1.2).

Panoramica delle funzionalità di Vulkan 1.1

Vulkan 1.1 include il supporto per l'interoperabilità di memoria/sincronizzazione, che consente agli OEM di supportare Vulkan 1.1 sui dispositivi. Inoltre, l'interoperabilità di memoria/sincronizzazione consente agli sviluppatori di determinare se Vulkan 1.1 è supportato su un dispositivo e di utilizzarlo in modo efficace quando lo è. Vulkan 1.1 ha gli stessi requisiti hardware di Vulkan 1.0, ma la maggior parte dell'implementazione si trova nel driver grafico specifico del SOC, non nel framework.

Le funzionalità più importanti di Vulkan 1.1 per Android sono:

  • Supporto per l'importazione e l'esportazione di buffer di memoria e oggetti di sincronizzazione da fonti esterne a Vulkan (per l'interoperabilità con fotocamera, codec e GLES)
  • Supporto per i formati YCbCr

Vulkan 1.1 include anche diverse funzionalità più piccole e miglioramenti dell'usabilità dell'API. Tutte le modifiche apportate all'API Vulkan di base con la revisione secondaria 1.1 sono disponibili all'indirizzo Revisioni principali (Vulkan 1.1).

Scegliere il supporto Vulkan

I dispositivi Android devono supportare il set di funzionalità Vulkan più avanzato disponibile, a condizione che supportino un'ABI a 64 bit e non abbiano poca memoria.

I dispositivi lanciati con Android 13 e versioni successive devono supportare Vulkan 1.3.

I dispositivi lanciati tramite Android 10 devono supportare Vulkan 1.1.

Altri dispositivi possono supportare facoltativamente Vulkan 1.3, 1.2 e 1.1.

Supportare una versione Vulkan

Un dispositivo Android supporta una versione di Vulkan se sono soddisfatte le seguenti condizioni:

  1. Aggiungi un driver Vulkan che supporti la versione Vulkan di interesse (deve essere una delle versioni Vulkan 1.3, 1.1 o 1.0) insieme ai requisiti CDD aggiuntivi della versione di Android. In alternativa, aggiorna un driver Vulkan esistente con un numero di versione Vulkan inferiore.
  2. Per Vulkan 1.3 o 1.1, assicurati che la funzionalità di sistema restituita dal gestore dei pacchetti restituisca true per la versione corretta di Vulkan.
    • Per Vulkan 1.3, la funzionalità è PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000).
    • Per Vulkan 1.1, la funzionalità è PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000).
    Il gestore dei pacchetti restituirà true per Vulkan 1.3 e Vulkan 1.1 aggiungendo una regola, mostrata di seguito, a un file device.mk appropriato.
    • Aggiungi quanto segue per 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
    • Aggiungi quanto segue per 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

Profilo di base Android (ABP)

Invitiamo tutti i dispositivi Android a rispettare il profilo Android Baseline 2022 più recente, come descritto nella guida al profilo Android Baseline.

Qualsiasi dispositivo che supporti Android 14 o versioni successive e l'API Vulkan deve soddisfare tutte le funzionalità definite nel profilo Android Baseline 2021. L'elenco completo delle funzionalità richieste è enumerato nel file del profilo Vulkan json, ma un sottoinsieme chiave delle funzionalità richieste include:

  • Texture compresse tramite ASTC ed ETC.
  • Spazi colore variabili tramite VK_EXT_swapchain_colorspace.
  • Ombreggiatura dei campioni e interpolazione multisample tramite sampleRateShading.

Integrazione del sistema di finestre (WSI)

In libvulkan.so, il driver implementa le seguenti estensioni di integrazione del sistema di finestre (WSI):

  • VK_KHR_surface
  • VK_KHR_android_surface
  • VK_KHR_swapchain
  • VK_KHR_driver_properties, implementato per Vulkan 1.1 in Android 10 solo
  • VK_GOOGLE_display_timing, implementato per qualsiasi versione di Vulkan in Android 10

Gli oggetti VkSurfaceKHR e VkSwapchainKHR e tutte le interazioni con ANativeWindow sono gestiti dalla piattaforma e non sono esposti ai conducenti. L'implementazione WSI si basa sull'estensione VK_ANDROID_native_buffer, che deve essere supportata dal driver. Questa estensione viene utilizzata solo dall'implementazione WSI e non è esposta alle app.

Flag di utilizzo di Gralloc

Le implementazioni Vulkan potrebbero richiedere l'allocazione di buffer swapchain con flag di utilizzo Gralloc privati definiti dall'implementazione. Quando crei una swapchain, Android chiede al driver di tradurre il formato richiesto e i flag di utilizzo dell'immagine in flag di utilizzo di Gralloc chiamando:

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

I parametri format e imageUsage vengono presi dalla struttura VkSwapchainCreateInfoKHR. Il conducente deve compilare *grallocConsumerUsage e *grallocProducerUsage con i flag di utilizzo di Gralloc richiesti per il formato e l'utilizzo. I flag di utilizzo restituiti dal driver vengono combinati con i flag di utilizzo richiesti dal consumer della swapchain durante l'allocazione dei buffer.

Android 7.x chiama una versione precedente di VkSwapchainImageUsageFlagsANDROID(), denominata vkGetSwapchainGrallocUsageANDROID(). Android 8.0 e versioni successive ritirano vkGetSwapchainGrallocUsageANDROID() ma chiamano comunque vkGetSwapchainGrallocUsageANDROID() se vkGetSwapchainGrallocUsage2ANDROID() non è fornito dal driver:

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

vkGetSwapchainGrallocUsageANDROID() non supporta i flag di utilizzo della swapchain o i flag di utilizzo di Gralloc estesi.

Immagini supportate da Gralloc

VkNativeBufferANDROID è una struttura di estensione vkCreateImage per la creazione di un'immagine supportata da un buffer Gralloc. VkNativeBufferANDROID viene fornito a vkCreateImage() nella catena di strutture VkImageCreateInfo. Le chiamate a vkCreateImage() con VkNativeBufferANDROID avvengono durante la chiamata a vkCreateSwapchainKHR. L'implementazione di WSI alloca il numero di buffer nativi richiesti per la swapchain, quindi crea un VkImage per ognuno:

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;

Quando crei un'immagine supportata da Gralloc, VkImageCreateInfo ha i seguenti dati:

  .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

In Android 8.0 e versioni successive, la piattaforma fornisce una struttura di estensione VkSwapchainImageCreateInfoKHR nella catena VkImageCreateInfo fornita a vkCreateImage quando sono necessari flag di utilizzo delle immagini swapchain per la swapchain. La struttura dell'estensione contiene i flag di utilizzo delle immagini della swapchain:

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

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

In Android 10 e versioni successive, la piattaforma supporta VK_KHR_swapchain v70, quindi l'app Vulkan è in grado di creare un VkImage supportato dalla memoria della swapchain. L'app chiama prima vkCreateImage con una struttura VkImageSwapchainCreateInfoKHR concatenata alla struttura VkImageCreateInfo. L'app chiama vkBindImageMemory2(KHR) con una struttura VkBindImageMemorySwapchainInfoKHR concatenata alla struttura VkBindImageMemoryInfo. Il valore imageIndex specificato nella struttura VkBindImageMemorySwapchainInfoKHR deve essere un indice di immagini swapchain valido. Nel frattempo, la piattaforma fornisce una struttura di estensione VkNativeBufferANDROID con le informazioni sul buffer Gralloc corrispondenti alla catena VkBindImageMemoryInfo, in modo che il driver sappia a quale buffer Gralloc associare VkImage.

Acquisire immagini

vkAcquireImageANDROID acquisisce la proprietà di un'immagine swapchain e importa una recinzione nativa segnalata esternamente in un oggetto VkSemaphore esistente e in un oggetto VkFence esistente:

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

vkAcquireImageANDROID() viene chiamato durante vkAcquireNextImageKHR per importare una barriera nativa negli oggetti VkSemaphore e VkFence forniti dall'app (tuttavia, gli oggetti semaforo e barriera sono facoltativi in questa chiamata). Il driver può anche utilizzare questa opportunità per riconoscere e gestire eventuali modifiche esterne allo stato del buffer Gralloc; molti driver non dovranno fare nulla qui. Questa chiamata mette VkSemaphore e VkFence nello stesso stato di attesa come se segnalato da vkQueueSubmit, in modo che le code possano attendere il semaforo e l'app possa attendere la barriera.

Entrambi gli oggetti vengono segnalati quando vengono segnalate le recinzioni native sottostanti. Se la recinzione nativa è già stata segnalata, il semaforo è nello stato segnalato quando questa funzione restituisce un valore. Il driver acquisisce la proprietà del descrittore del file di recinzione e lo chiude quando non è più necessario. Il driver deve farlo anche se non viene fornito un semaforo o un oggetto fence o anche se vkAcquireImageANDROID non va a buon fine e restituisce un errore. Se fenceFd è -1, è come se la recinzione nativa fosse già stata segnalata.

Immagini di rilascio

vkQueueSignalReleaseImageANDROID prepara un'immagine della swapchain per l'uso esterno, crea una recinzione nativa e pianifica la segnalazione della recinzione nativa dopo che i semafori di input hanno segnalato:

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

vkQueuePresentKHR() chiamate vkQueueSignalReleaseImageANDROID() nella coda fornita. Il conducente deve produrre una recinzione nativa che non segnala finché tutti i semafori waitSemaphoreCount in pWaitSemaphores non segnalano e non viene completato qualsiasi lavoro aggiuntivo necessario per preparare image per la presentazione.

Se i semafori di attesa (se presenti) hanno già segnalato e queue è già inattivo, il driver può impostare *pNativeFenceFd su -1 anziché su un descrittore di file di recinzione nativo effettivo, indicando che non c'è nulla da attendere. Il chiamante possiede e chiude il descrittore di file restituito in *pNativeFenceFd.

Molti driver possono ignorare il parametro dell'immagine, ma alcuni potrebbero dover preparare strutture di dati lato CPU associate a un buffer Gralloc per l'utilizzo da parte di consumatori di immagini esterni. La preparazione dei contenuti del buffer per l'utilizzo da parte di consumatori esterni deve essere eseguita in modo asincrono nell'ambito della transizione dell'immagine a VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.

Se l'immagine è stata creata con VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID, il driver deve consentire la chiamata ripetuta di vkQueueSignalReleaseImageANDROID() senza chiamate di intervento a vkAcquireImageANDROID().

Supporto delle immagini presentabili condivise

Alcuni dispositivi possono condividere la proprietà di una singola immagine tra la pipeline di visualizzazione e l'implementazione di Vulkan per ridurre al minimo la latenza. In Android 9 e versioni successive, il caricatore pubblicizza in modo condizionale l'estensione VK_KHR_shared_presentable_image in base alla risposta del conducente a una chiamata a vkGetPhysicalDeviceProperties2.

Se il driver non supporta Vulkan 1.1 o l'estensione VK_KHR_physical_device_properties2, il caricatore non pubblicizza il supporto delle immagini presentabili condivise. In caso contrario, il caricatore esegue query sulle funzionalità del driver chiamando vkGetPhysicalDeviceProperties2() e includendo la seguente struttura nella catena VkPhysicalDeviceProperties2::pNext:

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

Se il conducente può condividere la proprietà di un'immagine con il sistema di visualizzazione, imposta il membro sharedImage su VK_TRUE.

Convalida

Gli OEM possono testare la propria implementazione di Vulkan utilizzando CTS, che include quanto segue:

  • Test di conformità Khronos Vulkan nel modulo CtsDeqpTestCases, che includono test API funzionali per Vulkan 1.0, 1.1, 1.2 e 1.3.
  • Il modulo CtsGraphicsTestCases, che verifica che il dispositivo sia configurato correttamente per le funzionalità Vulkan che supporta.

Flag funzionalità Vulkan

Per esporre un flag di funzionalità, è necessario un dispositivo che supporti Android 11 o versioni successive e l'API Vulkan, android.software.vulkan.deqp.level. Il valore di questo flag di funzionalità è una data, codificata come valore intero. Specifica la data associata ai test Vulkan dEQP che il dispositivo dichiara di superare.

Una data nel formato AAAA-MM-GG viene codificata come un numero intero a 32 bit nel seguente modo:

  • I bit da 0 a 15 memorizzano l'anno
  • I bit 16-23 memorizzano il mese
  • I bit da 24 a 31 memorizzano il giorno

Il valore minimo consentito per il flag della funzionalità è 0x07E30301, che corrisponde alla data 01/03/2019, ovvero la data associata ai test dEQP Vulkan per Android 10. Se il flag della funzionalità è almeno questo valore, il dispositivo dichiara di superare tutti i test dEQP Vulkan di Android 10.

Il valore 0x07E40301 corrisponde alla data 1° marzo 2020, ovvero la data associata ai test Vulkan dEQP per Android 11. Se il flag della funzionalità è almeno questo valore, il dispositivo dichiara di superare tutti i test dEQP Vulkan di Android 11.

Il valore 0x07E60301 corrisponde alla data 01/03/2022, ovvero la data associata ai test Vulkan dEQP per Android 13. Se il flag della funzionalità è almeno questo valore, il dispositivo dichiara di superare tutti i test dEQP di Vulkan per Android 13.

Un dispositivo che espone un flag di funzionalità specifico (ad es. 0x07E30301, 0x07E40301, 0x07E60301) dichiara di superare tutti i test dEQP Android Vulkan di quel flag di funzionalità (Android 10, Android 11, Android 13 rispettivamente). Questo dispositivo potrebbe superare i test Vulkan dEQP di una versione successiva di Android.

Vulkan dEQP fa parte del CTS di Android. A partire da Android 11, il componente di esecuzione dei test dEQP di CTS riconosce il flag di funzionalità android.software.vulkan.deqp.level e ignora tutti i test dEQP Vulkan che, in base a questo flag di funzionalità, il dispositivo non dichiara di supportare. Questi test vengono segnalati come superati in modo banale.