Ta strona została przetłumaczona przez Cloud Translation API.

Wdrażanie interfejsu Vulkan

Vulkan to niskie środowisko pracy, Wieloplatformowy interfejs API zapewniający wysoką wydajność obrazu 3D grafiki. Jak OpenGL ES (GLES), Vulkan zapewnia narzędzia do tworzenia dzięki grafice w czasie rzeczywistym w aplikacjach. Zalety korzystania z Vulkana to między innymi zmniejszenie procesora i obsługę języka SPIR-V Binary Intermediate.

Aby można było wdrożyć Vulkan, urządzenie musi zawierać:

Moduł ładujący Vulkan udostępniany przez Androida.
sterowniki interfejsu Vulkan dostarczane przez układy SOC, takie jak GPU IHV, stosuje Interfejs Vulkan API – Aby zapewnić obsługę interfejsu Vulkan, Android wymaga sprzętu GPU z obsługą interfejsu Vulkan i powiązanego sterownika. GPU musi też obsługiwać GLES w wersji 3.1 lub nowszej. Skontaktuj się z dostawcą układu SOC, poproś o pomoc kierowcy.

Jeśli urządzenie ma sterownik Vulkan, musi zadeklarować FEATURE_VULKAN_HARDWARE_LEVEL i FEATURE_VULKAN_HARDWARE_VERSION – funkcje systemowe w wersjach, dokładnie odzwierciedlać możliwości urządzenia. Pomaga to zapewnić, urządzenie jest zgodne z dokument z definicją zgodności (CDD).

Program ładujący Vulkan

Moduł ładujący Vulkan platform/frameworks/native/vulkan to podstawowy interfejs między aplikacjami Vulkan a sterownikiem Vulkan urządzenia. Vulkan Program uruchamiający jest zainstalowany w tym miejscu: /system/lib[64]/libvulkan.so. Moduł ładujący to podstawowe punkty wejścia interfejsu Vulkan API, punkty wejścia rozszerzeń wymagane przez CDD Androida oraz wiele dodatkowych opcjonalnych rozszerzeń. Okno Rozszerzenia integracji systemu (WSI) są eksportowane przez program ładujący i głównie w module wczytującym, a nie w sterowniku. Moduł ładowania obsługuje również wyliczanie i wczytywanie warstw, które mogą ujawniać dodatkowe rozszerzenia i przechwytywać podstawowych wywołań interfejsu API w drodze do sterownika.

Pakiet NDK zawiera bibliotekę z kropką libvulkan.so dla Google Analytics. Biblioteka eksportuje te same symbole co moduł wczytywania. Aplikacje wywołują funkcje wyeksportowane z prawdziwej biblioteki libvulkan.so do wprowadź w ładowarce funkcje, które wysyłają wiadomości do odpowiednich lub sterownika na podstawie pierwszego argumentu. vkGet*ProcAddr() zwraca wskaźniki funkcji, do których wysyłane są trampoliny (czyli wywołuje go bezpośrednio do podstawowego kodu interfejsu API). Wywołanie funkcji są skuteczniejsze niż wyeksportowane symbole. skacze na trampolinie i w drodze.

Wyliczanie i wczytywanie sterownika

Podczas tworzenia obrazu systemu Android oczekuje, że system rozpozna, które GPU są dostępne. Moduł ładowania używa istniejącego mechanizmu HAL w hardware.h aby wykryć i wczytać sterownik. Preferowane ścieżki dla 32- i 64-bitowych sterowników Vulkan to:

/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

Uwaga: <ro.hardware.vulkan> i <ro.product.platform> zostały zastąpione wartością systemową właściwości tej nazwy. Szczegółowe informacje i obsługiwane alternatywne lokalizacje znajdziesz tutaj: libhardware/hardware.c.

W Androidzie 7.0 i nowszych pochodna interfejsu Vulkan hw_module_t otacza pojedynczą strukturę hw_module_t; obsługiwany jest tylko jeden sterownik, a ciąg stały Wartość HWVULKAN_DEVICE_0 jest przekazywana do open().

Pochodna języka Vulkan hw_device_t odpowiada jednemu sterownika obsługującego wiele urządzeń fizycznych. Struktura hw_device_t może zostać rozszerzona do eksportu vkGetGlobalExtensionProperties(), vkCreateInstance() i vkGetInstanceProcAddr(). Moduł ładowania może znaleźć wszystkie pozostałe VkInstance(), VkPhysicalDevice() i vkGetDeviceProcAddr() funkcji przez wywołanie vkGetInstanceProcAddr() obiektu hw_device_t.

Wykrywanie i wczytywanie warstw

Moduł ładowania Vulkan obsługuje wyliczanie i wczytywanie warstw, które mogą ujawniać rozszerzeń i przechwytywania podstawowych wywołań interfejsu API w drodze do sterownika. Android nie obejmuje warstw w obrazie systemu. jednak aplikacje mogą zawierać warstwy w pliku APK.

Podczas korzystania z warstw pamiętaj, że model zabezpieczeń i zasady Androida różnią się znacznie od innych platform. Android nie zezwala na wczytywanie kodu zewnętrznego w procesie niemożliwym do debugowania w środowisku produkcyjnym (bez dostępu do roota) urządzeń ani nie umożliwia zewnętrznego kodu sprawdzania ani kontrolowania pamięci, stanu itd. Obejmuje to zakaz zapisywania zrzutów podstawowych, interfejsu API logu czasu itd., aby je później sprawdzić. Tylko warstwy dostarczone w ramach na urządzeniach produkcyjnych są włączone aplikacje, których nie można debugować, a sterowniki nie mogą udostępniać funkcje, które naruszają te zasady.

Przykłady użycia warstw:

Warstwy w czasie programowania – weryfikacja Nie należy instalować warstw i podkładek do śledzenia/profilowania/debugowania. to obraz systemu urządzeń produkcyjnych. Warstwy i podkładki walidacyjne dla narzędzia do śledzenia, profilowania i debugowania powinny być możliwe do aktualizacji bez użycia systemu, . Deweloperzy, którzy chcą z nich korzystać tych warstw w trakcie programowania może modyfikować pakiet aplikacji, np. przez dodanie pliku do katalogu bibliotek natywnych. Inżynierowie IHV i OEM, którzy chcą diagnozować błędy w dostawie aplikacji, których nie można zmienić, dostępu do nieprodukcyjnych (z dostępem do roota) kompilacji obrazu systemu, chyba że te aplikacje które można debugować. Więcej informacji znajdziesz w artykule o warstwie sprawdzania poprawności interfejsu Vulkan na Androidzie.
Warstwy użyteczności – te warstwy ujawniają rozszerzeń, np. warstwa implementującą menedżera pamięci urządzenia. Programiści wybierają warstwy i ich wersje do użycia w swoich aplikacja; Różne aplikacje używające tej samej warstwy mogą nadal używać różnych wersji. Programiści wybierają, które z tych warstw chcesz przesłać pakietu aplikacji.
Wstrzyknięte (niejawne) warstwy – obejmuje warstwy, takie jak liczby klatek, sieci społecznościowej i nakładki w programie uruchamiającym gry udostępnione przez użytkownika lub innej aplikacji bez jej wiedzy i zgody. Te naruszają zasady zabezpieczeń Androida i nie są obsługiwane.

W przypadku aplikacji, których nie można debugować, moduł ładowania wyszukuje warstwy tylko w do katalogu biblioteki natywnej aplikacji i próbuje wczytać dowolną bibliotekę o danej nazwie pasujące do określonego wzorca (np. libVKLayer_foo.so).

W przypadku aplikacji możliwych do debugowania moduł ładowania wyszukuje warstwy w /data/local/debug/vulkan i próbuje wczytać wszystkie pasujące biblioteki do określonego wzorca.

Android umożliwia przenoszenie warstw z modyfikacjami środowiska kompilacji między Androidem a innymi platformami. Szczegółowe informacje o interfejsie między warstwami Loader, zobacz Architektura interfejsów Vulkan Loader. Utrzymywany na Khronos warstwy weryfikacji są hostowane w Warstwy weryfikacji Vulkan.

Wersje i możliwości interfejsu Vulkan API

W tabeli poniżej znajdziesz listę wersji interfejsu Vulkan API dla kilku wersji Androida.

Wersja Androida	Wersja interfejsu Vulkan
Android 13	Vulkan 1.3
Android 9	Vulkan 1.1
Android 7	Vulkan 1.0

Omówienie funkcji interfejsu Vulkan 1.3

Vulkan 1.3 łączy wiele wcześniej opcjonalnych rozszerzeń z główną funkcją Vulkan. Znaczna część tej funkcji ma na celu zwiększenie kontroli i dokładności interfejsu programowania Vulkan. Instancje z przebiegiem jednoprzebiegowym renderowania nie są już potrzebne renderowania obiektów kart lub buforów ramek. można zmniejszyć łączną liczbę obiektów stanu potoku, synchronizacja w interfejsie API jest ulepszona. Vulkan 1.3 ma te same wymagania sprzętowe co Vulkan 1.2, 1.1 i 1.0, przy czym większość implementacji jest oparta na sterowniku karty graficznej SoC, w ramach platformy.

Najważniejsze funkcje Vulkan 1.3 dla Androida to:

Obsługa instancji z pomyślnym wynikiem jednoprzebiegu renderowania
Obsługa natychmiastowego kończenia wywoływania funkcji cieniowania
Większa szczegółowość tworzenia, udostępniania i kontroli potoków

Vulkan 1.3 zawiera też kilka mniejszych funkcji i ulepszenia w zakresie łatwości obsługi interfejsów API. Wszystkie zmiany wprowadzone w podstawowym interfejsie Vulkan API w wersji 1.3 znajdziesz na stronie Wersje podstawowe (Vulkan 1.3).

Omówienie funkcji interfejsu Vulkan 1.2

Vulkan 1.2 dodaje wiele funkcji i rozszerzeń, które upraszczają interfejs API. Obejmuje to m.in. ujednolicony model pamięci i dodatkowe informacje, które można uzyskać ze sterownika urządzenia. Vulkan 1.2 ma te same wymagania sprzętowe co Vulkan 1.0 i 1.1; wszystkie jest implementacja w sterowniku karty graficznej SoC, a nie w platformie.

Najważniejszą funkcją Vulkan 1.2 w Androidzie jest obsługa 8-bitowej pamięci masowej.

Vulkan 1.2 zawiera też kilka mniejszych funkcji i ulepszenia w zakresie łatwości obsługi interfejsów API. Wszystkie zmiany wprowadzone w podstawowym interfejsie Vulkan API w wersji 1.2 znajdziesz na stronie Wersje podstawowe (Vulkan 1.2).

Omówienie funkcji interfejsu Vulkan 1.1

Vulkan 1.1 obsługuje interoperacyjność pamięci/synchronizacji, umożliwia producentom OEM obsługę Vulkan 1.1 na urządzeniach. Dodatkowo: interoperacyjność pamięci/synchronizacji umożliwia programistom , aby określić, czy urządzenie obsługuje standard Vulkan 1.1, i skutecznie z niej korzystać w odpowiednim momencie. Vulkan 1.1 ma te same wymagania sprzętowe co Vulkan 1.0, ale większość jest implementacja w sterowniku karty graficznej SOC, a nie w platformie.

Najważniejsze funkcje Vulkan 1.1 dla Androida to:

Obsługa importowania i eksportowania buforów pamięci oraz synchronizacji obiekty spoza interfejsu Vulkan (na potrzeby współdziałania z aparatem, kodekami i GLES)
Obsługa formatów YCbCr

Vulkan 1.1 zawiera też kilka mniejszych funkcji i ulepszenia w zakresie łatwości obsługi interfejsów API. Wszystkie zmiany wprowadzone w podstawowym interfejsie Vulkan API w wersji 1.1 znajdziesz na stronie Wersje podstawowe (Vulkan 1.1).

Wybierz obsługę interfejsu Vulkan

Urządzenia z Androidem powinny obsługiwać najbardziej zaawansowany zestaw funkcji Vulkan, pod warunkiem że obsługują 64-bitowy interfejs ABI i nie mają małej ilości pamięci.

Urządzenia z Androidem 13 lub nowszym powinny obsługiwać interfejs Vulkan 1.3.

Urządzenia uruchamiane na Androidzie 10 powinny obsługiwać interfejs Vulkan 1.1.

Inne urządzenia mogą opcjonalnie obsługiwać Vulkan 1.3, 1.2 i 1.1.

Obsługa wersji interfejsu Vulkan

Urządzenie z Androidem obsługuje wersję interfejsu Vulkan, jeśli są spełnione te warunki:

Dodaj sterownik Vulkan, który obsługuje wybraną wersję interfejsu Vulkan (musi to być jedna z wersji Vulkana) 1.3, 1.1 lub 1.0) wraz z dodatkowymi wymaganiami dotyczącymi CDD Wersja Androida. Możesz też zaktualizować istniejący sterownik Vulkan o niższym numerze wersji.
Uwaga: w przypadku Androida 14 lub nowszego wszystkie Urządzenia z obsługą interfejsu Vulkan muszą mieć sterowniki Vulkan 1.1. Zobacz Androida 14 Wymagania dotyczące CD w przypadku innych informacji.
W przypadku wersji Vulkan 1.3 lub 1.1 upewnij się, że funkcja systemowa zwrócona przez menedżera pakietów true dla prawidłowej wersji interfejsu Vulkan.
- W wersji Vulkan 1.3 funkcja ta jest PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x403000)
- W wersji Vulkan 1.1 funkcja ta jest PackageManager#hasSystemFeature(PackageManager.FEATURE_VULKAN_HARDWARE_VERSION, 0x401000)
Menedżer pakietów zwróci wartość true w przypadku Vulkan 1.3 i Vulkan 1.1, dodając regułę, jak pokazano poniżej, do odpowiedniego pliku device.mk.
- Dodaj następujące elementy do 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
```
- Dodaj następujące kod do 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
```

Profil podstawowy Androida (ABP)

Zachęcamy, aby wszystkie urządzenia z Androidem były zgodne z najnowszym profilem Android Baseline 2022 jako opisane w Przewodnik po profilu Baseline na Androida

Każde urządzenie z Androidem 14 lub nowszym i interfejsem Vulkan API musi spełniają wszystkie funkcje zdefiniowane w Profil Android Baseline 2021 Pełna lista wymaganych funkcji to wyliczane w pliku profilu Vulkan json, ale jest podzbiorem klucza wymaganego Funkcje obejmują:

Skompresowane tekstury przez ASTC i ETC.
Zmienne przestrzenie kolorów do VK_EXT_swapchain_colorspace.
Cieniowanie próbek i interpolacja wielu próbek przez sampleRateShading

Integracja z systemem Windows (WSI)

W libvulkan.so sterownik implementuje te rozszerzenia integracji systemu okien (WSI):

VK_KHR_surface
VK_KHR_android_surface
VK_KHR_swapchain
VK_KHR_driver_properties, zaimplementowana w wersji Vulkan 1.1 w Tylko Android 10
VK_GOOGLE_display_timing, zaimplementowana dla dowolnej wersji Vulkana w Androidzie 10

Obiekty VkSurfaceKHR i VkSwapchainKHR oraz wszystkie interakcje z usługą ANativeWindow są obsługiwane przez platformę i nie są nie są widoczne dla kierowców. Implementacja WSI opiera się na VK_ANDROID_native_buffer, które musi być obsługiwana przez kierowcę; to rozszerzenie jest używane tylko przez implementację WSI i nie jest widoczny dla aplikacji.

Flagi wykorzystania Gralloc

Implementacje interfejsu Vulkan mogą wymagać przydzielenia buforów zamiany za pomocą zdefiniowane przez implementację prywatne flagi wykorzystania Gralloc. Podczas tworzenia zamiany Android prosi kierowcę o przetłumaczenie żądanego formatu i wykorzystania obrazu do flag wykorzystania Gralloc, wywołując:

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
);

Parametry format i imageUsage są pobierane z strukturę VkSwapchainCreateInfoKHR. Kierowca powinien zapełnić *grallocConsumerUsage i *grallocProducerUsage oraz flagi wykorzystania Gralloc wymagane dla formatu i wykorzystanie. Flagi wykorzystania zwracane przez sterownika są łączone z wykorzystaniem. flagi żądane przez klienta zamiany przy przydzielaniu buforów.

Android 7.x wywołuje starszą wersję VkSwapchainImageUsageFlagsANDROID(), o nazwie vkGetSwapchainGrallocUsageANDROID(). Wycofujemy Androida 8.0 i nowsze vkGetSwapchainGrallocUsageANDROID(), ale nadal połączenia vkGetSwapchainGrallocUsageANDROID(), jeśli Kierowca nie zapewnia usługi vkGetSwapchainGrallocUsage2ANDROID():

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

vkGetSwapchainGrallocUsageANDROID() nie obsługuje zamiany swapchain lub rozszerzone flagi wykorzystania Gralloc.

Obrazy z obsługą gralloc

VkNativeBufferANDROID to rozszerzenie do vkCreateImage która pozwala utworzyć obraz oparty na buforze Gralloc. VkNativeBufferANDROID to przesłano do: vkCreateImage() w: VkImageCreateInfo łańcuch struktur. Połączenia z numerem vkCreateImage() wykonywane są za pomocą numeru VkNativeBufferANDROID w trakcie połączenia z: vkCreateSwapchainKHR. Wdrożenie WSI przydziela liczbę buforów natywnych żądanych dla wymiany, a następnie tworzy VkImage w przypadku każdej z nich:

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;

Podczas tworzenia obrazu z użyciem Gralloca VkImageCreateInfo ma następujące dane:

  .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

W Androidzie 8.0 i nowszych platforma zapewnia VkSwapchainImageCreateInfoKHR struktury rozszerzeń w VkImageCreateInfo sieć została przekazana do: vkCreateImage gdy do łańcucha wymiany wymagane są jakiekolwiek flagi użycia obrazu wymiany. Struktura rozszerzenia zawiera flagi wykorzystania zamiany obrazów:

typedef struct {
    VkStructureType                        sType; // must be VK_STRUCTURE_TYPE_SWAPCHAIN_IMAGE_CREATE_INFO_ANDROID
    const void*                            pNext;

    VkSwapchainImageUsageFlagsANDROID      usage;
} VkSwapchainImageCreateInfoANDROID;

W Androidzie 10 i nowszych platforma obsługuje VK_KHR_swapchain v70, aby aplikacja Vulkan mogła utworzyć Urządzenie VkImage korzysta z pamięci wymiany. Aplikacja najpierw łączy się vkCreateImage i VkImageSwapchainCreateInfoKHR połączone ze strukturą VkImageCreateInfo. Później aplikacja łączy się z urządzeniem vkBindImageMemory2(KHR) za pomocą VkBindImageMemorySwapchainInfoKHR połączony z Struktura VkBindImageMemoryInfo. imageIndex określona w strukturze VkBindImageMemorySwapchainInfoKHR musi być prawidłowym indeksem obrazów wymiany. Tymczasem platforma zapewnia VkNativeBufferANDROID strukturę rozszerzeń z odpowiednimi informacji z bufora Gralloc do łańcucha VkBindImageMemoryInfo, więc kierowca wie, z którym buforem Gralloca powiązać VkImage.

Pobieraj obrazy

vkAcquireImageANDROID nabywa prawo własności do obrazu wymiany i importuje natywne ogrodzenie sygnalizowane zewnętrznie Obiekt VkSemaphore i istniejący obiekt VkFence:

VkResult VKAPI vkAcquireImageANDROID(
    VkDevice            device,
    VkImage             image,
    int                 nativeFenceFd,
    VkSemaphore         semaphore,
    VkFence             fence
);

Usługa vkAcquireImageANDROID() jest wywoływana w trakcie vkAcquireNextImageKHR, aby zaimportować natywne ogrodzenie w obiektach VkSemaphore i VkFence udostępniane przez aplikację (obiekty semaforu i ogrodzenia są opcjonalnie). Kierowca może również wykorzystać tę możliwość do rozpoznawania, i obsługuje wszelkie zewnętrzne zmiany stanu bufora Gralloc; wielu kierowców nie musimy robić nic więcej. Ta rozmowa powoduje, że VkSemaphore oraz VkFence jest w takim samym stanie oczekiwania jak w przypadku zasygnalizowania przez vkQueueSubmit, Dzięki temu kolejki mogą czekać na semforze, a aplikacja – na ogrodzeniu.

Oba obiekty są sygnalizowane, gdy sygnał natywny ogrodzenia sygnalizuje. jeśli jest już zasygnalizowane przez natywne ogrodzenie, semafor jest w momencie zwrócenia tej funkcji. Kierowca przejmie prawo własności do pliku ogrodzenia i zamyka deskryptor pliku ogrodzenia, gdy nie jest już potrzebny. Kierowca musi to robić, nawet jeśli nie podano semfora ani obiektu ogrodzenia lub vkAcquireImageANDROID kończy się niepowodzeniem i zwraca błąd. Jeśli fenceFd wynosi -1. To tak, jakby natywne ogrodzenie było już jest sygnalizowany.

Opublikuj zdjęcia

vkQueueSignalReleaseImageANDROID przygotowuje obraz wymiany na do użytku zewnętrznego, tworzy natywne ogrodzenie i planuje sygnalizowanie tego ogrodzenia po sem horyzonty wejściowe wskazują:

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

vkQueuePresentKHR() łączy się z: vkQueueSignalReleaseImageANDROID() z danej kolejki. Kierowca musi wykonać natywne ogrodzenie, które nie wysyła sygnałów do czasu, aż wszystkie sem hory (waitSemaphoreCount) pWaitSemaphores i inne czynności, które trzeba wykonać, aby przygotowuje image do zakończenia prezentacji.

Jeśli smaphory oczekiwania (jeśli występują) są już sygnalizowane, a queue jest jest już nieaktywny, kierowca może ustawić *pNativeFenceFd do -1 zamiast rzeczywistego natywnego deskryptora pliku ogrodzenia, co wskazuje, że nie ma na co czekać. Element wywołujący jest właścicielem i zamykającym deskryptor pliku zwrócone w *pNativeFenceFd.

Wiele sterowników może ignorować parametr obrazu, ale niektórzy muszą się na to przygotować Struktury danych po stronie procesora powiązane z buforem Gralloc do wykorzystania przez zewnętrzne konsumentów. Przygotowanie zawartości bufora do użytku przez klientów zewnętrznych powinno asynchronicznie podczas przenoszenia obrazu do VK_IMAGE_LAYOUT_PRESENT_SRC_KHR

Jeśli obraz został utworzony za pomocą VK_SWAPCHAIN_IMAGE_USAGE_SHARED_BIT_ANDROID, kierowca musi Zezwalaj na wielokrotne wywoływanie numeru vkQueueSignalReleaseImageANDROID() bez interwencji wywołanych przez funkcję vkAcquireImageANDROID().

Obsługa udostępnionego obrazu z prezentacją

Niektóre urządzenia mogą współdzielić własność jednego obrazu między dzięki potokowi wyświetlania i implementacji interfejsu Vulkan, co pozwala zminimalizować opóźnienia. W Androidzie 9 i nowszych moduł ładowania warunkowo reklamuje VK_KHR_shared_presentable_image rozszerzenie oparte na kierowcy odpowiedź na połączenie z numerem vkGetPhysicalDeviceProperties2.

Jeśli sterownik nie obsługuje interfejsu Vulkan 1.1 ani VK_KHR_physical_device_properties2, moduł ładowania nie może i reklamuje obsługę udostępnianych obrazów. W przeciwnym razie ładowarka wysyła zapytanie o możliwości sterownika, wywołując funkcję vkGetPhysicalDeviceProperties2() i uwzględniając w łańcuchu VkPhysicalDeviceProperties2::pNext tę strukturę:

typedef struct {
    VkStructureType sType; // must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENTATION_PROPERTIES_ANDROID
    const void*     pNext;
    VkBool32        sharedImage;
} VkPhysicalDevicePresentationPropertiesANDROID;

Jeśli kierowca może współdzielić własność obrazu z wyświetlaczem system, ustawienie elementu sharedImage na VK_TRUE.

Weryfikacja

OEM może przetestować wdrożenie interfejsu Vulkan za pomocą CTS, takiego jak:

Testy zgodności Khronosa Vulkana w module CtsDeqpTestCases, które obejmują testy funkcjonalnego interfejsu API Vulkan 1.0, 1.1, 1.2 i 1.3.
Moduł CtsGraphicsTestCases, który sprawdza, czy urządzenie poprawnie skonfigurowane pod kątem obsługiwanych funkcji interfejsu Vulkan.

Flaga funkcji interfejsu Vulkan

Urządzenie obsługujące Androida 11 lub nowszego i obsługujące interfejs Vulkan API. jest wymagane do ujawnienia flagi funkcji, android.software.vulkan.deqp.level Wartość tej flagi funkcji to data zakodowana w postaci liczby całkowitej. Określa datę powiązaną z w ramach testów dEQP interfejsu Vulkan, które według urządzenia urządzenie spełnia wymagania.

Data w formacie RRRR-MM-DD jest zakodowana jako 32-bitowa liczba całkowita w następujący sposób:

Fragmenty 0–15: sklep rok
Fragmenty 16–23 – sklep miesiąca
Bits 24-31 store the day

Minimalna dozwolona wartość flagi cechy to 0x07E30301, który odpowiada dacie 1.03.2019, która jest datą powiązaną z Testy dEQP interfejsu Vulkan w Androidzie 10. Jeśli flaga cech ma co najmniej tę wartość, urządzenie deklaruje, że przeszły wszystkie testy Vulkan dEQP Androida 10.

Wartość 0x07E40301 odpowiada dacie 1.03.2020, która jest data związana z testami dEQP interfejsu Vulkan w Androidzie 11. Jeśli flaga funkcji ma co najmniej tę wartość, urządzenie twierdzi, że przeszło wszystkie testy dEQP Vulkana w Androidzie 11.

Wartość 0x07E60301 odpowiada dacie 1.03.2022, która jest data związana z testami dEQP interfejsu Vulkan dla Android 13. Jeśli flaga cech ma co najmniej tę wartość, urządzenie deklaruje, że spełnia wszystkie wymagania Androida 13 Vulkan testów dEQP.

Urządzenie, na którym widoczna jest flaga określonej funkcji (np. 0x07E30301, 0x07E40301, 0x07E60301) twierdzi, że przeszła wszystkie testy dEQP Androida Vulkana dla tej funkcji (Android 10, Android 11 i Android 13). To urządzenie mogą przejść testy Vulkan dEQP w nowszej wersji Androida.

dEQP interfejsu Vulkan wchodzi w skład pakietu Android CTS. Począwszy od Androida 11, komponent CTS zna android.software.vulkan.deqp.level flagę funkcji i pomija wszystkie testy Vulkan dEQP, które zgodnie z tym flaga funkcji – urządzenie nie obsługuje funkcji. Takie testy są są zgłaszane jako trywialne.