Implementare Vulkan

Vulkan è un'API multipiattaforma con un basso overhead per la 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 dell'overhead della CPU e il supporto del linguaggio SPIR-V Binary Intermediate.

Nota: questa sezione descrive l'implementazione di Vulkan. Per informazioni dettagliate sull'architettura, sui vantaggi, sull'API e su altre risorse di Vulkan, consulta Architettura di Vulkan.

Per implementare Vulkan correttamente, un dispositivo deve includere:

• Il caricatore Vulkan, fornito da Android.
• Un driver Vulkan, fornito da SoC come gli IHV GPU, che implementa l'API Vulkan. Per supportare la funzionalità Vulkan, il dispositivo Android necessita di hardware GPU compatibile con Vulkan e del relativo driver. La GPU deve supportare anche GLES 3.1 e versioni successive. Rivolgiti al fornitore del SoC per richiedere 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 riflettano con precisione le funzionalità del dispositivo. In questo modo, il dispositivo è conforme al Compatibility Definition Document (CDD).

Vulkan Loader

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 dell'API Vulkan di base, i punti di ingresso delle estensioni richiesti dal CDD di Android e molte altre estensioni facoltative. Le estensioni di Window System Integration (WSI) vengono esportate dal caricatore e implementate principalmente nel caricatore anziché nel driver. Il caricatore supporta anche la enumerazione e il caricamento di livelli che possono esporre estensioni aggiuntive e intercettare le chiamate API di base durante il percorso verso il driver.

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

Enumerazione e caricamento del 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 e 64 bit sono:

/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

Nota: <ro.hardware.vulkan> e <ro.product.platform> vengono sostituiti dal valore della proprietà sistema di quel nome. Per maggiori dettagli e le località alternative supportate, consulta libhardware/hardware.c.

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

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

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 dell'API di base durante il percorso verso il driver. Android non include livelli nell'immagine di sistema, ma le app possono includere livelli nel proprio APK.

Quando utilizzi i livelli, tieni presente che il modello e le norme di sicurezza di Android differiscono notevolmente da altre piattaforme. In particolare, Android non consente di caricare codice esterno in un processo non eseguibile il debug sui 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 del core, tracce API e così via sul disco per un'ispezione successiva. Solo i livelli forniti nell'ambito di app non debbugabili sono abilitati sui dispositivi di produzione e i driver non devono fornire funzionalità che violano queste norme.

I casi d'uso per i livelli includono:

• Livelli di compilazione: i livelli di convalida e gli shim per gli strumenti di tracciamento/profiling/debug non devono essere installati sull'immagine di sistema dei dispositivi di produzione. I livelli di convalida e gli shim per gli strumenti di monitoraggio/profiling/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 i problemi di spedizione di app non modificabili abbiano accesso alle build non di produzione (rooted) dell'immagine di sistema, a meno che queste app non siano di tipo debuggable. Per ulteriori 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 loro app. App diverse che utilizzano lo stesso livello possono comunque utilizzare versioni diverse. Gli sviluppatori scelgono quale di questi livelli includere nel pacchetto dell'app.
• Livelli iniettati (impliciti): includono livelli come frequenza fotogrammi, overlay di social network e launcher di giochi forniti dall'utente o da un'altra app senza che l'app ne sia a conoscenza o abbia dato il consenso. Queste violano le norme di sicurezza di Android e non sono supportate.

Per le app non di debug, il caricatore cerca i livelli solo nella directory della libreria nativa dell'app e tenta di caricare qualsiasi libreria con un nome corrispondente 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 corrispondente a un determinato pattern.

Android consente di eseguire il porting dei 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 nella funzionalità di base di Vulkan. Gran parte di queste funzionalità è inclusa con l'intento di aumentare il controllo e la granularità sull'interfaccia di programmazione Vulkan. Le istanze di pass di rendering a passaggio singolo non richiedono più oggetti di pass di rendering o framebuffer. Il numero totale di oggetti dello stato della pipeline può essere ridotto e la sincronizzazione all'interno dell'API viene sottoposta a revisione. 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 SoC, non nel framework.

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

• Supporto per le istanze di pass di rendering in un solo passaggio
• Supporto per l'interruzione immediata di un'invocazione dello shader
• Granularità più fine per la creazione, la condivisione e il controllo delle pipeline

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

Panoramica delle funzionalità di Vulkan 1.2

Vulkan 1.2 aggiunge una serie di funzionalità ed estensioni che semplificano l'interfaccia API. Sono inclusi un modello di memoria unificato e informazioni aggiuntive su cui è possibile eseguire query da un driver di dispositivo. Vulkan 1.2 ha gli stessi requisiti hardware di Vulkan 1.0 e 1.1; tutta l'implementazione è nel driver grafico specifico per SoC, non nel framework.

La funzionalità più importante di Vulkan 1.2 per Android è il supporto della memorizzazione a 8 bit.

Vulkan 1.2 include anche diverse funzionalità minori e miglioramenti dell'usabilità dell'API. Tutte le modifiche apportate all'API Vulkan di base con la revisione minore 1.2 sono disponibili in Revisioni principali (Vulkan 1.2).

Panoramica delle funzionalità di Vulkan 1.1

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

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

• Supporto per l'importazione e l'esportazione di buffer della memoria e oggetti di sincronizzazione al di fuori di Vulkan (per l'interoperabilità con fotocamera, codec e GLES)
• Supporto per i formati YCbCr

Vulkan 1.1 include anche diverse funzionalità minori e miglioramenti dell'usabilità dell'API. Tutte le modifiche apportate all'API Vulkan di base con la revisione minore 1.1 sono disponibili in Revisioni principali (Vulkan 1.1).

Scegliere il supporto Vulkan

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

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

I dispositivi lanciati tramite Android 10 dovrebbero supportare Vulkan 1.1.

Altri dispositivi possono eventualmente supportare 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 Android. In alternativa, aggiorna un driver Vulkan esistente di una versione Vulkan precedente.
   Nota: per Android 14 e versioni successive, tutti i dispositivi compatibili con Vulkan devono avere i driver Vulkan 1.1. Per ulteriori informazioni, consulta i requisiti CDD di Android 14.
2. Per Vulkan 1.3 o 1.1, assicurati che la funzionalità di sistema restituita dal gestore pacchetti restituisca true per la versione Vulkan corretta.
   • 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 del pacchetto restituirà true per Vulkan 1.3 e Vulkan 1.1 aggiungendo una regola, riportata 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

Nota: alcune app potrebbero dipendere da una versione di Vulkan più avanzata rispetto a quella disponibile su un dispositivo. In questo caso, queste app non verranno eseguite sul dispositivo. Ad esempio, le app che richiedono Vulkan 1.1 non verranno eseguite su dispositivi che supportano solo Vulkan 1.0. Alcune app potrebbero non richiedere una versione Vulkan più recente, ma potrebbero fornire funzionalità aggiuntive o un rendimento migliore quando la versione più recente è presente sul dispositivo.

Profilo di baseline Android (ABP)

Invitiamo tutti i dispositivi Android a essere conformi all'ultimo profilo Android Baseline 2022 come delineato nella guida al profilo Android Baseline.

Qualsiasi dispositivo che supporta 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 è elencato nel file del profilo Vulkan json, ma un sottoinsieme chiave delle funzionalità richieste include:

• Texture compresse tramite ASTC ed ETC.
• Spazi di colore variabili tramite VK_EXT_swapchain_colorspace.
• Ombreggiatura di esempio 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 solo su Android 10
• VK_GOOGLE_display_timing, implementato per qualsiasi versione Vulkan in Android 10

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

Flag di utilizzo di Gralloc

Le implementazioni di Vulkan potrebbero richiedere l'allocazione di buffer di swapchain con flag di utilizzo Gralloc privati definiti dall'implementazione. Quando viene creata una swapchain, Android chiede al driver di tradurre i flag di utilizzo del formato e delle immagini richiesti 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 ripresi dalla struttura VkSwapchainCreateInfoKHR. Il driver deve compilare *grallocConsumerUsage e *grallocProducerUsage con gli indicatori di utilizzo Gralloc richiesti per il formato e l'utilizzo. I flag di utilizzo restituiti dal driver vengono combinati con i flag di utilizzo richiesti dall'utente della swapchain durante l'allocazione dei buffer.

Android 7.x chiama una versione precedente di VkSwapchainImageUsageFlagsANDROID(), chiamata vkGetSwapchainGrallocUsageANDROID(). Android 8.0 e versioni successive ritirano vkGetSwapchainGrallocUsageANDROID(), ma richiamano ancora 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 Gralloc estesi.

Immagini supportate da Gralloc

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

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 viene creata un'immagine basata su 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 richiesti flag di utilizzo delle immagini della catena di scambio. La struttura dell'estensione contiene i flag di utilizzo delle immagini della catena di scambio:

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 supportaVK_KHR_swapchain v70, quindi l'app Vulkan è in grado di creare unVkImage supportato dalla memoria della catena di scambio. L'app chiama prima vkCreateImage con una struttura VkImageSwapchainCreateInfoKHR incatenata alla struttura VkImageCreateInfo. L'app chiama quindi vkBindImageMemory2(KHR) con una struttura VkBindImageMemorySwapchainInfoKHR a catena alla struttura VkBindImageMemoryInfo. Il imageIndex specificato nella struttura VkBindImageMemorySwapchainInfoKHR deve essere un indice di immagine della catena di scambio valido. Nel frattempo, la piattaforma fornisce una struttura di estensione VkNativeBufferANDROID con le informazioni corrispondenti del buffer Gralloc alla catena VkBindImageMemoryInfo, in modo che il driver sappia a quale buffer Gralloc associare VkImage.

Acquisisci le immagini

vkAcquireImageANDROID acquisisce la proprietà di un'immagine della swapchain e importa una recinzione nativa segnalata esternamente sia in un oggetto VkSemaphore esistente sia 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 un sistema di recinzione nativo negli oggetti VkSemaphore e VkFence forniti dall'app (tuttavia, sia gli oggetti semaforo che quelli di recinzione sono facoltative 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 in questo caso. Questa chiamata inserisce VkSemaphore e VkFence nello stesso stato di attesa come se fosse segnalato da vkQueueSubmit, in modo che le code possano attendere il semaforo e l'app possa attendere la recinzione.

Entrambi gli oggetti vengono segnalati quando la recinzione nativa sottostante emette un segnale. Se la recinzione nativa ha già emesso un segnale, il semaphore è nello stato segnalato quando questa funzione restituisce. Il driver acquisisce la proprietà del descrittore di file del recinto e lo chiude quando non è più necessario. Il driver deve farlo anche se non viene fornito un oggetto semaforo o recinto o anche se vkAcquireImageANDROID non riesce e restituisce un errore. Se fenceFd è -1, è come se il recinto nativo fosse già stato segnalato.

Immagini di rilascio

vkQueueSignalReleaseImageANDROID prepara un'immagine della swapchain per l'uso esterno, crea una recinzione nativa e pianifica l'invio di un segnale alla recinzione nativa dopo che i semafori di input hanno inviato un segnale:

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

vkQueuePresentKHR() chiama vkQueueSignalReleaseImageANDROID() nella coda fornita. Il driver deve produrre una recinzione nativa che non emette alcun segnale fino a quando non vengono segnalati tutti i semafori waitSemaphoreCount in pWaitSemaphores e viene completato qualsiasi lavoro aggiuntivo necessario per preparare image per la presentazione.

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

Molti driver possono ignorare il parametro 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 di chiamare vkQueueSignalReleaseImageANDROID() ripetutamente senza chiamate intermedie 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 condizionatamente l'estensione VK_KHR_shared_presentable_image in base alla risposta del driver a una chiamata a vkGetPhysicalDeviceProperties2.

Se il driver non supporta Vulkan 1.1 o l'estensioneVK_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 driver 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 supportate.

Flag funzionalità Vulkan

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

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

• I bit 0-15 memorizzano l'anno
• I bit 16-23 memorizzano il mese
• I bit 24-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 Vulkan dEQP per Android 10. Se il flag della funzionalità è almeno pari a questo valore, il dispositivo dichiara di superare tutti i test Vulkan dEQP di Android 10.

Il valore 0x07E40301 corrisponde alla data 01-03-2020, ovvero la data associata ai test Vulkan dEQP per Android 11. Se il flag della funzionalità è almeno pari a questo valore, il dispositivo dichiara di superare tutti i test Vulkan dEQP 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 pari a questo valore, il dispositivo dichiara di superare tutti i test Vulkan dEQP di Android 13.

Un dispositivo che espone un flag di funzionalità specifico (ad es. 0x07E30301, 0x07E40301, 0x07E60301) afferma di superare tutti i test dEQP di Vulkan per Android di quel flag di funzionalità (rispettivamente Android 10, Android 11, Android 13). 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 del programma di test dEQP del CTS è a conoscenza del flag di funzionalità android.software.vulkan.deqp.level e salta tutti i test Vulkan dEQP che, in base a questo flag di funzionalità, il dispositivo non dichiara di supportare. Questi test vengono segnalati come superati in modo banale.