I dont understand this WoW CPU/GPU bottlenecking..

[ChrisRay]

I just dont understand why this is occuring. I have actually encountered this problems in a few games as of late. But WoW is the one I have tested. So I thought I'd let you guys help me understand why something like this occurs.

My Test setup included. I did 4 preset scripted type runs for each setting and then divided my results by 4 and took the AVG. It worked out well and the margin for error was within 1 FPS.

Athlon 64 3800+ @ 2.4
Asus A8N SLI Deluxe
1 Gig DDR400 (Dual Channel)
6600GT SLI setup. (SLI was disabled)

I decided to keep SLI out of the comparison since it just confused me further. Anyway. The first thing that I thought was the game was GPU scaling to the resolution. But since I have noticed strange performance anomolies. I thought I'd do some more testing. Anyone else able to explain this? The game seems to scale with resolution but additional GPU performance doesnt seem to do the game any good. Why would this occur? I have also noticed things like this in other games as well. Obviously the only resolution thats benefiting from the higher clocks is the 1600x1200 resolution.

 

[OpenGL guy]

Looks like you are memory bandwidth limited until 16x12 then you are fill limited.

 

[Dave Baumann]

It'll be interface limited at 16x12 with only 128MB of RAM.

 

[OpenGL guy]

It'll be interface limited at 16x12 with only 128MB of RAM.

Except that the performance improved with increased engine speed.

 

[Dave Baumann]

You're right - a fillrate graph says not.

 

[Arun]

The biggest anomaly is those graphs don't even start at 0 anyway. It really makes it look a lot worse than it really is, I'm amazed so many websites use such ridiculous graphs nowadays.
Anyway, as OpenGL guy said, bandwidth is the limitation pre-1600x1200, and fillrate is as of 1600x1200. It's obviously impossible to say whether 1156x864 is CPU-limited, although the performance difference from 1280x1024 tells me it most likely isn't. There'd still be a slight reduction in maximum fillrate at 1600x1200, but that'd be explained by the lack of RAM most likely (not a total bottleneck, since obviously SOME textures could still be in video memory)
I'm not too sure what might be causing this though. Perhaps front-to-back ordered overdraw? Try testing without AF first, and then without AA but with AF.

Uttar

 

[ChrisRay]

The biggest anomaly is those graphs don't even start at 0 anyway. It really makes it look a lot worse than it really is, I'm amazed so many websites use such ridiculous graphs nowadays.
Anyway, as OpenGL guy said, bandwidth is the limitation pre-1600x1200, and fillrate is as of 1600x1200. It's obviously impossible to say whether 1156x864 is CPU-limited, although the performance difference from 1280x1024 tells me it most likely isn't. There'd still be a slight reduction in maximum fillrate at 1600x1200, but that'd be explained by the lack of RAM most likely (not a total bottleneck, since obviously SOME textures could still be in video memory)
I'm not too sure what might be causing this though. Perhaps front-to-back ordered overdraw? Try testing without AF first, and then without AA but with AF.

Uttar

Sorry I did not mean to mislead anyone with the graph. I dont think texture memory is "too" much of a concern. I noted when using Split Frame Rendering @ 1600x1200 with 4xAA/16xAF I get about 42 FPS on average. With 1280x1024 I also get 42 FPS on average with SFR. And of course @ 1156x864 I get decreased performance of about 45 FPS on average. Hinting at CPU limitation and SLI overhead.

Obviously. @ 1600x1200 4xAA/16xAF OpenGL Guy says it could be a fillrate bottleneck instead of bandwith. And SFR would also agree with these graphs and that conclusion. Though the lower resolutions confuse me a bit.

Anyway sorry about the graph. I should have left it at zero. But I wasnt trying to mislead anyone with performance or anything. I am also going to update it to include SLI results in just a moment.

*edit* Looks like I was a bit wrong about the SLI performance charactoristics. Keep in mind this in SFR. I'll try to test it without AF and AA later..

 

[Ailuros]

Frankly if a recent mainstream card turns out to be CPU bound with a AMD64/3800+, I really wonder what kind of CPU would be required to overcome that limitation.

It's not like it's that much different in the majority of games out there. The ridiculous part of the story is that I doubt that even an FX AMD would overcome said limitations right now.

 

[KimB]

Frankly if a recent mainstream card turns out to be CPU bound with a AMD64/3800+, I really wonder what kind of CPU would be required to overcome that limitation.

Well, one of the problems is that CPU's have progressed much slower in the past two years than they had previously. This was to be expected by the physics, but it seems that many in the industry did not expect such a slowdown.

This will probably continue to be a problem for a couple more years until multi-core CPU's start to get out to market, and game developers get used to designing games for parallel architectures. Once multicore becomes more viable, through a combination of software and hardware we'll be able to enjoy performance increases similar to the days of old, but it can't last forever (we need fundamentally different computing technology as soon as possible).

 

[GameCat]

The problem isn't really that CPUs are slow, it's that the graphics card hardly ever gets to do any work. WoW essentially has GeForce 1 geometric complexity, although I'm sure it consumes a fair amount of texture memory. That won't push any modern GPU unless you up the res to hit a fillrate ceiling. His CPU obviously isn't slow, it's just the only part of the system that sees any significant amount of work.

 

[ERP]

To me it looks like what your basically seeing is the GPU synchronised with the CPU, probably by a R/W lock in the command stream. So your limited by both the CPU and GPU.

It used to be pretty common in older PC titles, but you don't see it as much any more. MS went to great lengths to remove a lot of the "you can hurt yourself with this" functionality from the API.

 

[Pete]

The easiest way to test OGL's hypothesis would be to under/overclock the GT's memory, no? If you're not busy remaking graphs, I'd give that a try. You could skip 12x10 and just do the low and high res.

 

[ChrisRay]

The easiest way to test OGL's hypothesis would be to under/overclock the GT's memory, no? If you're not busy remaking graphs, I'd give that a try. You could skip 12x10 and just do the low and high res.

Oh I already had. actually @ 1156x864 the a 200 mhz memory drop does nothing. But @ 1280x1024 a 200 mhz memory drop results in a 2 FPS performance drop. So OpenGL guy is correct that there is a memory bandwith reliance. I am also going to take a wild guess and say the Unreal Engine performs similar to bandwith restrictions nay? As I have noticed similarities in the engine.

 

[KimB]

Oh I already had. actually @ 1156x864 the a 200 mhz memory drop does nothing. But @ 1280x1024 a 200 mhz memory drop results in a 2 FPS performance drop. So OpenGL guy is correct that there is a memory bandwith reliance.

Actually, I would say that's not the case. A 20% drop in memory bandwidth only resulting in a 5% drop in performance? Given the lack of a fillrate-related performance drop, the most logical answer is the one that ERP posted.

 

[ChrisRay]

Oh I already had. actually @ 1156x864 the a 200 mhz memory drop does nothing. But @ 1280x1024 a 200 mhz memory drop results in a 2 FPS performance drop. So OpenGL guy is correct that there is a memory bandwith reliance.

Actually, I would say that's not the case. A 20% drop in memory bandwidth only resulting in a 5% drop in performance? Given the lack of a fillrate-related performance drop, the most logical answer is the one that ERP posted.

So heres my question. If there is such CPU reliance, What other games tend to follow this trend? I also noticed some similarities with Unreal engines. Paticularly UT2004 and Unreal 2.. I didnt even notice this till I started working with SLI.

 

[KimB]

ERP's post wasn't so much about CPU-reliance, but rather inefficient load-balancing between the CPU and GPU.

 

[DOGMA1138]

this isnt realy related, but have you tested SLI preformance, in OGL vs D3D in WoW