OK, the story: a customer reports heavy performance problems with our 3D system on a GF3. I'm bored, so I decide to investigate the thing. I take my second PC (the only one with Windows), and pop in an old GF4 Ti4800 I still had lying around. OK, that's not a GF3, but our engine uses the same codepath for both, so the problem should be reproducable. AMD XP 2800, Windows 2000, 1GB of RAM, and the said GF4, running on older 53.03 drivers. I load the customers scene, and get around 130 fps. Hmm, seems fine to me. So I check the customers logs, and notice that he used the newest drivers, 66.93, also under Windows 2000. OK, no problem, I download and install them. I restart the engine - and get 11 fps on the exact same view !! WTF. I downgrade to 61.77: 17 fps... Finally back to 53.03: 130 fps. Peformance gets worse, the newer the driver. Great. Something is seriously messed up here. It seems to be a problem with VAR and/or VBO. When using standard vertex arrays, performance is approximately the same on all drivers. When using VAR, performance is near optimal on 53.03, but decreases exponentially within the 6x drivers. VBO again is near optimal on 53.03, and decreases also, but not nearly as bad as VAR. With the VBO codepath, I get around 40 fps on the 66.93 drivers - still better than the 11 fps with VAR, but still lightyears away from the 130 fps of the 53.03 drivers. Did anyone else notice very bad performance on GF3/GF4 cards with the 6x driver series ? That's really a problem, I need to find a workaround asap - other than telling our customer to install 53.03... Any help or hints are appreciated ! [Edited by - Yann L on December 30, 2004 1:58:53 PM]

I'm windows xp sp2, GF2, with 66.93 installed. If it helps, and if you have some application I can run to test, throw me a linky.

Quote:Original post by owl
I'm windows xp sp2, GF2, with 66.93 installed. If it helps, and if you have some application I can run to test, throw me a linky.

Thanks for the offer, but it's a commercial application, so I can't give it out.

Quote:
I noticed a much worse thing with these damn 6x drivers - none (I mean not a single!) of my IM programs worked! I use IM for some proof-of-concept things sometimes and I was shocked. Instead of the expected scenes I just got weird polygon garbage... I only noticed this because I didn't had my Radeon card for a few days and thus installed a GF4 with the latest (and obviously totally messed up) drivers.

Hmm. I tried an FX5900, and didn't experience any significant slowdown with 66.93.

I guess Nvidia is optimizing every last bit out of their Doom3 performance, while forgetting to keep good performance and compatibility with older hardware. I'm afraid that I might be using a driver codepath that used to be accelerated, but isn't anymore in the new drivers. Gah. If you don't copy Carmacks OpenGL coding style, you're basically fucked. I never had such problems with ATI.

*sigh*

I would still be interested in some more experiences with 6x drivers and GF3/GF4 cards. I would like to make sure it's not a hidden bug in my engine.

Quote:Original post by Yann L

Quote:Original post by owl
I'm windows xp sp2, GF2, with 66.93 installed. If it helps, and if you have some application I can run to test, throw me a linky.

Thanks for the offer, but it's a commercial application, so I can't give it out.

lol, I never expected such a thing :) Is something out there that I can quickly downlad to test VBAs VBOs? I don't have anything of that sort in this machine.

Can you run VTune and see where the slow-down is?

Perhaps they changed the location of your VBO and VAR memory, so it's now in VRAM instead of AGP? If that's the case, and especially if you don't overwrite every byte of the entire array sequentially, you may be suffering write combiner (fetch buffer) performance penalties when re-combining write lines.

Quote:Original post by hplus0603
Can you run VTune and see where the slow-down is?

Will do that tomorrow. I need to find the reason for this.

Quote:
Perhaps they changed the location of your VBO and VAR memory, so it's now in VRAM instead of AGP? If that's the case, and especially if you don't overwrite every byte of the entire array sequentially, you may be suffering write combiner (fetch buffer) performance penalties when re-combining write lines.

It's always been in VRAM, on purpose. My engine works a little different from other common ones. I use an associative and adaptive caching system for onboard memory management. But for the purpose of this test, all VBO/VAR data was completely static, nothing was dynamically updated. Basically: "bind static buffer, set pointers, render, repeat". The fact that something so simple fails so miserably makes me worry. I even made it fallback to the basic fixed function OGL 1.1 combiner path, without any shaders. No difference.

I might try to strip it down until I isolated the problem in a very small piece of code, that I could upload for public testing (and eventually send to NV, should the bug be confirmed).

Although I'm now 100% positive, that the problem is with VBO and/or VAR. With simple VAs, the performance is equal among all driver versions I tried.

Bah, this thing is frustrating. I'm off to bed now, will test more tomorrow.

sorry cant help, but with a gffx5900/5200 ive never had problems with VBO's drivers 5X. -> 7X.
whats your data types, verts3/4 texcoords2 color?
did u check the performance pdf's at the nvidia website, they also have a couple of vbo's ones from memory (not sure if they recommend what data to use)
IIRC theres also a old gf3 performance pdf at the nvidia site (might have it on my HD if u cant find it)