On mobile devices it would seem sensible to also run your benchmark until the battery is "flat", it might be a crude heuristic but it probably the best you can do with product devices where you can't easily break out power rails and the like.
You should treat benchmarks with a heavy pinch of salt, simply because it's caught up in the bullshit messaging world of marketing where the aim is just to produce the bigger or smaller number where appropriate.
The necessity to satisfy marketing ignores a lot of things. Benchmarks often translate poorly to real use.
Does GLbenchmark 2.7 provide any useful insight into the performance of the top fifty games in the Android mobile market? Probably not with a few 3d heavy exceptions.
And then you hit a grey area where software can behave badly on one piece of hardware versus the other because of implementation. So if the benchmark hits this area, is it a hardware problem or a benchmark software problem?
You should treat benchmarks with a heavy pinch of salt, simply because it's caught up in the bullshit messaging world of marketing where the aim is just to produce the bigger or smaller number where appropriate.
The necessity to satisfy marketing ignores a lot of things. Benchmarks often translate poorly to real use.
Does GLbenchmark 2.7 provide any useful insight into the performance of the top fifty games in the Android mobile market? Probably not with a few 3d heavy exceptions.
Some benchmarks will never die, you'll still see Dhrystone trotted out to this day. http://www.eejournal.com/archives/articles/20090602_coremark...
And then you hit a grey area where software can behave badly on one piece of hardware versus the other because of implementation. So if the benchmark hits this area, is it a hardware problem or a benchmark software problem?