Quoting: HihiDanniThanks for the read. Guess I should try to read the full thread next time.

No worries! Sometimes it's very easy to miss the odd comment. :-)

View this comment - View article - View full comments

Quoting: HihiDanniThe per-game driver optimizations on Windows aren't anything you'll find in the driver settings - those are completely different. These optimizations are on a lower level and hidden from the user. They're designed to work better with each game's misuse of 3D APIs. This is a big reason behind the push for Vulkan and similar APIs, as the driver developers don't have to spend as much time working around bugs in games because the games themselves have to use the API correctly.

In reality it's really not as simple as using the old "misusing APIs" meme and saying that's the only reason for game ready drivers. :-) I explained a little about some of the factors here:

https://www.gamingonlinux.com/articles/nvidia-38122-driver-released-with-lots-of-bug-fixes-and-newer-vulkan-support.9631/page=3#r92884

View this comment - View article - View full comments

Quoting: Eike

Quoting: DMGGame support said that it is driver fault and I need to wait till they optimize it. And how can I know, is it driver fault or game developer?

Most times, you just can't...

Well Said, even though some people post like they are sure of who's to blame unless you're in the developer (game/driver) it's usually pretty hard to tell especially with more subtle bugs.

Sometimes you can work it out but it's rarely obvious. In fact sometimes even as a developer it can take a good few days / weeks to work it out as it can end up being a bit of both :)

View this comment - View article - View full comments

Quoting: spiffyk

Quoting: GuestBut where are our ****ing performance optimizations for specific games?

You mean where are the workarounds introduced to make up for a game abusing the API? To hell with that.

It's more complicated than that in reality :) Your example is one thing that can happen in certain cases :( however you can also easily get the same effect for a number of other reasons.

The most likely on Linux is if a game is using newer implemented features that are not optimised fully in the drivers. Every new game can have the potential to use an API in a completely legal way but also hit an unexpected inefficiency in the drivers for certain specific hardware as real life usage rarely matches benchmark sample code. Life Is Strange on the NV10x0 series for example had a massive performance boost due to the game uncovering a use case that wasn't covered for that hardware when the game launched.

That means the end user might get a driver update that looks like performance optimisations for specific games when it's actually optimising the drivers and this impacts a popular game that uses that area of the drivers or API. Usually the issue in the driver might even have been highlighted by that game.

The Open Source Mesa drivers are littered with examples of this in the past 2 years. You can pick almost any game shipped within the last couple of years and benchmark the speed with 2 year old drivers and again now and you'll likely see huge boosts none of which are workarounds due to API abuse. As more games came to Linux and more Mesa developers had real life examples it allows them to optimised the drivers more as well as the more reported new features.

The second reason is linked to various API, hardware and game engine design choices. When optimising and designing a game you can have multiple ways of doing things that *should* all run fast but sometimes due to how drivers might work or how the underlying silicon of a specific card designed means they won't run as fast as expected.

This means you can end up with two (or more) different ways of optimising the same call in a graphics driver depending on how it's used and neither usage is wrong. If different games use these different philosophies then to get the best performance in the drivers then the driver might need to analyse how the API is being used and then use the optimal path for that use case. Given the large differences between GPU ranges and the larger difference between vendors you can end up with these compromises. A "game ready" driver in most cases is just a driver that is pre-loaded with information on the best decisions to make if it hits one of these use cases. Usually the driver tries to be smart and do this at run time but that is not always possible.

That is not to say drivers haven't had some very specific game changes that should be avoided but I thought a little more detail might be interesting to readers as the common "abusing the API" meme isn't really telling the entire story or the reasons why things like game specific drivers can exist and how the line between optimisation and game specific drivers can easily get blurred when you have extremely complex systems and sometimes ambiguous API definitions.

View this comment - View article - View full comments

Quoting: EgonautBut instead of trying to get the max FPS more upwards, maybe Feral could try to get the load more balanced on threads, if possible. If I could have stable 60 FPS I would be more happy as with 100+FPS and drops below 60 :)

The entire point is to have a more stable fps not a higher peak number as that by itself isn't that useful :) If you notice the bigger gains on Vulkan compared to GL are all on the minimum and average fps especially in the poorer performing areas, the peak fps in the best performing areas isn't that much slower on GL. This allows for a much better overall experience :)

The game engine is fairly threaded however some things can't be done at the same time and have to be serialised especially if that is how the engine works on all platforms.

Finally your CPU usage checks will be a little SKU'd as we need to spin the main thread when waiting on the GPU to avoid issues where the governor would reduce clock speed causing frame rate pulsing. Serious Sam for example is also effected by the governor being too keen to down-clock your CPU while playing.

Do send in your reproduction steps though as it does sound like you have an issue most people never experience.

View this comment - View article - View full comments

Quoting: Ehvis

Quoting: OlliCI was wondering why there was still one core with 100% on Vulkan. That explains it.

Probably because Mad Max in itself is not a game well optimised for using all cores. Vulkan can reduce the port overhead, it cannot make a game better.

OlliC was talking about the workaround we had to add to the game to avoid issues with the governor on Linux when using Vulkan. Liam mentioned it in the article. We spin the main thread when waiting on the GPU to avoid the governor power saving and causing stalls and pulse/stutters. This is similar to the issue that Serious Sam has.

Mad Max is multithreaded as an engine and the Linux version has a similar thread behaviour to the other platforms as it uses the same base engine code.

View this comment - View article - View full comments

Quoting: MohandevirThanks for your insight.

Still the Mad Max experience seem to demonstrate that lower end cpu gains a lot more from Vulkan than i7 cpus. I'm not saying that i3s are going to dethrone i5 or i7. I just think that it will make them valuable entry gaming rigs when it was nearly unplayable not log ago.

It'll certainly help for quite a few games.

Quoting: MohandevirAlso, I have in mind the i3-7320 or i3-7350k and futur iterations with High clock frequencies.

But I'm probably wrong.

We'll see :) I'm just guessing too. Check back in a year and you can tell me if you were right :D

View this comment - View article - View full comments

Quoting: Mohandevir

Quoting: edddeduck_feral

Quoting: MohandevirWe will see a new generation of i3 gaming rigs thus lowering the costs and giving better competition to traditional consoles

Or (more likely?) developers will think we have all these unused CPU cycles now lets push up the complexity some more make use of them! ;) History shows is you have spare cycles people don't make lower powered devices they make more complex games :)

For sure, but isn't it going to be handled by the gpu?

If you have lots of free resources you can always find something for them to do. I also guess the point is games don't ever go backwards in terms of resource demands only forwards. Finally i3 CPUs are already underpowered for certain games (even with Vulkan) so I can't see low powered CPUs suddenly playing high end games at high settings. It will make certain games with certain limitations more playable but it won't suddenly change everything and make an i3 a gaming CPU. The lack of cores for one is a big factor on i3 CPUs.

View this comment - View article - View full comments

Quoting: MohandevirWe will see a new generation of i3 gaming rigs thus lowering the costs and giving better competition to traditional consoles

Or (more likely?) developers will think we have all these unused CPU cycles now, lets increase the complexity and make use of them! ;) History shows if you have spare cycles people don't make lower powered devices they make more complex games :)

View this comment - View article - View full comments

Quoting: psycho_driverI really hope this work is back-ported to Shadow of Mordor since it uses roughly the same engine.

The engines are completely unrelated custom engines written by two seperate developers. They are not as related as XCOM and XCOM 2 for example.

View this comment - View article - View full comments