Ubisoft - paid in full by Nvidia?

[HurleyBird]

The pre-release benchmark for Lost Planet II, is also whats used in the final game. Returns the same results.
Not saying this is the case for HawXII, also AMD included Lost Planet II in one of their new slides thats leaked. So it seems they improved their tessellation performance to compare it to the gtx 460 , or they 'fixed' a driver for that game/benchmark. It would be interesting to see someone break down how the improvement was made.

My guess would be that either: LP2 uses one of the lower tesselation factors that HD68xx benefits from, or, AMD simply disabled tesselation for both cards

This is debatable.
I've been complaining about too low polycounts in games ever since the first T&L hardware was out (which drastically improved the polycount that hardware could theoretically handle, but games continued to be designed for low-end hardware with CPU-based T&L/consoles).

I also hate low polycounts, however, looking at say heaven benchmark, there isn't really a visible difference between normal and extreme tesselation. Like 8xAA (or even 4xAA) vs. 16xAA. There is however, a large performance difference. The problem with the way I've seen tesselation in games is that they only tesselate specific objects, and they apply a lot of tesselation towards those objects. I think the best middle ground is to apply tesselation to the entire scene, in a way that minimized geometry when it is not needed, and maximizing it when it is, instead of simply tesselating a few random objects to an extreme amount. In terms investment into tesselation, Nvidia is overkill, and AMD is underwhelming. I see the correct balance being somewhere in the middle.

 

[Scali]

What if you see this and this is your ideology but your boss comes in and says "well we're being paid by x-company and they want us to do this change because it makes their company look better" at that point you change your code to reflect this. When y-company comes around and says otherwise, how would you feel? And in their driver they make it so your original thought is implemented?

What would it matter how I felt about it?
If my boss decides that, this will be how the game is.
I could quit, but then someone else would just take over, and the game would be released like that anyway.

 

[Idontcare]

I don't consider those changes to the code.
Compiling (or re-compiling for that matter) is what a driver is supposed to be doing. As long as it remains true to the API specifications (input and output of every operation is according to specs), I see absolutely no problem with that. This is exactly what you expect from an optimizing compiler. And optimizing compilers are part of the DX/OpenGL API spec.

No, what I'm talking about is things like I'm specifying a 32-bit datatype, and the driver replaces it with a 16-bit one "because nobody can see the difference anyway, and our hardware happens to be a smidge faster". *I* decide whether or not people can see it. If *I* want a 16-bit datatype for that specific variable, then *I* will write that in my code. If I write a 32-bit datatype, that means I *want* a 32-bit datatype. I have my *reasons* for wanting that additional precision. I don't care whether or not whatever random IHV agrees with my choices for that precision.
If I run into performance problems on any kind of specific hardware then *I* will deal with that by supplying an alternative shader, if required.
See what I mean?

Wait, what!? D:

The gpu guys pull that crap?

I had assumed we were talking about taking liberties with the instructions while adhering to equivalent output.

But holy, that would irk me something fierce if they did what you are suggesting.

Do they (NV, AMD, or Intel) really do something so egregious? Or are you just making an extreme-case example to drive home the point?

In any event, yeah I get you. That would be so uncool if Microsoft intercepted the code from my compiled executables and elected to take liberties with what was actually requested of the CPU. (my code is finance related)

 

[Scali]

Fine explain it to me. Can you render to a MSAA texture with a stencil buffer and do a final resolve to another surface or not?

Yes, but what good would that do?

Whatever that guy is doing with 2x+ rendering is not what's going on here.

Yes it is, because he's doing *deferred* rendering.
This is where you first render your attributes into various textures, and do the final lighting/shading in screenspace, rather than directly (avoiding overdraw on the heavy shaders).
So you read back your textures before doing the final lighting... but in DX9 you have to resolve all your rendertargets before you can read them back in the lighting pass. *boom*, MSAA info gone, and you haven't even started shading yet! AA needs to be done AFTER shading. How?

 

[T2k]

Not with standard DX/OpenGL code, it's always non-standard extensions, generally as add-ons for an existing game.

Total bollocks.

 

[bryanW1995]

Read what I just said: I don't believe in fairytales that they can somehow give significant performance improvements without IQ degradation. So the 'better performance' isn't there in the first place.
Even with IQ degradation, these driver cheats rarely give more than a few % extra performance. So don't give me this 18 fps -> 33 fps nonsense.

I was actually exaggerating to make a point, as I'm sure you're aware, but idc's post shows a similar improvement. is cuda a "fairytale", too?

In fact, I use cuda to crunch DC, and that application relies on custom code that the original dev doesn't support. do you think the folding@home team would rather that everybody just not try as hard to cure cancer and use the default code?

 

[Scali]

Wait, what!? D:

The gpu guys pull that crap?

Yup, they do exactly that.
In fact, it gets worse...
In some cases they just replace your entire shader with their own. They don't even TRY to compile/optimize your code, they've just cooked up a 'better' one themselves.
The driver just detects your shaders by checking the process name and hashing the shader code you send to it, and then switch while nobody is looking.

I had assumed we were talking about taking liberties with the instructions while adhering to equivalent output.

But holy, that would irk me something fierce if they did what you are suggesting.

Do they (NV, AMD, or Intel) really do something so egregious? Or are you just making an extreme-case example to drive home the point?

Yes, nVidia, AMD, Intel (and others in the past) have all done this at some point, or are still doing it. I don't have to make up extreme examples... in fact, some of the stuff they pulled off, I honestly couldn't have come up with it if I tried.

One very obvious example of a total shader replacement at the time was the Nature test in 3DMark03. It ran everything with SM2.0 shaders, which ran very poorly on nVidia GeForce FX.
After a driver update, nVidia cards magically ran the test MUCH better.
However, upon closer inspection, the water had a very 'blocky' look... integer-like banding artifacts, while the original code used floating point datatypes (and looked perfectly smooth on ATi hardware, or nVidia hardware with older drivers). nVidia had replaced the entire water shader with a fixed-point equivalent!

They did a lot more than that too... Like exploiting the fact that the camera ran on a fixed path, so they could pre-program all sorts of geometry culling in the driver (and got caught because beta program members had a version of 3DMark03 where they could stop the benchmark and move the camera around... and look at a big black nothing).

See this article for the nasty details: http://www.extremetech.com/article2/0,3973,1086025,00.asp

 

[Scali]

I was actually exaggerating to make a point, as I'm sure you're aware, but idc's post shows a similar improvement. is cuda a "fairytale", too?

I already answered that.

In fact, I use cuda to crunch DC, and that application relies on custom code that the original dev doesn't support. do you think the folding@home team would rather that everybody just not try as hard to cure cancer and use the default code?

I think the folding@home team would be pretty pissed off if this custom code would send back wrong results all the time (in fact, GPU clients are a problem anyway, because a lot of people run on overclocked GPUs, which often have glitches... not a big problem if a pixel flashes in a game here and there, but it makes the entire work unit useless).

 

[Schmide]

Yes, but what good would that do?

Allow you to separate MSAA from HDR.

Yes it is, because he's doing *deferred* rendering.
This is where you first render your attributes into various textures, and do the final lighting/shading in screenspace, rather than directly (avoiding overdraw on the heavy shaders).

He's doing deferred rendering, but he's not doing MSAA.

So you read back your textures before doing the final lighting... but in DX9 you have to resolve all your rendertargets before you can read them back in the lighting pass. *boom*, MSAA info gone, and you haven't even started shading yet! AA needs to be done AFTER shading. How?

So you can't do the following 2 pass rendering?

Create Depth Stencil
Attach to MSAA texture render target
Render some objects with MSAA (pixels are accumleted for final resolve)
Blt to Final Render target (MSAA resolves all done once)
Attach Depth Stencil to Final Render target
Render HDR and items that don't need MSAA

 

[tijag]

QED should only be used if you actually offer proof of what you are saying. If what you say is true, than it is entirely possible that the Ubisoft coding makes AMD cards do more work than is actually required, and as such removing the unnecessary work speeds up tessellation.

My thoughts exactly.

Also... QED? really? Thats such an obnoxious thing to say.

 

[WelshBloke]

Really? This is what you are mad about?

When did Kyle become such a shill for AMD?

And why is every nV hit-piece posted and drooled over on this forum?

Well I at least you cant blame the red team for making the fuss.

 

[Scali]

Allow you to separate MSAA from HDR.

But we're talking about deferred rendering.

He's doing deferred rendering, but he's not doing MSAA.

Not in DX9 no, because he can't, as he explains. If he multisamples his G-buffer, it gets resolved before he can enter the shading pass. Hence he has to supersample it, so he won't lose the extra samples.

So you can't do the following 2 pass rendering?

Create Depth Stencil
Attach to MSAA texture render target
Render some objects with MSAA (pixels are accumleted for final resolve)
Blt to Final Render target (MSAA resolves all done once)
Attach Depth Stencil to Final Render target
Render HDR and items that don't need MSAA

You could do that, but it wouldn't be deferred rendering.
Deferred rendering is the operative word here, really.
Pretty much all DX9 titles that don't use deferred rendering, have MSAA, because it's very easy to implement, even with HDR.
But deferred renderers have this fundamental problem that they cannot preserve the MSAA data for the final shading/lighting pass. Which is why DX9 deferred renderers generally don't have any kind of AA, unless they use some kind of 'backdoor' implemented via driver extensions from nVidia or AMD.

 

[bryanW1995]

I already answered that.



I think the folding@home team would be pretty pissed off if this custom code would send back wrong results all the time (in fact, GPU clients are a problem anyway, because a lot of people run on overclocked GPUs, which often have glitches... not a big problem if a pixel flashes in a game here and there, but it makes the entire work unit useless).

not sure exactly how f&h does it, but in the past many DC users have tried to nerf the results to get extra credit for the work done. A typical solution is to send out the unit 3 times, if 2 of them agree and a 3rd is off, then the 3rd is invalidated and all that work was done for nothing. if none of the 3 agree then they send the WU out again. users know if they're getting errors and invalid data and can tune their machine accordingly. more importantly, cuda typically offers an enormous performance increase on a machine. typically a gtx 460 can do as much work as a highly oc'd i7 for example.

good thing you're not running F@H.


edit: this thread is hoppin'! 3 people posted while I was typing this!

 

[Schmide]

You could do that, but it wouldn't be deferred rendering.
Deferred rendering is the operative word here, really.

So semantically what's happening in the first render pass isn't deferred rendering? You're accumulating geometry for a final resolve.

I can't believe you're stringing all this out on a semantic technicality?

 

[Scali]

So semantically what's happening in the first render pass isn't deferred rendering? You're accumulating geometry for a final resolve.

I can't believe you're stinging all this out on a semantic technicality?

Well, we're talking about what Unreal Engine, or more specifically Batman:AA (what's in a name?) does.
So it's not a semantic technicality. Your hypotheses have nothing to do with what Batman:AA does, regardless of what label you want to attach to this technique.

Nice try though.
Or well, on second thought... not really. Basically what you're saying is this:
"It is possible to do MSAA in DX9 in certain ways" (obviously).
"Therefore, if Batman:AA would be completely rewritten, to use a totally different rendering technique, one that is compatible with doing MSAA in DX9, then you could theoretically have MSAA in Batman:AA through standard DX9 code".

I mean, uhhh, yea...

 

[Schmide]

Well, we're talking about what Unreal Engine, or more specifically Batman:AA (what's in a name?) does.
So it's not a semantic technicality. Your hypotheses have nothing to do with what Batman:AA does, regardless of what label you want to attach to this technique.

Nice try though.

WTF can you be more vague? The Unreal Engine doesn't allow HDR and MSAA in the same pass under DX9. The above technique does them in separate passes to achieve the desired result. As far as I know, this is what nVidia did in Batman and they labeled it MSAA.

All I can see is you playing semantic f-around f-around to cloud the issue. Nice try though?

 

[Scali]

What they do is something like this (ultra-simplified):
Stage 1:
- Render geometry to depth/stencil while at the same time using multiple render targets to store per-pixel colour, normal and other attributes.
Stage 2:
Render a fullscreen quad, using the per-pixel data collected in stage 1, running a pixelshader to light and shade every pixel on screen.

Problem being: how do you get the MSAA info from stage 1 into stage 2 in DX9?

Or if you prefer, from the horse's mouth:
http://www.pcgameshardware.de/aid,6...eeny-on-Unreal-Engine-3-and-UT-3/Spiele/News/

Unreal Engine 3 uses deferred shading to accelerate dynamic lighting and shadowing. Integrating this feature with multisampling requires lower-level control over FSAA than the DirectX9 API provides. In Gears of War on Xbox 360, we implemented multisampling using the platform's extended MSAA features. On PC, the solution is to support multisampling only on DirectX 10.

 

[Schmide]

What they do is something like this (ultra-simplified):
Stage 1:
- Render geometry to depth/stencil while at the same time using multiple render targets to store per-pixel colour, normal and other attributes.
Stage 2:
Render a fullscreen quad, using the per-pixel data collected in stage 1, running a pixelshader to light and shade every pixel on screen.

Problem being: how do you get the MSAA info from stage 1 into stage 2 in DX9?

Or if you prefer, from the horse's mouth:
http://www.pcgameshardware.de/aid,6...eeny-on-Unreal-Engine-3-and-UT-3/Spiele/News/

You don't! The MSAA is resolved before stage 2.

By fullscreen quad you're saying they're FSAA the scene then adding HDR??? From all the articles I've read they use a MSAA texture.

What you describe above (minus the fullscreen quad) seems more like the Half Life engine technique.

 

[Scali]

You don't! The MSAA is resolved before stage 2.

There is your problem. Stage 2 is the shading/lighting stage. Which is why Sweeney describes it as deferred shading.
Go over what I wrote again... Where are lights involved? Not in stage 1, are they? That's in stage 2. Stage 1 is just a 'gather' stage.

By fullscreen quad you're saying they're FSAA the scene then adding HDR??? From all the articles I've read they use a MSAA texture.

No, the fullscreen quad is for shading and lighting the scene in screen-space. I already mentioned that.
The first pass doesn't actually do any shading at all, and no lights are involved (apart from being used to position the shadowmaps, but not in any kind of lighting).
The second pass is where you determine the colour for each pixel. You have just already 'resolved' your geometry for each pixel, so you no longer need to render actual geometry. You just need to process each pixel, and a fullscreen quad will do for that (or actually a single clipped triangle, if we want to be pedantic).

You'll have to excuse me... when people like you come here with an alpha-male know-it-all attitude, trying to 'explain' to me how it works... I assume you are familiar with how Batman:AA's renderer works... so I don't bother explaining it in detail. I don't try to 'f-around'... I just assumed you knew what you were talking about.
Apparently you don't. That's not my fault. Seems like you're the one playing the game. If you had just come out and said "I have no idea how the Batman:AA renderer works, could you please explain me?" then I would have. But if you act like you're the expert, well, then I assume we can skip the basic background info, and get straight down to the AA implementation.

What you describe above (minus the fullscreen quad) seems more like the Half Life engine technique.

No, what I'm describing is deferred rendering/shading/whatever you want to call it.
Half-Life uses direct rendering, albeit with multipass/postprocessing here and there.

 

[Attic]

Moving back towards to OP. We haven't heard the response from Ubi yet, but this is the same company who released a DX10.1 patch for Assassins Creed and then recalled it when it showed AMD video cards beating Nvidia in benchmarks.

It doesnt put the nail in the coffin for Ubi in this case again shamefully hurting AMD users experiences for alterior motivations, but it does shed some light on what the company prioritizes and who perhaps is motivating these decisions.

Ubisoft doesn't need help looking bad regarding the DRM they have implemented, but this is the kind of thing that PC gaming needs to shed ASAP.

 

[Scali]

It doesnt put the nail in the coffin for Ubi in this case again shamefully hurting AMD users experiences for alterior motivations, but it does shed some light on what the company prioritizes and who perhaps is motivating these decisions.

Not so fast...
A few days ago, we had Richard Huddy complaining that nVidia was pushing over-tessellation, and there was no need to go beyond triangles that are 4 pixels.

Now (see SirPauly's link earlier in this thread) we have a statement that they are aiming to tessellate the triangles down to 6 pixels wide (so that would be well over 4 pixels total, since this is only the width, multiply by height...).
So this is well within what Richard Huddy suggested for tessellation limits.
Problem is, as I already said earlier... AMD's real problem is not the size of the triangles, but rather the amplification factor. This game uses very simple geometry as a basis for the tessellation down to 'normal' triangle count/size figures. So this still requires quite some throughput from the tessellator... And that is something that AMD doesn't have.
So Richard Huddy needs to figure out a new excuse now... His old one doesn't work, assuming the 6-pixel width and 1.5m polycount figures are accurate. Those aren't extraordinary figures... Crysis did that a few years ago already.

 

[extra]

Ahh Ubisoft...DRM, anyone? I think the only game I've bought by them was the original farcry...that was published by them, right? Same company that rolled back the 10.1 AC support, lol---sleaze at its best. Always makes me shake my head when companies try to make it so that software is artificially crippled on other company's stuff. In the industry I work in we have some big players that do that sort of thing all the time--which is great, because customers hate it and come flocking to us. All this is going to succeed in doing is helping AMD sell more cards...lol. Hell, next time I upgrade my video card, I'm going to switch to AMD in both my boxes (gf's box already has one), sick of the NV sleaze.

 

[Idontcare]

Yup, they do exactly that.
In fact, it gets worse...
In some cases they just replace your entire shader with their own. They don't even TRY to compile/optimize your code, they've just cooked up a 'better' one themselves.
The driver just detects your shaders by checking the process name and hashing the shader code you send to it, and then switch while nobody is looking.



Yes, nVidia, AMD, Intel (and others in the past) have all done this at some point, or are still doing it. I don't have to make up extreme examples... in fact, some of the stuff they pulled off, I honestly couldn't have come up with it if I tried.

One very obvious example of a total shader replacement at the time was the Nature test in 3DMark03. It ran everything with SM2.0 shaders, which ran very poorly on nVidia GeForce FX.
After a driver update, nVidia cards magically ran the test MUCH better.
However, upon closer inspection, the water had a very 'blocky' look... integer-like banding artifacts, while the original code used floating point datatypes (and looked perfectly smooth on ATi hardware, or nVidia hardware with older drivers). nVidia had replaced the entire water shader with a fixed-point equivalent!

They did a lot more than that too... Like exploiting the fact that the camera ran on a fixed path, so they could pre-program all sorts of geometry culling in the driver (and got caught because beta program members had a version of 3DMark03 where they could stop the benchmark and move the camera around... and look at a big black nothing).

See this article for the nasty details: http://www.extremetech.com/article2/0,3973,1086025,00.asp

[/shivers]

I feel like Will Ferrell in the movie Elf when papa Elf asks Buddy to look at the "clausometer".

http://www.entertonement.com/clips/...b-Newhart-Papa-Elf-Shockingly-Low-Clausometer

"oh my, that's shocking"

So...is this what these new drivers every 30days has been about? I always assumed they were fixing broken stuff, but it sounds like they busy themselves breaking the functioning stuff on occasion too.

 

[zebrax2]

I request that reviewers run a test with the said benchmark with both AMD and Nvidia hardware, keep the results on record then run it again when AMD release their driver level fix then do an image comparison of before and after and in comparison to nVidia. I think this is the only way to see whether this claim is actually true or not

 

[apoppin]

I request that reviewers run a test with the said benchmark with both AMD and Nvidia hardware, keep the results on record then run it again when AMD release their driver level fix then do an image comparison of before and after and in comparison to nVidia. I think this is the only way to see whether this claim is actually true or not

That is my plan. The benchmark is available after the game is released and the driver also.

Before the other posters get paranoid, "cheating" *used to* be a real issue. Both companies have grown up, matured and also watch each other very closely for this kind of optimization that Scali (and the rest of us) hates.

i don't see it getting worse. The devs themselves will "snitch" if their code gets changed; they watch for those things and they will often complain to the other IHV what happened. It then becomes embarrassing.

There are also some "new things" you guys are really going to LOVE .. something we have been asking for .. well, forever .. has been implemented. i think it is competitive, but they do listen to us .. and they compete against each other to give us the best experience on their HW.
:thumbsup: