Our second content creation benchmark is a radiosity utility provided by Valve. VRAD is one of the three major phases in compiling a level with the Hammer editor for Valve’s Source engine. The first stage called binary space partitioning divides the level up into a set of polygons that can be represented as a tree-like structure. The second stage calculates visibility information for polygons and light sources. VRAD is the last stage, where radiosity is calculated for the level based on the number and positions of various light sources. It is also the most taxing of the three stages in compiling a level – hence the most useful benchmark from the perspective of a game developer.
Figure 4 – VRAD Performance
Figure 4 above shows the execution time for the radiosity calculations – so smaller is better in this case. VRAD uses all available threads, but unlike POV-Ray, it appears to have some issues scaling. Westmere only improves performance by 10% over Nehalem, suggesting that limitations in the code or the data set prevent realizing the full benefit of the extra 8 threads. The power results seem to reinforce the limited scaling hypothesis. Westmere consumes 260W compared to 280W for Nehalem, suggesting that some of the threads and cores may have been idling and able to reduce the dynamic power consumption as a result.
Figure 5 – VRAD Energy Efficiency
Unlike POV-Ray, VRAD does not naturally report throughput numbers (e.g. pixels per second) and instead relies on execution time to measure performance. Thus instead of dividing throughput by average power, we instead count the total energy consumption (in joules or watt-seconds) to complete the task; again, lower is better. Westmere’s modest gains in performance and power consumption are somewhat more impressive when combined. Overall, Westmere uses 84% of the energy that Nehalem does to complete the same task.