RFC: gfx-rs to HAL bridge #1721

Introduction

Lately, I've been trying to wrap my head around what gfx-render is meant to be, and how we can approach it effectively. The project started before we took full course on Vulkan Portability (#1354, #1610), and the prototyping we got (thanks to @Bastacyclop fearless efforts) was not exactly bringing us the compatibility with the old/current gfx-rs. Meanwhile, our growing userbase has been putting more and more pressure to get something compatible.

Ideas

Here is the idea that struck me: if HAL ~ Vulkan (portability), then implementing gfx-render, which would have gfx-rs like API and Vulkan-like backing, would be equal to ... implementing gfx_device_vulkan. Here is good news: we do have some code in there. Surely it needs to be updated and revamped, but the target is the same.

Making one step further: given a functioning Vulkan backend, we could use the portability layer to direct it to our HAL implementation. This redirection can be done by something like gfx_window_hal that links to HAL and provides all the function pointers.

Proposed plan

Here is the concrete proposal for gfx-to-HAL bridge:

1. Resurrect and finish gfx_device_vulkan implementation (this is pre-ll branch!), potentially use ash for accessing Vulkan.
2. Create gfx_window_hal that links to the portability layer. It may have it's own features for different HAL backends.
3. Test all the existing apps on the Vk/HAL backing, translating to D3D12/Metal, but not necessarily to Vulkan (we need to go deeper!).

Fate of gfx-render

What does this mean for gfx-render, you may ask (#1466, #1281)? Well, I think we should salvage what we can (note: if someone volunteers to continue development, you have my blessing!). There might still be space for a new non-constrained higher level library, but not much need for it:

• there would already be existing gfx-rs
• also possible to hook up Vulkano (Alternative API backend vulkano-rs/vulkano#525)
• framegraph-like APIs show a lot of promise, and they are nothing like gfx-render
• we could provide individual smaller components for more convenient use of HAL, such as type safe builder/macro like render pass definition
• some clients (like Amethyst or WebRender) prefer talking to HAL directly anyway

My primary motivation behind gfx-render was the compatibility with existing apps, in particular - with our own examples. But with this bridge implemented, we'd just leave those examples be in pre-ll safely, keep supporting pre-ll, and shift to developing new examples specifically for HAL and it's future wrappers (more framegraphs!:) ).

Questions

Welcome to the comments section below ;)