AMD Catalyst Linux Driver Performs Wildly Different Based On Program's Name

An anonymous reader writes: In past years the AMD Catalyst Linux driver has yielded better performance if naming the executable "doom3.x86" or "compiz" (among other choices), but these days this application profile concept is made more absurd with more games coming to Linux but AMD not maintaining well their Linux application profile database. The latest example is by getting ~40% better performance by renaming Counter-Strike: Global Offensive on Linux. If renaming the "csgo_linux" binary to "hl2_linux" for Half-Life 2 within Steam, the frame-rates suddenly increase across the board, this is with the latest Catalyst 15.7 Linux driver while CS:GO has been on Linux for nearly one year. Should driver developers re-evaluate their optimization practices for Linux?

Comments

Speed v.s. reliability

[Z00L00K]

Speed increases may be sacrificing some reliability or cutting some corners. In a FPS game it may be worth it to reduce number of bits in the graphics to increase the frame rate in fast moving images but if you work on photo editing then you want precision rather than speed.

Maybe looking at the name of the executable was an easy way around that.

Re:Speed v.s. reliability

[i.r.id10t]

But then wouldn't it be better to let the end user choose whether something is optimized in a certain direction?

IE, if this can be done based on file name and looking up a profile from a list of Knows, would it be possible then to have an environment variable that if not set or set to "none" or whatever no in-driver corner cutting (ie, the game wasn't renamed), or if set to "FPS" do the speed thing at expense of precision, and if set to "photo" or whatever set to precision at cost of speed?

Re:Speed v.s. reliability

[jrumney]

So they have a whitelist to deal with this problem rather than an API call. The cynic in me wonders how much AMD charges to have your game listed on that whitelist.

Re:Speed v.s. reliability

[Z00L00K]

Don't underestimate the power of human laziness.

Re:Speed v.s. reliability

[Rockoon]

Speed increases may be sacrificing some reliability or cutting some corners.

Probably mostly corner cutting.

Don't need the 16x anisotropic shader if the texture isnt viewed from an extreme angle, or if the texture hasnt much high frequency detail, ...
Don't need the 16x antialiasing filter on edges of a polygon that connects seamlessly to another polygon, etc...

These two alone could be huge

Re:Speed v.s. reliability

[ckatko]

You mean like how in nVidia's control panel (and surely AMD has one) I already have per-application graphics settings for things like anti-aliasing, and negative LOD bias? Surely, if this was "laziness" they could have just used that existing infrastructure?

Re:Speed v.s. reliability

[Kjella]

Most of the time the information would be roughly as useful as a C compiler telling you what loops it will unroll. Game-specific optimizations basically means "take the whole rendering pipeline, make optimized shaders like ASM, reorder, parallelize, cut excess calculations, use conditional simplified algorithms and whatnot to achieve essentially the same output". It's not surprising that most of these tricks will work on a game built by the same engine, but it doesn't extend to the general case. So it wouldn't really be very useful, instead of "photo" or "fps" the profiles would basically be one per game.

I remember at some point the AMD open source developers said that they didn't have manpower to optimize for different workloads, so they were going with a simple structure using only one algorithm. They guesstimated that they could typically get 70% performance, simply because past a certain point making some things run better would make other things run worse. At the time they were more busy making it work at all though, but it might have been based on experience from Catalyst. Remember there's a pretty big gap between DirectX/OpenGL and actual hardware, at least before DX12/Vulkan/Mantle.

Re:First post

[JoeCommodore]

Too slow, you should have titled you first post Global Strike: Counter Offensive.

Confirmed

[Anonymous Coward]

Just tested on the game I develop, Warsow, and our latest version of Qfusion engine.

FPS jumped from 250 ~ to 300 ~ without a cap on the same location. WTF, AMD?

Re:what happens when

[Anonymous Coward]

you change it to HL3?

It gives an outdated error message stating that Duke Nukem Forever requires Perl 6.

Not the first time for AMD

[tepples]

This isn't even the first time AMD has done this. Back in the Quake III Arena days, renaming Quake3 to Quack3 would change its performance on a Radeon. Slashdot covered the Quack3 case

Re:However...

[Anonymous Coward]

I didn't notice any visible difference, or rendering errors.

Then again, our renderer is pretty ancient technology by many standards, although in some aspects at par with Doom3 / Source engine. All of these are based on the same-ish code (Quake1) originally and in many aspects OpenGL stuff is very similiar in all three, so I'm not surprised that optimizations carry over. I would expect Xonotic to get some boost too :)

Re:Why not have someone do it for you?

[jiriw]

Why? We're talking about Linux drivers here. Why not let the open source community write optimization profiles? Yes, you (AMD) have (has) to make some sort of interface and some documentation for it.
But the beauty is, now the community is selecting the best options for applications, doing their own testing which, with my limited knowledge, for AMD seems to be a very time and resource (paid testers) intensive process. Which is why it's lagging behind, for the Linux drivers, in the first place. Of course only software that's used by community members actually wanting to put time in creating these profiles, will eventually have good profiles. Like every other open source project. It will only improve if there are community members willing to put time/effort in it. And maybe, if you open up this process, game developers wanting their games to have a solid performance on AMD cards will write their own profiles.
Today nobody can optimize graphics performance beyond the usual resolution/AA/shader toggles on a per-application basis, except for a hand full of inside developers. And we know of some 'AAA' games coded so badly they are virtually unplayable without serious driver 'tweeks'. Why not give the open source community the possibility to optimize the games they think are worth it?

As with all open source software, it only gets better. Unless no-one cares. But then... who cares?

Re:The explanation is simple

[TyFoN]

The Source engine is using OpenGL on Linux and has absolutely nothing to do with DirectX