GameWorks vs GPUOpen: closed vs open does not work the way you think it does

I often read people claiming that GameWorks is unfair to AMD, because they don’t get access to the sourcecode, and therefore they cannot optimize for it. I cringe everytime I read this, because it is wrong on so many levels. So I decided to write a blog about it, to explain how it REALLY works.

The first obvious mistake is that although GPUOpen itself may be open source, the games that use it are not. What this means is that when a game decides to use an open source library, the code is basically ‘frozen in time’ as soon as they build the binaries, which you eventually install when you want to play the game. So even though you may have the source code for the effect framework, what are you going to do with it? You do not have the ability to modify the game code (eg DRM and/or anti-cheat will prevent you from doing this). So if the game happens to be unoptimized for a given GPU, there is nothing you can do about it, even if you do have the source.

The second obvious mistake is the assumption that you need the source code to see what an effect does. This is not the case, and in fact, in the old days, GPU vendors generally did not have access to the source code anyway (it might sound crazy, but in the old days, game developers actually developed games, as in, they developed the whole renderer and engine. Hardware suppliers supplied the hardware). These days, they have developer relations programs, and tend to work with developers more closely, which also involves getting access to source code in some cases (sometimes to the point where the GPU vendor actually does some/a lot of the hard work for them). But certainly not always (especially when the game is under the banner of the competing GPU vendor, such as Gaming Evolved or The Way It’s Meant To Be Played).

So, assuming you don’t get access to the source code, is there nothing you can do? Well no, on the contrary. In most cases, games and effect frameworks (even GameWorks) generally just perform standard Direct3D or OpenGL API calls. There are various game development tools available to analyze D3D or OpenGL code. For example, there is Visual Studio Graphics Diagnostics: https://msdn.microsoft.com/en-us/library/hh873207.aspx

Basically, every game developer already has the tools to study which API calls are made, which shaders are run, which textures and geometry are used, how long every call takes etc. Since AMD and nVidia develop these Direct3D and OpenGL drivers themselves, they can include even more debugging and analysis options into their driver, if they so choose.

So in short, it is basically quite trivial for a GPU vendor to analyze a game, find the bottlenecks, and then optimize the driver for a specific game or effect (you cannot modify the game, as stated, so you have to modify the driver, even if you would have the source code). The source code isn’t even very helpful with this, because you want to find the bottlenecks, and it’s much easier to just run the code through an analysis-tool than it is to study the code and try to deduce which parts of the code will be the biggest bottlenecks on your hardware.

The only time GPU vendors actually want/need access to the source code is when they want to make fundamental changes to how a game works, either to improve performance, or to fix some bug. But even then, they don’t literally need access to the source code, they need the developer to change the code for them and release a patch to their users. Sometimes this requires taking the developer by the hand through the source code, and making sure they change what needs to be changed.

So the next time you hear someone claiming that GameWorks is unfair because AMD can’t optimize for it, please tell them they’re wrong, and explain why.

 

This entry was posted in Direct3D, OpenGL, Software development, Software news and tagged , , , , , , , , , , , , . Bookmark the permalink.

21 Responses to GameWorks vs GPUOpen: closed vs open does not work the way you think it does

  1. dealwithit says:

    AMD don’t do well on tesselation. Let the whining commense:

  2. qwerty says:

    Good going man, insightful as always.

    “So the next time you hear someone claiming that GameWorks is unfair because AMD can’t optimize for it, please tell them they’re wrong, and explain why.”

    Y’know, explaining technical nuances to the average fanboy, specifically an AMD fanboy, is like trying to play checkers with a monkey – it is only a matter of time until he flips the board over, and starts flinging poop at you. :p

    • Scali says:

      Yea… AMD and nVidia are doing the same thing… AMD just packages it in a way that the average fanboy doesn’t catch on to it, apparently.

      Or actually, they’re not *quite* doing the same thing… nVidia actually gets stuff done, where AMD mostly talks about it. I wonder how things will go this time, with VR being the ‘hot new thing’. AMD has talked about how Polaris is ‘great for VR’… But they haven’t explained why. At the same time, nVidia didn’t just give us Pascal and a bunch of hollow marketing talk about VR. No, Pascal can actually do stereoscopic rendering in a single pass, to up to 16 different viewports with different projections, and they actually gave us some OpenGL extensions, some NVAPI calls for D3D, and some example code in VRWorks (wait, giving code, wasn’t that something to do with ‘Open’?).
      I really hope AMD has something technical for VR in store as well, and it’s not just “Oh, our GPU can’t do anything the previous generation couldn’t, but look, it’s cheaper!”

      • Thomas says:

        Cheaper is a good quality. Unfortunately I don’t see Polaris having an effect on VR space. They’re aiming Polaris for the minimum VR requirements of the *last* generation.

      • Scali says:

        Cheaper is a good quality.

        Yes, if you want to run your company into the ground. Look how well it’s working for them on the CPU side.
        If you don’t keep up with new features, and if you can’t match or exceed the efficiency of your competitor, in the end you’re always going to lose. Because it’s costing you more than your competitor to keep those prices low. You’re bleeding your company dry.

      • Thomas says:

        Sure, no argument here. There are many ways to “run your company into the ground”, including the opposite; being too expensive.

      • SilverInfinity says:

        It makes people feel good to stand on supposed ‘moral high ground’, even if it’s just an illusion. Open vs Closed, Big Guy vs Little Guy, David vs Goliath, etc.

        Hell, they’ll even go as far as to claim “I only buy AMD even if it doesn’t perform well, since I’m not sheep or had my soul devoured by the blue/green devil”. Then they complain that Intel isn’t moving fast enough for their liking.

  3. qwerty says:

    • Performance/$ is an important metric, especially for the average user. The problem for AMD has always been, that the average user also demands a product that does everything out-of-the-box with minimal hassle or any need for tweaking the driver settings. That is where Nvidia has always beaten them, perf/$ or not.

    • The 480s will be “made for VR”, just like the 390s were “made for 4K” – just a bunch of marketing porn that gets passed around at the “team red” circle-jerk.

    • Also, I think it is a bit ironic, how the AMD of the past used to mock Intel for “boasting about the GHz”, as the AMD of the present seems to be all about the GFLOP. 😀

    • Scali says:

      Performance/$ is an important metric, especially for the average user.

      Yes, but the advantage always goes to the vendor with the most efficient architecture. By the looks of it, Pascal is going to deliver better performance-per-watt/performance-per-transistor than Polaris. The result is that nVidia can get the same level of performance from a smaller/cheaper piece of silicon (and/or cheaper PCB, cooler etc, because there’s lower power draw, less heat to dissipate etc).
      So when it comes to putting a price on these parts (price is a completely arbitrary metric of course), nVidia can choose to price their products very aggressively, so that they get minimal profit on these parts (they can make up for it in the segments where AMD is not competing at all, such as the 1070/1080 and beyond). AMD then has no choice but to match or undercut nVidia’s price, but since their parts are more expensive to manufacture, that means they will have no profit at all.
      Which is pretty much what AMD has been doing on the CPU market for years now, and by the looks of it, since the launch of Maxwell, they are in that same position on the GPU-market as well.

      Given the pricedrops we’re currently seeing on the 970, it looks like NVidia had a healthy profit margin on these parts, simply because they could. There was no competition. They can now drop it to more aggressive pricing, and compete with Polaris until the 1050/1060 come around, which will probably deliver about the same performance at about the same price, but are cheaper to manufacture, so nVidia’s profits go back up in that segment. Making it ever more difficult for AMD to invest into their next generation (as we’ve already seen with their past few releases. A lot of rebadging, lack of innovation, lack of progress in terms of efficiency).

      Of course, MS and Sony are bleeding AMD dry on the console market as well. It looks like AMD wanted the console deals at all costs, literally. There just isn’t any money coming in.

    • Thomas says:

      “Of course, MS and Sony are bleeding AMD dry on the console market as well. It looks like AMD wanted the console deals at all costs, literally. There just isn’t any money coming in.”

      Can you elaborate on this? I’ve looked at AMD’s last few quarterly reports and their semi-custom segment haven’t had an operating loss. The semi-custom does include other items such as server/embedded processors, but I would guess game consoles still make up a large portion of it. To me it looks like semi-custom is doing a good job.

  4. Rebrandeon says:

    Polaris is FL12_0, what a joke AMD is, not even FL12_1.

    It’s not future proof at all and won’t run games that uses Conservative Rasterization, Rasterizer Ordered Views or Tiled Resources Tier 3.

  5. john says:

    The first obvious mistake is that although GPUOpen itself may be open source, the games that use it are not.

    WAT? is that even a way to start a rebutal?

  6. ATI nsider says:

    Nvidia’s GameWorks is a deliberate technique to try and gain a Monopoly in the Gaming Industry. GameWorks a Ripoff, Plain and Simple.

    • Scali says:

      I think you are giving nVidia too much credit here. Certainly, nVidia wants to give games added value on their hardware through GameWorks. But I doubt that nVidia actually believes that they would have the leverage to get a monopoly.
      Besides, most companies have similar initiatives, including Intel and AMD (Mantle being a prime example here).

  7. Yagamy Light says:

    > the code is basically ‘frozen in time’ as soon as they build the binaries

    This is untrue in general, unless I miss something. If I understand correctly, GPUOpen is just a lib shipped with games. So, if you’d really wanted, you could rebuild it, and replace the one shipped with game.

    More over, Steam actually does that: upon installing a game, if Steams finds in the system particular library (e.g. from repository), it won’t download it with the game.

    • Scali says:

      If I understand correctly, GPUOpen is just a lib shipped with games. So, if you’d really wanted, you could rebuild it, and replace the one shipped with game.

      I don’t know if that’s true (as far as I know, the code needs to integrate deep into your own engine. You can’t just ‘tack on’ effects with a library, they need to integrate deep into your pipeline, with your rendering algorithms, geometry and pixel formats etc. But perhaps there are special cases for well-known engines). But that’s not the point.
      Most games these days have protection against tampering with their files (both to protect from piracy and cheating).
      So even if you could build your own lib, the game wouldn’t accept anything other than the original file. The only way to replace the lib is if the developer issues it as an official update. Which they won’t do, because they used GPUOpen because AMD paid them to do so in the first place. That’s “Gaming Evolved”, exactly like “GameWorks”.

      More over, Steam actually does that: upon installing a game, if Steams finds in the system particular library (e.g. from repository), it won’t download it with the game.

      Only for generic libraries like DirectX or OpenAL. And even then usually the games still downloads and run the installers, the installers just don’t install older files. Libraries that are considered part of the game (as GPUOpen would be, as it’s tweaked specifically for each game), will be installed in the game directory.

Leave a comment