Suggestion: Remove VK_KHR_dynamic_rendering hard dependency

[vertver]

Some hardware (mostly mobile GPUs) and APIs (Vulkan <1.2) require Render Pass support in one or another form. The base Vulkan's Render Pass requires colour attachment descriptor on frame buffer creation. However, VK_KHR_imageless_framebuffer allows to mitigate this issue by just pushing metadata (format, width, height) instead of full descriptor.

What I'm proposing is Vulkan-style render passes with immediate Begin/End without declarative creation of additional handles. It will be easier to manage, easier to integrate with other APIs (WebGPU works in similar manner), and also the implementation will be significantly simpler.

https://github.com/libsdl-org/SDL/blob/06bf8d1924c982c7cb750dd8eea40e4482a7c0ac/include/SDL3/SDL_gpu.h#L3285
https://github.com/webgpu-native/webgpu-headers/blob/a55c3c6d03a13efd2245f7a66440b73f1a0d8844/webgpu.h#L6108

[dzhdanNV]

Thanks, Anton. It makes sense. I will start working on this next week starting with (hopefully simple) API proposal.

P.S. Weird but... SDL, WebGPU backends? :D

[vertver]

Yeah, both of these run on mobile devices as well. SDL_GPU also offers support for WebGPU, so it makes sense do things in similar manner.

[dzhdanNV]

I'm starting to work on this. And while I'm studying how it's done in SDL and WebGPU (also looking into VK imageless framebuffer extension), I'm opened for suggestions how it should look in NRI API.

[vertver]

As I said before, it seems like it should be implemented as immediate API, not as Vulkan-style vkCreateRenderPass stuff. The only problem of this approach is that it requires to store VkRenderPass somewhere else, like in command buffer itself through hash map or something else. Anything else is related to WebGPU/SDL_GPU, since I'm not trying to make a bicycle. The WebGPU is preferred, since I'm currently trying to implement backend for NRI

[dzhdanNV]

Hash map... (ok, I will think about it)

[Bonkt]

I'm not sure I understand what you want to achieve, but if it is to have a WebGPU backed for nri I really don't see why the interface of NRI has to be changed? OR are you talking about making an implementation of WebGPU using NRI?

[vertver]

Currently, NRI requires VK_KHR_dynamic_rendering, which is unsupported on most android devices before 2023, and because of that, not supported by WebGPU. What I'm proposing is return back render passes and implement them in similar to WebGPU way, which is the most convenient way of using render passes (since you don't need to create them, and on platforms where dynamic rendering is supported it will be pushed directly as BeginRendering/EndRendering) .

[dzhdanNV]

@Bonkt No big changes planned. I promise :) Current NRI interface around [Begin/End]Rendering is already mobile friendly, but not WebGPU friendly (since they support toasters). Thus, AFAIU, the plan is to minimally extend RenderingDesc to pass some missing information to allow hidden framebuffer (render pass) management under the hood only in VK implementation, and only if VK_KHR_dynamic rendering is not supported. No changes in D3D12 and D3D11 backends. Also I do hope NRI gets WebGPU backend :)

I'm integrating latest Agility SDK (released today) and after that I will finally analyze needed changes and update this thread (today).

[dzhdanNV]

@vertver I briefly looked into WGPURenderPassDescriptor (with deps) and it matches RenderingDesc. So, I think that probably NRI API changes are not needed at all. The issue is more about how to implement existing API in Vulkan backend if VK_KHR_dynamic_rendering is not supported. Am I missing something?

[vertver]

I think you're not missing anything, as I said, you need some form of a cache for render passes. Loot at dawn's implementation of it - https://github.com/google/dawn/blob/main/src/dawn/native/vulkan/RenderPassCache.cpp

[vertver]

Also, I suggest that if we want to fully support NRI dynamic-like api in WebGPU, we should also cache by dynamic parameters as well (so the base implementation should also work without VK_EXT_extended_dynamic_state support)

[dzhdanNV]

Since we have concluded that NRI API is implementable using WebGPU and/or old-school Vulkan:

• Can this issue be renamed to: Remove VK_KHR_dynamic_rendering hard dependency?
• You can also create a new issue: Remove VK_EXT_extended_dynamic_state hard dependency

To be honest for me both are low priority. To avoid jumping from task to task I will look into removing VK_KHR_dynamic_rendering hard dependency first.