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?

39 of 114 comments (clear)

  1. Speed v.s. reliability by Z00L00K · · Score: 5, Interesting

    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.
    1. Re:Speed v.s. reliability by i.r.id10t · · Score: 5, Insightful

      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
    2. Re:Speed v.s. reliability by jrumney · · Score: 5, Interesting

      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.

    3. Re:Speed v.s. reliability by Z00L00K · · Score: 5, Insightful

      Don't underestimate the power of human laziness.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    4. Re:Speed v.s. reliability by drinkypoo · · Score: 3, Interesting

      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.

      It won't work precisely like that. Instead, it'll be the influence of green privilege. Getting whitelisted will be easy for anyone who already spends a lot of money with AMD, and hard for everyone else... or anyone who spends a lot of money with nVidia.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    5. Re:Speed v.s. reliability by Rockoon · · Score: 4, Insightful

      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."
    6. Re:Speed v.s. reliability by ckatko · · Score: 4, Interesting

      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?

    7. Re:Speed v.s. reliability by fuzzyfuzzyfungus · · Score: 2

      I doubt that there is an actual price list. At least on the Windows side, releasing driver optimizations(sometimes including overt cheating if the popular benchmarking programs of the day are detected, though that seems to be rarer in recent years) to support popular programs and games is something that both Nvidia and ATI do reasonably routinely in order to improve their products' perceived competitiveness. You don't get a profile unless you have moved enough units to make it worth the effort, or there is a particularly embarrassing performance discrepancy; but the GPU vendors are sufficiently concerned about appearances that just stalling you is a poor choice. If anything, it appears to be that the GPU guys are the ones pushing for greater prominence in game, hence the obnoxious little videos that roll when you start some games and the Nvidia's enthusiasm for PhysX and related middleware being used.

      On Linux, it looks like AMD doesn't care very much(I assume that the Linux gaming numbers don't justify much engineering labor for specific titles; but if you have a 'Half-Life 2' optimization it wouldn't be terribly laborious to have the intern look up other Source-based games and add those to the list), but the same reasons for AMD's apathy would also discourage any one vendor from paying very much to get on 'the list'.

      That said, I have no reason to doubt that a vendor would outright refuse you if you demanded to pay your way onto the list(especially if you provided both cash and access to any information they needed about your application or from your developers); but unless it is actively all kinds of horribly broken without special optimizations, in which case you have a problem, simply selling enough copies makes supporting your application part of the job of selling GPUs. Since Intel is just waiting to scoop up everyone who doesn't care very much about graphics cards, neither vendor can really afford to withold optimizations and take a hammering in reputation just to squeeze a little protection money out of a publisher.

    8. Re:Speed v.s. reliability by Megol · · Score: 2

      As usual you are talking out of your ass. There are a lot of evidence of the reverse (Nvidia technologies and optimization support that artificially decrease AMD performance) but not that using AMD tech does the same for Nvidia. I'm not talking about simply missing optimizations here BTW.

      And we aren't talking about a whitelist, we are talking about drivers adjusting themselves using a coarse grained mechanism. The difference is obvious.

    9. Re:Speed v.s. reliability by binarylarry · · Score: 2

      How much are companies willing to pay to get into that hot, hot linux desktop gaming market?

      I say this joking as a Linux user who realizes the Linux market isn't exactly setting wallstreet's pants on fire.

      --
      Mod me down, my New Earth Global Warmingist friends!
    10. Re:Speed v.s. reliability by AmiMoJo · · Score: 2

      They don't usually reduce graphical quality unless absolutely necessary to get a reasonable frame rate. Most of the optimizations involve hand optimized shaders, or even just hints to the shader compiler built into the driver. Shaders are compiled to a high level bytecode a bit like Java, and then that is compiled into GPU native code, so there are opportunities for optimization.

      There can also be removal of checks that are confirmed not needed for a particular game, tweaks to GPU memory management code etc.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    11. Re:Speed v.s. reliability by pr0fessor · · Score: 2

      It depend on how you measure success, if it's by market share then that's just not accurate.

    12. Re:Speed v.s. reliability by Kjella · · Score: 4, Interesting

      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.

      --
      Live today, because you never know what tomorrow brings
    13. Re:Speed v.s. reliability by Anonymous Coward · · Score: 2, Insightful

      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.

    14. Re: Speed v.s. reliability by Anonymous Coward · · Score: 3, Insightful

      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

    15. Re:Speed v.s. reliability by khellendros1984 · · Score: 3, Interesting

      No, asking end-user to optimize their own software is the silliest thing I have ever heard. And people wonder why Apple is such a success and ${insert_random_OSS_company/software} isn't.

      The best of both worlds is somewhere in between. The vendor should provide optimizations for whatever they can, given time and budget, but they should also provide a mechanism for the user to tweak settings for non-vendor-optimized software. It's my perception that this is what both Nvidia and AMD do, through their respective control panels.

      The vendor that doesn't try to optimize anything on their own isn't going to look good enough in benchmarks to make any sales, but the vendor that doesn't allow the end-user to experiment with their own settings won't do well in the PC gaming market, where a lot of users like being able to experiment with settings to find the ones that they're happy with.

      --
      It is pitch black. You are likely to be eaten by a grue.
    16. Re: Speed v.s. reliability by theArtificial · · Score: 2

      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.

      AMD sabotages themselves more than anything with their drivers. It's not new.

      --
      Man blir trött av att gå och göra ingenting.
    17. Re: Speed v.s. reliability by Rockoon · · Score: 2

      It would be nice if all the tunables

      You seem to be under the impression that the stuff I mentioned are or could be "tunables" -- they are based on specific conditions of a specific rendering scenario, cannot be discerned at runtime without a performance hit, etc.. determined by extensive profiling and statistics gathering, not your imaginary "tunable parameters"

      It seems to me that you are quite far afield of your expertise to not know that determining if an edge of a polygon needs to be anti-aliased is something "tunable" - as if the end user is going to be presented with a list of several million polygon edges and enable and disable anti-aliasing on them individually..

      I wonder why you bothered opening your mouth at all

      --
      "His name was James Damore."
  2. Re:First post by JoeCommodore · · Score: 5, Funny

    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
  3. Confirmed by Anonymous Coward · · Score: 5, Informative

    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?

    1. Re:Confirmed by Narishma · · Score: 2

      There are monitors that render at higher than 60hz, Also, depending on how the game was coded, it can help with input latency to render at a higher framerate than the monitor supports.

      --
      Mada mada dane.
    2. Re:Confirmed by perpenso · · Score: 2

      ... I do not see the point of having the GPU rendering faster than the monitor's refresh rate, usually at 60FPS ...

      Note the game is under development. Those frame rates will probably not last as more code gets added to the game. Eventually new code will be getting discarded or optimized to get the frame rate up to 60fps.

      Also, it may be 300fps on a developer's system with the latest card/chipset AMD has to offer. If may be 60fps on the type of hardware consumers actually have.

  4. Good when used properly by jones_supa · · Score: 3, Interesting

    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.

    1. Re:Good when used properly by ckatko · · Score: 2

      > 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.

      That's the entire point. AMD is changing things without your knowledge and not publicly letting you use them for other programs. Imagine writing software and you discover that the filename of the game you're working on changes the performance AND introduces graphics glitches. Somehow the debug copy goes twice as fast. That's sketchy as hell for someone trying to write software.

    2. Re:Good when used properly by exomondo · · Score: 2

      This is a standard practice in the industry and has been for many years. Hand-optimized shaders are usually done in the development phase, the changes that are included in the driver are usually around optimizing memory allocation and management on a per-application basis rather than the generic solution that makes (often incorrect) assumptions about resource usage, something the application developer knows about but the driver developer does not. This is all changing in the next generation of graphics APIs that reduces the driver overhead by shifting the responsibility of resource maintenance to the application developer, it means less assumptions and more optimized performance without having to include application-specific optimizations in the driver package.

  5. AMD doesn't have NVDIA's resources to throw around by waspleg · · Score: 2

    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.

  6. Re:what happens when by Anonymous Coward · · Score: 4, Funny

    you change it to HL3?

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

  7. Re:First post by fuzzyfuzzyfungus · · Score: 2

    Give him some credit: you don't get -1 unless your post was at least locally offensive, if not globally.

  8. Re:AMD doesn't have NVDIA's resources to throw aro by waspleg · · Score: 2

    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.

  9. This is not some nefarious plot by Theovon · · Score: 3, Insightful

    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.

    1. Re:This is not some nefarious plot by mobby_6kl · · Score: 2

      I thought this stuff was common knowledge, and I just fucked around with OpenGl a little.

      Basically as you said in the initial post, the driver developers constantly need to write special cases for various games so that they work correctly and users don't whine on their forums. Either because the game developers are doing something crazy and/or stupid, or if they really encountered an edge case.

  10. Re:Serious question by fuzzyfuzzyfungus · · Score: 3, Interesting

    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).

  11. Re:what happens when by fuzzyfuzzyfungus · · Score: 2

    Unforeseen consequences.

  12. However... by Junta · · Score: 3, Insightful

    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.
    1. Re:However... by Anonymous Coward · · Score: 4, Interesting

      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 :)

  13. Not the first time for AMD by tepples · · Score: 4, Informative

    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

  14. Re:Why not have someone do it for you? by jiriw · · Score: 4, Insightful

    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?

  15. Re:The explanation is simple by TyFoN · · Score: 4, Informative

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

  16. Nothing new under the sun by Lisandro · · Score: 2

    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.