Feasibility of an extension implementation layer for `VK_KHR_dynamic_rendering` ?

[James2022-rgb]

Has there been any discussion of a VK_LAYER_KHRONOS_dynamic_rendering, that would implement VK_KHR_dynamic_rendering on top of the Vulkan 1.0/1.1 core render pass API ?

I have yet to use VK_KHR_dynamic_rendering extensively, but felt like such an implementation layer might come in handy e.g. when developing for Android when one mostly or exclusively uses single-subpass render passes.

Based on your knowledge on the extension, how feasible do you think such an implementation would be ?

One concern is that this hypothetical layer would, for each application-facing VkPipeline, need to create on-demand and track an actual VkPipeline for each actual VkRenderPass, not to mention creating those VkRenderPasss on-demand.

[jeremyg-lunarg]

Sorry for the delay. It seems like it would be feasible to implement but I'm not sure anyone has looked at it in more detail than you have. One thing to keep in mind is that all the renderpass stuff was added to Vulkan to improve performance on mobile tiled rendering GPUs. It might concern some folks if we're encouraging developers towards a non-optimal path.

[James2022-rgb]

Thanks.

I really only had use cases in mind where on-chip multipass rendering leveraging multiple-subpass render passes for TB(D)R is not an absolute requirement for performance.

Unlike desktop GPUs that tend to get regular driver updates, many Android devices are stuck on 1.0/1.1 where they won't receive any OTA driver update until the end of time, which is where such an extension layer might come in handy for running future apps written with VK_KHR_dynamic_rendering support in mind.

Regarding dynamic rendering and TB(D)R, an interesting merge request was submitted to mesa which implements VK_KHR_dynamic_rendering for turnip (Vulkan driver for Adreno).
On a related note: many drivers (barring mobile) on mesa seems to be moving towards implementing VK_KHR_dynamic_rendering only, relying on common code path across the driver stack to implement regular render pass on top of it.

[James2022-rgb]

I'm not even sure if I would take on the work of implementing such a layer (it wouldn't be an easy task) so I'm rather asking out of curiosity, but:
Would you be open to taking/reviewing a pull request if someone actually implemented this kind of extension layer ?

[jeremyg-lunarg]

I'm not even sure if I would take on the work of implementing such a layer (it wouldn't be an easy task) so I'm rather asking out of curiosity, but: Would you be open to taking/reviewing a pull request if someone actually implemented this kind of extension layer ?

Yes, I'd gladly take a pull request if the code works on the platforms we support for the sync2 layer (windows, android, linux) and there are some unit test included.

[James2022-rgb]

Thanks - that clears it up for now !