Horrible Framerate on NVIDIA cards

#1 Interesting. When we ran that demo on a GeForce 3 we got at least 30fps... Have you tried the OMEGA drivers? How does HalfLife 2 perform?

#2 I tested the official prebuilt Demo and it didnt have any issues... ran smooth.

I'm talking about the issues meant here:

www.garagegames.com/mg/forums/result.thread.php?qt=22487
www.garagegames.com/mg/forums/result.thread.php?qt=30464
www.garagegames.com/mg/forums/result.thread.php?qt=22574

after doing some experiments i can say the following:

The stuttering occurs when a portal connecting interior and exterior is in view (or at least if it isnt culled).
During that time the driver shows much activity and many cache misses with a move instruction.

Tom Spilman said about this:

Quote:
Next i fired off NVPerfHud. It shows a tremendous amount of time is being spent in the driver. When i use the T key to force 2x2 textures performance comes up to a respectable frame rate. So according to NVidia's docs that means i'm limited by texture bandwidth. Now i do have alot of large textures in the scene... but the 9800 seems not to mind.

I realized that when i get these stuttering i eventually get corrupted terrain textures too.
i had this captured on a pic:
www.rebtiel.net/rebtiel/ArtifactsInTSE.JPG
The awfull looking interiors have been fixed by adding materials to all textures used

but the terrain shows that some texture is missing and has been replaced by some solid yellow.
i even experienced this by switching from window to fullscreen.

[guessing]
Maybe the game looses its resources when said portals are in view and needs to reupload them. (Terrain textures would be my guess)
that would explain why 2x2 textures brings it to good framerates.
AFAIK is restoring resources a thing the driver has to handle and maybe ATI drivers do something different that prevents the textures from beeing uploaded from system memory again. (would explain why only Geforce Cards are affected)
[/guessing]

I'll have a dive into the code when i'm home and see if i can find something

I'm using 71.84 drivers on x64 OS.
Never played HL2... but Doom3 and Farcry ran smooth.

#3 I tried to define TERR_TEXTURE_DEBUG

during execution and while you move over the terrain you have a constant
allocating and deallocating of textures:

Quote:
-- allocTexKill 214 5226b60
++ allocTexMake 215 147f3eb0 (192, 160)@4
++ allocTexMake 216 147f3d70 (208, 160)@4
++ allocTexMake 217 146f44b0 (192, 176)@4
++ allocTexMake 218 146f4370 (208, 176)@4
-- allocTexKill 217 147f4770
-- allocTexKill 216 146f74d0
++ allocTexMake 217 147f4d10 (96, 160)@4
++ allocTexMake 218 147f4450 (112, 160)@4
++ allocTexMake 219 147f4770 (96, 176)@4
++ allocTexMake 220 5226d70 (112, 176)@4
-- allocTexKill 219 adfe1b0
-- allocTexKill 218 147db750
-- allocTexKill 217 147f3910
++ allocTexMake 218 147db750 (192, 112)@3
++ allocTexMake 219 f99dcb0 (200, 112)@3
++ allocTexMake 220 5226b60 (192, 120)@3
++ allocTexMake 221 147dbb20 (200, 120)@3
-- allocTexKill 220 147db880
++ allocTexMake 221 147f5050 (144, 128)@3
++ allocTexMake 222 146f76c0 (152, 128)@3
++ allocTexMake 223 147dbad0 (144, 136)@3
++ allocTexMake 224 146f6ee0 (152, 136)@3
-- allocTexKill 223 147f3600
-- allocTexKill 222 adfdc70
++ allocTexMake 223 adfe1b0 (160, 128)@3
++ allocTexMake 224 adfdc70 (168, 128)@3
++ allocTexMake 225 146f3b30 (160, 136)@3
++ allocTexMake 226 147f1fa0 (168, 136)@3
-- allocTexKill 225 146f9270
++ allocTexMake 226 147f3600 (120, 120)@3

I dont know if this is somehow related. It could be just the blending.

I'll continue to experiment tommorow

#4 Florian,

Just so you know, that terrain code is very, very outdated and probably buggy (though I've not tracked down the actual bugs). I will be revisiting it when I do my next round on the Atlas terrain code.

It was a quick port to give people something to work with until we finished Atlas. Now that Atlas is underway we can do a more thorough pass on it - which won't happen until TGE 1.4 is done.

Wanted to give you a head's up before you got into a thorough debugging session. Also, you might want to see if Atlas will do what you want, rather than messing with the legacy code.

Ben

#5 I'm just trying to make the old terrain "workable" again.

For our project Atlas is not an option right now because

1. we cant convert legacy terrain to Atlas without rebuilding from scratch
2. no ingame editors are available yet.
3. no holes possible in atlas terrain yet

We will convert to Atlas as soon as possible.

Until then our level artist needs to work with legacy terrain ...
which is almost impossible right now because of terribly low framerates.

So i will just keep looking for the weak point and see if i can fix it... i think that
terrain should run with more than 6fps on a Geforce 5600

#6 If i strip all shader effects except simple texture mapping from the spaceorc i get good framerates again. (i suspect the glow shader is the culprit)

in my project framerate gets back to 60fps if i remove specific buildings from the missionfile.

i currently investigate if there is a connection between low framerates and the map2dif.exe crashing on some buildings if i choose "extrusion test"

#7 Ok the slow orc rendering is actually not the orc but the gun he holds.

if I set the values in materials.cs like this I get good framerates again.

datablock Material(GunMetal)
{
   baseTex[0] = "demo/data/shapes/spaceOrc/gun_ID1";
   //bumpTex[0] = "demo/data/shapes/spaceOrc/gun_ID1_bump";
   cubemap = WChrome;
   pixelSpecular[0] = true;
   specular[0] = "0.58 0.65 0.71 1.0";
   specularPower[0] = 12.0;
   emissive[0] = true;
   glow[0] = true;
};

other bumpmapped objects render fine for some reason i dont know

EDIT: the cache misses i tested earlier were tested on the orcgun stuttering

#8 If you remove the orkbase from the mission file you get rid of the low framerates regarding portal from interior to terrain. The Tower that stands just outside doesnt need to be removed... it appears to have no effect on the framerate... in fact i placed about 20 of those towers and didnt have a major impact on my framerate.

only special interiors affect the framerate. Because i dont have the map file of this orkbase i cant test if "extrusion test" would crash on this.

#9 Good show.

I finally got the HEAD of TSE to compile and run... and when it did run it took off!

125+ FPS and didn't even break a sweat.

Nice to know its not TSE and just the old Demo code.

#10 Hello,

I know this is an old thread, but we the similar problem with TGEA on a Geforce 7600GT.
It seems that when we reach a specific overall texture size, the performance drops dramaticaly under 10 FPS.
We are using several 1024*1024 sized textures (both JPGs and PNGs), and the problem disappears either if we are downsizing them, or take out some of them. (for example we have about 30 1024*1024 textures on separate dts objects, and if we take out randomly 5 of them, this bug disappears.)
The strange is that, this problem does not affects ATI cards at all, tested with a simple RADEON 9600 128M, and X1950Pro 256M too.
We tried set Texture quality force low, and tested with the brand new drivers, but nothing have changed.

Has anybody something similar problem?

Thanks in advance

#11 Missing texture RAM.
ATI automatically uses hypermemory, something like virtual caching to RAM if VRAM isn't enough. does not sound fast, but makes a hell of difference on lower VRAM cards.

NVidia does not have such a mechanism.

What you could try is check which textures could be replaced by DDS (DXT compressed) textures as they hold their size on VRAM as well while jpg / png become of bmp size -> 4-6MB for a 1024x1024 texture.

What you might have been forgotton as well is that shadow and reflections need texture space as well. if antialias is enabled this will cost as well ...

#12 Thanks for the reply Marc--I wasn't even aware of that :)

Do keep in mind that 30 1024x1024 textures is a lot of texture data. A LOT.

#13 To marc: Could you explain how to use DDS for us? I have searched this forums, and found nothing useful. I use Constructor 1.0.2 to build my difs, and Constructor can not recognize this format. On the other hand, if I just simplely replace the png or jpg files with dds files, after loading the mission, the buildings loss their texture. It seems as if the dds file does not work in TGEA, however it can be used as bump map.
In fact,I have met the same question with Stephen, and I anxiously hope someone can help me out : www.garagegames.com/mg/forums/result.thread.php?qt=63645

Anyway, thanks.

#14 Just add a materials file and in it have it replace your texture with a .dds texture. Examle:

new Material(MyMaterialName)
{
   baseTex[0] = "~/data/interiors/mymaterialname.dds";
   mapTo = "mymaterialname";
};

You may not have to do the mapto with v1.01, not sure I haven't had much coding time lately. But previously it didn't auto detect the extension for DDS, but you could just map the dds to the material and it works fine.

#15 30 1024px textures is around 120MB of VRAM. Add a few shadowmaps, backbuffers, etc. and you're pushing 160mb or more.

DDS is good. Another option is just using slightly smaller textures. A 512px texture takes a quarter the space of a 1024px texture. Would cost only 30mb for those 30 textures then.

#16 Thank you for the answers, we converted the textures to DDS, and this is solved the problem.

Another problem arised when i tried to reskin with dds textures (setskinname). Everything was Ok with jpgs, but when i changed the materials to dds (and the material definitions of course), the skining not succeded, just solid white appeared on the model. But when i put the original jpgs back next to the new dds textures (same name, just extensions .jpg and .dds), the skining was OK, and the skin was the the new dds. It is strange, that the dds skining only works for me, when jpg textures with same name exists there too. When i tried to delete the old jpgs, the skin diseappeared again - i put back them, and skin was ok again (and the skin was the dds on the model).
But this maybe fit into an other topic.