The NVIDIA GeForce GTX 650 Ti Review, Feat. Gigabyte, Zotac, & EVGA

Compute Performance

As always our final set of real-world benchmarks is composed of a look at compute performance. As we have seen with GTX 680 other Kepler cards, Kepler appears to be significantly less balanced between rendering and compute performance than GF110 or GF114/GF116 were, and as a result compute performance suffers.  On the other hand, relative to the GTX 660 the GTX 650 Ti sacrifices a smaller portion of its compute performance than its ROP/L2/memory performance, so this may bode better for computer performance.

Our first compute benchmark comes from Civilization V, which uses DirectCompute to decompress textures on the fly. Civ V includes a sub-benchmark that exclusively tests the speed of their texture decompression algorithm by repeatedly decompressing the textures required for one of the game’s leader scenes. Note that this is a DX11 DirectCompute benchmark.

There really isn’t a lot to say here. The GTX 650 Ti is only slightly ahead of the GTX 550 Ti, never mind the GTX 560. Worse, it’s tied with the 7770 and well behind the 7850. Given the nature of the test, with cards on memory busses this small I believe we’ve run into a proxy test for memory bandwidth rather than compute throughput. Which just goes to show that all of that compute throughput is meaningless without the memory bandwidth and cache to feed the best.

Our next benchmark is SmallLuxGPU, the GPU ray tracing branch of the open source LuxRender renderer. We’re now using a development build from the version 2.0 branch, and we’ve moved on to a more complex scene that hopefully will provide a greater challenge to our GPUs.

Not surprisingly, the GTX 650 Ti loses to just about everything. SmallLuxGPU’s OpenCL renderer just doesn’t mesh well with Kepler and NVIDIA’s drivers. The resulting lead for the 7850 is nothing short of massive.

For our next benchmark we’re looking at AESEncryptDecrypt, an OpenCL AES encryption routine that AES encrypts/decrypts an 8K x 8K pixel square image file. The results of this benchmark are the average time to encrypt the image over a number of iterations of the AES cypher.

Unlike our previous OpenCL benchmark the GTX 650 Ti’s showing isn’t nearly as bad, but neither is it great. Both the GTX 560 and the 7770 are in the lead, but at least the improvement over the GTX 550 Ti is nothing short of amazing. At times NVIDIA’s problem isn’t where GTX 650 Ti is compared to last-generation cards, but rather it is compared to AMD’s strong Radeon HD 7000 series lineup.

Our fourth benchmark is once again looking at compute shader performance, this time through the Fluid simulation sample in the DirectX SDK. This program simulates the motion and interactions of a 16k particle fluid using a compute shader, with a choice of several different algorithms. In this case we’re using an (O)n^2 nearest neighbor method that is optimized by using shared memory to cache data.

Once more the GTX 650 Ti is in trouble. It can beat the GeForce 500 series, but even the 7770 is faster.

Finally, we’ll take a look at one last benchmark to our compute run with the benchmarkable version of the Folding@Home client. Folding@Home and similar initiatives are still one of the most popular consumer compute workloads, so it’s something NVIDIA wants their GPUs to do well at.

Here’s another case where memory bandwidth and L2 cache appear to be a problem. The GTX 650 Ti is much farther behind the GTX 660 than we would have expected, and even the GTX 560 can take a lead here. On the other hand memory bandwidth bottlenecking isn’t so bad that EVGA’s GTX 650 Ti can’t still take the lead over the other factory overclocked cards.