RADV Gets More Improvements For Mesa 17.1-dev, Lower Dota 2 CPU Usage

[phoronix]

Phoronix: RADV Gets More Improvements For Mesa 17.1-dev, Lower Dota 2 CPU Usage

While Mesa 17.0 was just released, new feature development continues building up for Mesa 17.1...

http://www.phoronix.com/scan.php?page=news_item&px=RADV-Discard-Useless-Cmd-Bufs

[Holograph]

Would it be correct to assume that this is an optimization that should be handled by games themselves and not drivers? Or does it really vary depending on which driver you use so that it's sort of out of the game's hands? (I'm not saying no to drivers optimizing games, but I really dislike it when games "require" driver optimizations in the first place.)

[Polarina]

Would it be correct to assume that this is an optimization that should be handled by games themselves and not drivers?

That is correct. The game is issuing redundant commands and this patch detects and discards those. This comes at a small performance cost to other applications that are better behaved.

[przemoli]

I think this code could be separated into new layer, so that it's shared by all drivers. Like really, really all of them. Vulkan have this idea built in.

[efikkan]

Would it be correct to assume that this is an optimization that should be handled by games themselves and not drivers? Or does it really vary depending on which driver you use so that it's sort of out of the game's hands? (I'm not saying no to drivers optimizing games, but I really dislike it when games "require" driver optimizations in the first place.)

Yes, you are correct.
Drivers should stop optimizing for specific games and specific mistakes made in games. All vendors do this to some degree, but the Mesa drivers seems to require a lot of this for every AAA game to get a half decent performance.

Even if this saves some CPU cycles by discarding the queue in the short run, adding more and more code to analyze the queue in real time will come with a performance cost eventually. In fact, these kinds of "optimizations" doesn't belong in a driver at all! A GPU driver should simply translate the API to the GPU's native machine code, nothing more.

[M@yeulC]

Yes, you are correct.
Drivers should stop optimizing for specific games and specific mistakes made in games. All vendors do this to some degree, but the Mesa drivers seems to require a lot of this for every AAA game to get a half decent performance.

Even if this saves some CPU cycles by discarding the queue in the short run, adding more and more code to analyze the queue in real time will come with a performance cost eventually. In fact, these kinds of "optimizations" doesn't belong in a driver at all! A GPU driver should simply translate the API to the GPU's native machine code, nothing more.

To be fair, I do not see this as a game-specific optimization, as it is rather generic. But yes, I get your point of view.
It's really a matter of philosophy, but following this path, we might end up not optimizing anything. It may be that some drivers require explicit flushes to work properly? If so, this workaround/optimization *must* be handled at the driver level, unless you want to start seeing games or applications that don't run on some hardware/software. And I don't think game/apps developers should focus their attention on supporting a myriad of different driver behaviors (that was on of the stated goals for Vulkan, IIRC).

[efikkan]

To be fair, I do not see this as a game-specific optimization, as it is rather generic. But yes, I get your point of view.
It's really a matter of philosophy, but following this path, we might end up not optimizing anything.

The philosophy is one thing, but it's not the main concern.
Let's say a driver creates a such workaround for a game, which analyzes the queue for some kind of pattern and optimizes it. Sounds great right? But no such process running in real time will be without a performance penalty, so even if it benefits certain games if we look at it isolated, the total number of such optimizations will eventually cost more than the gains.

Let's look at this hypothetical example:
* Game A: Optimize queue, cost 1.000 clocks, gain 40.000 clocks saved
* Game B: Optimize queue, cost 1.000 clocks, gain 40.000 clocks saved
...
* Game X: Optimize queue, cost 1.000 clocks, eliminate something redundant on GPU side.
...
After a while a driver might have 200 such optimizations. But by then, the total overhead of all the optimizations that doesn't apply would have reached to 200.000 clocks, way more than any game gained from a the few of them that applies to the game. This is why the driver never should optimize this at all, since eventually the cost of optimizing it will outweigh the gains by a large factor.

The same principle applies to other kinds of software as well. I've seen many pieces of software which "clever" developers fill up with workarounds and exceptions for edge cases until the code is dreadfully slow and totally unmaintainable, instead of fixing the real problem where it should be fixed.

[duby229]

No, in fact most of you guys are wrong. The reason game specific bug fixes don't belong in drivers is because game developers start relying on driver developers to fix their binary. Nip that reliance in the bud right now by making damn certain game developers -HAVE- to fix their own bugs. If app A works and app B doesn't work, guess which app will be the one that gets bought the most?

My opinion is simple, if the developer releases a quality game and it works he'll get paid for it and continue releasing quality games that work, and if he doesn't then he sells nothing and goes out of business which is good for the whole industry.

[andrei_me]

This is a quite generic optimization, is like doing nothing when you try to concatenate an empty string to an existing string, like an assertion

[starshipeleven]

This is why the driver never should optimize this at all, since eventually the cost of optimizing it will outweigh the gains by a large factor.

You make so much baseless assumptions that it looks like you are just trying to push your conclusions.