SPECviewperf
SPEC makes this benchmark to allow professionals to benchmark combinations of components so you can learn how well a specific component will work for a professional deployment. The following description is for each of the tests and is pulled directly from their page to avoid any issues or misunderstandings. These benchmarks are GPU targeted to see how your Graphics accelerator can render heavy professional workflows.
3ds Max viewset (3dsmax-06)
The 3dsmax-06 viewset was created from traces of the graphics workload generated by 3ds Max 2016 using the default Nitrous DX11 driver.
The models for this viewset came from the SPECapc for 3ds Max 2015 benchmark and other sources. In order to best approximate real-world use cases, several tests incorporate multiple viewsets on screen, each using a different rendering method. The styles of rendering in the viewset reflect those most commonly used in major markets, including realistic, shaded and wireframe. Some lesser-used but interesting rendering modes such as facets, graphite and clay are also incorporated. The animations in the viewset are a combination of model spin and camera fly-through, depending on the model.
Note: 3DStudioMax does not support 2160p so you will notice it is absent from the 4K results.
CATIA viewset (catia-05)
The catia-05 viewset was created from traces of the graphics workload generated by the CATIA V6 R2012 application from Dassault Systemes. Model sizes range from 5.1 to 21 million vertices.
The viewset includes numerous rendering modes supported by the application, including wireframe, anti-aliasing, shaded, shaded with edges, depth of field, and ambient occlusion.
Creo viewset (creo-02)
The creo-02 viewset was created from traces of the graphics workload generated by the Creo 3™ and Creo 4™ applications from PTC. Model sizes range from 20 to 48 million vertices.
The viewsets include numerous rendering modes supported by the application. Order-independent transparency is enabled for all models with transparent components.
Energy viewset (energy-02)
The energy-02 viewset is based on rendering techniques used by the open-source OpendTect seismic visualization application. Similar to medical imaging such as MRI or CT, geophysical surveys generate image slices through the subsurface that are built into a 3D grid. Volume rendering provides a 2D projection of this 3D volumetric grid for further analysis and interpretation.
At every frame, the bounding cube faces of the volume are tessellated and rendered with a fragment shader that performance a ray-cast from the eye position through the volume, accumulating transparent lit, color-mapped values until either the pixel becomes fully opaque or the volume is exited.
The voxel in the 3D grid is a single scalar value. A transfer function — simply a 1D lookup table — maps the 3D density value to color and alpha values. For lighting calculations, the gradients are computed on the fly using the central differences at each voxel. These state changes exercise various parts of the graphics subsystem. This viewset makes use of hardware support for 3D textures and therefore trilinear interpolation.
In addition to the volume rendering, the test includes both inline and crossline planes (slices in the X and Y planes). Also, for some subtests, “horizons” are present – these are geological strata boundaries of interest, generated by exploration geophysicists, and are rendered using textured triangle strips.
The 3D datasets used in this viewset are real-world seismic datasets found at https://wiki.seg.org/wiki/Open_data . They were translated from their native SEG-Y format and compressed using JPEG-2000.
Maya viewset (maya-05)
The maya-05 viewset was created from traces of the graphics workload generated by the Maya 2017 application from Autodesk.
The viewset includes numerous rendering modes supported by the application, including shaded mode, ambient occlusion, multi-sample antialiasing, and transparency. All tests are rendered using Viewport 2.0.
Medical viewset (medical-02)
The medical-02 viewset uses the Tuvok rendering core of the ImageVis3D (http://www.sci.utah.edu/software/imagevis3d.html) volume visualization program. It renders a 2D projection of a 3D volumetric grid. A typical 3D grid in this viewset is a group of 3D slices acquired by a scanner (such as CT or MRI).
Two rendering modes are represented – slice-based rendering and ray-casting.
For slice-based rendering, a series of coplanar slices aligned with the current viewing angle are computed on the CPU and then sent to the graphics hardware for texturing and further calculations, such as transfer function lookup, lighting and clipping to reveal internal structures. Finally, the slices are blended together before the image is displayed.
For ray-casting, rays are cast through the volume, accumulating transparently lit, colored pixels until full opacity or the bounds of the volume are reached.
For both slice-based and ray-cast rendering, the volumes are potentially subdivided into 512x512x512 3D volumes. This technique is known as “bricking” and typically results in better rendering performance on a wider range of GPU hardware.
The voxel in the 3D grid is a single scalar value. A transfer function — either a 1D or a 2D lookup table — maps the 3D density value to color and alpha values. For 2D tables, the second axis is defined as the magnitude of the gradient at each sample. For lighting calculations, the gradients are computed on the fly using the central differences at each voxel. These state changes exercise various parts of the graphics subsystem. This viewset makes use of hardware support for 3D textures and therefore trilinear interpolation.
Siemens NX (snx-03)
The snx-03 viewset was created from traces of the graphics workload generated by the NX 8.0 application from Siemens PLM. Model sizes range from 7.15 to 8.45 million vertices.
The viewset includes numerous rendering modes supported by the application, including wireframe, anti-aliasing, shaded, shaded with edges, and studio mode.
Solidworks viewset (sw-04)
The sw-04 viewset was created from traces of Dassault Systemes’ SolidWorks 2013 SP1 application. Models used in the viewset range in size from 2.1 to 21 million vertices.
The viewset includes numerous rendering modes supported by the application, including shaded mode, shaded with edges, ambient occlusion, shaders, and environment maps.
First up, we wanted to get our professional render tests done to see how each of these chips would support heavy GPU loads with professional workload apps for the GPU. To my surprise, the 2600 held its own even besting the 8700K in some test while you can see where certain apps such as Solidworks and OpenDtect definitely favored the higher clock speed performance of the 8700K but even then I’m not sure if the difference is enough to call it a clear win. Add on top of this that the 2600 pulls some clear victories even if by the smallest margin, needless to say, we are impressed with the fact that it’s not being obliterated by a chip double its cost.
Blender
Blender once again shows the 8700K’s prowess as far as pushing data, knocking out the BMW render in a clear 8 seconds faster but what was a real surprise was the difference in GPU render times as it completed a solid 30 seconds faster than the same GPU on the 2600 based system.
Cinebench R15
Cinebench is all about rendering out images and doing this on the CPU is hard work, and it offers tests for both single and multi-threaded renders along with even an OpenGL GPU based workload.
Here we see that the 2600 pulls quite a good result from the single threaded benchmark although being beaten readily it was only by about 13% and for an over 50% price savings that’s not too bad.
Looking at the multi-threaded benchmark and the tide turns in AMDs favor in a major way as now after multiple repeated runs it beats the 8700K by the slimmest of margins and so much to my surprise that I re-ran it multiple times as I assumed it must have been an error. but now you see with the appropriate workload the less than half the cost 2600 can beat the 8700K in a productivity workload.
The OpenGL test once again mirrors what we saw from the blender GPU render where it loses a little performance on the GPU side which I honestly cannot explain, especially when you see the gaming benchmarks coming up.