FarCry Performance Revisited: ATI Strikes Back with Sh 2b

jimmyjames123 said:
Does anyone know why FarCry doesn't include any provision for SM 2.0a for the GeForce FX series, but includes provision for SM 2.0b? ;)

As Demirug points out, neither of the PS3.0 or PS2.0b shaders are actually to complex to fit within the PS2.0a model in the first place, so you need to ask why they did the initial release patch as SM3.0 only... ;) ( :rolleyes: )

Of course, they ran with fewer PS2.0 shader on FX in the first place, probably for performance reasons. Adding longer PS2.0a shaders is not going to make it faster and so they probably decided not to add them on that same performance basis.
 
martrox said:
The problem I have with the 3.0(nV) pic is that some of the trees are much darker, looking like there's no light on them....it just looks wrong.

Undoubtably a bug. There's quite a few trees standing next to each other, that should receive similar lighting, where one is dark, and the other is light. If you compare to the ATI's, then the trees are lighted equally.

Guess that's one of those "some other minor things" xibitlabs is looking into... ;)
 
jimmyjames123 said:
Does anyone know why FarCry doesn't include any provision for SM 2.0a for the GeForce FX series, but includes provision for SM 2.0b? ;)

Because nVidia doesn't care about NV3x users anymore.

BTW I noticed that performance is down across the board for the x800's in comparison to their previous article about the Farcry SM3 improvements. Even with SM2b pathway, its still slower than in their previous article with the 4.6s (Which is even more depressing when you think about it since 4.7s sorta speed things up a slight bit). Is ATI striking back with slower performance now? That's a new twist.
 
DaveBaumann said:
As Demirug points out, neither of the PS3.0 or PS2.0b shaders are actually to complex to fit within the PS2.0a model in the first place, so you need to ask why they did the initial release patch as SM3.0 only... ;) ( :rolleyes: )

Hmm... I wonder if Crytek actually knew that the Radeon's could do things like instancing. Could you give us an educated guess Dave? ;)


As for the pixel shaders.... I wouldn't be surprised if they 'just' tried to see where improvements could be made with new techniques. Which logically means looking at PS3.0, and then found out that all the usefull stuff just happened to fit in PS2.0b also.

We can talk about them not putting all possible new renderpaths in the patch immediately... But eh... It's not even officially released yet, is it?
 
Ylandro said:
Hmm... I wonder if Crytek actually knew that the Radeon's could do things like instancing. Could you give us an educated guess Dave? ;)

Nobody did until fairly recently - especially developers. Instancing is tied to VS3.0 so the method for detection of instancing should be whether VS3.0 is there, which of course its not with R300/420. The method that ATI have used circumvents the normal detection and is non-obvious, so it will need to be talked about specifically with developer to support it (unless MS makes another change to the API).
 
Ylandro said:
martrox said:
The problem I have with the 3.0(nV) pic is that some of the trees are much darker, looking like there's no light on them....it just looks wrong.

Undoubtably a bug. There's quite a few trees standing next to each other, that should receive similar lighting, where one is dark, and the other is light. If you compare to the ATI's, then the trees are lighted equally.

Guess that's one of those "some other minor things" xibitlabs is looking into... ;)

nVidia have had lighting issues in Farcry since the 5xxx range. There were topics dedicated to things being dark and then when you got close enough all of a second going light.
 
Maybe they just captured a wave in the nV screenshot?

Lezmaka, Ylandro addressed the extra trees in the SM2.b/3.0 shots a few posts above yours, while clarifying trinibwoy's observation. Xbit manually extended the 3D tree line to its maximum value.

Ylandro, what's with that last rolleyes?

Quitch, didn't that used to happen just with rocks, or also with trees? I notice that the nV shot also seems to have darker grass, which seems to be related to the darker trees.
 
DaveBaumann said:
jimmyjames123 said:
Does anyone know why FarCry doesn't include any provision for SM 2.0a for the GeForce FX series, but includes provision for SM 2.0b? ;)

As Demirug points out, neither of the PS3.0 or PS2.0b shaders are actually to complex to fit within the PS2.0a model in the first place, so you need to ask why they did the initial release patch as SM3.0 only... ;) ( :rolleyes: )

Of course, they ran with fewer PS2.0 shader on FX in the first place, probably for performance reasons. Adding longer PS2.0a shaders is not going to make it faster and so they probably decided not to add them on that same performance basis.

If I am using the SM3 path on a NV35 it is faster than the SM2 Path. A longer shader is slower than a short shader but you will need two or more short shaders for on longer shader.

The 2B Path is slower because it did not contain any PP Flag. Will do some tests with 2B Path and PP Flags after my new development system is running.
 
If I am using the SM3 path on a NV35 it is faster than the SM2 Path. A longer shader is slower than a short shader but you will need two or more short shaders for on longer shader.

Is that the NV3x SM2.0 path?
 
DaveBaumann said:
If I am using the SM3 path on a NV35 it is faster than the SM2 Path. A longer shader is slower than a short shader but you will need two or more short shaders for on longer shader.

Is that the NV3x SM2.0 path?

Yes, but the Patch 1.2 version of the NV3X path. I am run the NV40 SM2 Path too but there are no real difference between NV3X SM2 and NV4X SM2 on a GFX 5900.

Maybe a SM2B PP version is faster because the SM30 path do the fog calculation in the pixelshader. SM2B use the fixed function fog.
 
In theory SM2.0B should be slower on NV40, as it will be producing output tuned to ATI R4x0 architecture. Things like scaler/vector pipelining. Same as SM2.0A shaders (that work) are slightly slower than SM2.0 on ATI R3x0 (SM2.0A prefer register reduction over instruction reduction, the opposite of SM2.0)
 
DeanoC said:
In theory SM2.0B should be slower on NV40, as it will be producing output tuned to ATI R4x0 architecture. Things like scaler/vector pipelining. Same as SM2.0A shaders (that work) are slightly slower than SM2.0 on ATI R3x0 (SM2.0A prefer register reduction over instruction reduction, the opposite of SM2.0)

I know this but it looks like that the driver is getting better with each release in doing this job if the HLSL compiler didn't.

Adding some code that will set PP flags takes not much time.
 
I too was concerned about the lighting but I just loaded the map up and it looks fine to me. Heres a screenshot. (Im running a 6800GT). http://img78.photobucket.com/albums/v312/Biff00a/FarCry0057.jpg
Sorry about the resize, I had to because my webspace doesnt allow over 200K images. It was originally running in 1600x1200.

Also about the waves not being there on the x800 card. Thats a common problem I've noticed with my 6800 as well. The Far Cry game sometimes sets the water level to "custom" without you knowing it and it makes the waves not appear. That does concern me though because if they benched the cards with one set at custom and the other at ultra high water levels the numbers wont be valid.

Sys info:
DX9C official (Just released)
61.76 drivers (Hacked SM3.0 support in the disp.inf)
Evga 6800 GT
New fxc.exe in bin32/ folder (From the DX9C SDK -- Supposedly required in order to compile the 3.0 shaders)
 
Pete said:
Um, Dave (and others), I thought the X600 was just a 9600 on PEG. It can support PS2.b? If so, why is it designated RV3x0?

I think the architectural difference between the previous ATi line and the new one is not much since there really isn't much to add from going to SM 2.0 to SM 2.0b. Adding new instruction sets for SM 2.0b shouldn't be hard at all for ATi with just tweaking.
 
Ylandro said:
No, it's not the beach itself. The area that's affeacted seems to be a blending of water and beach.

Haven't played the game, but I guess that's a part where the water is transparant? Maybe that's going wrong? Would also explain the behaviour on the steep rock wall on the right.
Weeee, see theres the catch.
You havent played the game, yet you feel you can comment on it?

What you are seeing in teh NV40 pic is the WASH of the waves... unlike other games the water doesnt just end... it washes up in white foam on the beach. Its just a matter of timing...

good god - the internet, where EVERYONES an expert...
(even those that dont admit to being, sheesh)
 
PoGGeh said:
Ylandro said:
No, it's not the beach itself. The area that's affeacted seems to be a blending of water and beach.

Haven't played the game, but I guess that's a part where the water is transparant? Maybe that's going wrong? Would also explain the behaviour on the steep rock wall on the right.
Weeee, see theres the catch.
You havent played the game, yet you feel you can comment on it?

What you are seeing in teh NV40 pic is the WASH of the waves... unlike other games the water doesnt just end... it washes up in white foam on the beach. Its just a matter of timing...

good god - the internet, where EVERYONES an expert...
(even those that dont admit to being, sheesh)

Please read my above post, Its not that the foam was just receeded. Before the first wave receeds fully the second wave already picks it up. So you ALWAYS see some white foam washing on the beach.

The problem is Far Cry sometimes changes the water level to "custom" instead of "Ultra High". This custom mode removes the foam. Its not a vendor specific problem. It is a Far Cry problem that the Devs should look into. In this screen Im about to post you can see what I am talking about. I waited until you could see the least of the foam. As you can see it is never truely "not there". It also better shows the lighting issue is not present on my machine. Click the picture for a 1600x1200 shot.

4XAA/16XAF:
<A HREF="http://img67.exs.cx/img67/6325/FarCry0057.jpg">
FarCry0057.jpg
 
Any of you guys pick this up??

-------------------

Ubisoft has taken the decision to withdraw this patch due to issues experienced by a number of users. An official statement follows:

"Far Cry patch 1.2 has shown unexpected behaviour on specific hardware configurations. These matters are mainly due to incompatibilities with several optimisations brought lately to the code, with the intent to please a large number of users.

We’re currently asking CRYTEK to work on delivering a new patch as soon as possible. Until then we have decided to remove the patch 1.2 from the official UbiSoft websites."


http://www.farcry.ubi.com/index.php
 
Back
Top