Evaluate Adding Vulkan Backend (Possibly Over Metal Backend)

[lunabunn]

Currently, miniquad only supports GL backends (OpenGL 3, OpenGL ES 3, and WebGL 1 depending on the platform). The readme states the following about additional backends that could be added in the future:

Not supported, but desirable platforms

• Android, GLES2 - work in progress.
• Metal. For both MacOs and IOS metal rendering backend next to opengl one is highly desirable. But I just dont have any MacOs capable hardware to start working on it :/

I would like to propose for a Vulkan backend to also be considered, perhaps even with a higher priority than Metal. Here are some pros and cons to start off the discussion:

Pros

• Vulkan is quickly emerging as the new-generation graphics API and is more futureproof than just OpenGL
• On a related note, OpenGL is also infamous for its driver bugs and other fuckery; Vulkan is much better in these regards
• Vulkan runs pretty well on MacOS (and iOS!) using MoltenVK (real world applications such as Dota 2, Dolphin Emulator, and Final Fantasy XIV have had success with MoltenVK-powered MacOS ports)
• Vulkan also runs well on Windows and Linux, making development and testing much more accessible than with a Metal backend
  • This is extremely important because even if the inherent perf of the tech is worse [on Mac], better accessibility means more opportunities for code optimization (related: https://github.com/KhronosGroup/MoltenVK/issues/1085#issuecomment-700938056)

Cons

• Vulkan is more verbose than Metal, possibly requiring more developer hours
• MoltenVK is obviously less performant than Metal on Mac (although it's still more performant than OpenGL; some also claim that the overhead isn't really noticeable, see issue thread https://github.com/KhronosGroup/MoltenVK/issues/1085)

[Norlock]

It will be great to have Vulkan as a backend, but I can imagine that it's not so easy, because you need a lot more resources to develop it.

[codedcosmos]

Looking at a couple examples of miniquad, I think the top level abstraction is sufficient that you could probably fit in a Vulkan backend without breaking existing stuff. Though it's possible I missed something.

Having said that what would a vulkan implementation for this project look like? Would it be based on vulkano or Ash or would it be a more raw calling C++ functions type implementation?

[lunabunn]

Having said that what would a vulkan implementation for this project look like? Would it be based on vulkano or Ash or would it be a more raw calling C++ functions type implementation?

First of all, to clarify: vulkano and ash are not comparable. ash is much closer to the "raw calling C++ functions" unlike vulkano, which aims to be a safe wrapper.

That being said, I would imagine (based on how GL is currently handled) that sapp-* would handle context creation and expose its own raw Vulkan bindings for miniquad to use. An auto-generation strategy such as that of erupt could be adopted, one of the already existing bindings crates could be reexported/vendored, et cetera.

[codedcosmos]

I think they are comparable they both ultimately let you implement Vulkan into your project. For my personal game engine I just used Rust Bindgen to call C++ functions. But I think going that route for a project like this would be a poor choice.

I think I might try to get started on some Vulkan implementation for miniquad based on Ash or Erupt. This issue has been open for a year and "As Far as I can tell"tm no progress has been made on it.