GameWorks FAQ: AMD, Nvidia, and game developers weigh in on the GameWorks controversy

Last week, Forbes published an explosive story claiming that Nvidia had used GameWorks to cripple AMD's performance in the new Ubisoft game Watch Dogs. This kicked off a series of events, including our own inability to duplicate similar results and a lengthy conversation with the senior vice president of Nvidia's content and technology division, Tony Tamasi. Rather than rely solely on these conversations and perpetuate the he-said-she-said nature of the AMD-Nvidia discussion, we decided to take the questions AMD has raised about GameWorks and Nvidia's counterpoints directly to developers themselves.

We sent out a number of requests for comment and insight to some of the most well-known project heads in the gaming business. Most respondents were only willing to speak off the record, but there were two exceptions: Tim Sweeney(Opens in a new window), the founder of Epic Games, and Richard Geldreich(Opens in a new window), a longtime OpenGL developer at Valve (semi-retired as of last week).

The GameWorks discussion has raised many questions about the nature of how game developers and IHV's (Integrated Hardware Vendors, aka GPU manufacturers) collaborate, whether or not source code is important to that process, whether Mantle and GameWorks should be seen as equivalents, why Nvidia developed GameWorks, and whether GameWorks is a threat to AMD at all.

Do AMD and Nvidia need access to developer source code?

The first thing to understand about IHV - developer relations is that the process of game optimization is nuanced and complex. The reason AMD and Nvidia are taking different positions on this topic isn't because one of them is lying, it's because AMD genuinely tends to focus more on helping developers optimize their own engines, while Nvidia puts more effort into performing tasks in-driver. This is a difference of degree -- AMD absolutely can perform its own driver-side optimization and Nvidia's Tony Tamasi acknowledged on the phone that there are some bugs that can only be fixed by looking at the source.

This philosophical difference of approach makes sense given what we know of the two companies. Nvidia's graphics business is much larger than AMD's and the company has invested a great deal of money in creating 3D libraries, rendering engines, programming tools, and in some cases, specialized hardware blocks. AMD hasn't tended to make as many of these kinds of investments; Mantle is the exception that proves the rule.

Some of this difference in approach is cultural but much of it is driven by necessity. In 2012 (the last year before AMD's graphics revenue was rolled into the console business), AMD made about $1.4 billion off the Radeon division. For the same period, Nvidia made more than $4.2 billion. Some of that was Tegra-related and it's a testament to AMD's hardware engineering that it competes effectively with Nvidia with a much smaller revenue share, but it also means that Team Green has far more money to spend on optimizing every aspect of the driver stack.

Next page: Should developers have access to middleware (GameWorks) source code?

Do developers need access to middleware (GameWorks) source code?

The various developers we interviewed indicated that source code access for middleware was extremely important if not mandatory. Middleware, it turns out, is often buggy or requires significant additional changes to perform as desired. Without access to the underlying code, developers are stuck either trying to convince the middleware owner to fix it or hacking out workarounds in their own implementation.

Again, however, this is a complicated topic. The programmers we spoke to were from large, well-established studios with a number of successful projects under their collective belts. Middleware, including GameWorks, can be tremendously valuable to smaller teams who either don't have the resources to build their own solutions or would prefer to work with a standardized set of capabilities.

Ultimately, GameWorks is game middleware that’s written in code, just as Havok Physics, SpeedTree, Unreal Engine 4, Unity, and WWise are game middleware that’s written in code. Often middleware providers share their code with hardware vendors and invite them to provide feedback on optimization for their hardware or to write actual code for inclusion in the middleware. At Epic, we have often done this with key hardware partners including both NVIDIA and AMD. Nvidia's full set of GameWorks libraries

However, there’s not a general expectation and certainly not an obligation that a middleware providers shares their code with hardware vendors, or accept optimizations back. There are legitimate reasons why they may choose not to, for example to protect trade secrets.

Nowadays, some game middleware packages are owned or supported by hardware companies, such as Intel owning Havok Physics, Nvidia owning PhysX and GameWorks, and AMD’s past funding and contributing to the development of Bullet Physics. Here IHVs are investing millions of dollars into creating middleware that is often provided to developers for free. It’s not necessarily realistic to expect that a hardware company that owns middleware to share their code with competing hardware companies for the purpose of optimizing it for their hardware, especially when hardware vendors are often involved in competing or overlapping middleware offerings.

Game and engine developers who choose middleware for their projects go in with full awareness of the situation. With Unreal Engine 4, Epic Games is a very happy user of Nvidia's GameWorks including PhysX and other components.

Clearly, what the developer's needs (and their budget) is a critical component of evaluating the usefulness of any middleware solution. As the developer of one of the largest engines in gaming, the UE4 team has been enthusiastic about working with Nvidia to provide support for its GW libraries.

Next page: Why did Nvidia build GameWorks?

Why did Nvidia build GameWorks?

The question of why Nvidia built GameWorks and what the company hoped to accomplish with its middleware is central to the debate over whether or not these libraries are good or bad for gamers. According to Valve programmer Rich Geldreich, the principle benefit of GameWorks is that it gives Nvidia an opportunity to optimize segments of code that it wouldn't normally control directly.

"[T]here are fundamental limits to how much perf you can squeeze out of the PC graphics stack when limited to only driver-level optimizations," Geldreich told ExtremeTech. "The PC driver devs are stuck near the very end of the graphics pipeline, and by the time the GL or D3D call stream gets to them there's not a whole lot they can safely, sanely, and sustainably do to manipulate the callstream for better perf. Comparatively, the gains you can get by optimizing at the top or middle of the graphics pipeline (vs. the very end, inside the driver) are much larger."

Nvidia is perceived by developers as genuinely passionate about building better products and creating great hardware experiences -- on its own equipment. Sometimes that aligns well to what the game studio is trying to accomplish, sometimes it doesn't -- as Geldreich detailed in his OpenGL post(Opens in a new window), Nvidia's dedication to great experiences is narrowly constrained to great experience on Nvidia hardware, whereas Valve is more concerned with building code that runs well on every system.

Could GameWorks be used to harm AMD (and by extension, AMD gamers)?

Geldreich spoke directly to this question, saying: "I don't think NV is purposely tilting the table here. But if you look at the big picture, I wouldn't preclude a sort of emergent behavior that could effectively tilt the competitive advantage to whatever vendor manages to embed the best developers into the most key game teams."

Are Mantle and GameWorks just different ways of securing a competitive advantage?

This is a point I've seen raised by both readers and a few of my own colleagues, but it's not a point that either AMD or Nvidia has ever argued. The rationale is that GameWorks and Mantle are both an attempt by their respective companies to fragment the API market and lock users into their own preferred solution and since they're both the same, they should be seen as canceling each other out. Business, in other words, as usual.

No developer agreed with that sentiment, but on this one point, the reasons why they disagreed varied widely. Some pointed to the source code difference (keep in mind, you still have to buy/negotiate the right to GW library source code with Nvidia). Some said they weren't sure if Mantle would be popular enough long term to ever pose a risk to the DX11 optimization process, or to significantly fragment the market. One individual we spoke to said it was impossible to separate the two programs from the problems that they solved, and Mantle and GameWorks were so different in that regard it made no sense to compare them.

Conclusion

Whether GameWorks is good or bad for developers and gamers is a more nuanced question than we made it sound when we first described the program last December, though the program has itself evolved since then. For developers, access to source code was the greatest single issue, and that's a concern Nvidia has apparently moved to address. Some of the developers we spoke to were skeptical of whether they'd ever use GameWorks, while others were excited about what engines like Unreal 4 could offer to gamers and developers alike.

Everyone we spoke to also recognized that GameWorks libraries are more difficult for AMD to optimize and that the company has a legitimate reason to be concerned about this. For better or worse, the GameWorks program has the potential to shift the industry towards a development and optimization model that's closer to the Nvidia way of doing business than the AMD equivalent. AMD, with its emphasis on standards compliance and collaborative effort, believes this is a bad thing.

In the long run it will be the developers themselves who ultimately decide if Nvidia's GameWorks program is worth using, though I acknowledge that comprehensive business deals handed down from the game publishers have an enormous impact on what features or software a development studio does or doesn't use.

The question of whether GameWorks is a good or bad thing for AMD gamers will be answered by how future GameWorks titles run on AMD hardware. Arkham Origins was a poor brand ambassador for the GameWorks program, even if the performance delta between AMD and Nvidia in that title wasn't linked to any particular GameWorks feature -- the gap between the two companies was and is far larger than normal. Subsequent GameWorks-enabled titles, however, have hewn much more closely to expected performance levels.