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?

114 comments

  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 johnsnails · · Score: 1

      Sounds like UDP vs TCP. Shouldn't different parts of the app 'know' how they should be treated.

    5. Re:Speed v.s. reliability by TheRaven64 · · Score: 1

      In particular, the number of corners that you can cut varies a lot depending on how the game is using the GPU. Dropping all geometry calculations back to 16-bit floating point is completely fine in some cases but would cause horrible artefacts in others. Newer nVidia GPUs will correctly handle subnormal floating point values, but in most games the slowdown if you encounter one will be noticeable, but the visual effects of just rounding them to zero will not be.

      --
      I am TheRaven on Soylent News
    6. 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.'"
    7. Re:Speed v.s. reliability by Anonymous Coward · · Score: 1

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

      What? Letting the customer have control over a product they bought!
      Nope, that isn't the direction we are moving towards.

    8. 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."
    9. 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?

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

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

    12. Re:Speed v.s. reliability by Gravis+Zero · · Score: 1

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

      that word doesn't mean what you think it means.

      --
      Anons need not reply. Questions end with a question mark.
    13. 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!
    14. Re:Speed v.s. reliability by vakuona · · Score: 0

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

      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.

    15. Re:Speed v.s. reliability by K.+S.+Kyosuke · · Score: 1

      The Old New Thing blog discussed in the past how Windows treats different popular old programs differently simply based on the known bugs in those programs. Maybe this could be something similar?

      --
      Ezekiel 23:20
    16. 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
    17. 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.

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

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

    21. Re: Speed v.s. reliability by bill_mcgonigle · · Score: 1

      Right, and what if hl2 uses small, low quality textures but you can force the renderer to do that badly with another app through some driver tunables? Crap rendering but OMG FPS! Be careful what you measure.

      It would be nice if all the tunables were at least available as environment variables or in /sys so tuners could be happy regardless.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    22. Re:Speed v.s. reliability by myowntrueself · · Score: 1

      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.

      Linux is actually setting wallstreet's pants on fire:
      http://www.forbes.com/sites/qu...

      Theres not much Microsoft in there.

      --
      In the free world the media isn't government run; the government is media run.
    23. Re:Speed v.s. reliability by Bob+the+Super+Hamste · · Score: 1

      My one takeaway from that article is this question:
      Aren't all Gentoo builds custom?

      --
      Time to offend someone
    24. 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.
    25. Re:Speed v.s. reliability by binarylarry · · Score: 1

      So wheres the part about the linux desktop gaming market?

      --
      Mod me down, my New Earth Global Warmingist friends!
    26. Re:Speed v.s. reliability by Anonymous Coward · · Score: 0

      Because when I bought my most recent card, the price/performance sweet spot that I wanted favored AMD over Nvidia. Besides that, I still had memories of when Nvidia was in the news for some annoying business practices like forbidding retail sites to show their card prices in comparisons, and AMD was in one of its periodic upswings in open source support. I haven't found any reason to second-guess my purchase; the card has always done what I've wanted it to.

    27. Re:Speed v.s. reliability by myowntrueself · · Score: 1

      So wheres the part about the linux desktop gaming market?

      The desktop gaming market is pretty insignificant in the big picture and talking of Linux not 'setting wall street on fire because of lack of gaming market' is just dumb.

      --
      In the free world the media isn't government run; the government is media run.
    28. Re:Speed v.s. reliability by binarylarry · · Score: 0

      I wish I could stab you in the face, you fucking rube.

      --
      Mod me down, my New Earth Global Warmingist friends!
    29. Re:Speed v.s. reliability by myowntrueself · · Score: 1

      I wish I could stab you in the face, you fucking rube.

      I work in the game industry and I'm a Linux veteran from 1991. I use Windows on my desktop because I need to test games.

      If this is what you mean by 'rube'
      http://www.merriam-webster.com...

      I'm not getting it. Try stabbing your screen harder.

      --
      In the free world the media isn't government run; the government is media run.
    30. Re:Speed v.s. reliability by squiggleslash · · Score: 1

      Yeah, I bet AMD is really expecting to rake in the zillions for being known as "That graphics card maker that makes hardware that seems to handle all games really poorly except {hidden whitelist}."

      --
      You are not alone. This is not normal. None of this is normal.
    31. Re:Speed v.s. reliability by Anonymous Coward · · Score: 0

      This isn't as simple as you make it out to be... it isn't just reducing the bit-depth of the display or taking generic "shortcuts".
      Each application profile is specifically tuned and tweaked for the game it was designed for. An application profile for source engine could run worse than the generic one on some different games, and even introduce visual bugs or glitches.

      The easiest (and method with the lowest false-positives) way to detect which profile is to check the executable name.
      It isn't just a simple ON/OFF switch for "make game run fast".

    32. 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.
    33. 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."
    34. Re:Speed v.s. reliability by exomondo · · Score: 1

      The driver has a set of generic operations that it does when it comes to allocating memory and moving that memory around, this is something that can have a dramatic impact on performance yet the developer has no control over it. Developers often work with the GPU manufacturer's driver department to optimize the driver for their specific use case which is done on a per-application basis. This is part of the reason that drivers these days are so large.

      This is one thing that is improving as part of the DirectX12 and Vulkan (glNext)/Mantle efforts going forward, the responsibility for things like pinning memory blocks in fast cache and determining what is allowed to be moved and copied (or rather strongly hinting at it) falls to the developer rather than the driver's generic solution or application-specific optimizations made by the vendor in the driver itself.

    35. Re: Speed v.s. reliability by Anonymous Coward · · Score: 0

      It seems you have underestimated the power of human laziness, despite previous warnings.

  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. Cars by Anonymous Coward · · Score: 0

    I noticed the same thing, when I replaced "Windstar" with a horse on its hind legs.

  4. what happens when by Limitless_Potential · · Score: 1

    you change it to HL3?

    1. Re:what happens when by Anonymous Coward · · Score: 0

      you change it to HL3?

      gaben eats it

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

    3. Re:what happens when by Megaweapon · · Score: 1

      It's the same framerate at this:

      $ cat /dev/null

      --
      I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
    4. Re:what happens when by fuzzyfuzzyfungus · · Score: 2

      Unforeseen consequences.

  5. 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 Anonymous Coward · · Score: 0

      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?

      I do not play games, but I do not see the point of having the GPU rendering faster than the monitor's refresh rate, usually at 60FPS.
      Also, if you're going to play games in Linux, make sure you use a stacking window manager not a compositing window manager like compiz or Enlightenment. The overhead of a compositing WM manager will slow everything down b/c the WM has to intercept and redraw EVERYTHING on the screen.

    2. 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.
    3. Re:Confirmed by Anonymous Coward · · Score: 0

      Remember that frame rates are rarely static. They always fluctuate depending on the complexity of the current scene being rendered. The reason you want excessive frame rates is a better guarantee that the frame rate will never dip below the refresh rate in any given situation throughout the duration of the game. However, these people should be using Vsync.

    4. Re:Confirmed by Anonymous Coward · · Score: 0

      Can you elaborate? It sounds counter intuitive to me. I would assume that drawing unnecessary frames could instead result in GPU being unavailable when required or even lead to clock speed drop due to heat.
      I don't see how drawing more frames now can increase frame rate in the future.

      Yet games don't cap fps to monitors refresh rate, so I assume there is a reason for that.

    5. Re:Confirmed by Anonymous Coward · · Score: 0

      Not OP but curious, can you explain about input lag why would it help? My only guess would be that the input reading is taken on each frame. If that is the case, why code a game in such a way? Why not sample inputs more frequently, it would surely be less demanding on the system than asking it to render excessive frames?

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

    7. Re:Confirmed by Anonymous Coward · · Score: 0

      Because a single-threaded application that executes everything it needs to sequentially during a frame is a lot easier to code than one doing everything in separate threads and dealing with all the synchronization issues that entails.

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

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

  8. Heuristic Optimization? No, identifying executable by Anonymous Coward · · Score: 1

    "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

  9. Re:AMD doesn't have NVDIA's resources to throw aro by Kartu · · Score: 1

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

  10. Don't use profiles by Anonymous Coward · · Score: 0

    Optimize performance yourself.

  11. Why not have someone do it for you? by grimJester · · Score: 1

    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.

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

    2. Re:Why not have someone do it for you? by Anonymous Coward · · Score: 1

      As with all open source software, it only gets better.

      GNOME 3, KDE4, systemd, pulseaudio and a bunch of other software begs to differ.

  12. Or... by cirby · · Score: 1

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

    1. Re:Or... by jones_supa · · Score: 1

      Generally the application knows what kind of frames it has drawn successfully and can calculate its own frame rate based on that. But I guess you could cheat an external recording software. In the driver, just output 30 fps content with doubled frames and you get fake 60 fps.

    2. Re:Or... by drinkypoo · · Score: 1

      In the driver, just output 30 fps content with doubled frames and you get fake 60 fps.

      Someone would definitely notice something so blatant as that. You could instead do half-assed frames every other frame, doing a crappy skew instead of a proper render or something. That was the whole idea behind Microsoft Talisman... which failed not for technical reasons, but due to mismanagement. Mostly, the highly questionable decision to involve Cirrus Logic.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:Or... by Anonymous Coward · · Score: 0

      or not. It's just as it has always been, AMD (and NVidia) inspects the current AAA games, and tweaks/forces driver settings, and supplies select optimized shaders and other resources, to get higher frame-rates and better reviews.

  13. Is it just the length of the name by gurps_npc · · Score: 1

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

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

  16. 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 Anonymous Coward · · Score: 0

      it's hard to cover the corner cases. i agree. but that's not what's happening here. you're describing is blacklisting, what's happening is whitelisting. not the same.

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

      I don't see the difference. You can whitelist for optiizations that work for specific apps that don't work as well for others.

      Also consider this: By now, AMD engineers are fully aware of the fact that by doing blacklisting or whitelisting, people will interpret it negatively. They don't need the bad press over having done something inappropriate. So if they're doing it ANYWAY, either there's a solid financial reason, or there's a solid engineering reason. I haven't bought an AMD CPU in more than 10 years, and I have AMD GPUs by accident in laptops, so I'm not an AMD fanboi. However, knowing what I know about GPUs, GPU drivers, and what both Nvidia and AMD do, I'm going to go with "engineering reasons" on this one.

      Note: I designed a graphics accelerator that sits in every air traffic control display system around the US. I've also been an expert witness for patent lawsuits in both graphics and chip design. I can tell you from all angles, that the engineers care primarly about meeting their deadlines. They do things right and make mistakes on that basis. They also care about correctness over performance.

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

    4. Re:This is not some nefarious plot by Anonymous Coward · · Score: 0

      Similar underlying reason. They know how to do it quick and dirty, but too dirty to blanket affect all applications and they don't have a good way to detect if they need this weirdness.

      Say the case of that subpixel precision issue; you might need that for some scientific gpu data farm, but half life no one gives a shit.

  17. Re:Serious question by Megol · · Score: 1

    No.

  18. 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.
    1. Re:The explanation is simple by Anonymous Coward · · Score: 0

      Uh, what? There's no DirectX here...

    2. Re: The explanation is simple by Anonymous Coward · · Score: 0

      DirectX? Why is this modded up?

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

    4. Re:The explanation is simple by Khyber · · Score: 1

      Same principle applies. Jesus it's like you don't know how per-application driver settings work.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    5. Re: The explanation is simple by Khyber · · Score: 1

      Because the principle fucking applies the same way. Do you not know how per-application driver settings works?

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  19. Re:Heuristic Optimization? No, identifying executa by Megol · · Score: 1

    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.

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

  21. Re: Serious question by Anonymous Coward · · Score: 0

    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.

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

  23. egg or chicken by Anonymous Coward · · Score: 0

    Ideally the driver is first, and then you code for the driver.

  24. Reaction to bad design. by Anonymous Coward · · Score: 0

    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.

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

    1. Re:Not the first time for AMD by Anonymous Coward · · Score: 1

      I remember this! And my first thought was "not again".

      What I also remember clearly is the response from ATI. Not long after the quack3 fiasco, they asserted the next version of drivers would instead make general optimizations based on shaders (like an optimizing compiler), instead of hack based on process image names.

      As we now can determine, that was a lie.

    2. Re:Not the first time for AMD by Anonymous Coward · · Score: 0

      Not the first time they supply optimized shaders and resources for current AAA games in the driver download? You're right it's not, and it won't be the last time either, for both AMD and NVidia. Why do you think these driver downloads are hundreds of MB in size, when the actual drivers are only a handful MB of code?

    3. Re:Not the first time for AMD by Carewolf · · Score: 1

      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

      Of course not, it is standard industry practice at this point. NVidia does the same.

  26. Re:AMD doesn't have NVDIA's resources to throw aro by Anonymous Coward · · Score: 0

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

  27. Nope by slashmydots · · Score: 1

    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.

  28. Nothing unusual by Anonymous Coward · · Score: 0

    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.

    1. Re:Nothing unusual by cheesybagel · · Score: 1

      No the correct solution is to allow users to configure those aspects of the driver on a per app basis while shipping some pre done profiles for some applications.

    2. Re:Nothing unusual by Anonymous Coward · · Score: 0

      No the correct solution is to allow users to configure those aspects of the driver on a per app basis while shipping some pre done profiles for some applications.

      Ha-ha-ha-ha-ha.

      Seriously, you have no idea how silly that comment is. All that would do is ensure users screwed up their games in a multitude of different ways by enabling random options, and then blamed the video card manufacturer for their games sucking.

    3. Re:Nothing unusual by Anonymous Coward · · Score: 0

      No the correct solution is to allow users to configure those aspects of the driver on a per app basis while shipping some pre done profiles for some applications.

      The correct solution would be to educate the game company on how their code works poorly on your product, so you do not have to create custom hacks in your drivers.

    4. Re:Nothing unusual by Anonymous Coward · · Score: 0

      The correct solution would be to educate the game company on how their code works poorly on your product, so you do not have to create custom hacks in your drivers.

      In some cases, that might work. Valve, for example, will be supporting the Source engine for a long time, so they'd probably modify it to work better and push out a patch. In other cases, the development team has been broken up, and the code is in a hacked-together graphics library they outsourced to India.

      And, in either case, game reviews are complaining that your card is 50% slower than the competition, and you're losing sales. So you still need to push out the hack until the game is fixed.

  29. Re: AMD doesn't have NVDIA's resources to throw ar by Anonymous Coward · · Score: 0

    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.

  30. More that 60fps useful and hints? by Midnight+Thunder · · Score: 1

    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.
    1. Re:More that 60fps useful and hints? by Anonymous Coward · · Score: 0

      It's only useful as a guarantee that the game will play well. Remember that frame rates are rarely static. They always fluctuate depending on the complexity of the current scene being rendered. The higher the frame rate, the less chance the frame rate will drop below the refresh rate in any given situation throughout the duration of the game. During normal usage, Vsync should be enabled. Some idiots think that Vsync induces input lag, when in fact the real culprit is poorly designed code, bad drivers, or weak hardware.

    2. Re:More that 60fps useful and hints? by ChoGGi · · Score: 1

      On my system if I'm playing at 1920x1080 then it's fine and good for 60fps, but if I enable eyefinity and play at 5760x1080 then that 60fps isn't as likely to be around
      so faster is always better

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

  32. Ridiculous by SuperDre · · Score: 1

    it's ridiculous that drivers themselves aren't optimized and seem to be game-based optimized.. that's something that should stop..

  33. users of AMD should re-evaluate their purchasing d by Anonymous Coward · · Score: 0

    Nt

  34. ChaosEsque? by Anonymous Coward · · Score: 0

    Can you try this for ChaosEsque Anthology (Xonotic Fork)?

  35. Dear AMD... by buckfeta2014 · · Score: 0

    ... screw you. Give us back the old ATI.

    Sincerely,

    Everybody.

    --
    Buck Feta. You know what to do.
  36. No need. by Anonymous Coward · · Score: 0

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

    1. Re:No need. by Anonymous Coward · · Score: 0

      Yeah, it's not like AMD has been releasing specs and paying in-house developers to help out with the FOSS driver for nearly a decade now.

      Oh, wait.

  37. Better drivers by MoarSauce123 · · Score: 1

    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