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?
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Too slow, you should have titled you first post Global Strike: Counter Offensive.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
I noticed the same thing, when I replaced "Windstar" with a horse on its hind legs.
you change it to HL3?
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?
Should driver developers re-evaluate their optimization practices for Linux?
Not necessarily. For example, replacing game shaders with optimized platform-specific ones can offer great performance increase with no tradeoffs. The GPU makers know their chip architecture inside out, but game developers usually target a higher level concept such as some shader language. Unless you develop for fixed hardware such as consoles, of course.
There's really two ways how you can relate to these kind of optimizations: "Hey, you're cheating!" or "Cool, thanks for help!". I personally are fine with them, but I would like to clearly know when specific optimizations are in use, and can turn them off when needed. Maybe after application startup the driver could render some popup in the frame buffer such as "AMD Catalyst(R) optimizations in use" which would fade out after a few seconds.
The STEAM store shows 504 pages of Windows games @ 25 per page = ~12,600 titles. OS X shows 173 pages @ 25 pages = ~4325 titles. Linux + SteamOS shows 99 pages @ 25 pages = 2475 titles but according to steamdb.info which has actual numbers for this category but not the other 2 there are 1,140 titles that work with 499 hinting at support.
This says nothing of sales numbers. Linux has gotten a big boost for gaming from Valve but it's still a distant 3rd and that's only in the PC gaming world and doesn't account for consoles at all.
I doubt AMD has the resources to dedicate to shit like this when they're consistently not the leader of anything. My speculation is that the only reason they still exist so to keep Intel/Nvidia out of monopoly court.
"The driver has to apply imperfect heuristics to guess what the game is doing, and the game in turn has to do peculiar things in order to trigger the right heuristics. Again, for the big games somebody sits down and matches the two manually."
Source: http://www.gamedev.net/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/#entry5215019
They are better than most people think. Figure how they got to power both Sony and Microsoft consoles.
Or how 290x beat Titan while costing several times more.
Sadly, that "oh, but they suck" attitude does hurt a lot. Try to find a notebook with IPS screen and AMD's Carrizo APU... =[
Optimize performance yourself.
You have professionals doing the tweaking now. Publishing a documented interface for you to do your own tweaking seems like a waste of money to both AMD and the game developer.
Maybe the system checks program names and then tells the program it's actually running faster, instead of, you know, actually running faster? Do the programs themselves time the rate, or do they just rely on driver calls?
"This is a really fast driver release!" "How can you tell?" "It says so."
Or maybe they're doing a "faster without drawing more" trick.
"Yeah, it's Half-Life 2. Just put in an occasional doubled frame. Nobody can tell the difference, right? They'll just think it's a headcrab effect."
Some idiot may be doing something funky with the name of the executable - taking up a String with an 250 max length vs a byte.
excitingthingstodo.blogspot.com
Give him some credit: you don't get -1 unless your post was at least locally offensive, if not globally.
I don't think you understood my point. My point is they're better off spending money making their Windows drivers/profiles better because that's where they have the most customers and since they don't have nearly the money, which you can see for yourself, they're better off spending it where they get the biggest return. As you pointed out that likely includes the consoles.
AMD and Nvidia are constantly dealing with bugs and pecularities in specific games and apps. I've seen examples where some unexpected or unusual drawing configuration made an Nvidia GPU totally make a mess on the screen. The solution, to achieve correctness, was to do something relatively slow. This kind of thing can be caused by hardware bugs. And it can be caused by hardware LIMITATIONS. For instance, say the hardware only has 8 bits of fractional precision and 16 bits of integer precision. It is possible for an app to try to draw something that runs into limits of those precisions, making two triangles not abut in the way that they should. This is commonly caused by having a triangle with a vertex WAY off the screen, so the software has to clip it, but clipping it requires subpixel precision that the hardware can't do.
Now, sure, some of these could be cases of "we could fix it properly, but it's just easier to select a slow rendering algorithm to get it right." And yes, if some company paid more, maybe they could get the proper solution sooner. But keep in mind that they're running into release cycle issues here. The driver is DONE, except for this list of 3 apps that don't work right. Do we spend an extra 3 months finding clever solutions? Or do we release right now something that benefits all other applications? The latter is more sensible. Those corner cases can be fixed in the next few releases.
In general, these problems are caused by applications doing something WEIRD. Not necessarily wrong, but definitely something unexpected that no other app does. And all the corner case apps do different weird things. Tracking it all down and making them ALL work both correctly and fast is HARD.
No.
HL2 and CS:GO are meant for different DX versions.
HL2 being originally DX 8.1 and CS:GO being DX9.
Switch to HL2.exe = DX8.1 mode, nuts insane framerate increase.
Rendering capabilities are pre-set by application name in the drivers.
There's your answer.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
So what does your post title and your quote have in common?
The quote is correct: the standard mechanism for optimizations of the extremely complex graphics driver is heuristical but there is a coarse grain mechanism that allows bypassing that. It is triggered by the executable name in most cases.
IFF a game not individually optimized in that manner have similar rendering patterns as a game that does renaming can help.
Probably not directly. To the degree that Microsoft has any specific plan to limit game adoption on non-Windows platforms it is called 'DirectX'. It is the first-class set of APIs on Windows and any games developed for it, or drivers developed to support it, are obviously resources dedicated to gaming being better on Windows and either unavailable or produced at additional cost for OpenGL elsewhere.
Once you get into how AMD's OpenGL driver does(or doesn't) apply application specific optimizations for different OpenGL games, though, MS doesn't have nearly as much to gain from any specific meddling. The general success of DirectX and Windows gaming is presumably the reason why AMD cares relatively little(along with the fact that people looking to use proprietary drivers on Linux usually go Nvidia, while AMD is regarded as very much the second choice unless you are looking for the vendor more cooperative with FOSS driver development).
Maybe it's just a case where Linux just isn't big enough for AMD to put many resources into the game profiles for Linux based OS's. You can at least on the windows side create your own profiles so is it possible on the Linux side? I don't blame AMD at all since there simply aren't enough Linux based gamers for them to spend much resources on. Tell Value to send some cash to AMD to help development of better support for Linux.
Are there any rendering mistakes or quality differences? Are there any issues with stability? Frame rate is not the only metric, it's just the only metric anyone can simply publish.
XML is like violence. If it doesn't solve the problem, use more.
Ideally the driver is first, and then you code for the driver.
Hate to say it, but the driver is part of a visualization delivery STACK and there is no way a downstack service should be aware of the upstack user. If it needs to, then there is a problem with the stack, not the driver. While the quickest, most practical solution for the device manufacturer is putting a hack in the driver, it is also the WORST way to go. But this isn't what boggles me.
What gets me are the comments here in Slashdot, where a staggering number of people simply say this wrong hack should be extended for their favorite game. No. What we should be doing is demanding that the stack be fixed so that this never occurs in the first place.
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
I guess there's good money in professional graphics on Linux. The hardware offerings for that are insanely overpriced and people do pay for them. But AMD seems to have sort of dropped the ball on that one. :(
You're right! They should waste their money hiring someone to test every single game extensively and raise the price of graphics cards to cover it.
I can't speak for Linux, but I worked on Windows video drivers many years ago. Lots of games did really freaking stupid things that crippled performance because the game developers had no clue about how video hardware worked, or assumed that every card worked the same as the 3dfx Super Fast Bastard card in their PC. So we'd have to detect that stupid behaviour and trigger special case code that did the same thing in a more efficient manner, or users would whine that our cards sucked because Call Of GTA 6 ran like crap.
Sometimes we'd have heuristic code which detected a game doing Really Freaking Stupid Thing #42 and swapped a function pointer somewhere to push it through a sane path in the driver. Other times we'd have to check the executable name at startup, and reconfigure the driver to work around it there (often by disabling driver functionality so the game decided to execute a different code path internally).
So, if changing the name of an executable makes it faster, odds are that executable is doing similar things to the one you renamed it to, and the video driver developers just haven't had any complaints from users that made them look at performance in that game.
The correct solution would be for game developers to get a clue and stop doing really freaking stupid things.
Yeah, like that's gonna happen.
Their GPUs might be decent (Catalyst is another story), but I wouldn't touch AMD for anything that runs on a battery. Intel is just too far ahead in power efficiency.
Stepping beyond the frame rate difference, why are we needing more that 60 fps for single view and 120 fps for steroscopic?
Back to AMD, do they provide any other method to hint at the sort of optimisation an application is needing, if it is a question of games vs non-games, for example?
Jumpstart the tartan drive.
Both AMD and nVidia have been doing this for years with their Windows drivers. Why? Because apps like 3DMark and games like CS, Quake are used to benchmark video cards by reviewers.
it's ridiculous that drivers themselves aren't optimized and seem to be game-based optimized.. that's something that should stop..
Nt
Can you try this for ChaosEsque Anthology (Xonotic Fork)?
... screw you. Give us back the old ATI.
Sincerely,
Everybody.
Buck Feta. You know what to do.
> Should driver developers re-evaluate their optimization practices for Linux?
No need.
I just will make sure to write down AMD's name, just like I decided to use just Nouveau since some time ago.
I hope someone does for them what Nouveau has done for Nvidia, for their own good...
Shows in general that hardware vendors still do not bother much to provide decent drivers or any at all for Linux. It all falls on the backs of clever developers who craft drivers that the manufacturer could have done better. As long as desktop computing and with that especially gaming is still mainly a Windows event not much will change. Chicken and egg problem... As far as laziness and bad decisions in software development go, they are plenty and all over the place. Such as referencing records in lookup tables by record ID rather than the given ID. Reseed the table and the program stops working. Or the choice of some to store bits not as bit field but as strings in text fields as "0" and "1" or "Y" and "N". Or relying on UI controls to be in a specific state when the dialog or page gets loaded rather than explicitly setting it. Or requesting records from a service and trusting that the first item returned is always the same field rather than explicitly requesting the records and values in the order needed. Or failing when a data folder is not present instead of creating that folder instead. I could go on for a long time, but it may just be that the comment field on /. allows for more characters to be entered than can be stored in the designated table column. I've come across all these issues plenty of times and I am sure I haven't seen it all or even be close.
So basing something on a volatile identifier such as a file name is not that out of the world. If as suggested the optimization is different based on the application there is not much else the driver developers could go by. There is no entry in a file header or object in memory that specifies that this or that app needs this or that optimization or is of this or that application type.
I would have designed it differently, start of with a known good and stable configuration for every app, then allow the enthusiast user to tweak settings that can be easily reverted back to default and that can be saved as a profile. When the app gets an update it might be necessary to have the user assign the saved profile again. Also provide an option to make a selected profile the default for all applications unless otherwise specified