Multiple Render Backends

[PixelDust22]

First of all, congrats on the release of bevy 0.6! The new bevy_render is definitively going to be an important step towards making bevy a true general-purpose game engine!

However, looking at the codebase for the new renderer I'm a bit disappointed that I wouldn't be able to use most of the new features that were introduced in this new version due to our decision to use wgpu directly.

I'm currently working on a voxel renderer and my tech requires the use of many Vulkan extensions that are currently unimplemented in wgpu - VK_KHR_ray_tracing, VK_KHR_buffer_device_address, VK_KHR_acceleration_structure and vkQueueBindSparse just to name a few. These extensions are not just a "nice-to-have" for my purpose - they're going to be a requirement for the renderer to function properly due to the intrinsic complexity of the voxel raytracer. I don't expect these features to be implemented anytime soon on wgpu - how are you going to build a cross-platform sparse binding feature when wgpu doesn't even have the concept of "memory binding"?

Before the render rewrite I was able to get around those issues by replacing bevy_wgpu with a custom backend that calls Vulkan APIs directly. I could still do the same thing today by completely replacing bevy_render with a custom implementation, but that also means I wouldn't be able to take advantage of render graphs, cameras, the Render subapp and most of the other nice things that was included in this release. And because bevy_render is such a core component of the bevy engine, it also means that any application using a custom renderer wouldn't be compatible with the rest of bevy's ecosystem.

Referring to cart's comment in #639:

I agree that long term it probably makes sense to have multiple render pipelines, but short term I would much rather maintain a single pipeline that runs decently everywhere while still looking good when you need it to (ex: google's Filament).
Once the renderer, the platform impls, and the rest of the engine have stabilized a bit, then we can consider splitting pipelines in the interest of optimization and/or render features.

Now that we've released the new renderer, it might be a good opportunity to start a discussion about having multiple render backends to support features that are absent on wgpu. If I'd like to build a bevy_contrib_vk for a render backend that calls Vulkan APIs directly, how is that going to work in tandem with the bevy_render that we currently have?

I understand that using wgpu directly is probably a good idea for the goals that bevy wants to achieve. Looking at the codebase I think there aren't many bevy_render components that would require a direct dependency on wgpu - at least the camera, color, mesh, primitives, and render_graph modules can be easily extracted out from bevy_render and put into a separate crate that doesn't depend on wgpu.

So I guess my question is

• Would it be a good idea to extracts common components from bevy_render so that a custom renderer could also depend on these components? If it requires building a small abstraction on certain wgpu types would that be acceptable?
• If we then use these common components to build a bevy_render_vulkan for example, is it possible for it to work alongside bevy_render?

[HackerFoo]

Would it be possible to implement what you need as a wgpu extension?

[PixelDust22]

Many features that I need are gonna be exclusive to DX12 and Vulkan. I think the goal (and benefit) of wgpu has been portability and ease of use. Extending wgpu with a bunch of advanced and hard-to-use Vulkan extensions that would only work on Vulkan would be in contradiction of that goal. Basically, for my use case, the overhead of having to implement a large number of extensions far outweight the cross-platform benefit of wgpu.

[PixelDust22]

And sometimes it's not a problem of what wgpu doesn't do. For example, sometimes I want full control over the presentation, swapchain and resources but wgpu will also assume control over those resources. It'll also insert pipeline barriers on places where I don't want a pipeline barrier to exist. When your use case requires that level of control, wgpu just doesn't make sense anymore. See kvark's comment in gfx-rs/wgpu#1912