[SirPauly]

Originally Posted by Bouncing Zabaglione Bros.

Both cards do the work, but only the Nvidia card benefits with AA. ATI's cards do the work but don't get the benefits of improved visuals. It's just another way for Nvidia to trip the opposition with dodgy coding.

You say that but the performance without AA, well, the 4890 offered a lot more performance -- and a lot more performance. Where are you getting this detrimental from -- a quote?

Don't you think it may be prudent to see benches or performance numbers? Or you simply believe a quote on the surface and that's it?

[Freak'n Big Panda]

Originally Posted by Humus

And you base this on what?

That was a tounge and cheek way of me saying they don't have the money to do those sorts of things, but as evidence I didn't hear about any code being supplied to any developers when I was working in the mobile marketing department. Not that taht means much, very possible that it happened without my knowing, the mobile section is somewhat seperated from the desktop guys.

[Bouncing Zabaglione Bros.]

Originally Posted by SirPauly

You say that but the performance without AA, well, the 4890 offered a lot more performance -- and a lot more performance. Where are you getting this detrimental from -- a quote?

Don't you think it may be prudent to see benches or performance numbers? Or you simply believe a quote on the surface and that's it?

It's based on the "spill the beans article". Have you actually read it?

[jaredpace]

8xAA w/ vendor hack 61FPS
8xAA forced in CCC 53FPS
http://forums.anandtech.com/showpost...&postcount=103

[SirPauly]

Originally Posted by Bouncing Zabaglione Bros.

It's based on the "spill the beans article". Have you actually read it?

Yeah, and find it odd considering ATI offers more performance and you're still using detrimental strongly.

[Bouncing Zabaglione Bros.]

Originally Posted by SirPauly

Yeah, and find it odd considering ATI offers more performance and you're still using detrimental strongly.

It's the principle of it. Nvidia won't let Eidos remove the vendor-id lock on what is a standard bit of code, but they still ensure that ATI cards have to do AA work and lock out any ATI card from showing the AA.

You think we should thank Nvidia for still being slower despite doing that? How about people who only have lesser cards, where it makes a significant difference to playable framerates?

It's the same old cheating crap we've been seeing from Nvidia for years, and I'm quite frankly sick of it.

[Zaphod]

Originally Posted by Bouncing Zabaglione Bros.

Both cards do the work, but only the Nvidia card benefits with AA. ATI's cards do the work but don't get the benefits of improved visuals. It's just another way for Nvidia to trip the opposition with dodgy coding.

Well, that sucks, but that's also not what I meant. If Nvidia takes the same (or greater) penalty for that writing those useless depth values when running 'apples to apples' (i.e. without any AA), then there is no ploy to deliberately slow down ATI hardware. At worst that particular fact is "amusing". Bad code. Period.

Putting that vendor lock in the in the first place (and/or claiming copyright to in an attempt to fragment the market to the detriment of gamers everywhere) is just bad form to begin with, I'm not arguing that.

Just this: Never attribute to malice what could just as easily be attributed to stupidity.

[Bouncing Zabaglione Bros.]

Originally Posted by Zaphod

Just this: Never attribute to malice what could just as easily be attributed to stupidity.

So hang on - Nvidia write code, take the trouble of locking ATI cards out of it, but don't lock the whole thing, just the part that produces results, not the part that does the work?

I don't think so. Let's look at past performance from Nvidia, and then attribute the problem to malice, as that's so often been the case when dealing with Nvidia.

There's no point giving Nvidia the benefit of the doubt, as they've too often been found to be unworthy of it.

[SirPauly]

Originally Posted by Bouncing Zabaglione Bros.

It's the principle of it. Nvidia won't let Eidos remove the vendor-id lock on what is a standard bit of code, but they still ensure that ATI cards have to do AA work and lock out any ATI card from showing the AA.

You think we should thank Nvidia for still being slower despite doing that? How about people who only have lesser cards, where it makes a significant difference to playable framerates?

It's the same old cheating crap we've been seeing from Nvidia for years, and I'm quite frankly sick of it.

I think it is great that end-users can use AA in DirectX 9 -- Unreal, here, because there were many times many end-users couldn't. Let's not forget that important point. It's good to see nVidia and ATI both try here to improve the experiences for their customer base.

Hopefully, there may be some agreement or something that can solve this dispute. No, I don't like leverage at times and loathe it. Didn't like seeing it here or seeing nVidia PhysX GPU's being locked out with ATI GPU's --- try to understand but still bothered by it. I'd like to see nVidia bend a bit as I would like to see ATI be more pro-active.

They both can improve and be better to me for gamers as a whole.

[Sxotty]

Originally Posted by Zaphod

Let's accept the premise that ATI cards does some unnecessary legwork due to the Nvidia engineered AA implementation. Now, does Nvidia cards not do the same unnecessary work or does this work impact ATI cards to a greater degree? If yes, let's talk nefarious purposes; else it's just bad code.

That is why I posted what I did ages ago. The claim does not even make sense the way it was presented originally.

[Zaphod]

Originally Posted by Bouncing Zabaglione Bros.

There's no point giving Nvidia the benefit of the doubt, as they've too often been found to be unworthy of it.

Just because someone bribed the official doesn't mean they also poisoned the competition. The first thing is bad enough and any additional poorly construed conjecture just clouds the issue.

[Bouncing Zabaglione Bros.]

Originally Posted by Zaphod

Just because someone bribed the official doesn't mean they also poisoned the competition. The first thing is bad enough and any additional poorly construed conjecture just clouds the issue.

I think it clouds the issue when we ignore past performance and the company culture that allows this sort of thing to happen, and give Nvidia a clean slate every time. You stop giving people the benefit of the doubt when every time they take advantage of you for it.

Unless you consider Nvidia's coders to be incompetent, why else would the workload part of the code be allowed to run, but not the rendering part? Someone had the bright idea that they could slow down the competing cards in this way, just as someone had the bright idea that they could put a vendor lockout on a standard bit of code, put a copyright notice on it, and give it to Eidos whilst maintaining ownership and controlling what gets done with that code.

[Creig]

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

Do we know exactly what this "first step" is? Is it the bulk of the MSAA calculation or a minor performance hit?

[homerdog]

I'm still wondering, do NV cards perform this mysterious "extra step" when MSAA is not enabled?

[Sxotty]

Originally Posted by homerdog

I'm still wondering, do NV cards perform this mysterious "extra step" when MSAA is not enabled?

Exactly. Maybe they had to change something more fundamental in the engine so AA would be feasible later.

[Humus]

Originally Posted by DemoCoder

When I do patches of third party code, I often put these kinds of 'locks' around the code not because I truly want to lock out third party hardware, but because I don't want to be responsible for breaking the app on hardware I don't certify/test/validate for.

Having worked 3.5 years as an ISV Engineer at ATI / AMD in the past I can say that I never once took this approach. I've had my dirty fingers in a lot of engines and added code and optimizations, but never once did I add a vendor check to anything. However, I did on a few occasions remove vendor checks and replace with proper checks for support. Something breaking in the middle of development is not a big issue. I can't imagine this code was inserted the last week or something. Was there a problem QA would have caught it soon enough.

[Humus]

Originally Posted by Freak'n Big Panda

That was a tounge and cheek way of me saying they don't have the money to do those sorts of things, but as evidence I didn't hear about any code being supplied to any developers when I was working in the mobile marketing department. Not that taht means much, very possible that it happened without my knowing, the mobile section is somewhat seperated from the desktop guys.

Providing code or going on-site and adding it myself was the sort of thing I did all the time when I was there. It's certainly something AMD does and something I did all the time I was there. The assumption that some people seem to have (not saying you do) that some sort of laziness or reluctance from AMD's side is involved here is absolutely ridiculous. If they let the most important title of the year pass by without providing the most basic assistance the heads would be rolling in ISV Engineering team.

[Demirug]

Originally Posted by Creig

Do we know exactly what this "first step" is? Is it the bulk of the MSAA calculation or a minor performance hit?

Originally Posted by Sxotty

Exactly. Maybe they had to change something more fundamental in the engine so AA would be feasible later.

The trick is pretty easy.

The unreal engine needs for every pixel a depth value to render correctly. Reading back depth values isn’t supported at all for DX9. But nvidia and ATI have implemented some “driver hacks” to work around this limitation. Unfortunately this works only for nonAA depth buffers. Epic ignores this problem and therefore the engine doesn’t support AA by its own.
If you force AA by the driver the driver uses AA color and depth buffers but ensure that they look like non AA buffers for the engine. This is a heavy operation.

To support AA direct the engine was modified to write the depth value in the alpha channel. This requires some additional shader instructions. Later the AA color buffer is resolved to a non AA buffer and the depth value can be read from the alpha channel.

As the color buffer needs to resolve anyway they save the work to resolve the depth buffer that is needed by driver forced AA.

The reason why the write the depth value to alpha even without AA is simple. To disable this you need a complete additional shader set and implement a switch based on the AA state. Such a change would not be an easy quick hack.

[Davros]

Originally Posted by Humus

If they let the most important title of the year pass by without providing the most basic assistance the heads would be rolling in ISV Engineering team.

If only ati hadn't sacked you, i mean the donkey was consenting....

[mmendez]

Originally Posted by Demirug

The trick is pretty easy.
To support AA direct the engine was modified to write the depth value in the alpha channel. This requires some additional shader instructions. Later the AA color buffer is resolved to a non AA buffer and the depth value can be read from the alpha channel.

How does that affect transparency?

[MfA]

Why would it need framebuffer alpha for transparency?

[mmendez]

Originally Posted by MfA

Why would it need framebuffer alpha for transparency?

Sorry, I misread it.

[almighty]

Excellent read : http://brightsideofnews.com/news/200....aspx?pageid=0

[obonicus]

Some weird comments and comparisons there.

[homerdog]

Originally Posted by almighty

Excellent read : http://brightsideofnews.com/news/200....aspx?pageid=0

Originally Posted by Theo

Note that you can turn Anti-Aliasing on any Unreal Engine 3-based game from the nVidia ForceWare or ATI Catalyst Control Panels. Thus, thiswhole affair is a matter of user convenience and the ability to select an AA setting inside the game.