News - AMD exec says NVIDIA neglecting gamers

[Anaerin]

'Developer relations' between one company and the next are OK in my book as long as they have put in the time and money and have reached an agreement to bring the best product out for your hardware. However what some specific posters seem to have ignored is that nVidia have not only optimised the best experience for nVidia cards (which is fine) but they have also hindered performance of a competitor's cards (by disabling AA) which is not OK at all. It's one thing to eat a healthy breakfast in preparation for the race and it's another to steal your competitor's trainers and throw them into the river. Anyone arguing that nVidia put more effort into helping developers (which, let me stress again, is OK) is an empty argument because it completely misses what the real issue is: nVidia using tactics designed to undermine the performance of competitiors' products.

Here's something wrong with what you said:

they have also hindered performance of a competitor's cards (by disabling AA)

Do you realise that, without NVidia's code, there would be no AA on any card, NVidia, AMD/ATI, Intel, Matrox, S3, no AA whatsoever. That's how things look and work by default in UE3. So NVidia's code enables AA on their cards, and takes the default codepath for everything else. As the default codepath is no AA, there's no AA.

[shaithis]

Why is it "uneconomical" and "too time consuming" for Eidos to write the AA code for the Unreal engine.....but not for nVidia/AMD?

We really need more info as it all sounds to me (especially given the content of the letters) that Eidos has taken a shortcut by jumping into bed with nVidia and between themselves and nVidias actions, have scrwwed AMD video card owners.

AMD hasn't really done anything wrong, unless you count "not finishing a 3rd parties game" :S
I would love to know what was said up-front between Eidos and nVidia which prompted the code exchange.....and I would also love to know why Eidos felt they couldn't write that peice of code on their own, even if it meant AMD users would only get AA enabled when running on a DX10 complient OS and card.

[Phage]

We really need more info as it all sounds to me (especially given the content of the letters) that Eidos has taken a shortcut by jumping into bed with nVidia and between themselves and nVidias actions, have scrwwed AMD video card owners.

AMD hasn't really done anything wrong, unless you count "not finishing a 3rd parties game" :S
I would love to know what was said up-front between Eidos and nVidia which prompted the code exchange.....and I would also love to know why Eidos felt they couldn't write that peice of code on their own, even if it meant AMD users would only get AA enabled when running on a DX10 complient OS and card.

^^ This.

[Anaerin]

Why is it "uneconomical" and "too time consuming" for Eidos to write the AA code for the Unreal engine.....but not for nVidia/AMD?

Considering Eidos haven't written Unreal Engine (Epic did that) and writing and testing software patches to huge software engines like the UE is no trivial task, with the need to test it on as many differing platforms as possible and to ensure that it works with all the quirks of various vendor's implementations, that makes it "too time consuming" and "uneconomical".

We really need more info as it all sounds to me (especially given the content of the letters) that Eidos has taken a shortcut by jumping into bed with nVidia and between themselves and nVidias actions, have scrwwed AMD video card owners.

Eidos and NVidia were working together. It's part of NVidia's "The way it's meant to be played" scheme. NVidia give testing platforms for QA on a whole bunch of systems running the gamut of NV graphics hardware and system boards, and provide bugfixes and optimisations to game developers to help their games run the best on NV's hardware.

It was probably an aside, from one NVidia developer to another (Eidos/RockSteady developer) - "Hey, there's no AA in this! You using UE3? We've got a drop-in patch that enables AA for our cards, and we've tested it so it works on pretty much everything we've ever made. Would you like it?" Unsurprisingly, Eidos said "Sure!", as it would be too much work for them to write, and it adds that extra polish.

AMD/ATI then got an advanced copy of the game, for QA testing, and found there was no AA on their platform, but there was on NV's, and sent an e-mail over asking "WTF?".
Eidos explained that NV had given them some code that enables AA on their cards.
AMD/ATI responds "Oh, cool. You know, that code works with our cards too, so you can just change their code to take out the lock and it'll work fine here"
Eidos reads this, and gets a word in their ear from their legal department, shaking their heads, and so answer "Sorry, but that code belongs to NVidia. We're not changing their code. But if you want to supply your own, we can add that, too".
AMD/ATI demurrs, as they don't have any code that'll do that kind of thing, and starts slinging mud instead.

AMD hasn't really done anything wrong, unless you count "not finishing a 3rd parties game" :S
I would love to know what was said up-front between Eidos and nVidia which prompted the code exchange.....and I would also love to know why Eidos felt they couldn't write that peice of code on their own, even if it meant AMD users would only get AA enabled when running on a DX10 complient OS and card.

As I said, Eidos/NVidia were partners, through the "The way it's meant to be played" scheme. That means they work together.

While most cards may support DFR+AA, that doesn't mean the engine supports it. In this case, UE3, it doesn't. Which means no AA on any platform at all. AMD/ATI users are getting the same experience with NVidia's patch as they would be getting without it - namely no AA.

NVidia is not actively disabling AA on non-NV hardware, they're letting the engine do what it would normally do.

[Replicant]

I guess everyone forgot the Half Life 2 deals with Valve and Ati? There were a lot of anti NVidia actions there, to the detriment of the gamers... While I do not particularly like it when a graphics card manufacturer pays for special treatment in a game, I understand it. ATI and NVidia want thier cards to play the best in all games. They are willing to pay a little extra from time to time to get a particularly popular game to perform better on their cards.

I myself am happy that Ati came out with a fast card, not that I'll buy one. Every innovation is met with another and keeps competition strong.

Anyway, just my two cents.

[Zhaoman]

Here's something wrong with what you said:

Do you realise that, without NVidia's code, there would be no AA on any card, NVidia, AMD/ATI, Intel, Matrox, S3, no AA whatsoever. That's how things look and work by default in UE3. So NVidia's code enables AA on their cards, and takes the default codepath for everything else. As the default codepath is no AA, there's no AA.

... Well if this guy is anything to go by:

The way I see it is that MSAA (As Huddy clearly states in his e-mail subject line) in DX10 mode should work because it's part of the damn specs of the unreal engine 3.5 (aka UE3 DX10) AFAIK and ARE FOR SURE PART OF DX10 SPEC. UE3 DX9 does not support AA with deferred shadows (DPR+AA...Or essentially deferred pixel/shadow HDR+AA) because of dx9 limitations (no DPR+AA in the API), but DX10 does, and UE3.5 supports DX10. Nvidia can tout their DX9 workaround that ATi doesn't have, but could support in hardware (since the X1000 series, nvidia 8000 series), that's fine and lovely. Good for them. IN DX9 mode.

Remember the x1000 series pushing HDR+AA that nVIDIA couldn't do in the 7000 series? Yeah, that's this essentially, as the deferred shadows in UE3 (that the DX9 API can't support simultaneously with AA) are HDR. Hence why this only works on 8000 series and up nvidia hardware. Huddy knows this. ATi should be able to push AA through catalyst, just like nvidia does with their essentially built-in force work-around they've used in the past (that Huddy also mentions). Granted, if to be supported in-game, ATi should provide or help write that code...For DX9.

This game runs in DX10 mode. ATi supports DX10. DX10 will do DPR+AA. ATi should be supported. End of conversation.

Like Huddy says in his e-mail, they are likely using the DX10 codepath for AA...Why are they locked out? Because nvidia enabled AA in DX9 mode through forcing hax and built it into the game GUI? This should not transfer over to DX10. That's just BS on all fronts, any way you cut it.

This is clearly what can only be described as TWIMTBP douchebaggery of EPIC proportions, or some very strange misunderstanding on EIDOS' and Rocksteady's part. You'd think devs would know better?

Huddy is confused as to what nVIDIA did, and so am I. I am willing to bet nVIDIA did jack shat to enable AA in DX10 mode, because DX10 supports deferred rendering + AA in the effing SPEC API, where-as dx9 (and nvidia dx9 cards) does not. Nvidia did not create the dx10 spec, nor the engine's ability to support the dx10 API. Even further, why should they care if someone forces it through cat in dx9 mode? Obviously it wouldn't be supported, but to lock it out completely in both modes can only be described as a dev super fail.

Got it Eidos/Rocksteady? DX10 yes. DX9 if forced through catalyst or ATi helps with code for in-game (that could be supported back to X1000 series..although would prolly run very badly).

Hope that answers your question but of course we need solid evidence that ATi did have their own code that was consequently refused but right now we just don't know.

I guess everyone forgot the Half Life 2 deals with Valve and Ati? There were a lot of anti NVidia actions there, to the detriment of the gamers... While I do not particularly like it when a graphics card manufacturer pays for special treatment in a game, I understand it. ATI and NVidia want thier cards to play the best in all games. They are willing to pay a little extra from time to time to get a particularly popular game to perform better on their cards.

As far as I can remember, this was down to the fact that the GeForceFX series was pants and ATi had a brilliant 9 series lined up at the time. I don't recall foul play being a factor.

[caveman-jim]

Eidos reads this, and gets a word in their ear from their legal department, shaking their heads, and so answer "Sorry, but that code belongs to NVidia. We're not changing their code. But if you want to supply your own, we can add that, too".
AMD/ATI demurrs, as they don't have any code that'll do that kind of thing, and starts slinging mud instead.

Now correct me if I'm wrong, but haven't AMD publicly stated Eidos was offered an AMD developer AA solution and it was rejected? If so that undercuts your argument here as it's just not true that AMD don't have the code and are slinging mud.

[Rollo]

The emails Huddy posted prove only that McNaughton and Huddy purposefully mislead gamers in to believing that ‘evil’ NVIDIA paid Eidos to screw over AMD.

The emails Huddy posted say:

AMD Dev Rel is MIA until Batman is already “hot”. Batman : Arkham Asylum launched on 9/15 for PC. Emails are dated 9/29. Two weeks after launch.
Eidos asked them for their code in the email to Huddy.

AMD refused to do the work, wanting NVIDIA’s IP instead.

Nowhere does it indicate NVIDIA locked them out.

Nowhere does it say Eidos will not let them have AA. It says “give me code’ and they cannot change (and potentially break) the NVIDIA provided and QAed code.

Nowhere does it mention that AMD tested the NVIDIA code on their hardware to make sure it does not break anything, which would likely result in tech support calls for Eidos and a bad customer experience. Should Eidos just trust that AMD hardware works on the code NVIDIA created? Do you have a QA matrix and results you can provide them to ensure they do not have to foster your QA costs?

Fun fact: AMD cards cannot support AA on all surfaces.

AMD wants free tech with no work. If they want AA in Batman Arkham Asylum they should provide Eidos with the code to do it, as NVIDIA has done.

Kombatant got it right, what developer wouldn't take an offer to have the AA code given to them rather than have to write it at their cost and time?

[caveman-jim]

Kombatant got it right, what developer wouldn't take an offer to have the AA code given to them rather than have to write it at their cost and time?

You'll get no argument from me on that point. Eidos' use of the UE3 engine almost guarantees that they would want to leverage nVidia's developer assistance.

[Rollo]

To me, all this bickering over emails is secondary to the REAL issue:

Why weren't ATi dev relations people working with Eidos long before this game launched to provide their customers with the best possible gaming experience?

Does anyone here actually believe if ATi approached Eidos six months before the game launched and said "We want to work with you on adding code to enable AA for our customers" that Eidos would have replied "No, no, we can only allow one graphics vendor to work with us on this title"?

That's the ONLY issue here. My guess is they could still do it if it is such a big deal to them, they just don't want to spend the time, or perhaps lack the expertise to write the code. Hard to say.

BTW- WAY cool to see you here Caveman. You are one of the guys I miss talking to at the treacherous Rage3d. Hope all is well with you.

[CAT-THE-FIFTH]

I guess everyone forgot the Half Life 2 deals with Valve and Ati? There were a lot of anti NVidia actions there, to the detriment of the gamers... While I do not particularly like it when a graphics card manufacturer pays for special treatment in a game, I understand it. ATI and NVidia want thier cards to play the best in all games. They are willing to pay a little extra from time to time to get a particularly popular game to perform better on their cards.

I myself am happy that Ati came out with a fast card, not that I'll buy one. Every innovation is met with another and keeps competition strong.

Anyway, just my two cents.

Actually it was mainly due to the fact that the FX series had such poor DX9 performance that Valve had to run HL2 on the FX series in DX8 mode whereas the equivalent ATI cards could run it in DX9.

TWIMTBP was launched in 2003 by Nvidia and IIRC it was partly due to the issues with the FX series.

TBH,it does not worry me if companies want to optimise games for their hardware as long as they don't try to exclude their competitors from doing so as well actively.

[kalniel]

Aye, that's intentional. New code == buggy code. Debugging code is the single most time consuming job for a programmer. So if you have 'old' code that's known to work (read: tested, and already debugged), it's best to use it.

Exactly, and it's not because they don't want the time of writing new code - it's because that time could be better spent creating things of more benefit. Programmers end up doing the same amount of work, it's just how much is produced as a result.

[meltedrabbit]

Now correct me if I'm wrong, but haven't AMD publicly stated Eidos was offered an AMD developer AA solution and it was rejected? If so that undercuts your argument here as it's just not true that AMD don't have the code and are slinging mud.

The one of the ways that nVidia could have caused a problem, intentionally or not, would have been to mix its AA C++ code directly into the ArkA source code files. The proper way to fix the problem would have been to provide the AA code in separate files with stubs that could be linked to separate libraries loaded at runtime in a DLL. Of course, it seems a bit stupid that the code sounds like its checks for nVidia's PCI vendor ID code and then for the device ID code, which is absolutely stupid/malicious and not defensible in any way. The code should be checking for DX9 AA capability with its code via API calls to DirectX. This is either a CS101 level mistake, which I doubt, or it is a blatantly malicious act on the part of nVidia. There is no need to check hardware vendor IDs and device codes for a user mode application, ever. This is even worse considering that AA on ArkA works fine on Radeon cards when ArkA is fooled into thinking the card is a Geforce GTX260.

The post from spyre on the Eidos forums linked to on CatalystMaker's Twitter account describes how to make ATI Tray Tool fool ArkA. However, the Device ID should be "05E2", and not "5E2", for technical reasons, but ATI Tray Tool probably prepends a "0" to "5E2", so no big problem.

[Seeratlas]

I'd be very surprised if Nvidia 'accidentally' did anything anticompetitive in providing their code
Someone once observed that 'business is war without guns, and sometimes with guns.."
As an attorney, I would not want to defend a class or governmental action naming eidos and Nvidia for anticompetitive behavior. Whether such an action would prevail or not would be irrelevant. The publicity and disclosure of the Nvidia lockout of ATI, discovery into and consequent public disclosure of payments or other *arrangements* reached by and between Nvidia and eidos with respect to this issue, the prospects of a boycott against against both companies by current and prospective owners of ATI cards etc...the downside, both in PR and monetary loss of all of these potential negatives appear to me to substantially outweigh any possible self-satisfaction gained by Nvidia with this seemingly intentional middle finger salute to ATI and its customers; not to mention those Nvidia owners who have systems running both cards. If I was counseling the corp, I'd be asking who came up with this particular bit of *genius*....This industry is a game of market share..I fail to see how this benefits either Eidos or Nvidia.

While I have no dog in this fight, Nvidia's rep's statement apparently authorizing eidos to unlock the code at their discretion would go a long way to convincing a trier of fact that Nvidia did and does not intend to assert any proprietary right to the usage of their AA enabling code or any *intention* to cause Eidos to exclude it's being rendered operable on ATI hardware.

Having said all that, the fact that the mere insertion of an authorizing code enables it for ATI hardware says something as to the *real* intentions of the would be defendants..

Nope, I would not have counseled this course of conduct.

Seer

[caveman-jim]

To me, all this bickering over emails is secondary to the REAL issue:

Why weren't ATi dev relations people working with Eidos long before this game launched to provide their customers with the best possible gaming experience?

Does anyone here actually believe if ATi approached Eidos six months before the game launched and said "We want to work with you on adding code to enable AA for our customers" that Eidos would have replied "No, no, we can only allow one graphics vendor to work with us on this title"?

That's the ONLY issue here. My guess is they could still do it if it is such a big deal to them, they just don't want to spend the time, or perhaps lack the expertise to write the code. Hard to say.

BTW- WAY cool to see you here Caveman. You are one of the guys I miss talking to at the treacherous Rage3d. Hope all is well with you.

I do think that is a valid point - and if you go back a little in the thread you'll see I'm hoping to get it addressed as well.

I understand why nVidia included a vendor ID check, but I don't understand why Eidos agreed to it - if it were me I would want everyone to enjoy the game as best they could. But perhaps thats my naivety!

AMD's developer relations need improving, no doubt. This little spat has shown a lot of passion from AMD which is a refreshing change, but I don't think we're going to get AMD validating the AA solution and accepting it as-is to run on their cards so the vendor ID can be removed, let alone create their own and a patch included - as it stands customers who desire AA can force it through the control panel, so the return on investment is very low other than showing they could do it.

Nice to bump into you too, and don't be so hard on Rage3D... it's the Intarwebz largest ATi fansite, after all

Hit me up on PM or email if you wanna chat.

[Anaerin]

As an attorney, I would not want to defend a class or governmental action naming eidos and Nvidia for anticompetitive behavior. Whether such an action would prevail or not would be irrelevant. The publicity and disclosure of the Nvidia lockout of ATI, discovery into and consequent public disclosure of payments or other *arrangements* reached by and between Nvidia and eidos with respect to this issue, the prospects of a boycott against against both companies by current and prospective owners of ATI cards etc...the downside, both in PR and monetary loss of all of these potential negatives appear to me to substantially outweigh any possible self-satisfaction gained by Nvidia with this seemingly intentional middle finger salute to ATI and its customers; not to mention those Nvidia owners who have systems running both cards. If I was counseling the corp, I'd be asking who came up with this particular bit of *genius*....This industry is a game of market share..I fail to see how this benefits either Eidos or Nvidia.

While I have no dog in this fight, Nvidia's rep's statement apparently authorizing eidos to unlock the code at their discretion would go a long way to convincing a trier of fact that Nvidia did and does not intend to assert any proprietary right to the usage of their AA enabling code or any *intention* to cause Eidos to exclude it's being rendered operable on ATI hardware.

Having said all that, the fact that the mere insertion of an authorizing code enables it for ATI hardware says something as to the *real* intentions of the would be defendants..

Nope, I would not have counseled this course of conduct.

If NVidia allowed the code to run on all hardware, not just theirs, and it was found that their code was the cause of some incompatibility with other hardware (Using some kind of trick that's API compliant, but not supported under someone else's implementation), then NVidia would be liable for changing the code (As it's their code) to make it work on any and/or all other platforms, and AMD/ATI/anyone else could then sue them for "Anti-competitive behaviour" for their code "breaking" the experience for other vendors.

By putting in the ID lock, they are effectively saying "This is what we are releasing this code to be used against. We know it works on these devices, and we will support it on those devices, and nothing else. If you circumvent this lock, we can not be held responsible for whatever may happen".

Neither Eidos, nor NVidia, have made or engineered things so AMD/ATI can't get AA working, all they have to do is provide code that unlocks it that they are willing to QA and support, the same way NVidia have. AMD/ATI haven't done that.