Khronos' 3D Portability Initiative Could Be Quite Interesting, Boon For Linux Gaming

[phoronix]

Phoronix: Khronos' 3D Portability Initiative Could Be Quite Interesting, Boon For Linux Gaming

While most are focused on the OpenXR VR announcement from The Khronos Group as well as the new Vulkan extensions, less people seem to be talking about their call for participation around a new "3D Portability Initiative", which if it succeeds could be a win for Linux gamers and others...

http://www.phoronix.com/scan.php?page=news_item&px=3D-Portability-Khronos-Effort

[BrandonB]

I had similar thoughts when I saw this earlier today. Seems like this might be a "workaround" of sorts to the way the big players are all pushing their own APIs. No matter how great Vulkan is, I will be shocked if we ever see it on Xbox hardware or an iDevice. The current question is likely: Go for Vulkan and leave out the Xbox, or go for DirectX12 and leave out Linux? We all know how that one ends. With this new initiative, we can only hope that the "best" option for developers supports DirectX12, but ALSO just happens to support Vulkan.

Quite sad that instead of being able to get support for open standards, we have to rely on translation, conversion, and/or compilation workarounds to conform for locked down hardware platforms.

[edoantonioco]

This sounds like bgfx

[Sumenia]

Thanks to Microsoft, we still can't create a vulkan UWP surface . (https://github.com/KhronosGroup/Vulkan-Docs/issues/366)

[quintesse]

But at the same time, I am surprised they are going after "yet another 3D API." I am a bit curious why they don't try to make Vulkan more adopted everywhere and promote that as their sole 3D next-gen API... There already is the MoltenVK efforts for running Vulkan on iOS/macOS systems, including the new Vulkan 1.0.42 extensions for presenting to iOS/macOS native surfaces. If there was a serious effort underway to get the Vulkan API running over the top of Direct3D 12, that could better fill the void, address any Vulkan Windows shortcomings, and seemingly make rather a portable 3D API.

They could try to layer Vulkan compatibility layers on top of D3D and Metal, or they could go this 3D-Portability route. Both are valid options and both are layers. But it depends on your goal. The problem with translating layers from one full-blown system to another is that you often need to emulate *everything* down to the smallest little detail or things won't always work 100% (the article itself mentions similar problems when trying to put an OpenGL layer on top of D3D). With a different API you can try to find a common denominator, a way that will make the best possible use of common features and either abstract over any big differences that exist or maybe even take some features away if there's no good way to implement them in all cases (in that case not even pretending you're supporting it and passing the problem on to the developer).

So those are possible technical reasons to go with a new API. The other reason is political. It might take quite some time to convince Microsoft to let go of its decade long investment in the Direct3D ecosystem and start focusing on Vulkan instead, and Apple will most likely never do so. Which means that when you try to convince developers and tool builders to focus on Vulkan you'll be fighting the efforts of the platform owners that will still be advertising their own (existing, proven) solutions.

So instead of trying to convince the entire world to switch to Vulkan you just come up with a way for developers and tool builders to not have to care about the underlying API (as long as it's "good enough") and hopefully you'll avoid the infighting.

[ssokolow]

They could try to layer Vulkan compatibility layers on top of D3D and Metal, or they could go this 3D-Portability route. Both are valid options and both are layers. But it depends on your goal. The problem with translating layers from one full-blown system to another is that you often need to emulate *everything* down to the smallest little detail or things won't always work 100% (the article itself mentions similar problems when trying to put an OpenGL layer on top of D3D). With a different API you can try to find a common denominator, a way that will make the best possible use of common features and either abstract over any big differences that exist or maybe even take some features away if there's no good way to implement them in all cases (in that case not even pretending you're supporting it and passing the problem on to the developer).

So those are possible technical reasons to go with a new API. The other reason is political. It might take quite some time to convince Microsoft to let go of its decade long investment in the Direct3D ecosystem and start focusing on Vulkan instead, and Apple will most likely never do so. Which means that when you try to convince developers and tool builders to focus on Vulkan you'll be fighting the efforts of the platform owners that will still be advertising their own (existing, proven) solutions.

So instead of trying to convince the entire world to switch to Vulkan you just come up with a way for developers and tool builders to not have to care about the underlying API (as long as it's "good enough") and hopefully you'll avoid the infighting.

3D, meet Linux Audio. Dealing with people is hard. Let's just abstract that problem away.

[starshipeleven]

So instead of trying to convince the entire world to switch to Vulkan you just come up with a way for developers and tool builders to not have to care about the underlying API (as long as it's "good enough") and hopefully you'll avoid the infighting.

Dunno about you, but "trying to convince the entire world to do X" sounds like horribly inpractical to me.

Back then when there was not a standard it was still possible, but now there is decades of entrenched DX users that can't just jump ship for lulz.

[indepe]

Eventually, it may make sense to have a higher-level API that runs on all 3 lower-level APIs. And some may already start thinking in that direction. Perhaps as a smaller API that covers only a subset of the functionality, yet at a higher level. However for the time being, it appears much more important to complete and optimize Vulkan implementations and ensure their reliability and accessibility. At least from a Linux perspective, Vulkan will be the foundation of all graphics. Also, I can't imagine that a lot of game engines would write for an intermediate API, instead of having one or multiple optimized backend(s). Even if there will be exceptions.

[Electric-Gecko]

The current question is likely: Go for Vulkan and leave out the Xbox, or go for DirectX12 and leave out Linux? We all know how that one ends. With this new initiative, we can only hope that the "best" option for developers supports DirectX12, but ALSO just happens to support Vulkan.

I myself have long wondered why any developers ever chose DX12 over Vulkan (other than than those few months before Vulkan 1.0 release, and Microsoft-affiliated studios). But especially for the DX12 games that ended up doing an OpenGL Linux port. Does anyone here have any idea why any devs ever made that decision? From what I've read everywhere, DX12 and Vulkan are considered to be totally equivalent in quality. Is there a greater marketing advantage of claiming DX12 support than Vulkan; greater "brand recognition"?

Here's something interesting about an id Software programmer arguing that it doesn't make sense that developers are choosing DX12. Although the writer of the article appears to have a rather stupid perspective on the issue.
http://gamingbolt.com/id-software-de...ferent-than-pc
An important point to argue for Vulkan that us Linux users often forget is that much of the PC gaming market share is Windows 7, which supports Vulkan but not DX12.

While I feel like developers could safely just ignore DX12 and use Vulkan, there's still Metal for Apple platforms. So having many parts of the Metal API the same as Vulkan would be an advantage to programmers, or even borrow some components of OpenGL (read my next point).

Eventually, it may make sense to have a higher-level API that runs on all 3 lower-level APIs. And some may already start thinking in that direction. Perhaps as a smaller API that covers only a subset of the functionality, yet at a higher level. However for the time being, it appears much more important to complete and optimize Vulkan implementations and ensure their reliability and accessibility. ... Also, I can't imagine that a lot of game engines would write for an intermediate API, instead of having one or multiple optimized backend(s).

I once read on some website that Metal has a significant difference from DX12 and Vulkan; it has a more high-level approach to memory management that's more like OpenGL, making it easier to code for. The writer suggested that an API similar to Metal could be built on top of Vulkan, which would be easier to code for than pure Vulkan, despite a small performance cost (but still better than OpenGL).

As for making a higher-level API that runs on Vulkan, Metal & DX12; I would probably remove DX12 from the mix, and possibly replace with OpenGL if possible. There just isn't much point of having DX12, is there? Maybe just the advantage of Xbox One support, but no need for Windows-oriented DX12.

I suppose there is a need for a Vulkan graphical engine, which could possibly support Metal as well. But the developers of OGRE say that Vulkan would be very little advantage to them, as they are using AZDO methods for OpenGL. But that confuses me. I though the whole point of Vulkan was to get low overhead that can't be achieved with OpenGL. So how could it be easier to do AZDO with OpenGL than to use Vulkan?

[indepe]

...
But the developers of OGRE say that Vulkan would be very little advantage to them, as they are using AZDO methods for OpenGL. But that confuses me. I though the whole point of Vulkan was to get low overhead that can't be achieved with OpenGL. So how could it be easier to do AZDO with OpenGL than to use Vulkan?

I'd expect they were using OpenGL historically and then focussed on AZDO methods. My understanding is that AZDO covers only a specific subset of OpenGL, so I'm not sure if that results in the same flexibility as with Vulkan.

In any case, the other "whole" point of Vulkan is to directly support multi-threaded use, something which AZDO methods do not. (And dispatching to a dedicated API thread comes at a cost of performance and architectural complication.)