Vulkan ist ein geringer Overhead, plattformübergreifende API für leistungsstarkes 3D Grafiken. Wie OpenGL ES (GLES) Vulkan bietet Tools zum Erstellen hochwertiger, Echtzeitgrafiken in Apps. Zu den Vorteilen von Vulkan gehören eine Reduzierung der CPU-Leistung. und Unterstützung für die SPIR-V Binary Intermediate.
Damit Vulkan erfolgreich implementiert werden kann, muss ein Gerät Folgendes enthalten:
- Das von Android bereitgestellte Vulkan-Ladeprogramm.
- Einen Vulkan-Treiber, der von SoCs wie GPU-IHVs bereitgestellt wird und implementiert die Vulkan API Um die Vulkan-Funktionalität zu unterstützen, muss die Android-App Gerät benötigt Vulkan-fähige GPU-Hardware und den zugehörigen Treiber. Die GPU muss außerdem GLES 3.1 und höher unterstützen. Wenden Sie sich an Ihren SoC-Anbieter, Treibersupport anfordern.
Wenn ein Gerät einen Vulkan-Treiber enthält, muss das Gerät dies
FEATURE_VULKAN_HARDWARE_LEVEL
und
FEATURE_VULKAN_HARDWARE_VERSION
-Systemfunktionen mit Versionen, die
die Funktionen des Geräts genau widerspiegeln. So wird sichergestellt,
das Gerät den
Das Compatibility Definition Document (CDD) (Dokument zur Kompatibilitätsdefinition).
Vulkan-Ladeprogramm
Der Vulkan-Loader platform/frameworks/native/vulkan
ist der
primäre Schnittstelle zwischen Vulkan-Apps und dem Vulkan-Treiber eines Geräts. Der Vulkan
Ladeprogramm ist unter /system/lib[64]/libvulkan.so
installiert. Ladeprogramm
bietet die wichtigsten Einstiegspunkte der Vulkan API, also die Einstiegspunkte von Erweiterungen
die gemäß dem Android-CDD erforderlich sind, sowie viele zusätzliche optionale Erweiterungen. Fenster
WSI-Erweiterungen (System Integration) werden vom Loader exportiert und hauptsächlich
nicht im Treiber, sondern im Ladeprogramm implementiert. Das Ladeprogramm unterstützt auch
Ebenen auflisten und laden, die zusätzliche Erweiterungen und Achsenabschnitte offenlegen können
werden wichtige API-Aufrufe
an den Treiber weitergeleitet.
Das NDK enthält eine Stub-libvulkan.so
-Bibliothek für
Verknüpfung. Die Bibliothek exportiert dieselben Symbole wie das Ladeprogramm. Apps rufen die Funktionen auf
aus der echten libvulkan.so
-Bibliothek in
Trampolinfunktionen im Ladeprogramm eingeben, die an den entsprechenden
Layer oder Treiber basierend auf ihrem ersten Argument. Das vkGet*ProcAddr()
gibt die Funktionszeiger zurück, an die die Trampoline
ruft er direkt in den API-Kerncode auf. Aufruf durch die Funktion
statt der exportierten Symbole, ist effizienter, da sie
überspringt das Trampolin
und macht los.
Treiberaufzählung und -Laden
Wenn das System-Image erstellt wird, erwartet Android, dass das System weiß, welche GPUs
verfügbar sind. Das Ladeprogramm verwendet den vorhandenen HAL-Mechanismus in
hardware.h
um den Treiber zu finden und zu laden. Bevorzugte Pfade für 32-Bit- und 64-Bit-Vulkan-Treiber sind:
/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
Ab Android 7.0: Vulkan-hw_module_t
-Ableitung
umschließt eine einzelne hw_module_t
-Struktur. wird nur ein Treiber unterstützt und der konstante String
HWVULKAN_DEVICE_0
wird an open()
übergeben.
Die hw_device_t
-Ableitung des Vulkans entspricht einer einzelnen
Treiber, der mehrere physische Geräte unterstützen kann. Die
hw_device_t
-Struktur kann auf Export erweitert werden
vkGetGlobalExtensionProperties()
, vkCreateInstance()
und
vkGetInstanceProcAddr()
-Funktionen. Das Ladeprogramm kann alle anderen
VkInstance()
, VkPhysicalDevice()
und
vkGetDeviceProcAddr()
-Funktionen hinzu, indem Sie
vkGetInstanceProcAddr()
des hw_device_t
-Objekts.
Erkennung und Laden von Ebenen
Der Vulkan Loader unterstützt das Auflisten und Laden von Ebenen, zusätzliche Erweiterungen und fangen API-Kernaufrufe auf dem Weg zum . Android enthält keine Schichten auf dem System-Image. Allerdings Apps können Ebenen in ihrem APK enthalten.
Beachten Sie bei der Verwendung von Ebenen, dass das Sicherheitsmodell und die Richtlinien von Android deutlich von anderen Plattformen. Android gestattet insbesondere Laden von externem Code in einen nicht Debug-fähigen Prozess in der Produktion (nicht gerootet) Geräte und ermöglicht es externen Code auch nicht, die Prozesse Speicher, Zustand und so weiter. Dazu gehört ein Verbot des Speicherns von Core Dumps, zur späteren Prüfung auf das Laufwerk übertragen. Nur Ebenen, die im Rahmen von nicht debugfähige Apps sind auf Produktionsgeräten aktiviert und Treiber dürfen die gegen diese Richtlinien verstoßen.
Anwendungsfälle für Ebenen:
- Ebenen in der Entwicklungszeit – Validierung Layers und Shims für Tracing-/Profiling-/Debugging-Tools sollten nicht auf das System-Image der Geräte in der Produktionsphase. Validierungsebenen und Shims für Tracing-/Profiling-/Debugging-Tools sollten ohne System aktualisiert werden können. Bild. Für Entwickler, die eine dieser Ebenen während der Entwicklung das App-Paket verändern kann, indem sie dem Verzeichnis ihrer nativen Bibliotheken eine Datei hinzufügen. IHV- und OEM-Ingenieure, die Fehler beim Versand nicht modifizierbarer Apps diagnostizieren, Zugriff auf Nicht-Produktions-Builds (gerootet) des System-Images, es sei denn, diese Apps Debug-fähig sind. Weitere Informationen finden Sie unter Vulkan-Validierungsebenen unter Android.
- Dienstprogrammebenen: Diese Ebenen werden Erweiterungen, wie z. B. eine Schicht, die einen Speichermanager für den Gerätespeicher implementiert. Entwickler wählen Ebenen und Versionen dieser Ebenen für ihre App; können verschiedene Apps, die dieselbe Ebene nutzen, verschiedenen Versionen. Entwickler wählen aus, welche dieser Ebenen App-Paket.
- Injizierte (implizite) Ebenen: Enthält Ebenen wie die vom Nutzer oder vom Nutzer bereitgestellte Overlays ohne Wissen oder Einwilligung der App nutzen. Diese gegen die Sicherheitsrichtlinien von Android verstoßen und daher nicht unterstützt werden.
Bei nicht debugfähigen Apps sucht das Ladeprogramm nur im
in das native Bibliotheksverzeichnis der App ein und versucht, eine beliebige Bibliothek mit einem Namen
die mit einem bestimmten Muster übereinstimmen (z. B. libVKLayer_foo.so
).
Bei Debug-fähigen Anwendungen sucht das Ladeprogramm nach Layers in
/data/local/debug/vulkan
und versucht, übereinstimmende Bibliotheken zu laden
ein bestimmtes Muster zu erkennen.
Android ermöglicht das Portieren von Layern mit Build-Umgebungsänderungen zwischen Android und anderen Plattformen. Weitere Informationen zur Schnittstelle zwischen den Layern und der Loader, siehe Architektur der Vulkan-Loader-Schnittstellen. Die Chronos unterhalten werden Validierungsschichten Vulkan-Validierungsebenen:
Vulkan API-Versionen und -Funktionen
In der folgenden Tabelle sind die Vulkan API-Versionen für mehrere Android-Releases aufgeführt.Android-Version | Vulkan-Version |
---|---|
Android 13 | Vulkan 1.3 |
Android 9 | Vulkan 1.1 |
Android 7 | Vulkan 1.0 |
Vulkan 1.3: Funktionen im Überblick
Vulkan 1.3 kanonisiert eine Reihe zuvor optionaler Erweiterungen in die Vulkan-Kernfunktion. Ein Großteil dieser Funktionen wird genutzt, um die Kontrolle und den Detaillierungsgrad der Vulkan-Programmierschnittstelle. Render-Karten-Instanzen mit einzelnem Durchlauf werden nicht mehr benötigt Karten-/Ticketobjekte oder Framebuffer rendern. Die Gesamtzahl der Pipelinestatusobjekte kann reduziert werden. API-Synchronisierung überarbeitet wurde. Vulkan 1.3 hat dieselben Hardwareanforderungen wie Vulkan 1.2, 1.1 und 1.0, wobei der Großteil der Implementierung im SoC-spezifischen Grafiktreiber erfolgt, innerhalb des Frameworks.
Die wichtigsten Funktionen von Vulkan 1.3 für Android sind:
- Unterstützung für Rendering-Karten-Instanzen mit einem einzigen Durchlauf
- Unterstützung für das sofortige Beenden eines Shader-Aufrufs
- Genauere Erstellung, Freigabe und Steuerung der Pipeline
Vulkan 1.3 enthält außerdem mehrere kleinere Funktionen und Verbesserungen an der API-Nutzerfreundlichkeit. Alle Änderungen die an der Kern-Vulkan API mit der Nebenversion 1.3 vorgenommen wurde, finden Sie unter Core Revisions (Vulkan 1.3)
Vulkan 1.2: Funktionen im Überblick
Vulkan 1.2 bietet eine Reihe von Funktionen und Erweiterungen, die die API-Oberfläche vereinfachen. Dazu gehören ein einheitliches Speichermodell und zusätzliche Informationen, die von einem Gerätetreiber abgefragt werden können. Vulkan 1.2 hat dieselben Hardwareanforderungen wie Vulkan 1.0 und 1.1. alle Die Implementierung erfolgt im SoC-spezifischen Grafiktreiber, nicht im Framework.
Die wichtigste Vulkan 1.2-Funktion für Android ist die Unterstützung von 8-Bit-Speicher.
Vulkan 1.2 enthält außerdem mehrere kleinere Funktionen und Verbesserungen an der API-Nutzerfreundlichkeit. Alle Änderungen die an der Kern-Vulkan API mit der Nebenversion 1.2 vorgenommen wurde, finden Sie unter Core Revisions (Vulkan 1.2)
Vulkan 1.1: Funktionen im Überblick
Vulkan 1.1 unterstützt die Interoperabilität von Arbeitsspeicher/Synchronisierung, ermöglicht es OEMs, Vulkan 1.1 auf Geräten zu unterstützen. Außerdem Dank Memory/Sync Interoperabilität können Entwickler:innen um festzustellen, ob Vulkan 1.1 auf einem Gerät unterstützt wird, und es effektiv zu nutzen. wenn es so weit ist. Vulkan 1.1 hat dieselben Hardwareanforderungen wie Vulkan 1.0, aber die meisten erfolgt die Implementierung im SOC-spezifischen Grafiktreiber und nicht im Framework.
Die wichtigsten Vulkan 1.1-Funktionen für Android sind:
- Unterstützung für den Import und Export von Zwischenspeichern und Synchronisierung des Arbeitsspeichers Objekte von außerhalb von Vulkan (zur Interoperabilität mit Kamera, Codecs und GLES)
- Unterstützung für YCbCr-Formate
Vulkan 1.1 enthält auch mehrere kleinere Funktionen und Verbesserungen an der API-Nutzerfreundlichkeit. Alle Änderungen die an der Kern-Vulkan API mit der Nebenversion 1.1 vorgenommen wurde, finden Sie unter Core Revisions (Vulkan 1.1)
Vulkan-Unterstützung auswählen
Android-Geräte sollten die fortschrittlichsten Vulkan-Funktionen unterstützen, unterstützen 64-Bit-ABIs und haben keinen geringen Arbeitsspeicher.
Geräte, die mit Android 13 und höher auf den Markt gebracht werden, sollten Vulkan 1.3 unterstützen.
Geräte, die mit Android 10 auf den Markt gebracht werden, sollten Vulkan 1.1 unterstützen.
Optional können andere Geräte Vulkan 1.3, 1.2 und 1.1 unterstützen.
Vulkan-Version unterstützen
Ein Android-Gerät unterstützt eine Vulkan-Version, wenn die folgenden Bedingungen erfüllt sind:
- Füge einen Vulkan-Treiber hinzu, der die betreffende Vulkan-Version unterstützt (muss eine Vulkan-Version sein) 1.3, 1.1 oder 1.0) zusätzlich zu den zusätzlichen CDD-Anforderungen der Android-Version Alternativ können Sie auch einen vorhandenen Vulkan-Treiber mit einer niedrigeren Vulkan-Versionsnummer aktualisieren.
- Achten Sie bei Vulkan 1.3 oder 1.1 darauf, dass die vom Paketmanager zurückgegebene Systemfunktion Folgendes zurückgibt:
true
für die korrekte Vulkanversion.- Bei Vulkan 1.3 ist diese Funktion
PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000)
- Bei Vulkan 1.1 ist dies
PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000)
true
für Vulkan 1.3 und Vulkan 1.1 zurück, indem er eine Regel hinzufügt: in eine entsprechendedevice.mk
-Datei hochladen.- Füge für Vulkan 1.3 Folgendes hinzu:
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
- Bei Vulkan 1.3 ist diese Funktion
- Füge für Vulkan 1.1 Folgendes hinzu:
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
Android Baseline-Profil (ABP)
Wir empfehlen allen Android-Geräten, das neueste Android Baseline 2022-Profil einzuhalten, die in den Profilleitfaden für Android Baseline
Alle Geräte, die Android 14 oder höher und die Vulkan API unterstützen, müssen
alle in den
Profil „Android Baseline 2021“. Die vollständige Liste der erforderlichen Funktionen
in der Datei json
des Vulkan-Profils aufgezählt, aber eine Schlüsselteilmenge der erforderlichen
Funktionalität:
- Komprimierte Texturen über ASTC und ETC.
- Variable Farbräume bis
VK_EXT_swapchain_colorspace
. - Sample-Shading und Multisample-Interpolation durch
sampleRateShading
Windows-Systemintegration (WSI)
In libvulkan.so
implementiert der Treiber Folgendes:
WSI-Erweiterungen (Window System Integration):
VK_KHR_surface
VK_KHR_android_surface
VK_KHR_swapchain
VK_KHR_driver_properties
, implementiert für Vulkan 1.1 in Nur Android 10VK_GOOGLE_display_timing
, für jede Vulkan-Version implementiert für Android 10
Die Objekte VkSurfaceKHR
und VkSwapchainKHR
sowie alle
Interaktionen mit ANativeWindow
werden von der Plattform abgewickelt
den Treibern ausgesetzt. Die WSI-Implementierung basiert auf dem
VK_ANDROID_native_buffer
-Erweiterung, die sein muss
vom Treiber unterstützt wird, Diese Erweiterung wird nur von der WSI-Implementierung verwendet
und nicht für Apps sichtbar ist.
Gralloc-Nutzungs-Flags
Bei Vulkan-Implementierungen müssen möglicherweise Swapchain-Zwischenspeicher zugewiesen werden. Implementierungsdefinierte private Gralloc-Nutzungs-Flags. Beim Erstellen einer Swapchain Android bittet den Fahrer, das angeforderte Format und die Bildnutzung zu übersetzen. Gralloc-Nutzungs-Flags durch Aufrufen von
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 );
Die Parameter format
und imageUsage
stammen aus
VkSwapchainCreateInfoKHR
. Der Fahrer sollte
*grallocConsumerUsage
und *grallocProducerUsage
mit
Die für das Format erforderlichen Gralloc-Nutzungs-Flags
und deren Nutzung. Die vom Treiber zurückgegebenen Nutzungs-Flags werden mit der Nutzung kombiniert
Flags, die vom Swapchain-Nutzer beim Zuweisen von Puffern angefordert werden.
Android 7.x ruft eine frühere Version von VkSwapchainImageUsageFlagsANDROID()
auf,
mit dem Namen vkGetSwapchainGrallocUsageANDROID()
. Android 8.0 und höher werden eingestellt
vkGetSwapchainGrallocUsageANDROID()
ruft aber weiterhin an
vkGetSwapchainGrallocUsageANDROID()
wenn
vkGetSwapchainGrallocUsage2ANDROID()
wird nicht vom Fahrer bereitgestellt:
VkResult VKAPI vkGetSwapchainGrallocUsageANDROID( VkDevice device, VkFormat format, VkImageUsageFlags imageUsage, int* grallocUsage );
vkGetSwapchainGrallocUsageANDROID()
unterstützt keine Flags für die Swapchain-Nutzung und keine erweiterten Flags für die Gralloc-Nutzung.
Gralloch-gestützte Bilder
VkNativeBufferANDROID
ist eine vkCreateImage
-Erweiterung
zum Erstellen eines Bilds mit Gralloc-Zwischenspeicher. VkNativeBufferANDROID
ist
für vkCreateImage()
in VkImageCreateInfo
bereitgestellt
Strukturkette. Anrufe an vkCreateImage()
mit VkNativeBufferANDROID
erfolgen
während des Anrufs an vkCreateSwapchainKHR
. Die WSI-Implementierung weist
die Anzahl der nativen Puffer,
die für die Auslagerungskette angefordert wurden,
VkImage
für jede Adresse:
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;
Beim Erstellen eines Gralloc-gestützten Bildes hat VkImageCreateInfo
folgende Daten:
.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
Ab Android 8.0 bietet die Plattform
VkSwapchainImageCreateInfoKHR
-Erweiterungsstruktur in der
Kette VkImageCreateInfo
für vkCreateImage
bereitgestellt
wenn Flags zur Verwendung von Swapchain-Images für die Swapchain erforderlich sind.
Die Erweiterungsstruktur enthält die Flags für die Verwendung von Swapchain-Images:
typedef struct { VkStructureType sType; // must be VK_STRUCTURE_TYPE_SWAPCHAIN_IMAGE_CREATE_INFO_ANDROID const void* pNext; VkSwapchainImageUsageFlagsANDROID usage; } VkSwapchainImageCreateInfoANDROID;
Ab Android 10 unterstützt die Plattform
VK_KHR_swapchain
Version 70, damit die Vulkan-App
VkImage
durch Swapchain-Speicher gestützt. Erste Anrufe in der App
vkCreateImage
mit VkImageSwapchainCreateInfoKHR
Struktur, die mit der VkImageCreateInfo
-Struktur verkettet ist. Dann
App ruft vkBindImageMemory2(KHR)
mit einer
VkBindImageMemorySwapchainInfoKHR
-Struktur mit
VkBindImageMemoryInfo
-Struktur. Das imageIndex
die in der VkBindImageMemorySwapchainInfoKHR
-Struktur angegeben ist,
ein gültiger Swapchain-Image-Index. Gleichzeitig bietet die Plattform
VkNativeBufferANDROID
-Erweiterungsstruktur mit den entsprechenden
Gralloc-Pufferinformationen
an die VkBindImageMemoryInfo
-Kette senden,
der Treiber weiß, mit welchem Gralloc-Zwischenspeicher
VkImage
gebunden werden soll.
Bilder aufnehmen
vkAcquireImageANDROID
erwirbt die Inhaberschaft eines Swapchain-Images
und importiert einen extern signalisierten nativen Zaun in einen bestehenden
VkSemaphore
-Objekt und ein vorhandenes VkFence
-Objekt:
VkResult VKAPI vkAcquireImageANDROID( VkDevice device, VkImage image, int nativeFenceFd, VkSemaphore semaphore, VkFence fence );
vkAcquireImageANDROID()
wird angerufen während
vkAcquireNextImageKHR
zum Importieren eines
nativer Zaun in die VkSemaphore
- und VkFence
-Objekte
von der App bereitgestellt werden (sowohl Semaphore- als auch Fence-Objekte)
optional). Der Fahrer kann diese Gelegenheit auch nutzen, um
und externe Änderungen
am Gralloc-Pufferstatus verarbeiten; dass viele Autofahrer
nichts tun müssen. Bei diesem Aufruf werden die VkSemaphore
und
VkFence
in den Status „Ausstehend“, wie wenn von vkQueueSubmit
signalisiert,
damit die Warteschlangen auf die Semaphore warten und die App auf dem Zaun warten kann.
Beide Objekte werden signalisiert, wenn der zugrunde liegende native Zaun signalisiert. wenn
bereits signalisiert hat, befindet sich die Semaphore im Signal
wenn diese Funktion zurückgegeben wird. Der Fahrer ist Inhaber der Zaundatei.
-Deskriptor und schließt den Fence-Datei-Deskriptor, wenn er nicht mehr benötigt wird. Der Fahrer
Dies gilt auch dann, wenn weder ein Semaphore- noch ein Zaunobjekt bereitgestellt wird
vkAcquireImageANDROID
schlägt fehl und gibt einen Fehler zurück. Wenn
fenceFd
ist -1, als wäre der native Zaun bereits vorhanden
signalisiert.
Release-Images
vkQueueSignalReleaseImageANDROID
bereitet ein Swapchain-Image vor für
für den externen Gebrauch, erstellt einen nativen Zaun und plant die Signalisierung des nativen Zauns nach dem
die Eingabesemaphoren signalisiert haben:
VkResult VKAPI vkQueueSignalReleaseImageANDROID( VkQueue queue, uint32_t waitSemaphoreCount, const VkSemaphore* pWaitSemaphores, VkImage image, int* pNativeFenceFd );
vkQueuePresentKHR()
ruft vkQueueSignalReleaseImageANDROID()
an
in der angegebenen Warteschlange. Der Fahrer muss einen Zaun aufstellen, der kein Signal
bis alle waitSemaphoreCount
Semaphoren
pWaitSemaphores
-Signal und alle weiteren Schritte, die zum
Bereiten Sie image
auf die Präsentation vor.
Wenn die Wartesemaphoren (falls vorhanden) bereits signalisiert haben und queue
bereits inaktiv ist, kann der Fahrer *pNativeFenceFd
festlegen
in -1
anstelle eines tatsächlichen
nativen Fence-Dateideskriptors. Dies weist darauf hin,
Sie müssen nichts warten. Der Aufrufer besitzt die Dateibeschreibung und schließt sie.
zurückgegeben in *pNativeFenceFd
.
Viele Fahrer ignorieren den Image-Parameter, einige müssen sich jedoch möglicherweise vorbereiten.
Mit einem Gralloc-Zwischenspeicher verknüpfte CPU-seitige Datenstrukturen zur Verwendung durch externe
und Image-Nutzer. Die Vorbereitung von Pufferinhalten für die Verwendung durch externe Nutzer sollte
asynchron als Teil des Übergangs des Bildes zu
VK_IMAGE_LAYOUT_PRESENT_SRC_KHR
Wenn das Image mit einer
VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID
, muss der Fahrer
Wiederholtes Anrufen von vkQueueSignalReleaseImageANDROID()
erlauben
ohne dass dazwischen Aufrufe von vkAcquireImageANDROID()
erfolgen.
Unterstützung für gemeinsam präsentierte Bilder
Einige Geräte können die Eigentumsrechte an einem Bild teilen,
der Anzeigepipeline und der Vulkan-Implementierung,
um die Latenz zu minimieren.
Unter Android 9 und höher bewirbt das Ladeprogramm unter bestimmten Bedingungen die
Erweiterung „VK_KHR_shared_presentable_image
“ auf Basis des
Antwort auf einen Aufruf von vkGetPhysicalDeviceProperties2
.
Wenn der Treiber weder Vulkan 1.1 noch die
VK_KHR_physical_device_properties2
-Erweiterung, das Ladeprogramm funktioniert nicht
die Unterstützung freigegebener präsentierbarer Bilder zu bewerben. Andernfalls fragt der Loader ab,
Rufen Sie vkGetPhysicalDeviceProperties2()
auf, um die Treiberfunktionen aufzurufen.
und die folgende Struktur in den
VkPhysicalDeviceProperties2::pNext
-Kette:
typedef struct { VkStructureType sType; // must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENTATION_PROPERTIES_ANDROID const void* pNext; VkBool32 sharedImage; } VkPhysicalDevicePresentationPropertiesANDROID;
Ob der Fahrer die Eigentumsrechte an einem Bild mit dem Display teilen kann
wird das sharedImage
-Mitglied auf VK_TRUE
gesetzt.
Zertifizierungsstufe
OEMs können ihre Vulkan-Implementierung mit CTS testen. Dies umfasst Folgendes:
- Khronos Vulkan-Konformitätstests
im Modul
CtsDeqpTestCases
an, Dazu gehören funktionale API-Tests für Vulkan 1.0, 1.1, 1.2 und 1.3. - Das Modul
CtsGraphicsTestCases
, das prüft, ob das Gerät für die unterstützten Vulkan-Funktionen konfiguriert ist.
Vulkan-Feature-Flag
Ein Gerät, das Android 11 oder höher und die Vulkan API unterstützt
ist erforderlich, um
ein Funktions-Flag bereitzustellen,
android.software.vulkan.deqp.level
Der Wert dieses Funktions-Flags
ist ein Datum, codiert als Ganzzahlwert. Es gibt das Datum an, das mit
die Vulkan-dEQP-Tests, die das Gerät als bestanden hat.
Ein Datum im Format JJJJ-MM-TT wird wie folgt als 32-Bit-Ganzzahl codiert:
- 0–15 Bits pro Jahr
- 16–23 Bits pro Monat
- 24–31 Bits
Der minimal zulässige Wert für das Feature-Flag ist 0x07E30301
,
das dem 01.03.2019 entspricht, also dem Datum, das dem
Vulkan-dEQP-Tests für Android 10. Wenn das Feature-Flag mindestens diesen Wert hat,
das Gerät behauptet, alle Android 10-Vulkan dEQP-Tests bestanden zu haben.
Der Wert 0x07E40301
entspricht dem Datum 2020-03-01, also
das Datum, das den Vulkan-dEQP-Tests für Android 11 zugeordnet ist Wenn die Funktion
Wenn das Flag mindestens diesen Wert hat, gibt das Gerät an, alle Android 11-Versionen
Vulkan-dEQP-Tests.
Der Wert 0x07E60301
entspricht dem Datum 2022-03-01, also
das Datum, das den Vulkan-dEQP-Tests für
Android 13 Wenn das Feature-Flag mindestens diesen Wert hat,
das Gerät angibt, alle Android 13-Vulkans zu bestehen
dEQP-Tests.
Geräte, die ein bestimmtes Funktions-Flag (z. B.
0x07E30301
, 0x07E40301
, 0x07E60301
)
gibt an, alle dEQP-Tests von Android Vulkan (Android 10,
Android 11 bzw. Android 13). Dieses Gerät
können Vulkan-dEQP-Tests einer späteren Android-Version bestehen.
Vulkan dEQP ist Teil der CTS von Android. Ab Android 11 mit dem dEQP-Test-Runner
CTS-Komponente erkennt android.software.vulkan.deqp.level
kennzeichnen, und überspringt alle Vulkan-dEQP-Tests, die laut dieser
Funktions-Flag: Das Gerät gibt keinen Support aus. Solche Tests sind
die als unbedeutend fortbestehend gemeldet wurden.