Batmangate: AMD vs. nVidia vs. Eidos fight analyzed
AMD perspective
For starters, we talked to Chris Hook, who told us that AMD's standpoint is: "Eidos had been compensated by nVidia to put a piece of code in the game that would recognize an ATI Vendor ID and then activated what was a very average implementation of Anti-Aliasing on nVidia hardware alone.
The controversy raised questions such as whether AMD's ISV team [Independent Software Vendor] was being aggressive enough, was prepared enough, and if games really run better on nVidia hardware. We’d like to address those questions publically."
The reason for Batmangate: Different Control Panels for nVidia and ATI
Over the past couple of years, we have continuously asked why is AMD continuously reluctant to speak on-the-record about the issues [when they appear], and finally received a following answer: "AMD has been a little reluctant to tell our side of the story, because unlike nVidia, we prefer to work with our partners to find and settle these issues privately. Today, we are telling our side of the story what really went in the background and why we think that perhaps some of Eidos customers who are buying Batman: AA and running them on ATI hardware are being disadvantaged perhaps not so much by Eidos but by nVidia."
As you can imagine, hearing such harsh statements from AMD is not something we are used to, and we decided to dig in deeper. According to information given to us, Eidos went shopping for a co-marketing deal around GDC 2009 conference in San Francisco [March 23-27, 2009]. This is a standard business practice - co-marketing contracts are usually signed six months prior to title release. Eidos offered the deal to AMD and nVidia on the graphics side, with Dolby already being signed on the audio side. On March 28, 2009 Richard Huddy received confirmation inside AMD that the company taped out their DirectX 11 chips and that the situation is looking really good for the company. As a subsequent decision, AMD decided "not to engage heavily with Batman: Arkham Asylum from Rocksteady and EIDOS as we have done with other DirectX 11 game developers."
Naturally, we asked for a definition of how AMD exactly stayed in touch with both Rocksteady and Eidos, as nVidia can easily cry foul on this one. According to Richard Huddy, "It should not come as a surprise that [Batman is] one of the games that we have not quite walked away from, but decided it wasn't our priority to work with them and on a real day-to-day, engineer-on-site kinda basis that we have with DirectX 11 games. So, we did continue to receive builds coming from both Rocksteady and Eidos, we have worked directly with Rocksteady on solving issues on AMD hardware. In fact, one of AMD's very best and most proactive engineers, Mr. Nick Thibieroz maintained regular dialog with Rocksteady, a lot of backs and forward feedback on how to tune the game for AMD hardware I n all sorts of scenarios, DirectX 9 and DirectX 10 hardware, with Nick taking a quiet look on how it behaved on our then upcoming DirectX 11 hardware, too. That dialogue progressed in absolutely natural and cooperative kinda way up until around mid-August."
As you might imagine, it seems that mid-August is the time when the 'sh** hit the fan'. Richard continued on saying that "We got the build and it was the first time that MSAA [Multi Sample Anti-Aliasing] was supported inside the game. On the front end, it was labeled 'MSAA Trademark NVIDIA Corporation'."
Naturally, seeing the code that states MSAA being a trademark of any company would raise the alarm in competing technologies. According to Richard, both ATI and nVidia recommend the following standard technique for enabling MSAA: "storing linear depth into the alpha channel of the RenderTarget and using that alpha value in the resolve pass. You only need to linearize it if you are storing something like 8-bit color so that you can get depth approximation, stuff it into alpha channel and then when you've finished rendering at high resolution you simply filter down the color values and use depth value maintain some kind of quality to your Anti-Aliasing so you don't just average."
We have asked our "panel of independent judges" i.e. developers about this method to ensure objectivity of this article and in both cases our developers told us that the description above is a standard technique advocated to gamers by both AMD and nVidia. With the description above being explained to us as "standard", it turns out that the code that was labeled "MSAA Trademark NVIDIA Corporation" was identical to the one recommended by both sides with one very important difference: nVidia's code features a Vendor ID lock that allows for AA menu inside the game only if nVidia hardware is detected.
What got AMD seriously aggravated was the fact that the first step of this code is done on all AMD hardware: "'Amusingly', it turns out that the first step is done for all hardware (even ours) whether AA is enabled or not! So it turns out that NVidia's code for adding support for AA is running on our hardware all the time - even though we're not being allowed to run the resolve code!
So… They've not just tied a very ordinary implementation of AA to their h/w, but they've done it in a way which ends up slowing our hardware down (because we're forced to write useless depth values to alpha most of the time...)!"
The explanation given by Rocksteady was that the nVidia "used some special technique that couldn’t reliably be expected to work on AMD hardware and that EIDOS has done some sort of QA test on AMD hardware and found problems." On August 12, 2009 - less than 48 hours after the initial version of the code marked with "MSAA Trademark NVIDIA Corporation" was uploaded to AMD's FTP server - Rocksteady uploaded new version of the code that still didn't allow for in-game MSAA of ATI hardware.
AMD contacted Rocksteady and Eidos again and the immediate response from the developer was that there was at least one more build before they went final, and that Rocksteady would try to get that [code] in. The odd situation that we have here is that code was proprietary to nVidia is identical to the standard advice both companies used ever since DirectX 10.1 came out and sorted out Anti-Aliasing calls. As we all know, DirectX 10.1 removes excessive passes and kills the overhead that happened in development of the original DirectX 10.0. Even if you have DirectX 10.0 hardware, in most cases that DX10.0 overhead is run over by DX10.1 if developers had adjusted their approach to MSAA.
By late August, Rocksteady got back to AMD and stated "that they [Rocksteady] will look back and try to sort that one out for Day One patch, but that it was too late to hit the Golden Master. We were expecting that Day One patch would contain that MSAA-enabler. They made a clear statement it is Rocksteady's intention to enable MSAA on our hardware. When the Day One patch arrived, we were disappointed that it didn't contain that support."
Rocksteady gave a clear intention to enable in-game AA code on AMD cards with a statement that found its way to Beyond3D Forum: "The form of anti-aliasing implemented in Batman: Arkham Asylum uses features specific to NVIDIA cards. However, we are aware some users have managed to hack AA into the demo on ATI cards. We are speaking with ATI/AMD now to make sure it’s easier to enable some form of AA in the final game."
Things turn out even more interesting when the game was released. On Batman: Arkham Asylum Forums, people experimented with nVidia code and got it to run on ATI hardware in a very trivial way - by changing vendorID from ATI to nVidia. On September 11, AMD's Ian McNaughton posted a very interesting post claiming that by changing the VendorID from ATI to nVidia; you would not only get AA selection inside the game, but also higher performance. There was a thread on Eidos' forums that explained how to enable in-game AA on ATI hardware, but it went the way of dodo birds:
"We don't know what happened there, we don't know did nVidia went back and stated "Hey, we wrote this code and pushed through our own QA and it is not O.K. for you to loosen it up and let it run on anyone's hardware but ours."
"We don't know if EIDOS or Rocksteady went back and think up some sort of excuse - I don't know, but proprietary claim I suspect, comes from some kind of track record from nVidia that the code was made by them and that they didn't wanted to allow it to run on our hardware.
I am not sure why Eidos came to such a conclusion that there was a rendering problem. People have been able to experiment to run that nVidia code on AMD hardware and as far as I am aware, never met a problem making it run. If you were to go to EIDOS discussion forum about this for the moment, they have posted how to turn the Anti-Aliasing on through the Catalyst Control Center, you can notice that one forum poster posted immediately after how to make in-game control work on AMD hardware. As far as I know, there is no issue about it. So, I suspect that EIDOS must have got confused, they probably had reports of corruption because of some other problem we had on that particular build of the game. They also might have pressure; it is my guess from nVidia - not to allow this MSAA code to run on our hardware."
As you can see in Ian's statement, there was enough dynamite to blow the thing out of proportion by fanboys, but at the core of the matter lies in the fact that if you change vendor ID from AMD to nVidia, you get that in-game option for MSAA. Richard Huddy went on to say that he alleges how nVidia might have played a murky game "by giving them that MSAA support extremely late in the game, which is trivial, standard implementation that both nVidia and we would recommend any time in the last year or longer, being that late in the game they created a situation in which they put EIDOS and Rocksteady in the middle of a very difficult situation."
Richard continued on to say that "I have sat down with EIDOS on multiple occasions and said okay, we fix this now, we are happy there is a way forward, you might as well get a build out to players in the future. But the fact that it isn't fixed now doesn't mean it won't happen in the future."
 According to Richard, who was the former European head of Developer Relations at nVidia [it is little known that Richard Huddy was nVidia's Employee #94 and he stayed for years until he departed from the company 'on moral grounds']
"When I was at nVidia, I was instructed to do these kinds of things. It is very much a style they tend to be involved in. You could say it's just me whining and coming to the conclusion that nVidia are bad people and so on, but if I am looking for differences in style, the one really obvious one is this: there I was, with my team, working primarily on DirectX 11 titles. And there is nVidia working on Batman: Arkham Asylum. I could try to lock DX11 functions and content to AMD hardware. I can do that today on the basis that nVidia can't do any QA on their DirectX 11 hardware. It is irresponsible… I could come up with this speech about nVidia not having good hardware but ultimately, it is irresponsible and plain wrong. We are spending the time with DirectX 11 developers; they use our hardware, so we should not allow for that code to run on nVidia DX11 hardware when it appears next year? No one can do QA on something like Unigine unless they are using AMD hardware. No nVidia hardware can be used for S.T.A.L.K.E.R.: Call of Pripyat, none can be done on DiRT 2 because their hardware is still in the development phase. If I were to follow their style, I could argue that DX11 games should not be able to run on future nVidia hardware. In my opinion, it would just be irresponsible thing to do so."
Do note that AMD is not doing the same thing, and if AMD would turn rogue, you could use Richard's quote against them: "We haven't locked a single line of code to AMD hardware. No fragments of code anywhere that I am aware of, is locked to any AMD hardware. That is a really big difference in style. Blocking functions that are absolutely standard DX code to nVidia hardware is just putting a games developer, Rocksteady and games publisher, EIDOS - into the middle of kinda marketing battle between two GPU manufacturers is doing disservice to gamers. That's my position, obviously."
From the explanation above, it looks that AMD is crying foul for all the right reasons. This reminds us of shady games that Intel used to play with their compilers requiring "vendorID=GenuineIntel" in order to enable standard x86 multimedia extensions such as SSE. All in all, the move looked quite backward to us. Nick Thibieroz of AMD immediately contacted Rocksteady directly and gave them "feedback on how it was a trivial matter to open that [code] to run on AMD hardware and it would in fact, run on all AMD hardware I can think of, since the introduction of the 9700. Everything look supported, DirectX 9, DirectX 10, DirectX 10.1, DirectX 11... There would be no problem."
Next Page: Technical issue turns into a legal one, AMD-EIDOS e-mail exchange
© 2009 - 2010 Bright Side Of News*, All rights reserved.
|
|
