Implementa Vulcano

Vulkan è un'API multipiattaforma a basso costo per grafica 3D ad alte prestazioni. Come OpenGL ES (GLES) , Vulkan fornisce strumenti per la creazione di 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 per il linguaggio SPIR-V Binary Intermediate .

Per implementare Vulkan con successo, 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 necessita di hardware GPU compatibile con Vulkan e del driver associato. La GPU deve supportare anche GLES 3.1 e versioni successive. Consulta il fornitore del SoC per richiedere il supporto del driver.

Se un dispositivo include un driver Vulkan, il dispositivo deve dichiarare le funzionalità di sistema FEATURE_VULKAN_HARDWARE_LEVEL e FEATURE_VULKAN_HARDWARE_VERSION , con versioni che riflettono accuratamente le capacità del dispositivo. Ciò aiuta a garantire che il dispositivo sia conforme al Compatibility Definition Document (CDD).

Caricatore Vulcaniano

La platform/frameworks/native/vulkan del caricatore 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 dal CDD Android e molte estensioni opzionali aggiuntive. Le estensioni Window System Integration (WSI) vengono esportate dal caricatore e implementate principalmente nel caricatore anziché nel driver. Il caricatore supporta inoltre l'enumerazione e il caricamento di livelli che possono esporre estensioni aggiuntive e intercettare le chiamate API principali nel loro percorso verso il driver.

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

Enumerazione e caricamento dei driver

Quando viene creata l'immagine del sistema, Android si aspetta che il sistema sappia quali GPU sono disponibili. Il caricatore utilizza il meccanismo HAL esistente in hardware.h per individuare 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 Vulkan hw_module_t racchiude una singola struttura hw_module_t ; è supportato solo un driver e la stringa costante HWVULKAN_DEVICE_0 viene passata a open() .

Il derivato Vulkan hw_device_t corrisponde a un singolo driver in grado di supportare più dispositivi fisici. La struttura hw_device_t può estendersi 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 .

Individuazione 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 principali nel loro percorso verso il driver. Android non include livelli nell'immagine del sistema; tuttavia, le app potrebbero includere livelli nel proprio APK.

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

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 spessori per gli strumenti di tracciamento/profilazione/debug dovrebbero essere aggiornabili senza un'immagine di sistema. Gli sviluppatori che desiderano 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 presuppone che gli ingegneri IHV e OEM che desiderano diagnosticare errori nella spedizione di app non modificabili abbiano accesso a build non di produzione (rooted) dell'immagine di sistema, a meno che tali app non siano debuggabili. Per ulteriori informazioni vedere Livelli di convalida Vulkan su Android .
  • Livelli di utilità : questi livelli espongono estensioni, come un livello che implementa un gestore di memoria per la memoria del dispositivo. Gli sviluppatori scelgono i livelli e le versioni di tali livelli da utilizzare nella loro app; app diverse che utilizzano lo stesso livello potrebbero comunque utilizzare versioni diverse. Gli sviluppatori scelgono quale di questi livelli includere nel pacchetto dell'app.
  • Livelli inseriti (impliciti) : includono livelli come frequenza fotogrammi, social network e sovrapposizioni di avvio del gioco forniti dall'utente o da qualche altra app senza la conoscenza o il consenso dell'app. Questi violano le politiche di sicurezza di Android e non sono supportati.

Per le app non debuggabili, 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 modello particolare (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 modello particolare.

Android consente il porting dei livelli con le modifiche all'ambiente di compilazione tra Android e altre piattaforme. Per dettagli sull'interfaccia tra i livelli e il caricatore, vedere 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 versioni Android.
Versione Android Versione Vulcaniana
Androide 13 Vulcano 1.3
Androide 9 Vulcano 1.1
Androide7 Vulcano 1.0

Panoramica delle funzionalità di Vulkan 1.3

Vulkan 1.3 canonizza una serie di estensioni precedentemente opzionali nelle funzionalità principali di Vulkan. Gran parte di queste funzionalità sono incluse con l'intento di aumentare il controllo e la granularità sull'interfaccia di programmazione Vulkan. Le istanze di passaggio di rendering a passaggio singolo non necessitano più di oggetti di passaggio di rendering o framebuffer. Il numero totale di oggetti dello 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 del SoC, non nel framework.

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

  • Supporto per istanze di passaggio di rendering a passaggio singolo
  • Supporto per terminare immediatamente un'invocazione di shader
  • Granularità più precisa sulla creazione, condivisione e controllo della pipeline

Vulkan 1.3 include anche diverse funzionalità minori e miglioramenti dell'usabilità dell'API. Tutte le modifiche apportate all'API Vulkan principale con revisione minore 1.3 possono essere trovate 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 la superficie dell'API. Ciò include un modello di memoria unificato e informazioni aggiuntive che possono essere richieste 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 del SoC, non nel framework.

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

Vulkan 1.2 include anche diverse funzionalità minori e miglioramenti dell'usabilità dell'API. Tutte le modifiche apportate all'API Vulkan principale con revisione minore 1.2 possono essere trovate in Core Revisions (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 è 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 dall'esterno 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 principale con revisione minore 1.1 possono essere trovate in Revisioni principali (Vulkan 1.1) .

Scegli 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 poca memoria.

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

I dispositivi avviati tramite Android 10 dovrebbero supportare Vulkan 1.1.

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

Supporta una versione Vulkan

Un dispositivo Android supporta una versione 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, assicurarsi 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 pacchetti restituirà true per Vulkan 1.3 e Vulkan 1.1 aggiungendo una regola, mostrata come segue, 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)

Incoraggiamo tutti i dispositivi Android a conformarsi all'ultimo profilo Android Baseline 2022 come indicato 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 è elencato nel file json del profilo Vulkan, ma un sottoinsieme chiave delle funzionalità richieste include:

  • Texture compresse tramite ASTC ed ETC.
  • Spazi colore variabili tramite VK_EXT_swapchain_colorspace .
  • Ombreggiatura del campione e interpolazione multicampione tramite sampleRateShading .

Integrazione del sistema finestra (WSI)

In libvulkan.so , il driver implementa le seguenti estensioni WSI (Window System Integration):

  • VK_KHR_surface
  • VK_KHR_android_surface
  • VK_KHR_swapchain
  • VK_KHR_driver_properties , implementato per Vulkan 1.1 solo in Android 10
  • 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 driver. 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 di swapchain con flag di utilizzo Gralloc privati ​​definiti dall'implementazione. Quando si crea una swapchain, Android chiede al driver di tradurre il formato richiesto e i flag di utilizzo dell'immagine 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
);

Il format e i parametri imageUsage vengono presi dalla struttura VkSwapchainCreateInfoKHR . Il driver dovrebbe 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 dal consumatore di swapchain durante l'allocazione dei buffer.

Android 7.x chiama una versione precedente di VkSwapchainImageUsageFlagsANDROID() , denominata vkGetSwapchainGrallocUsageANDROID() . Android 8.0 e versioni successive deprecano 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 di swapchain o i flag di utilizzo estesi di Gralloc.

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 della struttura VkImageCreateInfo . Le chiamate a vkCreateImage() con VkNativeBufferANDROID avvengono durante la chiamata a vkCreateSwapchainKHR . L'implementazione WSI alloca il numero di buffer nativi richiesti per la swapchain, quindi crea una VkImage per ciascuno di essi:

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 si crea 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 richiesti flag di utilizzo dell'immagine swapchain per la swapchain. 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 supporta VK_KHR_swapchain v70, quindi l'app Vulkan è in grado di creare una VkImage supportata dalla memoria swapchain. L'app chiama innanzitutto vkCreateImage con una struttura VkImageSwapchainCreateInfoKHR concatenata alla struttura VkImageCreateInfo . Quindi l'app chiama vkBindImageMemory2(KHR) con una struttura VkBindImageMemorySwapchainInfoKHR concatenata alla struttura VkBindImageMemoryInfo . L' imageIndex specificato nella struttura VkBindImageMemorySwapchainInfoKHR deve essere un indice immagine swapchain valido. Nel frattempo, la piattaforma fornisce una struttura di estensione VkNativeBufferANDROID con le corrispondenti informazioni sul buffer Gralloc 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 un recinto nativo segnalato esternamente sia in un oggetto VkSemaphore esistente che 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 recinto nativo negli oggetti VkSemaphore e VkFence forniti dall'app (tuttavia, sia gli oggetti semaforo che quelli recinto sono facoltativi in ​​questa chiamata). Il driver può anche sfruttare questa opportunità per riconoscere e gestire eventuali modifiche esterne allo stato del buffer Gralloc; molti conducenti non dovranno fare nulla qui. Questa chiamata inserisce VkSemaphore e VkFence nello stesso stato in sospeso come se segnalato da vkQueueSubmit , quindi le code possono attendere sul semaforo e l'app può attendere sul recinto.

Entrambi gli oggetti vengono segnalati quando segnala il recinto nativo sottostante; se la recinzione nativa ha già segnalato, allora il semaforo è nello stato segnalato quando questa funzione ritorna. Il driver assume la proprietà del descrittore del file di fencing e lo chiude quando non è più necessario. Il driver deve farlo anche se non viene fornito né un semaforo né un oggetto fencing o anche se vkAcquireImageANDROID fallisce e restituisce un errore. fenceFd è -1 è come se il recinto nativo fosse già segnalato.

Rilascia immagini

vkQueueSignalReleaseImageANDROID prepara un'immagine swapchain per uso esterno, crea un recinto nativo e pianifica la segnalazione del recinto nativo dopo che i semafori di input hanno segnalato:

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

vkQueuePresentKHR() chiama vkQueueSignalReleaseImageANDROID() sulla coda fornita. Il driver deve produrre una recinzione nativa che non segnala finché tutti i semafori waitSemaphoreCount nel segnale pWaitSemaphores non vengono completati e qualsiasi lavoro aggiuntivo richiesto per preparare image per la presentazione.

Se i semafori di attesa (se presenti) hanno già segnalato e queue è già inattiva, il driver può impostare *pNativeFenceFd su -1 invece di un effettivo descrittore di file di fencing nativo, 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 image, ma alcuni potrebbero dover preparare strutture dati lato CPU associate a un buffer Gralloc per l'utilizzo da parte di consumatori di immagini esterni. La preparazione del contenuto 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 la chiamata ripetuta di vkQueueSignalReleaseImageANDROID() senza che intervengano chiamate a vkAcquireImageANDROID() .

Supporto per immagini presentabili condivise

Alcuni dispositivi possono condividere la proprietà di una singola immagine tra la pipeline di visualizzazione e l'implementazione 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 per le immagini presentabili condivise. Altrimenti, il caricatore interroga le 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 .

Validazione

Gli OEM possono testare la propria implementazione 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 di funzionalità Vulcaniano

Un dispositivo che supporta Android 11 o versioni successive e che supporti 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 valore intero. Specifica la data associata ai test Vulkan dEQP che il dispositivo dichiara di superare.

Una data nel formato AAAA-MM-GG è codificata come numero intero a 32 bit come segue:

  • 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 di funzionalità è 0x07E30301 , che corrisponde alla data 2019-03-01, che è la data associata ai test Vulkan dEQP per Android 10. Se il flag di funzionalità è almeno questo valore, il dispositivo dichiara di superare tutti i test dEQP di Android 10 Vulkan.

Il valore 0x07E40301 corrisponde alla data 2020-03-01, che è la data associata ai test Vulkan dEQP per Android 11. Se il flag di funzionalità è almeno questo valore, il dispositivo dichiara di superare tutti i test Vulkan dEQP di Android 11.

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

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

Vulkan dEQP fa parte di Android CTS. A partire da Android 11, il componente runner test dEQP di CTS è a conoscenza del flag di funzionalità android.software.vulkan.deqp.level e salta qualsiasi test dEQP Vulkan che, secondo questo flag di funzionalità, il dispositivo non dichiara di supportare. Tali test vengono segnalati come banalmente superati.