Also, switching web browser tabs while running the benchmark may affect your results due to the web browser changing the priority of the benchmark process.Ĭharles Lui ( and Byron Kropf ( created this project for their senior project. Note: for the most consistent benchmark results, don't run other intensive applications while attempting to benchmark your system. We also have a cubes benchmark that attempts to keep the frames per second (FPS) within a specified range, and will increase the amount of cubes in the scene if the FPS is too high, or decrease the cubes if the FPS is too low.

Having more objects that can be added before each stair step in the graph indicates a better performing graphics card. The general graph trend will have a stair step pattern to it with each stair step indicating another frame that was needed in order to process the current number of objects. When the test is completed we use the D3.js library to display a graph of the data collected. Stressing the card is defined by, when the work takes more than 4 frames of time to render. By default, the test will currently run for 100 frames, if the test finds that it didn’t stress the card enough, then the benchmark will be extended until it does. The test runs for a number of frames that changes depending on the capability of the system being tested. In order to reduce error caused by the complexity of the objects used, we made the objects as simple as possible, all of the objects are screen filling rectangles of a flat color. This is achieved by drawing an increasing number of objects in each frame, and looking for where the number of objects being used forces the GPU to break the job into multiple frames.

Our benchmark works by testing the amount of work that your GPU can process into a single frame rather than the typical benchmark metric of how many frames can be processed in a second. In addition, when we started getting data out of our benchmark, the results supported the theoretical results that we were looking for, which was quite encouraging. We accomplished our goal of prototyping a new way of benchmarking graphics performance in a web browser. We cannot use frames per second as a measurement of graphics performance because it can be inaccurate in the context of a web browser this is where the project comes into play. Instead, it measures the amount of work that a device can do in the time period of a single frame. The main benchmark in the project does not use the typical measurement, frames per second, to measure the graphical performance of the computer. This is a significant project because 3D graphics are becoming more and more prevalent, and our project provides a way to accurately measure the graphics performance on a device.

The research and coding was done by Byron Kropf and Charles Lui, with guidance and supervision by Remi Arnaud. The project client was Remi Arnaud from AMD, and he proposed this project in order to experiment with a new format of GPU testing that the functionality of WebGL now gives us access to. The goal of the project was to create a web-based open source graphics benchmark with HTML5 and WebGL using a testing metric other than frame rate. Welcome to our WebGL Performance Benchmark

Online video card benchmark