SPECviewperf 11 – Multisample Testing
SPECviewperf 11
SPECviewperf tests FSAA performance by running its standard test suite several times, setting the FSAA feature of the graphics card being tested to all possible FSAA sample values. If a graphics card supports up to 16 samples – supporting 16, 8, 4, and 2 samples – the test would run five times, running tests for 16, 8, 4, 2, and no samples.
The test is run with no FSAA enabled so that a baseline test result can be produced. The goal of the test is to determine what performance penalty, if any, enabling FSAA with a given sample rate incurs. During the individual tests, screen shots are captured. This allows the tester to review the effects that FSAA is having on the rendered image. It is important to note that as FSAA is altering the image, there is no way to automatically validate pixel accuracy of the images rendered. It is up to the tester to evaluate the individual image captures to determine if the FSAA-produced images for a given sample size are visually pleasing to the user. As mentioned earlier, a subjective evaluation is necessary as individual preference for the FSAA results plays a part with respect to the aesthetic quality of the images produced.
If the FSAA test produces a score that is within 10 percent of the non-FSAA score, under SPECviewperf 10 rules that score will be considered valid for the specific sample rate. If a SPECviewperf test score for a particular test is 20.0, for example, and the same test score with FSAA enabled with a sample of 8 produces 19.5, the official results will be listed as 20.0 with FSAA up to a sample of 8 enabled. Sample rates may affect individual tests differently with respect to performance, so each test will include the best FSAA sample rate score within the 10-percent threshold. If no sample rate falls within the 10-percent threshold, the test score will indicate that no FSAA sample rate achieved the performance threshold for this test.
Image from Lightwave-01
SPECviewperf tests FSAA performance by running its standard test suite several times, setting the FSAA feature of the graphics card being tested to all possible FSAA sample values. If a graphics card supports up to 16 samples – supporting 16, 8, 4, and 2 samples – the test would run five times, running tests for 16, 8, 4, 2, and no samples.
The test is run with no FSAA enabled so that a baseline test result can be produced. The goal of the test is to determine what performance penalty, if any, enabling FSAA with a given sample rate incurs. During the individual tests, screen shots are captured. This allows the tester to review the effects that FSAA is having on the rendered image. It is important to note that as FSAA is altering the image, there is no way to automatically validate pixel accuracy of the images rendered. It is up to the tester to evaluate the individual image captures to determine if the FSAA-produced images for a given sample size are visually pleasing to the user. As mentioned earlier, a subjective evaluation is necessary as individual preference for the FSAA results plays a part with respect to the aesthetic quality of the images produced.
If the FSAA test produces a score that is within 10 percent of the non-FSAA score, under SPECviewperf 10 rules that score will be considered valid for the specific sample rate. If a SPECviewperf test score for a particular test is 20.0, for example, and the same test score with FSAA enabled with a sample of 8 produces 19.5, the official results will be listed as 20.0 with FSAA up to a sample of 8 enabled. Sample rates may affect individual tests differently with respect to performance, so each test will include the best FSAA sample rate score within the 10-percent threshold. If no sample rate falls within the 10-percent threshold, the test score will indicate that no FSAA sample rate achieved the performance threshold for this test.
Image from Lightwave-01
Due to length of testing time for the new SPECviewperf 11, I limited the results to an AA level of 8x – higher than most professional developers would likely be using in a real-world environment anyway. My first surprise was how little the performance changed on the AMD offerings as the level of AA increased – this is either a feature of the new Evergreen architecture or a bug of the driver that we just haven’t nailed down yet. The NVIDIA offerings did scale quite a bit more (and were more in line with what I thought would happen) but only in once case was there a concern for me: Snx-01. In that test we see the performance of the new Quadro 5000 fall below the FirePro V8800 at 4xAA and even below the V7800 at 8xAA. Otherwise, it was smooth sailing for the Fermi card here.
