The Khronos Group have announced a '3D Portability Initiative' to enable 3D applications that are portable across Vulkan, DX12 and Metal.
If this picks up some proper traction, it could be a really great solution for future Linux ports for developers to have to worry a little less about the graphics API involved.
From their page on it:
So at this stage, they don't have anything ready to show as it sounds like very early draft work on the design of the API itself. It does bring another problem though, which is the 'yet another API' issue. Sure, it sound fantastic, in theory. It could end up with its own set of issues, that's if it ever actually takes off.
What do you think to this?
Thanks for the email hidekin! Article taken from GamingOnLinux.com.
If this picks up some proper traction, it could be a really great solution for future Linux ports for developers to have to worry a little less about the graphics API involved.
From their page on it:
QuoteOne possible path forward to help resolve this dilemma is to define a portability solution that enables rendering code to be written and run, at close to full efficiency, over Vulkan®, DX12 and Metal-based systems. Such a solution would need to address differences between both rendering APIs and shading languages.
So at this stage, they don't have anything ready to show as it sounds like very early draft work on the design of the API itself. It does bring another problem though, which is the 'yet another API' issue. Sure, it sound fantastic, in theory. It could end up with its own set of issues, that's if it ever actually takes off.
What do you think to this?
Thanks for the email hidekin! Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
I don't really know what WebGL is capable of, but a big part of the initiative will be about shader-language conversion from HLSL (DirectX), GLSL (OpenGL), MSL (Metal) to Spir-V, which is the Vulkan shader language. If they'd only develop these converters, it would be a big help porting games to Vulkan.
Here's what Oxyde Games say in the Steam forum about Linux support (mid 2016):
"The remaining issue is HLSL to Vulkan. One of our partners is working on an HLSL shader converter. Once we have that, we should be able to release a Vulkan version soon after."
Here's what Oxyde Games say in the Steam forum about Linux support (mid 2016):
"The remaining issue is HLSL to Vulkan. One of our partners is working on an HLSL shader converter. Once we have that, we should be able to release a Vulkan version soon after."
3 Likes, Who?
Obligatory XKCD;
Obligatory XKCD;
truth to be told it's not really true. Opengl will go slowly into retirement as vulkan gains support.
Also I have only seen exactly 1 game using metal so far. So metal is barely out there.
2 Likes, Who?
Mountain Man 2 Mar 2017
Obligatory XKCD;It's worth noting that the phrase "competing standards" is, essentially, an oxymoron.
![
At any rate, improved portability between APIs can only be a good thing, so I'm in favor of it. Perhaps then we won't see cases like Civ 6 where it runs like butter on Windows but chugs on Linux.
2 Likes, Who?
[...]
At any rate, improved portability between APIs can only be a good thing, so I'm in favor of it. Perhaps then we won't see cases like Civ 6 where it runs like butter on Windows but chugs on Linux.
Your forgetting that we already have a cross platfrom 3d acceleration API, having an additional one will mean just as little as the previous one if people don't use it.
Worse still if the new standard wraps/jit compiles it's competitors that will make it slower and thus be seen as worse. Sure you can run Sports franchise 2019 on Linux thanks to 'shiny API v#++' but the performance is 10% lower than on windows - conclusion; 'shiny API v#++' sucks
0 Likes
Mountain Man 2 Mar 2017
As long as Microsoft exists, DirectX will exist, and Microsoft spends a lot of money to make sure it stays dominant, so for the foreseeable future, a lot of Linux games are going to be DirectX first and some other API second. Since developers are unlikely to abandon DirectX enmasse, the next best thing is improved portability.[...]Your forgetting that we already have a cross platfrom 3d acceleration API, having an additional one will mean just as little as the previous one if people don't use it.
At any rate, improved portability between APIs can only be a good thing, so I'm in favor of it. Perhaps then we won't see cases like Civ 6 where it runs like butter on Windows but chugs on Linux.
Worse still if the new standard wraps/jit compiles it's competitors that will make it slower and thus be seen as worse. Sure you can run Sports franchise 2019 on Linux thanks to 'shiny API v#++' but the performance is 10% lower than on windows - conclusion; 'shiny API v#++' sucks
0 Likes
I feel like it's a wrong solution for a wrong problem. It will only complicate things, building unnecessary abstraction layers that developers will have to target. Instead, MS, Apple and the rest of lock-in jerks should be pressured by developers to support Vulkan itself.
Last edited by Shmerl on 2 Mar 2017 at 5:18 pm UTC
Last edited by Shmerl on 2 Mar 2017 at 5:18 pm UTC
3 Likes, Who?
It's bad, because instead of pushing for real cross platform solution, it encourages lock-in jerks to keep using lock-in.
It's like instead of insisting to use HTML, someone would come up with truncated abstraction, above Flash, ActiveX and HTML proper.
Last edited by Shmerl on 2 Mar 2017 at 6:17 pm UTC
It's like instead of insisting to use HTML, someone would come up with truncated abstraction, above Flash, ActiveX and HTML proper.
Last edited by Shmerl on 2 Mar 2017 at 6:17 pm UTC
2 Likes, Who?
I don't like the idea. First, we'll have an extra layer that is only needed for political reasons, not technical reasons. Second, Microsoft and Apple will still try their best to undermine this new initiate just as they are trying to undermine Vulkan so we'll still eventually end up in the same situation. The solution to this mess is in the hands of game studios; if they don't want to target multiple APIs then they can simply target Vulkan and that will allow them to run their code on all platforms (MacOS and iOS can run Vulkan using MoltenVK).
1 Likes, Who?
If I understand that Khronos site correctly (no guarantees for that), they suggest to work out the common functionality of all three Next-Gen APIs (DX12, Metal and Vulkan), and then use an Abstraction-API plus Spir-V (Standard Portable Intermediate Representation, Vulkan) as an intermediate Language, with open source tools to convert back and forth, from and to any of the three APIs plus one extra target (WebGL-Next), which itself uses JavaScript and WebAssembly on top of a Web-Browser using the native API of the system it runs on.
IF that is really possible I'd see several consequences:
1. Almost automatic portability between APIs, except for certain features outside common functionality.
2. With Vulkan existing on Windows, the only real argument for developers to support DX12 is XBox Support, because XBox is too big a platform to be left out, but has no Vulkan support. With a working 3D Portability Solution developers could use Vulkan or the 3D-PS Language and easily port to DX12 just for XBox.
3. No problem to support Mac. Very few developers would use Metal directly. Most apps would just get converted to Metal.
4. In the long run I'd see a unification of APIs, in the form of 3D-PS (almost Vulkan), which is exactly what I would love to see, because its open, and because its exactly what those well-named lock-in jerks try to prevent from happening.
Then there ist this WebGL-Next thing, which would be built based on the 3D Portability Solution. To be honest: I don't know what WebGL is used for today, so I tend to ignore it.
If this all won't work out, I'd say: Shader language converters are useful!
IF that is really possible I'd see several consequences:
1. Almost automatic portability between APIs, except for certain features outside common functionality.
2. With Vulkan existing on Windows, the only real argument for developers to support DX12 is XBox Support, because XBox is too big a platform to be left out, but has no Vulkan support. With a working 3D Portability Solution developers could use Vulkan or the 3D-PS Language and easily port to DX12 just for XBox.
3. No problem to support Mac. Very few developers would use Metal directly. Most apps would just get converted to Metal.
4. In the long run I'd see a unification of APIs, in the form of 3D-PS (almost Vulkan), which is exactly what I would love to see, because its open, and because its exactly what those well-named lock-in jerks try to prevent from happening.
Then there ist this WebGL-Next thing, which would be built based on the 3D Portability Solution. To be honest: I don't know what WebGL is used for today, so I tend to ignore it.
If this all won't work out, I'd say: Shader language converters are useful!
0 Likes
It's bad, because instead of pushing for real cross platform solution, it encourages lock-in jerks to keep using lock-in.
It's like instead of insisting to use HTML, someone would come up with truncated abstraction, above Flash, ActiveX and HTML proper.
The issue is, that Vulkan is no real cross platform solution. You don't have it on Mac to my knowledge. You don't have it on iOS. You don't have it on XBox. You don't have it on PS4.
They have cross platform capabilities. Without the vendors distributing it... ye, it's not as cross platform as developers may want it to be. An in-code wrapper for your own product is what you may will want for that. It creates traction too for the performance loss and/or issues with the ports. If they open up the solution, and game (engine) developers using it, it can become a really great solution.
Sadly, the ideal world is far from reality. Best we can get out of this is ... all others see the issues we see now. Though, I expect ports from DX12/Vulkan/GNM to be much more straight forward than DX9/10/11 to OpenGL.
Last edited by STiAT on 3 Mar 2017 at 12:44 am UTC
0 Likes
I don't like the idea. First, we'll have an extra layer that is only needed for political reasons, not technical reasons. Second, Microsoft and Apple will still try their best to undermine this new initiate just as they are trying to undermine Vulkan so we'll still eventually end up in the same situation. The solution to this mess is in the hands of game studios; if they don't want to target multiple APIs then they can simply target Vulkan and that will allow them to run their code on all platforms (MacOS and iOS can run Vulkan using MoltenVK).
Not on XBox!
0 Likes
It's bad, because instead of pushing for real cross platform solution, it encourages lock-in jerks to keep using lock-in.
It's like instead of insisting to use HTML, someone would come up with truncated abstraction, above Flash, ActiveX and HTML proper.
The issue is, that Vulkan is no real cross platform solution. You don't have it on Mac to my knowledge. You don't have it on iOS. You don't have it on XBox. You don't have it on PS4.
They have cross platform capabilities. Without the vendors distributing it... ye, it's not as cross platform as developers may want it to be.
Sadly, the ideal world is far from reality.
Oh yes, technically it is cross platform, but then there is reality, as you say.. What keeps Vulkan from beeing true cross platform is Microsoft, Apple and Sony.
But on the Khronos page they say:
"Due to industry demand, Khronos is initiating the development of a solution to enable 3D applications that are portable across Vulkan, DX12 and Metal."
So it seems the whole 3D portability-thing is on the table because the industry wants to get past Microsofts and Apples behaviour. Sony operates in another sphere..
Last edited by on 3 Mar 2017 at 1:39 am UTC
0 Likes
So it seems the whole 3D portability-thing is on the table because the industry want's to get past Microsofts and Apples behaviour. Sony operates in another sphere..
Fair point, accepted. And I guess this is the only reason, because the game developers are sick of lock-ins and porting engines - game developers mostly are content creators, not engine developers. And Vulkan/Metal/DX12 are finally similar enough to do such porting layers with enough performance.
Last edited by STiAT on 3 Mar 2017 at 1:00 am UTC
0 Likes
I highly doubt they would create yet another API. After all, they just decided Vulkan is the best they could come up with.
The best thing they can do is to implement these:
- Tools to convert from any shading language to SPIR-V
- Translation layer from Vulkan to other APIs, such as dx, metal, sce (playstation).
In other words, you would end up coding in Vulkan as the universal API, and use the translation layer when not possible, for example on OSX, PS and XBox.
The best thing they can do is to implement these:
- Tools to convert from any shading language to SPIR-V
- Translation layer from Vulkan to other APIs, such as dx, metal, sce (playstation).
In other words, you would end up coding in Vulkan as the universal API, and use the translation layer when not possible, for example on OSX, PS and XBox.
0 Likes
[...]
They use the exclusive standards.
Why?
I have no fucking idea.
[...]
Because it's the safe logical progression DX12 might be 99% different to DX11, but being used to DX they will take that 1% familiarity over something the is 100% unknown.
0 Likes
In other words, you would end up coding in Vulkan as the universal API, and use the translation layer when not possible, for example on OSX, PS and XBox.
Yes, that's actually a good direction for now. And unlike MoltenVK that translation layer should be open.
0 Likes
[...]
They use the exclusive standards.
Why?
I have no fucking idea.
[...]
Because it's the safe logical progression DX12 might be 99% different to DX11, but being used to DX they will take that 1% familiarity over something the is 100% unknown.
From the viewpoint of a D3D developer, it's actually a lot better than that; Microsoft have a "merged" D3D11/D3D12 mode that gets you many of the benefits of D3D12 API while keeping most of the D3D11 calls the same. There is really no reason to change to Vulkan unless a developer wants to target additional platforms.
The reasoning behind this announcement/initiative is probably a pragmatic acknowledgement that the world will not become Vulkan overnight, and possibly not at all. For a general cross-platform application that wants to have some 3D capability, and for WebGL client implementations, having such a compatibility layer may help ( they are inviting input, so we don't know how such a layer would work ).
For games and other performance-sensitive applications, maybe it is not such a good idea, as there would probably not be as much opportunity to optimize with either a source-level code generator or binary-level translator.
As something of an aside, there seems to be an assumption by many people that adoption of Vulkan by developers is both an obvious step and a trivial task. For some developers one or both of these are true, but for many they are not.
What if you have a game or other application written in C++/COM on Windows, with all the appropriate development and content tools a practices? Are you going to adopt a new C API and development model for a few percent extra sales, or use the safe option of an updated familiar friend?
Vulkan is the "natural" 3D API for Android/Linux ARM devices and GNU/Linux x86 devices ( as well as potentially other Linux, BSD and SysV derivatives ), so anyone that has an interest in targeting these platforms, such as game engine developers, have been quick to adopt Vulkan. But I think it is the support in Android that is the more important driver for adoption than any support in Windows.
0 Likes
Patreon
PayPal
How to install GE-Proton on Steam Deck, SteamOS, Linux
An idiots guide to setting up Minecraft on Steam Deck / SteamOS with controller support
See more from me