Apoppin called it -Nvidia 3D displays at bestbuy

[Seero]

It is? What law is that?

http://en.wikipedia.org/wiki/United_States_antitrust_law

So was it illegal when Nvidia created the MSAA coding in Batman:AA that caused AMD cards to run slower than they should have while using FSAA?

Keep in mind the difference between "I run faster than you", " I made you run slower then me." and "I run slower when running with someone else." The key is the bolded. If the code make AMD cards performs bad, than it does. If the code was made not to run on AMD cards, than it doesn't. AMD had a lot of chances to write their own codes to make MSAA possible in batman. They said whatever Nvidia wrote will work on AMD cards too, but they didn't say that it is illegal for Eidos or Rocksteady to alter Nvidia's code. Yes Rocksteady or Eidos would re-engineer a new set of code that will enable MSAA for both vendor, but AMD can also do that. So Nvidia gave a piece of code to Eidos for free. Richard Huddy blames Rockstead, Eidos, and Nvidia for not making either a different piece of code that does the something without the ID check, or simply remove the ID check. When bit-tech asked

bit-tech: Given Nvidia licensed its own MSAA technology for Unreal Engine 3, why don't you just do the same thing? Put your code in as well and when the game detects your vendor ID it uses this code instead.

We're currently working with Eidos and we want that to be in there in a future update. That's not a commitment to it, but we are working with Eidos to make it happen because I believe it's in every consumer’s interest.

It is clear that they had the opportunity to supply their codes all along.

Except that there currently is no unusual performance hit evidenced. If you would read the TweakTown article I linked to (http://www.tweaktown.com/articles/3344/ati_radeon_hd_5870_5970_with_nvidia_physx/index.html), you'll see that there are no adverse issues reported while using the oops-we-forgot-to-lock-out-PhysX Nvidia 257.15 Beta ForceWare driver.

Removing the "all Nvidia" lock resulted in multiple PhysX sessions with a variety of Nvidia cards. Apparently it wouldn't take much at all for Nvidia to allow PhysX to work with an AMD card present. But they prefer to simply lock it out.

Let say the floor is wet, it doesn't mean you will guarantee to fall, but there is a higher chance. If there is a sign saying "Do not walk through" and you choose to ignore the sign, it still doesn't mean you will fall. But if you do fall face first, breaking your skull and ended up paralyzed, then don't say that you are not warned.

If the driver can detect whether there exists a supported card in the system before installing itself, do you really think is shall be this easy to remove such check?🙄

So to summarize, the AA actually was nothing special and does work just fine with AMD cards once the vendor ID check is removed.

See above.

If you're planning on going on a rant like that again in the future, please make sure to at least get your facts straight first.

I can use the cash in your bank account or your wallet just fine. Can I sue you for hiding your wallet or putting a password on your accounts?

I can even show you that there won't be a problem for me to spend your money. Let me know when you are ready for a demo.

So in other words, you're saying that Nvidia only puts in these checks so that we can take them back out again? I'm having a tough time believing that one.

To make it simple so you understand, Nvidia wants AMD card users to sometimes experience PhysX GPU acceleration too as long as it is possible, regardless of stabilities. First, introduce a id check, and accidentally leaked a patch which bypass the check, or may be, accidentally, put a version without a check in its webpage's beta download sector. Hey, Nvidia users are not affected as driver download are automatic and supports never skips a beat (196.75 is just a myth 😛). AMD users have to search, tries, get viruses, and all the fun stuffs to experience PhysX for 2 days.

Isn't that the sort of same argument we were using while trying to explain to you why EyeFinity won't work on Nvidia cards?

Not by Lonyo's definition. The argument of Eyefinity is like trying to run a Dx9 card under win7 with Dx11 only games. This argument is about having a Dx11 card upon different OS.

Based upon Lonyo's definition of "lock", the Eyefinity and Dx9 card arguments are both physical locks, which are not locks (hardware locks). The OS arguments does not consist of physical locks, and therefore, are locks(software locks). I am only using the ones they we can all agreed which can classifies as "locks."
(I admire myself)

 

[golem]

They most certainly CAN, it is as easy as a firmware level vendor check.
It is just illegal and very stupid to do so.

PS. nvidia? they put a "key" (a password basically) in SLI capable mobos and their driver's DRM make it refuse to run SLI mode unless it is present.
Also illegal AND stupid, also something that no competitor in their right mind would complain about.

Isn't that just semantics? Okay I should have said they can't legally.

 

[Outrage]

Lawsuit. The chip is marketed as 64 bit processor when used with a 64 bit O/S, not a 64 bit processor unless you are using a Nvidia GPU. Well they could market it as such, but then sales would probably drop.

When you browse the gfx cards at nvidias site they dont mention that GPU physx will be disabled if you are using anything beside a nvidia gpu to render with. you have to look for it in there faq at the bottom.

they dont really shout out that you cant use anything besides a nvidia gpu in your system, amd could use the same approach.

It would be stupid, but they could do it.

 

[Seero]

Isn't that just semantics? Okay I should have said they can't legally.

I used to believe that NVidia video card won't work on CF ready mobo and AMD card won't work on SLI ready mobo.

 

[apoppin]

It is? What law is that? So was it illegal when Nvidia created the MSAA coding in Batman:AA that caused AMD cards to run slower than they should have while using FSAA?

Do you like to repeat the same lie over and over, Creig?

Why?

Rocksteady coded MSAA support for Radeons into Batman:AA for their GotY edition almost a year ago 😛

 

[taltamir]

Isn't that just semantics? Okay I should have said they can't legally.

Its is real semantics issue rather then me pretending to misunderstand. Semantics is the study of meaning. I was completely certain that you meant your statement to be "there are technical reasons why they can't do so". I replied with "actually its easy to do so, but there are legal reasons why they wouldn't and economic reasons why they shouldn't"
Had I been certain of what you meant but chose to intentionally misinterpret it to put you down I would have been a jerk and a fool, and "pointless semantics" or "splitting hair" would have been an appropriate response to such behavior.
Anyways, my apologies for misunderstanding.

 

[Creig]

Do you like to repeat the same lie over and over, Creig?

Why?

Rocksteady coded MSAA support for Radeons into Batman:AA for their GotY edition almost a year ago 😛

(*sigh*) It's no lie. I'm referring to the original version of Batman:AA. You know, the one that contained a vendor ID check which locked out MSAA from anything but Nvidia cards? Nvidia originally DID try to lock out MSAA from Batman:AA, did they not? Until the community backlash forced them to backpedal and they later gave Rocksteady permission to release a patch which removed the check.

And please stop with the large, brightly colored fonts. Most of us are quite capable of comprehending regular sized, black text. Supersizing and coloring your response simply makes me think you're somehow becoming more like Wreckage. If I recall, he was fond of doing the same thing thinking it would somehow make his arguments stronger.

 

[Creig]

that is different then both the nvidia and AMD version of the story.
AMD says nvidia paid developer to disable AA in AMD cards.

From what I remember, Nvidia produced the MSAA implementation and included the vendor ID check in it. This is what was given to Rocksteady to include in Batman:AA. Didn't Rocksteady themselves say that the code belonged to Nvidia and that Nvidia lawyers hadn't given permission for Rocksteady to remove the vendor ID check when it was requested that they remove the check?

nVidia says they personally wrote the code for AA implementation for the developer (who didn't want to spend money on doing it themselves) and AMD refused to do the same.

True enough. I believe AMD actually said that since it was a standard implementation of AA, it should work on anyone's card.

Tech sites say that the code nvidia provided includes a check for nvidia card, and if you disable it it works on AMD cards as well.
I don't know where you got your version...

Again, true. I'm not disputing any of the above. I believe the specific part you're not liking is:

So was it illegal when Nvidia created the MSAA coding in Batman:AA that caused AMD cards to run slower than they should have while using FSAA?

I remember reading that AMD examined the coding in Batman:AA and found that the first part of the MSAA coding was still being performed on AMD cards, even though AMD cards weren't being allowed to display MSAA. Even if an AMD user forced FSAA through the control panel, it went something like this:

1) Begin game
2) Begin MSAA calculations
3) Vendor ID check
4) If vendor = Nvidia, continue MSAA and display
5) If vendor = other, halt MSAA
6) Perform FSAA calulations and display

It was the placement of the vendor ID check that AMD objected to. If it had performed the check before the MSAA calculations had started, there would have been no problem. But because the MSAA calculations were started then halted, it caused additional workload to AMD cards. Thus lower framerates. That's how I remember the situation.

if what AMD says is true then it is definitely illegal, if what nvidia says is true its most likely isn't (consult a lawyer to be sure, I am not 100% certain about that)

Perhaps. Or it could have simply been a programming mistake. But it's still rather damning that the code which caused AMD cards to run slower in this title came from their direct competitor, Nvidia.

 

[apoppin]

(*sigh*) It's no lie. I'm referring to the original version of Batman:AA. You know, the one that contained a vendor ID check which locked out MSAA from anything but Nvidia cards? Nvidia originally DID try to lock out MSAA from Batman:AA, did they not? Until the community backlash forced them to backpedal and they later gave Rocksteady permission to release a patch which removed the check.

And please stop with the large, brightly colored fonts. Most of us are quite capable of comprehending regular sized, black text. Supersizing and coloring your response simply makes me think you're somehow becoming more like Wreckage. If I recall, he was fond of doing the same thing thinking it would somehow make his arguments stronger.

Don't tell me how to post, Creig. Your arguments remind me of evolucion8's; so what?

This is the third time that i called you on this and you ignored the first two times
:|

And you are still posting FUD. Nvidia did not need to give "permission" to Rocksteady. AMD finally worked with them on the GotY edition; there was never a patch made available for Batman that implemented AA for Radeons.
:thumbsdown:

 

[Creig]

Physx is a feature that Nvidia has sole control over, it's their technology. A video card working in a PCIe slot if it follows the PCIe standard is not something that AMD can turn off. So no even if AMD wanted to stop Nvidia cards working on their motherboards, they can't. So giving them credit not not doing something they can't do anyway makes sense in what way?

It's the Northbridge in a computer than actually controls the PCIe slot in a computer. PCIe by itself is simply an interface and interconnect between a PCIe device and either the chipset Northbridge (in the case of graphics cards) or Southbridge (other devices).

Since AMD creates their own Northbridge (and Southbridge) chips, it would VERY easy for them to include a lockout that would prevent any Nvidia card from operating on an AMD based motherboard. Yes, PCIe slots are an industry standard, but the NB and SB chips which control those slots are very much proprietary.

Do I think AMD would ever do this? No. But the capability exists.

 

[Creig]

Don't tell me how to post, Creig. Your arguments remind me of evolucion8's; so what?

This is the third time that i called you on this and you ignored the first two times
:|

And you are still posting FUD. Nvidia did not need to give "permission" to Rocksteady. AMD finally worked with them on the GotY edition; there was never a patch made available for Batman that implemented AA for Radeons.
:thumbsdown:

I'll check it out. I was under the impression that there had been a patch released for the original version. I do not condone the intentional spreading of false information. If I was wrong, I will gladly post a retraction.

update - It appears you were correct. The only official patch seems to be the 1.1 that adds PhysX to the non-GoTY edition. What I read about turned out to be an unofficial one to add the MSAA for non Nvidia cards.

http://www.tommti-systems.de/start.html

 

[apoppin]

I'll check it out. I was under the impression that there had been a patch released for the original version. I do not condone the intentional spreading of false information. If I was wrong, I will gladly post a retraction.

Thank-you.

It was AMD that brought Batman AA GotY to my attention. It is in their own HD 5000 series reviewer's guide (for over a year) but NO tech site uses the GotY of Batman (aFaiK) nor has any site (except ABT that has) even brought attention to it.

My very next review, to be published early next week, will finally use Batman AA GotY to give an apples-to-apples comparison of HD5870/68x0 with 8xAA as set in game versus their GeForce counterparts (at 8xQ to be most fair)
:thumbsup:

 

[SirPauly]

It was good to see AMD pro-active getting in-game AA in there!🙂

 

[taltamir]

So was it illegal when Nvidia created the MSAA coding in Batman:AA that caused AMD cards to run slower than they should have while using FSAA?

1) Begin game
2) Begin MSAA calculations
3) Vendor ID check
4) If vendor = Nvidia, continue MSAA and display
5) If vendor = other, halt MSAA
6) Perform FSAA calulations and display

If I understood correctly, then the first sentence is saying that in addition to the above, the FSAA code has been modified such that FSAA on AMD renders slower that FSAA on nvidia, intentionally.

 

[exar333]

It was good to see AMD pro-active getting in-game AA in there!🙂

proactive [prəʊˈæktɪv]
adj
1. tending to initiate change rather than reacting to events
:hmm:

 

[SirPauly]

It was still good to see!🙂

 

[railven]

Creig seemed to understand my scenario best. Again, I didn't argue that it was right and I openly said if AMD every went that route I'd swear of ATI (being an ATI supporter.) That isn't my idea of a healthy competition.

My scenario didn't involve a lock out, ie nVidia hardware WOULDN'T work on AMD hardware, but because AMD controls that ecosystem (example of PhysX is created by nVidia and thus controlled by NVidia, AMD chipsets are created by AMD and ths controlled by AMD - and I included the loophole that third party vendors can have a field day implementing their own variations.)

My scenario was simple: AMD could implement a bottleneck/throttle in their chispets when a NON-AMD GPU is detected with the preface (ie a LIE, see nVidia's lie about why PhysX is disabled when non-Nvidia cards are detected) that because of the design of the new APUs the NB (chipsets) have to be synchronized specifically to a way that it is only 100% compatible with AMD GPUs. So when an Nvidia GPU is found, the system won't turn it off, but throttle it negating any performance advantages thus leaving the end user with a thought "Why bother with an nVidia card when it doesn't outperform an AMD card that is priced cheaper" due to the way the chipset was designed.

If one argues this is illegal, immoral, whatever, the same must be said to how nVidia handled PhysX - as much as you wish to argue they are different, they are exactly the same as in the vendor/creator controls the end result. A user doesn't benefit from having an nVidia card secondary to an AMD card in their system because of nVidia's method of handling PhysX.

Again, third party vendors can go their own route and suffer license rights, or whatever, but that is outside of the scenario I presented.

 

[golem]

Its is real semantics issue rather then me pretending to misunderstand. Semantics is the study of meaning. I was completely certain that you meant your statement to be "there are technical reasons why they can't do so". I replied with "actually its easy to do so, but there are legal reasons why they wouldn't and economic reasons why they shouldn't"
Had I been certain of what you meant but chose to intentionally misinterpret it to put you down I would have been a jerk and a fool, and "pointless semantics" or "splitting hair" would have been an appropriate response to such behavior.
Anyways, my apologies for misunderstanding.

No problem and thanks for the explanation.

 

[golem]

It's the Northbridge in a computer than actually controls the PCIe slot in a computer. PCIe by itself is simply an interface and interconnect between a PCIe device and either the chipset Northbridge (in the case of graphics cards) or Southbridge (other devices).

Since AMD creates their own Northbridge (and Southbridge) chips, it would VERY easy for them to include a lockout that would prevent any Nvidia card from operating on an AMD based motherboard. Yes, PCIe slots are an industry standard, but the NB and SB chips which control those slots are very much proprietary.

Do I think AMD would ever do this? No. But the capability exists.

The technical capability exist, but could they do and still market their wares as PCIe compliant if they did something like this?

Let me revise my point, since can't is too absolute a term. AMD doesn't do lock outs because it is illegal or not feasible from a business standpoint, not because they technically can't.

 

[Seero]

From what I remember, Nvidia produced the MSAA implementation and included the vendor ID check in it. This is what was given to Rocksteady to include in Batman:AA. Didn't Rocksteady themselves say that the code belonged to Nvidia and that Nvidia lawyers hadn't given permission for Rocksteady to remove the vendor ID check when it was requested that they remove the check?

True enough. I believe AMD actually said that since it was a standard implementation of AA, it should work on anyone's card.

Again, true. I'm not disputing any of the above. I believe the specific part you're not liking is:

I remember reading that AMD examined the coding in Batman:AA and found that the first part of the MSAA coding was still being performed on AMD cards, even though AMD cards weren't being allowed to display MSAA. Even if an AMD user forced FSAA through the control panel, it went something like this:

1) Begin game
2) Begin MSAA calculations
3) Vendor ID check
4) If vendor = Nvidia, continue MSAA and display
5) If vendor = other, halt MSAA
6) Perform FSAA calulations and display

It was the placement of the vendor ID check that AMD objected to. If it had performed the check before the MSAA calculations had started, there would have been no problem. But because the MSAA calculations were started then halted, it caused additional workload to AMD cards. Thus lower framerates. That's how I remember the situation.


Perhaps. Or it could have simply been a programming mistake. But it's still rather damning that the code which caused AMD cards to run slower in this title came from their direct competitor, Nvidia.

www.brightsideofnews.com

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

Now you believe that the "MSAA calculations" occurred when using AMD card, but are not able to enable MSAA because of "vendor ID check". You probably got this idea from the following quote

"'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...)!"

So basically he said that a) "Depth value" is being pass to alpha unconditionally, b) the code Nvidia code uses "Depth value", c) AMD code path doesn't require depth value to be passed to alpha all the time, and therefore d) your conclusion.

He however didn't explain what "Depth value" really is, but to laymen it means "MSAA calculation", which is not true. It boils down to this statement in quote:

because we're forced to write useless depth values to alpha most of the time...

However, that doesn't mean depth values are useless and only used by the MSAA code. In fact, the above statement is true as it has nothing to do with video card or MSAA but it is less efficient to selectively pass depth values to alpha.

It isn't about the technology, not programming, but playing with words. I don't know how good Richard Huddy is in terms of programming, but he is extremely good at playing with words.

In laymen's terms, without MSAA enabled, there are nothing that AMD cards need to do more than Nvidia cards. Benchmark on Batman shows that. That means,

because we're forced to write useless depth values to alpha most of the time...

is either a lie or really has no effect in terms of performance.

What was true was the fact that there exists a "video card ID check", which Richard Huddy worded as "vendor ID check", which is necessary because not all video cards can have MSAA enabled, regardless of vendor.

If the definition of open is so that someone, other than themselves, can develope new technology, programs and hardwares so that it also work on their hardwares, then AMD is surely open.

 

[Seero]

lock out Nvidia via chipset

They can do that, and they will do that. In fact, they probably have done that. Meet "Llano" and "Sandy Bridge".

Please do not be confused. No AMD product was sabotaged when Nvidia is present. Nvidia sabotaged themselves when the environment is incorrect.

AMD can release a chipset which all USB port will be disabled when a Non-AMD video card is present. I bet Nvidia will not have a problem with that.

 

[Obsoleet]

Who cares. NV is screwed with Llano and SB. They aren't Intel, Physx is not important like x86 instructions. The small-timers at NV have no weight to throw around.

 

[Lonbjerg]

Who cares. NV is screwed with Llano and SB. They aren't Intel, Physx is not important like x86 instructions. The small-timers at NV have no weight to throw around.

Even an "APU" is just as far behind a high-end GPU as IGP always have been.

I suspect people have way to high hopes about onboard graphics...and the performance "gains".

 

[railven]

Please do not be confused. No AMD product was sabotaged when Nvidia is present. Nvidia sabotaged themselves when the environment is incorrect.

Exactly my scenario, just the reversal. And in both situations with the accompanied hardware, performance suffers. So, yeah.