Shadow of Mordor : Linux vs Windows Performance

[ekianjo]

I compiled the results of a few benchmarks done from a couple of different configurations - since Shadow of Mordor just came out on Linux a few days ago. 

Unfortunately the gap between Linux and Windows is pretty big

They should hire Notaz or PtitSeb to do better ports

http://boilingsteam.com/shadow-of-mordor-performance-tests/

 

[_wb_]

There is no inherent reason why the OS should matter (that) much for game performance. The only real thing that could make a difference is the way the kernel does scheduling (if it's not giving the resources to the game but to some background processes, there's of course a problem) and maybe DirectX vs OpenGL or something.

So this is not an inherent property of the OS, it is a property of the game code. If the code is not the same, then chances are that the performance will not be the same, and blaming it on the OS is a bit stupid.

How well does the Linux port run when compiled for Windows? I.e. using OpenGL instead of DirectX and whatever. Most likely it will perform more or less exactly the same as in Linux.

 

[ekianjo]

So this is not an inherent property of the OS, it is a property of the game code. If the code is not the same, then chances are that the performance will not be the same, and blaming it on the OS is a bit stupid.

 

I'm not blaming it on the OS. 

As I mentioned in the comments itself, the gap is probably coming from :

- OpenGL drivers being less efficient than DirectX drivers for the same hardware: there is less incentive to optimize them.

- OpenGL is not very good at dealing with multiple threads (that's what I heard. Not an expert here).

- Porters may not be capable of getting the most out of OpenGL (lack of experience ? lack of skills ?)

- Direct Manufacturer support: it's been known for a long time that nVidia and AMD work directly with high profile devs to ensure they get the most of of their GPUs - which means DirectX optimization.

 

[_wb_]

So this is not an inherent property of the OS, it is a property of the game code. If the code is not the same, then chances are that the performance will not be the same, and blaming it on the OS is a bit stupid.

 

I'm not blaming it on the OS. 

I know you don't, it's just that people might look at the title of this thread ("Linux vs Windows Performance") and get the impression that this tells something about the inherent quality of Linux vs Windows, while it really doesn't.

 

[notaz]

It most often boils down to Direct3D vs OpenGL. When the games have OpenGL mode available on Windows, switching to that also loses lots of performance.

Actually today's 3D tech sucks big time. Instead of defining the interface to access the GPU at hardware level, it's is defined by some software API. What I mean is that it could be done as CPU instead - there is a well defined instruction set that can be used by any program or any OS, it doesn't matter completely if it's Linux, Windows, BSD, MacOS or "hello world" program you just compiled, CPU just fetches the stream and executes it. To produce the stream, you can use free compiler, you can use commercial compiler or you can write it by hand in assembly or even with a hex editor.

With GPUs things are horrible, there is imaginary software API (actually many of them!), and there is vendor that supplies a broken driver that works on single OS with a single API (mostly) and nowhere else. And yes the driver is always broken, if you are a Windows PC gamer. what do you do when a new game comes out? Update your drivers. For every bigger game. It always means the same thing, that the game developers tried to do something new and hit a driver bug and needed vendors to fix their shit. And it has been like this for ages. In mobile world, where drivers are almost never updated after device comes out, things are a lot lot worse.

What could be done is that the GPUs accepted fixed standard command stream, just like CPUs do with their instruction sets. Vendors could supply binary blobs that would load directly into GPUs to be able to fix their bugs. The huge improvement here would be the loss of OS and driver dependence, and the lame imaginary graphics programming API like D3D or OpenGL. I do understand that different GPU vendors do things in different ways, but it is also true for CPU vendors (it's long known that x86 translates it's lame instruction set into internal uops before executing anything) and they can manage it just fine.

So that's why the 3D tech sucks. It's one of the reasons I can't make myself work on Pyra's 3D driver hacks. No matter what you do the 3D driver will always be broken, like it is on pandora.

 

[ekianjo]

SO that's why 3D tech sucks.

Do you think Vulkan is a step in the right direction ? 

 

[notaz]

Maybe, but it doesn't solve the main problem of having to rely on vendor to do a proper driver, which will never happen.