Trinity, Llano, Sandy Bridge, and Ivy Bridge all dedicate a substantial chunk of their die area to graphics. And, with the exception of Llano, they all have special-purpose video transcoding logic, as well. We sought to unleash all of those extra transistors in a few general-purpose applications, to see if the competitive picture would change at all.
LuxMark OpenCL rendering
We've deployed LuxMark in several recent reviews to test GPU performance. Since it uses OpenCL, we can also use it to test CPU performance—and even to compare performance across different processor types. And since OpenCL code is by nature parallelized and relies on a real-time compiler, it should adapt well to new instructions. For instance, Intel and AMD offer integrated client drivers (ICDs) for OpenCL on x86 processors, and they both claim to support AVX. The AMD APP ICD even supports Bulldozer's distinctive instructions, FMA4 and XOP.
First, a word about those missing bars in the graph. Sandy Bridge's HD 3000 integrated graphics lack OpenCL support, so we couldn't run LuxMark on the Core i7-2670QM's IGP. Also, the AMD processors don't support Intel's ICD driver, so we were only able to run LuxMark on their integrated Radeon HD graphics and on their CPU cores using the AMD APP ICD. Ivy Bridge is the only processor that supports both AMD and Intel ICDs and has the ability to execute OpenCL code using its integrated graphics.
As we saw in our Ivy Bridge review last month, AMD's APP ICD yields better results than Intel's ICD when the IGPs are kept out of the running. The best results are obtained by combining the CPU with the APP ICD and the integrated graphics with their own OpenCL drivers. Regardless of the configuration, though, Trinity falls well behind both Ivy Bridge and Sandy Bridge. At the same time, it's still nicely ahead of Llano.
AMD supplied us with a special build of The GIMP 2.8, which features a wealth of OpenCL-accelerated filters. Future GIMP builds will feature an entirely OpenCL-accelerated image processing pipeline, but the build we used did not. Here's what AMD had to say on the subject:
The upcoming major release of GIMP is expected to move its main processing pipeline to use the GEGL library. . . . Knowing that OpenCL and GEGL are the future, the current OpenCL work is designed to impact GEGL, not the current GIMP pipeline. One consequence of aligning with GEGL is that the speed of adoption will rely on GEGL integration with GIMP. In current GIMP builds, there are special menus to use GEGL operation. There is other overhead as well. While we’re seeing nice speedups with OpenCL now, even better performance is expected once GIMP moves completely to the GEGL pipeline.
We tested by loading up an image from our camera, a 32-bit, 4272x2848 bitmap, running through 15 GEGL filters, and averaging the results. AMD says OpenCL kernel code is built when a filter is run for the first time, and this results in a "slight performance hit." To compensate for that hit, we ran each filter four times and only recorded results from the last three runs.
Sadly, The GIMP's GEGL operations weren't available on our Intel systems. The menu simply didn't show up, not even when we had the AMD APP ICD installed. Our results for the AMD systems tells us what we already know: Trinity is quicker than Llano. The difference is more pronounced here than in LuxMark, though.
|Linux gathers steam with CryEngine port, Valve's DX-to-GL translator||3|
|Valve VR engineer moves on to Oculus||0|
|Titanfall PC includes 35GB of uncompressed audio||96|
|New Microsoft brass 'extremely committed' to the Xbox||28|
|Surface Power Cover extends run times with second battery||31|
|Need a little more help...||22|
|iOS 7.1 aims to atone for iOS 7's shortcomings||67|
|Sony, Panasonic cooking up 1TB optical discs||69|