GPU vs CPU "limiting" tests

[Jim Bancroft]

This is from anandtech's recent survey of HL2 performance on various graphics cards:

...Next let's take a look at at_coast_05, another very GPU limited test that has a good deal of NPC interaction as well as GPU limiting elements...

I've seen them mention "GPU limited" and "CPU limited" tests before, and I'm not quite sure what they mean? By GPU limited, are they saying the calculations taking place are bottlenecked by the GPU's hardware and that it's throttled as far as it can go? If so, does the spillover then force the CPU to pick up the pace, which provides a good baseline test to compare processors? Likewise, under what circumstances can you tell if a level or game scene is "CPU limited"-- when a Radeon X300 performs about as well as an X800?

 

[Insomniak]

Originally posted by: Jim Bancroft
This is from anandtech's recent survey of HL2 performance on various graphics cards:

...Next let's take a look at at_coast_05, another very GPU limited test that has a good deal of NPC interaction as well as GPU limiting elements...

I've seen them mention "GPU limited" and "CPU limited" tests before, and I'm not quite sure what they mean? By GPU limited, are they saying the calculations taking place are bottlenecked by the GPU's hardware and that it's throttled as far as it can go? If so, does the spillover then force the CPU to pick up the pace, which provides a good baseline test to compare processors? Likewise, under what circumstances can you tell if a level or game scene is "CPU limited"-- when a Radeon X300 performs about as well as an X800?

If a test is GPU limited, this means the app performance is limited by the power of the GPU (go figger!). In other words, the CPU nowhere near fully stressed while the GPU is running full tilt. What this means is that if one card happens to perform better than another in a test, then that card is more capable in that app, because performance is only different if the GPUs have different abilities (i.e. one is faster than the other).

CPU limited is the opposite. The GPU is hardly running any load while the CPU is getting held between a rock and a hard place. Thus, in this situation, differences in performance are due to the abilities of the CPU, and not other system components.

Basically, you want a test to be limited by the component you're testing - that way, you can tell the differences between the components by how they perform in that test, which ones are faster, etc.

And yes - when an X300 performs the same as an X800, you're looking at CPU limitation.

 

[Matthias99]

Originally posted by: Jim Bancroft
This is from anandtech's recent survey of HL2 performance on various graphics cards:

...Next let's take a look at at_coast_05, another very GPU limited test that has a good deal of NPC interaction as well as GPU limiting elements...

I've seen them mention "GPU limited" and "CPU limited" tests before, and I'm not quite sure what they mean? By GPU limited, are they saying the calculations taking place are bottlenecked by the GPU's hardware and that it's throttled as far as it can go? If so, does the spillover then force the CPU to pick up the pace, which provides a good baseline test to compare processors? Likewise, under what circumstances can you tell if a level or game scene is "CPU limited"-- when a Radeon X300 performs about as well as an X800?

A "GPU-limited" benchmark is as you describe -- a benchmark where the limitation on performance (by whatever metric you're using) is the speed of the GPU. GPU calculations do not "spill over" to the CPU (wtf?), so in a case like this, putting in a faster CPU will provide little or no performance increase.

A "CPU-limited" benchmark is one where the limitation on performance is the speed of the CPU. In these cases, increasing the GPU power (or reducing the effective GPU load, as by lowering detail settings or reducing display resolution) will not improve performance. For instance, in 3DMark01, performance with any modern video card (at the stock settings) is determined almost entirely by the speed of the CPU and RAM.

 

[VirtualLarry]

Originally posted by: Matthias99
A "GPU-limited" benchmark is as you describe -- a benchmark where the limitation on performance (by whatever metric you're using) is the speed of the GPU. GPU calculations do not "spill over" to the CPU (wtf?), so in a case like this, putting in a faster CPU will provide little or no performance increase.

Yeah. Although, if you read one of BenSkywalker's posts in a thread a few months ago about the "Cell" architecture-based consoles, he claimed that they were going to do just that. I don't buy it, there isn't isn't enough physical interconnect resources between chips to make that feasable, and would make the software development process quite a bit more complex. Curious if you thought if doing such a thing might be feasable, either now, or in the (semi-) distant future?

 

[Malak]

Well an x300 will never perform as good as an x800.

Although I only have a 3ghz P4 and it's clearly near the bottom in those charts, my average FPS is high enough that it doesn't matter. I won't notice the different if I were running an AMD 4000+, since my refresh rate is at 75hz anyway. I would have gone AMD if I could have, but at time of order there was no pci-e mobo for AMD, and it would have been more expensive to wait. But right now, I don't think I need higher. If and when I do, I can always OC.

 

[Matthias99]

Originally posted by: VirtualLarry

Originally posted by: Matthias99
A "GPU-limited" benchmark is as you describe -- a benchmark where the limitation on performance (by whatever metric you're using) is the speed of the GPU. GPU calculations do not "spill over" to the CPU (wtf?), so in a case like this, putting in a faster CPU will provide little or no performance increase.

Yeah. Although, if you read one of BenSkywalker's posts in a thread a few months ago about the "Cell" architecture-based consoles, he claimed that they were going to do just that. I don't buy it, there isn't isn't enough physical interconnect resources between chips to make that feasable, and would make the software development process quite a bit more complex. Curious if you thought if doing such a thing might be feasable, either now, or in the (semi-) distant future?

Well, Cell (a joint venture between IBM and Sony, and possibly some other folks, which is being used as the CPU and possibly part of the GPU in the Playstation 3, and possibly for future supercomputing efforts from IBM) does put a large amount of 'interconnect resources' between its processors (it is a scalable architecture consisting of a potentially very large number of relatively simple but very fast processors working together). For a while Sony was saying it would be used as both the CPU and GPU for the PS3 -- but recently it looks like they are going with a more conventional GPU designed by NVIDIA, and Cell will be used mainly as the CPU, and possibly in some sort of supplemental fashion for graphics rendering.

A hybrid CPU/GPU design is certainly *possible*, especially in a highly parallel system. GPUs are becoming more and more like CPUs (DirectX10, in particular, is supposed to add significantly to how programmable they are) -- at some point, they may be practically indistinguishable. When that happens, you might as well just have a whole bunch of "processors" that get allocated dynamically to do "CPU" or "GPU"-type tasks, and that are tied to the same shared memory. After all, a GPU is basically just a big hardwired SIMD vector processor (with some programmable elements added in the last few generations of GPU hardware), that happens to be hardwired to do 3D coordinate transformation and rendering calculations.

It certainly adds *considerably* to both hardware and programming complexity -- but the payoff would be a hugely scalable system with massive amounts of both CPU and GPU power, which could potentially trade off freely between them. I think a full-fledged commercial system like this is at least 4-5 years off, however.

 

[VirtualLarry]

Yeah, I kind of dismissed the probability of seeing something like that in the PS3, at the time, because unless the GPU and CPU shared the same die, the latency would be killer trading off in-progress calculations between the two. However.. since that time, NV came out with their PCIe video cards that use system memory (like AGP does), and they apparently managed to develop a design that largely hides the latency issue, so... I don't know, it could be possible, if not to dynamically swap calculations between computing units mid-stride, then, like you suggest, perhaps re-allocate/partition the available computing resources, perhaps on a per-frame basis, depending on scene-graph load metrics or something. That would be incredibly powerful and efficient, but I also tend to agree that such a thing is still at least a few years off yet. Either way, it will be interested once the PS3 is demoed. (sorry for the OT sub-thread)