RFC: gfx-rs to HAL bridge

[kvark]

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 ;)

[msiglreith]

As nice as it sounds, implementing gfx_device_vulkan will be quite tough IMO and this was actually my motivation to try something lower level. I'm not totally sure in what direction we should go in terms of API surface for the majority of users. Incrementally trying to provide helpers for certain pitfalls of the API (synchronization, memory management, upload strategies, ..) might be the best approach and would benefit both groups of users.

[Bastacyclop]

I think that gfx-render drifted a lot from gfx-rs precisely because of the difficulty to implement it with HAL. Favorising higher level constructions like framegraphs and engines seems promising, so maybe gfx-render (or the result of its salvage) should focus on helping those constructions (for example by providing the helpers mentioned by @msiglreith). Of course, having the bridge would still be great.

[kvark]

Note https://github.com/doitsujin/dxvk that maps D3D11 to Vulkan. It's not too far from the gfx_device_vulkan bridge I propose. We may look in there if facing a blocker.

[kvark]

At this point, I think we can call it, and declare pre-ll done for good. I don't imagine anybody doing this task. Feel free to reach out otherwise!