3D Graphics Benchmarks for Low-Power Architectures

Currently, there is much interest in wireless 3D graphics applications, in particular games. Since current 3D graphics accelerators consume too much power to be employed in mobile computing devices, several companies and universities have started to develop low-power 3D graphics accelerators. However, to the best of our knowledge, there is no publicly available benchmark suite appropriate for evaluating such devices. In this paper we present a set of 3D graphics benchmarks which can be considered typical 3D workloads of contemporary and emerging mobile devices. First, reasons why most 3D benchmarks employed for desktop computers are not suitable for mobile environments are given. After that, simulation results such as the number of triangles or fragments processed by a typical rasterization pipeline are presented. Finally, we discuss some architectural implications of the obtained results for low-power implementations

GraalBench: A 3D Graphics Benchmark Suite for Mobile Phones

In this paper we consider implementations of embedded 3D graphics and provide evidence indicating that 3D benchmarks employed for desktop computers are not suitable for mobile environments. Consequently, we present GraalBench, a set of 3D graphics workloads representative for contemporary and emerging mobile devices. In addition, we present detailed simulation results for a typical rasterization pipeline. The results show that the proposed benchmarks use only a part of the resources offered by current 3D graphics libraries. For instance, while each benchmark uses the texturing unit for more than 70% of the generated fragments, the alpha unit is employed for less than 13% of the fragments. The Fog unit was used for 84% of the fragments by one benchmark, but the other benchmarks did not use it at all. Our experiments on the proposed suite suggest that the texturing, depth and blending units should be implemented in hardware, while, for instance, the dithering unit may be omitted from a hardware implementation. Finally, we discuss the architectural implications of the obtained results for hardware implementations