Donnerstag • 30.03.2017 • 18:30 Uhr
 Neuigkeiten
 Artikel
 Downloadbereich
 Bildergalerie
 Forum
 PowerVR FAQ
 Suchmachine
 Mitarbeiter
 Impressum
 SGX544MP angekündigt
 Der aktuelle Stand
 zweiter SGX Artikel ...
 Die Videofähigkeiten...
 neue Treiber für Pou...
 neuer Treiber mit Ha...
 SGX - Aufbau, Techn...
 neuer Serie5XT Grafi...
 Apple und Intel inve...
 Mehrere weitere Lize...
 SGX - PowerVRs Shade...
 Interview mit ImgTec...
 Quack - das andere D...
 Hercules4500 AGP4x-M...
 Optionen des KYRO Tr...
 FSAA auf KYRO
 Nummer 5 lebt!
 Startpartition von W...
 MBX - Mobile Grafik
 Die Grafikfähigkeite...
 Vivid! - PowerVR Gra...
 Videologic Neon 250
 Geforce 6800 - the n...
 Beyond3d
 BluesNews
 Chrome-Center
 Hartware
 Imagination T.
 ParaKnowYa
 Planet 3dNow!
 PowerVR
 PowerVR-Ext.
 PVR Generations
 Tom's Hardware
 Videologic
 VoodooExtreme

3D Center


PowerVR

Imagination Technologies

Geforce 6800 - the next generation

I had mixed feelings about the specific game, ever since I first lay my hands on the demo. Don’t misunderstand me the graphics are breathtaking and the game is differentiating itself from other FPS games in terms of AI and physics, yet the demands it puts on systems in general are quite high in my opinion. I’ll come back to that one later on.

Cry Tek is close to releasing Patch 1.2, which enables Shader Model 3.0 for accelerators that support SM3.0 (currently only the NV40 line of products). There aren’t any differences in terms of image quality between the SM2.0 and SM3.0 path from what I’ve read or from what I was able to see when gaming with either/or. For the time being the SM3.0 path concentrates on performance increases for SM3.0 GPUs via pass reduction wherever possible.

Before I started writing this review I still had an Athlon XP2200+ and only 512MB host ram; a perfect opportunity to see how things look like on even lower end systems than this one. Please keep in mind that I had every in game setting set to the absolute maximum, 4x AA and 4x full trilinear AF set through the application (while the driver control panel was set to “application preference” and “high quality”). I used 1280*960*32 as my testing resolution, because albeit with both the XP2200 and 3000 the system still remains CPU limited, there isn’t a single chance that the game will be playable in higher resolutions than that, unless I tune down settings more than just a little.

Yes those are frames per second and I was looking at single digit frame rates more than often during each of the demos. In Regulator performance actually slightly decreased (~5%), Training and Volcano saw an interesting increase (~17-18%), while Research took literally off reaching a quite impressive 55% performance increase.

Interesting to note are the Triangle rates the log files deliver; let’s have a look how it looks like for Research specifically:

SM2.0 path:

Min FPS: 10.89 at frame 434, Max FPS: 36.65 at frame 713
Average Tri/Sec: 966368, Tri/Frame: 45955

SM3.0 path:

Min FPS: 23.16 at frame 89, Max FPS: 46.40 at frame 738
Average Tri/Sec: 855186, Tri/Frame: 26196

As a side note, Far Cry absolutely needs more than 512MB host ram; loading times are extremely long and the HDD is swapping more than just a lot during game play, causing way too many stutters, especially when the player is faced with opponents. Of course is a low end CPU not good enough either; let’s see how it ranges with identical settings on what I consider to be a mid-range CPU nowadays and 1024MB of host ram:

Gaming is a lot easier with that setup; most of the hard drive swapping is gone and the desktop doesn’t take ages to recover after you exit the game. Differences between the SM2.0 and 3.0 path are more or less in the same ballpark in Training/Volcano, Regulator sees now a 6+% performance increase and the differences in Research shrunk to 45% this time.

As it’s understandable performance in most occasions is quite normal indoors; as soon as you get outside though and the Polygon rate exceeds the 120-150K rate, it can get really nasty especially if highest quality filtering is being enabled.

The next thing I tried is to compare application full trilinear 4xAF, vs. driver control panel 4x “quality” AF, which utilizes the hybrid bi-/trilinear mode (see “brilinear”) and Anisotropic Optimisations enabled (texturing stage “0”= trilinear, stages “1-7” = bilinear). FarCry was configured to “trilinear” and 1xAF (note that I compared SM3.0 scores only this time):

The differences in according percentages are:

Training: +22.08%
Research: +16.72%
Regulator: +30.26%
Volcano: +37.15%

Would one now change to bilinear in the application and leave the CP options as above, there would be another healthy increase added. Problem being here that bilinear AF exposes in quite a few spots MIPmap banding, which I personally cannot tolerate.

The game is playable in 1280*960*32 if in game settings get tweaked in between medium to high settings and optimized texture filtering. The going gets still tough, because first person shooters need a bit more than 30-40fps averages to be considered absolutely “smooth”.

Last thing I tried was the Pier demo (from PCGH), also used by 3Dcenter in their recent artikel.

1280*960*32
Maximum in game settings
4xAA / 4xAF *
(*) trilinear/4xAF in game, driver CP= application specific, high quality

SM2.0 path = 26.34 fps
SM3.0 path = 27.79 fps

A 5.5% increase here between the two paths; nothing to write home about really.

Let’s see how it looks like if I switch to “quality” CP AF.

All other settings identical as above except:
(*) Trilinear/1xAF in game, driver CP= 4xAF, quality
(Only SM3.0 path performance compared):

SM3.0 path = 36.17 fps

Compared to the former SM3.0 score, that’s a healthy 30% performance increase.

Finally I compared point sprites vs. instancing with the SM3.0 path. To enable instancing you’ll have to set “e_vegetation_sprites_distance_ratio = 100”.

Sprites:

Play Time: 103.01s, Average FPS: 36.17
Min FPS: 29.32 at frame 2994, Max FPS: 48.68 at frame 1970
Average Tri/Sec: 5464713, Tri/Frame: 151073

Instancing:

Play Time: 115.76s, Average FPS: 32.19
Min FPS: 22.97 at frame 823, Max FPS: 48.42 at frame 1949
Average Tri/Sec: 11141941, Tri/Frame: 346156

Performance decreases only very little compared to the increase in triangle ratios between the two cases. While with sprites the Tri/Frame ratio peaked at somewhere around 200+k Tris, with instancing it almost touched the 800k rate in some spots. Instancing makes objects in the far clipping distance look quite a bit better, yet the very high polygon rates also slightly increase texture aliasing.

For the end I asked Demirug for his opinion about Far Cry in general:

“Show me the island
We probably all agree that Far Cry's Cry Engine can render some very complex environments. We won't try to dispute that fact. However, unfortunately, Cry Tek doesn't deserve much praise regarding efficiency in using gamers' PC's scarce computing resources. You're in for some unpleasant surprises if you capture and analyze Far Cry's communication and the graphics API, using the proper tools.

The concerns start with the crosshair. It's composed of five small lines and the engine renders these lines separately, one by one. In terms of CPU load it doesn't make much difference how much geometry is rendered per API call but it sure does matter how many API calls are made in total**. This is but the first sign of CPU time being spent carelessly. More of the same - with more significant performance implications - can be observed in the engine's terrain rendering. Terrain is split in tiles, which isn't a bad idea actually. However, each of those tiles is split again, into strips, which get rendered individually. Thus the CPU has to do a lot of unnecessary work to render each tile, even though one call per tile would have been perfectly sufficient.

This isn't a big deal as long as the CPU is much more powerful than the GPU. But then GPU performance isn't used carefully either. Naturally lighting calculations are quite complex and it’s crucial to minimize these calculations. Far Cry has the tendency at this point to constantly conduct a large number of lighting calculations, for objects that end up being overdrawn. The lighting calculations themselves aren't optimal either. Each light source gets rendered individually. Consequently the workload for reading out textures is repeated for every light source. The maximum allowed instruction count for 2.0 class shaders is an obvious problem here. But these shader length limitations aren't as bad as to require rendering every light one by one. Far Cry does exactly this, all the time, even though a (small) number of lights could be rendered in a single pass in many instances with PS2.0. With chips that allow longer shaders such as the GeForce FX line, or the new Radeon X800, all lights could always be rendered in one single pass.

Each one of my concerns is only a minor offense against optimisation rules when reviewed in isolation, but they pile up. With the new patch some of these problems get addressed, but unfortunately only for users with SM3.0 capable cards. Everyone else is left only with the currently unoptimized SM2.0 path.”

UPDATE:
In the meantime Cry Tek released (and has withdrawn again) the 1.2 patch. Apparently it does contain a SM2.0b path for R420 class accelerators.

Seite 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
 Geforce 6800 - the next genera...
 17 Seiten
 verfasst von Ailuros
 Donnerstag - 26.08.2004 - 18:20 Uhr
[1]  Introduction & Systemsetup
[2]  Antialiasing & Anisotropic Filt...
[3]  2. Anisotropic filtering
[4]  Synthetic Applications
[5]  F1 2002
[6]  Rallisport Challenge
[7]  Serious Sam: The Second Encount...
[8]  Need For Speed: Underground
[9]  Unreal Tournament 2004
[10]  Far Cry
[11]  Hybrid Super-/Multisampling Mod...
[12]  Hybrid Super-/Multisampling Mod...
[13]  2D, DVD / VIDEO Playback
[14]  Summary
[15]  Softmode
[16]  doom3
[17]  DVD