Slashdot Mirror
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?
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?
Don't blame me, I voted for Kodos
Don't underestimate the power of human laziness.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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
"His name was James Damore."
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.
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.
No.
The things being optimized are things that you as the user will never see. Things like writing to the depth/stencil buffers despite never using the value, not disabling unused sections of the OpenGL pipeline, and in shader land, better optimized compilation of shader programs.
The reason these optimizations are done by amd/nvidia is because people use these games to benchmark their products. "You're getting a crappy framerate because EA wrote a crappy renderer" is not an excuse you, as a customer, are going to willingly entertain. That means that any sufficiently popular game will get the once over from the driver guys to see if there's an performance to be squeezed out to give them a leg up on their rival.
As a result, a large portion of the front end code of their drivers is game specific hacks to make things run faster. It's why open source drivers, which generally follow instructions and do what they're told, are generally slower than their amd/nvidia counterparts.
Nvidia gameworks most certainly breaks games on AMD hardware on purpose and developers make money for using it AND nvidia sends people to implement it so of course a dev will use it.
Nvidia claims they do not pay companies to use gameworks and that's true they don't...but they DO pay to insert that little nvidia banner in the games intro and sometimes in game ads like project cars and its million nvidia trackside banners.
So they look like they are giving gameworks away for free and devs just use it cause its awesome but in reality devs use it because nvidia is paying them too.
AMD spends more time fixing nvidia sabotage than anything else. If nvidia would actually fight fair they likely wouldn't stand a damn chance. Hell nvidia became #1 by cheating benchmarks...how quickly everyone forgets. They cheated major benchmarks for YEARS before finally being caught but damage done they were already considered performance king and #1 in sales even if in reality games were running better on ati/AMD hardware
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?