[matt_m]

Yeah that seems like that might be the best option right now, and it doesn't look like it will be too expensive either. What I probably would like more is the reverse, a Metal wrapper for Vulkan, since it seems so much easier to get started with Metal. Too bad Metal is a Swift/Obj-C API so it's not straightforward how to make it cross platform.

I don't know how much bad faith I want to assume on Apple's part, since there are probably some legitimate technical reasons why they don't want to support a lower level API (and they came out with Metal first). Vulkan is such a pain to use anyway that it's probably mostly used by engine developers who generally don't have a problem supporting multiple APIs like Metal / DirectX etc.

But at the very least, it would be nice if they upgraded their OpenGL version, since they already support that and it's only them holding back some of the newer features.

[pjmlp]

Vulkan is such a pain that one of the GDC 2018 talks is "Getting explicit: How hard is Vulkan really?".

https://www.khronos.org/news/events/gdc-2018

[Tobba_]

Vulkan is almost 1:1 equivalent to "modern" OpenGL except the need for a more advanced allocator. You had to write the exact same thing in OpenGL if you wanted decent performance, except through an entire translation layer.

I don't think anyone who actually worked on a serious engine thinks it's somehow harder to use. Sure, there's more boilerplate and it might get pretty difficult to port something to it, but that's something else entirely.

[pjmlp]

Except one also gets to compare Vulkan with Metal, DX 12, LibGNMX, LibGNM , NVN, all of them with a bit more developer friendliness and tooling in mind.

Which I guess, it is where the resistance is coming from, hence the need for such presentation.