Implementare Vulkan

Vulkan ha un overhead basso, API multipiattaforma per un 3D ad alte prestazioni le immagini. Ad esempio, OpenGL ES (GLES), Vulkan offre strumenti per creare contenuti di alta qualità, di grafica in tempo reale nelle app. I vantaggi dell'utilizzo di Vulkan includono la riduzione della CPU overhead e il supporto per la lingua SPIR-V Binary Intermediate.

Per implementare correttamente Vulkan, un dispositivo deve includere:

  • Il caricatore Vulkan, fornito da Android.
  • Un driver Vulkan, fornito da SoC come IHV GPU, che implementa API Vulkan. Per supportare la funzionalità Vulkan, Android Il dispositivo richiede hardware GPU compatibile con Vulkan e il driver associato. La GPU devono supportare anche GLES 3.1 e versioni successive. Rivolgiti al fornitore di SoC per richiedere assistenza alla guida.

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

Caricatore Vulkan

Il caricatore Vulkan platform/frameworks/native/vulkan è a riga di comando principale tra le app Vulkan e il driver Vulkan di un dispositivo. Vulkan Il caricatore è 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 altre estensioni facoltative. Finestra Le estensioni di integrazione del sistema (WSI) vengono esportate dal caricatore e principalmente implementato nel caricatore anziché nel driver. Il caricatore supporta anche enumerando e caricando strati che possono esporre estensioni e intercettazioni aggiuntive principali chiamate API fino al conducente.

NDK include una libreria stub libvulkan.so per collegamento. La libreria esporta gli stessi simboli del caricatore. Le app chiamano le funzioni esportata dalla libreria libvulkan.so reale in inserire le funzioni del trampolino nel caricatore, che le inviano al o driver in base al primo argomento. vkGet*ProcAddr() restituisce i puntatori di funzione a cui vengono inviati i trampolini (ovvero chiama direttamente al codice API principale). Chiamata tramite la funzione piuttosto che i simboli esportati, è più efficiente in quanto salta il trampolino e fa schifo.

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 hardware.h per scoprire 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, la derivata di Vulkan hw_module_t aggrega un singolo struct hw_module_t; è supportato un solo driver e la stringa costante HWVULKAN_DEVICE_0 è stato passato a open().

La derivata di Vulkan hw_device_t corrisponde a una singola in grado di supportare più dispositivi fisici. La La struttura hw_device_t può estendersi all'esportazione vkGetGlobalExtensionProperties(), vkCreateInstance() e Funzioni di vkGetInstanceProcAddr(). Il caricatore può trovare tutti gli altri VkInstance(), VkPhysicalDevice() e vkGetDeviceProcAddr() funzioni chiamando il valore vkGetInstanceProcAddr() della struttura hw_device_t.

Rilevamento e caricamento dei livelli

Il caricatore Vulkan supporta l'enumerazione e il caricamento di strati che possono esporre estensioni aggiuntive e intercettare le chiamate API principali lungo il percorso conducente. Android non include livelli nell'immagine di sistema, ma le app potrebbero includere livelli nell'APK.

Quando utilizzi i livelli, tieni presente che il modello di sicurezza e i criteri di Android sono significativamente diverse da quelle di altre piattaforme. In particolare, Android non consente caricamento di codice esterno in un processo non di debug in produzione (non rooted) dispositivi né consente a codice esterno di ispezionare o controllare i processi memoria, stato e così via. È incluso il divieto di salvare i core dump, le API e così via su disco per ispezionarli in un secondo momento. Solo i livelli pubblicati nell'ambito le app non di debug siano abilitate sui dispositivi di produzione e i driver non devono fornire che violano queste norme.

I casi d'uso per i livelli includono:

  • Livelli del tempo di sviluppo: Convalida non devono essere installati strati e shim per gli strumenti di tracciamento/profilazione/debug l'immagine di sistema dei dispositivi di produzione. Strati di convalida e shim per gli strumenti di tracciamento/profilazione/debugging devono essere aggiornabili senza un sistema dell'immagine. Gli sviluppatori che vogliono utilizzarne uno di questi strati durante lo sviluppo possono modificare il pacchetto dell'app, ad esempio aggiungendo un file alla directory delle librerie native. ingegneri IHV e OEM che vuoi diagnosticare gli errori nella spedizione di app non modificabili, si suppone che abbiano Accesso a build non di produzione (rooted) dell'immagine di sistema, a meno che quelle app di cui è possibile eseguire il debug. Per ulteriori informazioni, consulta la pagina relativa ai livelli di convalida di Vulkan su Android.
  • Livelli di utilità: questi strati espongono , 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 nelle app; app diverse che utilizzano lo stesso livello possono usare diverse versioni. Gli sviluppatori scelgono quale di questi livelli inviare nel proprio pacchetto dell'app.
  • Livelli inseriti (impliciti): include livelli come frequenza fotogrammi, social network e overlay per l'avvio del gioco forniti dall'utente oppure alcune altre app all'insaputa o senza il consenso dell'app stessa. Questi violano le norme di sicurezza di Android e non sono supportate.

Per le app non di cui non è possibile eseguire il debug, il caricatore cerca i livelli solo nelle alla 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 uno schema particolare.

Android consente il trasferimento dei livelli con modifiche all'ambiente di build Android e altre piattaforme. Per i dettagli sull'interfaccia tra i livelli e caricatore, consulta Architettura delle interfacce del caricatore Vulkan. Mantenuto da Khronos e i livelli di convalida sono ospitati Livelli di Vulkan Validation.

Versioni e funzionalità dell'API Vulkan

Nella tabella seguente sono elencate 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à principale di Vulkan. Gran parte di questa funzionalità è inclusa nell'intento di aumentare il controllo e la granularità su l'interfaccia di programmazione Vulkan. Le istanze di passaggio di rendering a passaggio singolo non hanno più bisogno eseguire il rendering di oggetti pass o framebuffer. Il numero totale di oggetti di stato della pipeline può essere ridotto e la sincronizzazione all'interno dell'API è rinnovata. 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 di istanze di passaggio di rendering con passaggio singolo
  • Supporto per l'interruzione immediata della chiamata di uno shaker
  • Livello di granularità più preciso per la creazione, la condivisione e il controllo della pipeline

Vulkan 1.3 include anche diverse funzionalità più piccole e miglioramenti dell'usabilità delle API. Tutte le modifiche apportate all'API Vulkan principale con la revisione secondaria 1.3 è disponibile 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 visualizzazione dell'API. Sono inclusi 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; tutte le 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à più piccole e miglioramenti dell'usabilità delle API. Tutte le modifiche apportate all'API Vulkan principale con la revisione secondaria 1.2 è disponibile all'indirizzo Revisioni principali (Vulkan 1.2).

Panoramica delle funzionalità di Vulkan 1.1

Vulkan 1.1 include il supporto per l'interoperabilità tra memoria e sincronizzazione, che consente agli OEM di supportare Vulkan 1.1 sui dispositivi. Inoltre, l'interoperabilità tra memoria e sincronizzazione consente agli sviluppatori per stabilire se Vulkan 1.1 è supportato su un dispositivo e utilizzarlo in modo efficace quando sono disponibili. Vulkan 1.1 ha gli stessi requisiti hardware di Vulkan 1.0, ma la maggior parte delle l'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 dei buffer di memoria e della sincronizzazione oggetti dall'esterno di 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à delle API. Tutte le modifiche apportate all'API Vulkan principale con revisione secondaria 1.1 sono disponibili all'indirizzo Revisioni principali (Vulkan 1.1).

Scegli l'assistenza Vulkan

I dispositivi Android dovrebbero supportare il set di funzionalità Vulkan più avanzato disponibile, a condizione che supportano un'ABI a 64 bit e non dispongono di memoria insufficiente.

I dispositivi che vengono 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 supportare facoltativamente Vulkan 1.3, 1.2 e 1.1.

Supportare una versione Vulkan

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

  1. Aggiungi un driver Vulkan che supporti la versione Vulkan che ti interessa (deve essere una versione Vulkan 1.3, 1.1 o 1.0) insieme ai requisiti aggiuntivi CDD delle 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, assicurarsi che la funzionalità di sistema restituita dal gestore di pacchetti restituisca true per la versione vulkan corretta.
    • Per Vulkan 1.3 la funzione è PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000).
    • Per Vulkan 1.1 la funzione è PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000).
    di Gemini Advanced. Il gestore di pacchetti restituirà true per Vulkan 1.3 e Vulkan 1.1 aggiungendo una regola, mostrato 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
di Gemini Advanced.

Profilo Android Baseline (ABP)

Invitiamo tutti i dispositivi Android a essere conformi all'ultimo profilo Android Baseline 2022 come descritto nel Guida al profilo Android Baseline.

I dispositivi che supportano Android 14 o versioni successive e l'API Vulkan devono che soddisfano tutte le funzionalità definite Profilo Android Baseline 2021. L'elenco completo delle funzionalità richieste è enumerato nel file json del profilo Vulkan, ma un sottoinsieme chiave del valore include:

  • Texture compresse tramite ASTC ed ETC.
  • Spazi di colore variabili fino a VK_EXT_swapchain_colorspace.
  • Ombreggiamento campione e interpolazione multicampione tramite sampleRateShading.

Integrazione di sistemi di finestre (WSI)

In libvulkan.so, il driver implementa quanto segue Estensioni WSI (window System Integration):

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

Gli oggetti VkSurfaceKHR e VkSwapchainKHR e tutti le interazioni con ANativeWindow sono gestite dalla piattaforma e non vengono esposto ai conducenti. L'implementazione di WSI si basa VK_ANDROID_native_buffer, che deve essere supportate dal conducente; questa estensione viene utilizzata solo dall'implementazione di WSI e non è esposto alle app.

Flag di utilizzo di Gralloc

Le implementazioni Vulkan potrebbero richiedere l'allocazione dei buffer swapchain flag privati di utilizzo di Gralloc, definiti dall'implementazione. Quando crei una swapchain, Android chiede al conducente di tradurre il formato richiesto e l'utilizzo dell'immagine per i 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 provengono da la struttura VkSwapchainCreateInfoKHR. Il conducente deve compilare *grallocConsumerUsage e *grallocProducerUsage con i flag di utilizzo Gralloc richiesti per il formato e sull'utilizzo. I flag di utilizzo restituiti dal conducente sono combinati con l'utilizzo flag richiesti dal consumatore di swapchain durante l'allocazione dei buffer.

Android 7.x chiama una versione precedente di VkSwapchainImageUsageFlagsANDROID(), denominato vkGetSwapchainGrallocUsageANDROID(). Android 8.0 e versioni successive verrà ritirato vkGetSwapchainGrallocUsageANDROID() ma continua a chiamare vkGetSwapchainGrallocUsageANDROID() se vkGetSwapchainGrallocUsage2ANDROID() non è fornito dal conducente:

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

vkGetSwapchainGrallocUsageANDROID() non supporta l'utilizzo di swapchain o flag di utilizzo esteso di Gralloc.

Immagini supportate da Gralloc

VkNativeBufferANDROID è un'estensione vkCreateImage struttura per creare un'immagine supportata da un buffer Gralloc. VkNativeBufferANDROID è fornita a vkCreateImage() in VkImageCreateInfo di una struttura a catena. Chiamate a vkCreateImage() con VkNativeBufferANDROID effettuate durante la chiamata a vkCreateSwapchainKHR. L'implementazione di WSI assegna 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;

Durante la creazione di 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 offre Struttura dell'estensione VkSwapchainImageCreateInfoKHR nel 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 supporta VK_KHR_swapchain v70, pertanto l'app Vulkan è in grado di creare una VkImage con supporto della memoria swapchain. L'app chiama per la prima volta vkCreateImage con VkImageSwapchainCreateInfoKHR strutturata concatenata alla struttura VkImageCreateInfo. Quindi, l'app chiama vkBindImageMemory2(KHR) con un Struttura VkBindImageMemorySwapchainInfoKHR concatenata al struttura VkBindImageMemoryInfo. imageIndex specificate nella struttura VkBindImageMemorySwapchainInfoKHR devono che sia un indice di immagini swapchain valido. Al contempo, la piattaforma offre Struttura dell'estensione VkNativeBufferANDROID con la corrispondente le informazioni del buffer Gralloc nella catena VkBindImageMemoryInfo, quindi il conducente sa a quale buffer Gralloc associare VkImage.

Acquisisci immagini

vkAcquireImageANDROID acquisisce la proprietà di un'immagine swapchain e importa una recinzione nativa segnalata esternamente sia in un Oggetto VkSemaphore e 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 nativa negli oggetti VkSemaphore e VkFence forniti dall'app (tuttavia sia gli oggetti semafori che recinzioni sono facoltativa in questa chiamata). Il conducente può anche sfruttare l'opportunità e gestire eventuali modifiche esterne allo stato del buffer di Gralloc; molti conducenti non fare nulla qui. Questa chiamata inserisce VkSemaphore e VkFence nello stesso stato In attesa 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 la recinzione nativa sottostante la segnala. se la recinzione nativa ha già segnalato, il semaforo si trova nella quando viene restituita questa funzione. Il conducente acquisisce la proprietà del file del recinto e chiude il descrittore del file di recinto quando non è più necessario. Il conducente devono farlo anche se non viene fornito né un semaforo né un oggetto recinto, o anche se vkAcquireImageANDROID non riesce e restituisce un errore. Se fenceFd è -1, come se la recinzione nativa fosse già segnalato.

Immagini release

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

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

vkQueuePresentKHR() chiama vkQueueSignalReleaseImageANDROID() presenti nella coda fornita. Il conducente deve produrre una recinzione nativa che non segnali fino a tutti i waitSemaphoreCount semafori in pWaitSemaphores ed eventuali operazioni aggiuntive necessarie per prepara image per il completamento della presentazione.

Se i segnali di attesa (se presenti) sono già segnalati e queue è già inattivo, il driver può impostare *pNativeFenceFd a -1 anziché un descrittore del file di recinto nativo, che indica che non c'è niente da aspettare. Il chiamante possiede il descrittore del file e lo chiude restituito in *pNativeFenceFd.

Molti driver possono ignorare il parametro immagine, ma è possibile che alcuni debbano prepararsi Strutture di dati lato CPU associate a un buffer Gralloc per l'utilizzo da parte di consumatori di immagini. La preparazione dei contenuti del buffer per l'uso da parte dei consumatori esterni dovrebbe da eseguire in modo asincrono nell'ambito della transizione VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.

Se l'immagine è stata creata con VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID, il conducente deve consenti a vkQueueSignalReleaseImageANDROID() di essere chiamato ripetutamente senza intervenire su chiamate a vkAcquireImageANDROID().

Supporto di immagini presentabili condivise

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

Se il driver non supporta Vulkan 1.1 o VK_KHR_physical_device_properties2, il caricatore no pubblicizzare il supporto di immagini presentabili condivise. In caso contrario, il caricatore esegue query le funzionalità del conducente chiamando vkGetPhysicalDeviceProperties2() e includere la seguente struttura nel 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 display nel sistema, imposta il membro sharedImage su VK_TRUE.

Convalida

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

  • Test di conformità di Khronos Vulkan nel modulo CtsDeqpTestCases, che includono test funzionali dell'API 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 supporti Android 11 o versioni successive e l'API Vulkan per esporre un flag di funzionalità, android.software.vulkan.deqp.level. Il valore di questo flag di caratteristica è una data, codificata come valore intero. Specifica la data associata a i test Vulkan dEQP che il dispositivo dichiara di superare.

Una data nel formato AAAA-MM-GG viene 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 salvano la giornata

Il valore minimo consentito per il flag di funzionalità è 0x07E30301, che corrisponde alla data 2019-03-01, che è la data associata al Test Vulkan dEQP per Android 10. Se il flag della caratteristica corrisponde almeno a questo valore, il dispositivo afferma di superare tutti i test Vulkan dEQP di Android 10.

Il valore 0x07E40301 corrisponde alla data 2020-03-01, che è la data associata ai test Vulkan dEQP per Android 11. Se l'elemento è almeno questo valore, il dispositivo dichiara di superare tutte le richieste di assistenza di Android 11 Test dEQP Vulkan.

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

Un dispositivo che espone un flag di funzionalità specifico (ad esempio 0x07E30301, 0x07E40301 e 0x07E60301) afferma di superare tutti i test dEQP Android Vulkan relativi alla funzionalità in questione (Android 10, Android 11 e Android 13). Questo dispositivo potrebbe superare i test Vulkan dEQP di una release successiva di Android.

Vulkan dEQP fa parte di Android CTS. Da Android 11, il test runner dEQP di CTS sia a conoscenza del android.software.vulkan.deqp.level il flag di caratteristica e salta qualsiasi test Vulkan dEQP che, secondo questo flag funzionalità: il dispositivo non dichiara di supportare. Tali test vengono riportate come banali.