Epic Games looking to make Vulkan the default API for Linux games in Unreal Engine

And we were beginning to wonder if Epic had forsaken EU4 on Linux. But does this mean that all the current OpenGL issues (thinking of ARK, et al) will never get fixed?

Nice vote of confidence towards Vulkan API support for Linux.

And we were beginning to wonder if Epic had forsaken EU4 on Linux. But does this mean that all the current OpenGL issues (thinking of ARK, et al) will never get fixed?

They still released Fortnite last week with only Win+Mac support. Do they have Metal support for that or is the OpenGL support actually good enough?

ARK devs already said that OpenGL won't be fixed and that they will switch to Vulkan for that. In ARK time of course.

Too bad they're not committing to Vulkan as the default on every platform that has support for it.

HLSL support means less work for porting games from DirectX?
https://youtu.be/bjE-sCkgC7o?t=8m1s

They would generate Vulkan shader language using HLSL thus decreasing time required for porting. Or I got it wrong :)

They still released Fortnite last week with only Win+Mac support. Do they have Metal support for that or is the OpenGL support actually good enough?

ARK devs already said that OpenGL won't be fixed and that they will switch to Vulkan for that. In ARK time of course.

That would be for Metal API, I don't know if there is an option to run openGL but I doubt it as they were building for Metal for more than a year.

HLSL support means less work for porting games from DirectX?
https://youtu.be/bjE-sCkgC7o?t=8m1s

They would generate Vulkan shader language using HLSL thus decreasing time required for porting. Or I got it wrong :)

They want a HLSL to SPIR-V compiler. IIRC, that is already being worked on by someone.

glslang actually currently can compile a lot of HLSL, at least modern one (D3D10 era and later), here is the github issue following the progress, and as I understand it, it is pretty usable right now and actually can compile a lot of DX shaders for Vulkan.

On the other hand, the work there does not focus on earlier D3D9 era HLSL, and cannot compile such old code. But the guy from VK9 (Vulkan implementation of D3D9 API) works on a D3D9 shaders → SPIR-V transpiler – but he tries to compile from binary (not HLSL code), as his aim is to run D3D9 binaries.

EDIT: and following a link from the comments of the glslang issue – it seems Microsoft also works on their own open-source HLSL → SPIR-V compiler. Interesting times we live in.


Last edited by silmeth on 3 August 2017 at 4:00 pm UTC

This is on their trello since the begin of the year, still waiting for the launch

They still released Fortnite last week with only Win+Mac support. Do they have Metal support for that or is the OpenGL support actually good enough?

ARK devs already said that OpenGL won't be fixed and that they will switch to Vulkan for that. In ARK time of course.

That would be for Metal API, I don't know if there is an option to run openGL but I doubt it as they were building for Metal for more than a year.

I dont know for sure but Metal is based on vulkan with some changes, wondering how much code change it would take for vulkan version for linux.

They still released Fortnite last week with only Win+Mac support. Do they have Metal support for that or is the OpenGL support actually good enough?

ARK devs already said that OpenGL won't be fixed and that they will switch to Vulkan for that. In ARK time of course.

That would be for Metal API, I don't know if there is an option to run openGL but I doubt it as they were building for Metal for more than a year.

I dont know for sure but Metal is based on vulkan with some changes, wondering how much code change it would take for vulkan version for linux.

Metal isn't based on Vulkan. The two are considered "low level" APIs, and will share a lot of similar features (and may even have a common ancestor in there somewhere), but Metal was released before Vulkan.

Interestingly enough, the talks have a section on "portable Vulkan", which has changed direction from the original intent of a common high level API (yet another one), and instead is the feature set common to basically DX12, Metal, and Vulkan, as seen from Vulkan itself. This kind of means you can write code in "portable Vulkan", and it will internally map (hopefully fairly directly) to Metal or DX12.
I personally want that project to take off, just because it would make writing portable code that much easier for everyone.

Interesting project hopefully it gains support a truly unified code with only minimal changes required per platform, would only improve Linux traction.

I wonder why they wouldn't make it the default on windows either. That will make not only their vulkan renderer more stable (more people get to test it), but also damage directx considerably, which is nice.

I wonder why they wouldn't make it the default on windows either. That will make not only their vulkan renderer more stable (more people get to test it), but also damage directx considerably, which is nice.

Politics - there are microsoft published titles using UE4 (and probably DX12) - by all means they'll make vulkan a windows option, but I'd bet these politics will keep it not the default

I wonder why they wouldn't make it the default on windows either. That will make not only their vulkan renderer more stable (more people get to test it), but also damage directx considerably, which is nice.

Defaulting to Vulkan on Windows at this stage would create unnecessary problems for Windows users.

And we were beginning to wonder if Epic had forsaken EU4 on Linux. But does this mean that all the current OpenGL issues (thinking of ARK, et al) will never get fixed?

They still released Fortnite last week with only Win+Mac support. Do they have Metal support for that or is the OpenGL support actually good enough?

Fortnite on Mac runs on Metal. Unreal Engine dropped support for OpenGL on Mac since UE 4.15 (February'2017).

Politics - there are microsoft published titles using UE4 (and probably DX12) - by all means they'll make vulkan a windows option, but I'd bet these politics will keep it not the default

Doesn't Tim Sweeney like to complain about MS? Going all way Vulkan sounds like an easy way to undermine some of MS hegemony.


Last edited by Shmerl on 4 August 2017 at 3:26 am UTC

Politics - there are microsoft published titles using UE4 (and probably DX12) - by all means they'll make vulkan a windows option, but I'd bet these politics will keep it not the default

Doesn't Tim Sweeney like to complain about MS? Going all way Vulkan sounds like an easy way to undermine some of MS hegemony.

He always complains, but actually they never took real action. They just hold the hammer above the heads.

HLSL support means less work for porting games from DirectX?
https://youtu.be/bjE-sCkgC7o?t=8m1s

They would generate Vulkan shader language using HLSL thus decreasing time required for porting. Or I got it wrong :)

I think it's not quite that easy. There are API differences in using HLSL for DirectX vs Vulkan, but work is ongoing to help with that. So "it depends on the code" is probably the best thing to say, but I think it would at least help. I don't really work with it that much; these are just areas I would expect to need special consideration.

Wouldn't expect to see anything from this being done by porters for at least 6 months, if not longer. Just in case anyone was wondering.

According to a guy from Oxide ( at GDC ) that contrasted D3D12 and Vulkan engines for Ashes of the Singularity, the only significant HLSL source difference to compile to SPIR-V is for binding resources. They just use a preprocessor to insert "register(foo)" for D3D12 or "layout(foo)" for Vulkan.

At the moment though, SPIR-V generated code lacks a lot of the optimisation it should have ( i.e. there is a lot more SPIR-V bytecode than D3D12 bytecode to implement the same feature ). This, along with lack of experience with Vulkan threading, probably contribute to lower than expected performance gains we have seen to date ( 10-15% better than D3D11 seems a common claim ). Elsewhere in the video linked in Liam's post, LunarG mention their work to perform SPIR-V to SPIR-V optimisation, which should benefit all shaders that target SPIR-V.

EDIT: and following a link from the comments of the glslang issue – it seems Microsoft also works on their own open-source HLSL → SPIR-V compiler. Interesting times we live in.

As I understand it Microsoft and Google are collaborating using LLVM to get HLSL -> SPIR-V. Microsoft work on the front-end compiler and Google the back-end. There is certainly a lot of maneuvering going on in the graphics world, so I'm sure they each have their own self-interest reasons to collaborate, but I am encouraged that Vulkan does not seem to be receiving outright hostility.

I wonder why they wouldn't make it the default on windows either. That will make not only their vulkan renderer more stable (more people get to test it), but also damage directx considerably, which is nice.

There are 3 reasons I can think of why developers will continue with D3D in the short term.

1. Vulkan ( and D3D12 actually ) are properly supported only on Windows 10, but not other Windows versions. Eventually Vulkan will have broad WIndows support, so it will be interesting to see if D3D12 then gets a magic backport to older Windows versions.

2. To support Microsoft consoles, developers need to use Microsoft technology, so they will need to understand the Microsoft ecosystem. I can see no real likelihood for Microsoft to support Vulkan on the XBox.

3. Vulkan is not as fast as D3D12. This should change as Vulkan drivers mature, and Vulkan/SPIR-V receive a similar degree of optimisation to D3D, but it's not there yet.


Although Vulkan adoption is not as extensive as some would like, I am encouraged by what I hear from game and engine developers. For example, Egosoft have just put a VR version of their most recent Space sandbox game into early access on Steam. Although this is only for Windows at present, they stated that the engine is a new build that uses Vulkan, not D3D, and that they intend to use this Vulkan engine for their next game. Egosoft is not a large company, so it suggests that moving to Vulkan as the primary ( or only ) render API is already perfectly practical if the benefits are there.