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!
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!
Some you may have missed, popular articles from the last month:
14 Likes, Who?
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?
Quoting: GuppyObligatory XKCD;
The statement is very vague so I do not know. Of course we do not want another standard, we just want vulkan to win here. It is that simple. But if the 3D Portability Initiative is just a name for projects like HLSL -> Spir-V these are obviously good projects that will help everyone. So I do not know if that obligatory XKCD is relevant. It depends what are their goals and the statement is unclear.
1 Likes, Who?
Quoting: lucinosQuoting: GuppyObligatory XKCD;
The statement is very vague so I do not know. Of course we do not want another standard, we just want vulkan to win here. It is that simple. But if the 3D Portability Initiative is just a name for projects like HLSL -> Spir-V these are obviously good projects that will help everyone. So I do not know if that obligatory XKCD is relevant. It depends what are their goals and the statement is unclear.
These conversions are only part of what they want to do. As you can read on the linked Khronos page they want to develop a WebGL Next API which would try to read DirectX- or Metal-, or Vulkan-Code and shading languages and convert it to WebGL Next. What this WebGL Next finaly will be, I don't know. I guess it can't be too far from Vulkan. At least it shares Spir-V with Vulkan. We'll see if they succeed with that, and how good it will be.
0 Likes
Quoting: GuppyObligatory 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?
Quoting: GuppyObligatory 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?
Quoting: Mountain Man[...]
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
Quoting: GuppyAs 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.Quoting: Mountain Man[...]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 March 2017 at 5:18 pm UTC
Last edited by Shmerl on 2 March 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 March 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 March 2017 at 6:17 pm UTC
2 Likes, Who?
See more from me