4 ms·
At some point in the execution culling has to happen. It will always happen on the GPU so adding your own CPU based culling will lead to double checking and low
by sjtrny 12y ago
At some point in the execution culling has to happen. It will always happen on the GPU so adding your own CPU based culling will lead to double checking and lower performance in most cases. It only makes sense to do your own culling if your GPU doesn't do it or if you have some spatial partition system which can cull in bulk.
- to3m 12y agoI only ever worked on the Wii, but on that system CPU-based (coarse-ish) culling seemed to be usually the right tradeoff. The GPU was mostly OK, but its vertex throughput always seemed rather poor, particularly if you supplied lots of vertex attributes. The CPU on the other hand was pretty fast, with short pipelines and low-latency RAM. (I was always under the impression that the Wii was at heart just a Gamecube with a higher clock speed and some extra RAM, so I figure the same principles would apply.) While working on this game, I got some code that a colleague wrote for another product to pre-generate all the GPU commands offline, so things could be drawn with 0% CPU overhead. But once I'd merged it all in and got it working, the thing was actually slower! No good sending them all to the GPU and letting it deal with them, it turned out. It was faster to have the CPU carefully check each state setting and not bother the GPU with the redundant ones. (Sort-of disclaimer: Wii developers never got tools as good as the ones for the PS3 or Xbox360. In particular, there was very little visibility into the GPU's working, just some poorly-documented performance counters, and a Javascript tool that would estimate a per-vertex cycle count for a given set of vertex attributes. So it's possible I just got something wrong. And sadly I can't claim to be the sharpest tool in the box.)