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:
- 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.
- 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)
.
true
per Vulkan 1.3 e Vulkan 1.1 aggiungendo una regola, mostrata come segue, a un filedevice.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
- Per Vulkan 1.3 la funzionalità è
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.