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?

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

    2. 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.'"
    3. 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?

    4. 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
    5. 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.
  2. 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.

  3. The explanation is simple by Khyber · · Score: 1, Interesting

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

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