Implementare Vulkan

Vulkan è un'API multipiattaforma a basso costo per attività grafiche 3D ad alte prestazioni. Come OpenGL ES (GLES), Vulkan offre strumenti per creare grafiche in tempo reale di alta qualità nelle app. I vantaggi dell'utilizzo di Vulkan includono la riduzione dell'overhead della CPU e il supporto per il 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 gli IHV GPU, che implementa l'API Vulkan. Per supportare la funzionalità Vulkan, il dispositivo Android deve avere hardware GPU compatibile con Vulkan e il driver associato. 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).

Caricatore 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 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 l'enumerazione e il caricamento dei livelli che possono esporre estensioni aggiuntive e intercettare le chiamate API principali lungo il percorso verso il driver.

NDK include una libreria stub libvulkan.so per il collegamento. 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

Una volta 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

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ò estendersi alle funzioni di esportazione 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 dei livelli che possono esporre estensioni aggiuntive e intercettare le chiamate API principali lungo il percorso verso il driver. Android non include i livelli nell'immagine di sistema, ma gli APK delle app potrebbero includere livelli.

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 su 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à: espongono le 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 il trasferimento dei livelli con modifiche all'ambiente di build 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 questa funzionalità è inclusa nell'intento di aumentare il controllo e la granularità dell'interfaccia di programmazione Vulkan. Le istanze di passaggio di rendering a passaggio singolo non hanno più bisogno di oggetti framebuffer 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 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à 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 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. Ciò include un modello di memoria unificato e informazioni aggiuntive che è possibile interrogare 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, 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 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 che vengono avviati 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 con un numero di versione Vulkan inferiore.
  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

Profilo di baseline Android (ABP)

Invitiamo tutti i dispositivi Android a essere conformi all'ultimo profilo Android Baseline 2022 come indicato 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.
  • Ombreggiamento del campione e interpolazione multicampione 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, implementata 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 Vulkan potrebbero richiedere l'allocazione di buffer swapchain con flag di utilizzo privati di Gralloc 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 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 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 dell'immagine swapchain per quest'ultima. La struttura dell'estensione contiene i flag di utilizzo dell'immagine 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 supportaVK_KHR_swapchain v70, quindi l'app Vulkan è in grado di creare unVK_KHR_swapchain supportato dalla memoria della catena di scambio.VkImage L'app chiama innanzitutto vkCreateImage con una struttura VkImageSwapchainCreateInfoKHR collegata 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 del buffer Gralloc corrispondenti alla catena VkBindImageMemoryInfo, in modo che il conducente 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 perimetro nativo negli oggetti VkSemaphore e VkFence forniti dall'app (tuttavia, sia gli oggetti semaforo che quelli di perimetro 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 lo segnala. Se la recinzione nativa l'ha già segnalata, il semaforo si trova nello stato segnalato quando la funzione ritorna. Il driver acquisisce la proprietà del descrittore file 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 un 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. Il chiamante possiede e chiude il descrittore del 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 come parte 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 delle 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 flag di funzionalità è una data, codificata come un 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 salvano la giornata

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 runner del test dEQP di CTS è a conoscenza del flag funzionalità android.software.vulkan.deqp.level e salta qualsiasi 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.