GRVK Allows AMD's Deprecated Mantle API To Run Atop Vulkan

[sebastianlacuesta]

Wow, nice! Looks like it's available for Windows only though. Would be cool if they opened up, supported Vulkan 1.2 and worked on Linux

Works great in Wine. I don't remember any linux glide program not ported to OpenGL though.

[CochainComplex]

Zink is an OpenGL to Vulkan translation layer (just like how DXVK is a DirectX to Vulkan layer).

Vallium is a software renderer for Vulkan (similar to Kazan), just like llvmpipe is a software renderer for OpenGL.

GRVK is a Mantle to Vulkan translation layer.

Examples:

OpenGL -> Zink -> Vulkan
Mantle -> GRVK -> Vulkan
DirectX -> DXVK -> Vulkan
Vulkan -> MoltenVK -> Metal

Vulkan -> Mesa Vallium driver -> CPU -> Output
Vulkan -> Mesa RADV driver -> AMD GPU -> Output

DirectX -> DXVK -> Vulkan -> Mesa Vallium driver -> CPU -> Output

...I hope dx will die .... that daisychaining is eating all the cpu overhead savings which we originally have gained by the new API's

[Alexmitter]

can rival Adobe AIR

Adobe Air is the toolkit used for all the Adobe creative suite stuff, it also runs on Linux as https://flathub.org/apps/details/com.adobe.Flash-Player-Projector demonstrates.
Its not a good toolkit tho, its on Qt level.

and Microsoft Silverlight in uselessness

dotnet core was born out of the platform independent CLR implementation of silverlight, so it became quite useful after all.

[JMB9]

AFAIK Adobe AIR is working on Flash and extending it with a runtime system - so flash runs on the Flash Player but AIR needs a big bloated environment which was no longer supported on Linux in 2012 - marking the soon death. As Adobe put the plug from Adobe Reader for Linux and is not present on Linux in any way ... and this is a good thing for Linux.
I am quite amused that Adobe InDesign is extremely expensive and its documents are worse than what one can build up easily with TeX/LaTeX (not to mention what you can do with this professional tooling if you know what you are doing with TeX) - but of cause much better than Word or LibreOffice where every formula looks strange/ugly. But most people can not even see that big difference - as one gets accustomed to bad type settings.

But back to the point - Linux gaming and conversation layers.
Vulkan should be more suited as being nearer to the HW, i.e. not wasting too much energy on heating but being very fast.
It is stupid to use any additional layer if not necessary - you may get things to work, but I don't want to use Wine or any other translation layer due to efficiency.
It is more code, more wasted cycles and much more bugs (this argument is well known to say that Wayland/Weston is superior to X, which is in that case not that simple as it seems) - and today mentioning security would be totally silly, as we don't come near a secure environment.
So it is a nice project to mention - but using it would mean to use an inferior solution and wasting energy.

We need more efficient HW (AMD and competitors are working on it - and I hope they will deliver) - we need a thin layer to use it wise (which may be Vulkan) and the game engines like Godot, Irrlicht [two examples for free ones], Unreal_Engine or Unity [two example for proprietary ones] should make good use of it.
And this means we cannot afford too much shared code (this can never be efficient - especially as Windows never used much of the HW features - which is also very well known) and especially no additional layering - we do have a global energy problem and all should be aware of that.

So this is a learning tool and PoC, but NOT for real life to let games run.
If SW is consisting of so badly written code (or similar quality proprietary libs) that it can not be provided as 64 bit right now, it is dead.
Flash is deprecated and will stop any support end of 2020 - THIS YEAR. And still you see fresh games using AIR in 2020 like 32 bit code released in 2020.
It would be better to be aware of dead/legacy code and help developers making good choices by not buying such programs - if it should run under Linux one should use Linux ports and not Wine. If you need to - OK, but this is not a real solution - and this should be clear for all.
Reading that a port crashes and thus using the Windows version under Wine as solution is not understanding the technical part.
A real Linux port must be faster as the Windows version - or it is no Linux port at all. It is impressive what OSE [Open-Source Engines] provide for games more than 10 years old (even when the proprietary engine is still worked on) - concerning quality, speed - efficiency.

We should admire good code - not inefficient crap. So playing with layers may only be useful for a transition phase.
And looking at the 32 bit dump shows that compatibility is only good for less than 5 years - and should be abandoned thereafter.
Thus the layer for 3dfx is a mere learning project. It does not make any sense for gaming today.
Giving that impression is not a wise thing ... looking at it may though - as we can learn from that.

[baka0815]

And Mantle being the basis for Vulkan. Nice.

Isn't Vulkan like Mantle+? I thought AMD donated Mantle as a basis for Vulkan so it should be nearly identical?!

[Danny3]

It would be nice if all these projects would take the DXVK lead with naming and be renamed to:
OGVK for OpenGL to Vulkan
MAVK / MTVK for Mantle to Vulkan

The Zink and GRVK are just too confusing.

[V1tol]

Not open at all, but at least exists: Nglide

http://dege.freeweb.hu/ Used dgVoodoo 2 for some time (it uses DX11). Also seems to be working in Wine quite good.

Beware: Google Safebrowsing alerts on this site so it's up to you whether to open it or not.

[CochainComplex]

It would be nice if all these projects would take the DXVk lead with naming and be renamed to:
OGVK for OpenGL to Vulkan
MAVK / MTVK for Mantle to Vulkan

The Zink and GRVK are just too confusing.

for the full confusion we have vkd3d ...

dxvk sugests dx -> vk ...but vkd3d has a fliped direction vk <- d3d

[Danny3]

for the full confusion we have vkd3d ...

dxvk sugests dx -> vk ...but vkd3d has a fliped direction vk <- d3d

Yep, you're right, that's even more confusing.

[libcg_]

Isn't Vulkan like Mantle+? I thought AMD donated Mantle as a basis for Vulkan so it should be nearly identical?!

Vulkan is similar, but not identical. For example the descriptor binding system is completely different. Mantle has more dynamic state than Vulkan, although most of it is covered by `VK_EXT_extended_dynamic_state` which is a hard requirement of GRVK. The shaders are AMDIL bytecode which looks quite similar to DXBC.