Windows 10 vs. Ubuntu Linux Gaming Performance With NVIDIA GeForce GTX 1060/1080

[indepe]

The fact that we just heard that Feral (still) intends to start using Vulkan with an upcoming port, surely settles a lot of points being discussed here.

[MVinhas]

Found this on the reddit thread about this post, someone might be interested.



From a quick look, it appears true. Their 1080p high benchmark ran a lot slower for the same graphics card despite using what I assume is probably a faster CPU(5960x vs 7700k)

The keyword there is "GTX970". The gap between Windows and Linux on Maxwell hardware is much more short.

[Jahimself]

The problem here, is that the bench is disadvantaging linux. 4k is not the resolution used by the majority. And on top of that MSAA always performs really bad on linux. You should have made one bench 4K without MSAA separated from other bench. One bench in 1080p on low settings without MSAA, one in high 1080p and one in ultra/high with MSAA. The only game where linux is faster than windows is metro last light, but SSAA is not activated, if you activate it, linux again will be behind windows. On low settings game tends to have perf really close with windows on feral interactive ports. We love feral because they bring a lot of port but generally their port have not great perf unlike the one from VP or Apsyr. Borderlands 2 was on same level as windows, Arma 3 is as fast as windows right now, bioshock infinite is as fast as on windows, Xcom 2 is allright, Dawn of War 2 is close to windows as well. I think Feral, VP and Aspyr should all work together. Obviously VP always have the best performances while feral has stability and aspyr some major titles. Looking forward to vulkan improvments.

[username4890]

spykes. The difference is less than 2 fps. Fot all we know it's because of the os swapping the game out and not the driver. I'm willing to bet if the same test were run a few times, linux would edge out sometimes too. It's really not worth being worried about.

[torsionbar28]

Yup, game developers are soooo going to throw away and rewrite their engines in Vulkan just to make all those Linux users (<1%) happy.

Because it's multiplatform yada yada and it will solve all the "problems" that Windows users never had in the first place. Only the ones on Linux.

And because of that "failure" Windows 10, installed on several hundred million comps at the moment.

It was pure unjustified baseless wishful thinking right from the start. Induced by Gabe Newell et al. When will this pipe dream stop? Seriously. Follow the white rabbit, guys.

Wow, angry much? A few years ago we didn't even have Steam, now look at the gaming ecosystem available on Linux. Thousands of games. These things don't happen over night. It was just a few years ago Microsoft had 90% web browser market share, now they have single digits. Change takes time, not everyone wants to be an early adopter.

[jnrivers]

I think it's very important to point out that all the ports tested are wrapper based ports, games written for D3D using a compatibility layer (example: eON). This is the reason they tank on Linux performance so it's kinda expected.

[smitty3268]

Why would a DX11->Vulkan port have the same issues, if a DX12->Vulkan port doesn't?

Because a DX11 game is going to be written in such a way that it's optimized for DX11 and the way that API works, which is different from Vulkan.

A DX12 game will be written in a way that's optimized for DX12 but the point to recognize there is that it's the same way that the Vulkan API works, so it should port over very simply.

A DX11 -> Vulkan port is indeed likely to be better than one going to OpenGL, just because it's a lower-level and more flexible API based around what the hardware can actually do, but for the same reason it's also likely a more expensive and time-consuming port to do correctly and I'm not sure the balance is going to work out that great for these AAA ports. Certainly it won't be nearly as good as a DX12 -> Vulkan port will be.

The threading model was just an example of how DX -> GL doesn't align nicely all the time. There are plenty of other ways that DX11 and GL or Vulkan don't match.

[indepe]

Because a DX11 game is going to be written in such a way that it's optimized for DX11 and the way that API works, which is different from Vulkan.

A DX12 game will be written in a way that's optimized for DX12 but the point to recognize there is that it's the same way that the Vulkan API works, so it should port over very simply.

A DX11 -> Vulkan port is indeed likely to be better than one going to OpenGL, just because it's a lower-level and more flexible API based around what the hardware can actually do, but for the same reason it's also likely a more expensive and time-consuming port to do correctly and I'm not sure the balance is going to work out that great for these AAA ports. Certainly it won't be nearly as good as a DX12 -> Vulkan port will be.

The threading model was just an example of how DX -> GL doesn't align nicely all the time. There are plenty of other ways that DX11 and GL or Vulkan don't match.

You might be right, but, in so far as I can tell, not for any reason that you have already given here. The fact that DX12 is more low-level, by itself, isn't likely to make it easier (though it could). In translating a higher level API to a lower level API, you usually have more flexibility (in my experience), than in translating a lower-level API to a different low-level API.

So far I haven't heard that DX12 and Vulkan are very alike. I'd guess I would have, if it were the case. I have only heard that they are both low-level. Perhaps you have such knowledge.

[indepe]

...and actually I was thinking more of the port's ability to resolve performance problems, than the ease of implementation.

[smitty3268]

So far I haven't heard that DX12 and Vulkan are very alike. I'd guess I would have, if it were the case. I have only heard that they are both low-level. Perhaps you have such knowledge.

They are. Both of them are based around the current hardware designs from AMD and NVidia, and what that hardware does. Both were driven initially by the Mantle API.

It's not that they're identical, but they both are reflections of current hardware rather than some higher-level abstraction layer like GL and D3D11 were.