This game also supports Nvidia's PhysX, with some nice GPU-accelerated add-on effects if you have a GeForce card. Processing those effects will put a strain on your GPU, and we're already testing at some pretty strenuous settings. Still, I've included results for the GeForce GTX 295 in two additional configurations: with PhysX effects enabled in the card's default multi-GPU SLI configuration, and with on-card SLI disabled, in which case the second GPU is dedicated solely to PhysX effects. It is possible to play Sacred 2 with the extra PhysX eye candy enabled on a Radeon, but in that case, the physical simulations are handled entirely on the CPU—and they're unbearably slow, unfortunately.
You can see the performance hit caused by enabling PhysX at this resolution. On the GTX 295, it's just not worth it. Another interesting note for you... As I said, enabling the extra PhysX effects on the Radeon cards leads to horrendous performance, like 3-4 FPS, because those effects have to be handled on the CPU. But guess what? I popped Sacred 2 into windowed mode and had a look at Task Manager while the game was running at 3 FPS, and here's what I saw, in miniature:
Ok, so it's hard to see, but Task Manager is showing CPU utilization of 14%, which means the game—and Nvidia's purportedly multithreaded PhysX solver—is making use of just over one of our Core i7-965 Extreme's eight front-ends and less than one of its four cores. I'd say that in this situation, failing to make use of the CPU power available amounts to sabotaging performance on your competition's hardware. The truth is that rigid-body physics isn't too terribly hard to do on a modern CPU, even with lots of objects. Nvidia may not wish to port is PhysX solver to the Radeon, even though a GPU like Cypress is more than capable of handling the job. That's a shame, yet one can understand the business reasons. But if Nvidia is going to pay game developers to incorporate PhysX support into their games, it ought to work in good faith to optimize for the various processors available to it. At a very basic level, threading your easily parallelizable CPU-based PhysX solver should be part of that work, in my view.