Diese Seite wurde von der Cloud Translation API übersetzt.

Vulkan implementieren

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

Hinweis: <ro.hardware.vulkan> und <ro.product.platform> durch den Wert des Systems ersetzt werden. dieses Namens. Weitere Informationen und unterstützte Alternativstandorte finden Sie unter libhardware/hardware.c

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.
Hinweis:Unter Android 14 und höher werden alle Vulkan-fähige Geräte müssen Vulkan 1.1-Treiber haben. Siehe Android 14 Anforderungen der CDD für weitere Informationen Informationen.
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)
Der Paketmanager gibt true für Vulkan 1.3 und Vulkan 1.1 zurück, indem er eine Regel hinzufügt: in eine entsprechende device.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
```
- 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 10
VK_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.