【冷眼旁观】AnandTech披露Galaxy S4跑分作弊

------------------------------------------------------------
Characterizing GPU Behavior
------------------------------------------------------------
Samsung awesomely exposes the current GPU clock without requiring root access. Simply run the following command over adb and it’ll return the current GPU frequency in MHz:
adb shell cat /sys/module/pvrsrvkm/parameters/sgx_gpu_clk
Let’s hope this doesn’t get plugged, because it’s actually an extremely useful level of transparency that I wish more mobile platform vendors would offer. Running that command in a loop we can get real time updates on the GPU frequency while applications run different workloads.
Running any games, even the most demanding titles, returned a GPU frequency of 480MHz - just like@AndreiF alleged. Samsung never publicly claimed max GPU frequencies for the Exynos 5 Octa (our information came from internal sources), so no harm no foul thus far.
（Running Epic Citadel - 480 MHz）
Firing up GLBenchmark 2.5.1 however triggers a GPU clock not available elsewhere: 532MHz. The same is true for AnTuTu and Quadrant.

（Running AnTuTu – 532 MHz SGX Clock）
Interestingly enough, GFXBench 2.7.0 (formerly GLBenchmark 2.7.0) is unaffected. We confirmed with Kishonti, the makers of the benchmark, that the low level tests are identical between the two benchmarks. The results of the triangle throughput test offer additional confirmation for the frequency difference:
We should see roughly an 11% increase in performance in GLBenchmark 2.5.1 over GFXBench 2.7.0, and we end up seeing a bit more than that. The reason for the difference? GLBenchmark 2.5.1 appears to be singled out as a benchmark that is allowed to run the GPU at the higher frequency/voltage setting.

------------------------------------------------------------
The CPU is also Affected
------------------------------------------------------------
The original post on B3D focused on GPU performance, but I was curious to see if CPU performance responded similarly to these benchmarks.
Using System Monitor I kept an eye on CPU frequency while running the same tests. Firing up GLBenchmark 2.5.1 causes a switch to the ARM Cortex A15 cluster, with a default frequency of 1.2GHz. The CPU clocks never drop below that, even when just sitting idle at the menu screen of the benchmark.

翻译啊！！！

Run GFXBench 2.7 however and the SoC switches over to the Cortex A7s running at 500MHz (250MHz virtual frequency). It would appear that only GLB2.5.1 is allowed to run in this higher performance mode.
A quick check across AnTuTu, Linpack, Benchmark Pi, and Quadrant reveals the same behavior. The CPU governor is fixed at a certain point when either of those benchmarks is launched. Linpack for Android: Exynos 5 Octa all cores 1.6 GHz (left), Snapdragon 600 all cores 1.9 GHz (right)
Interestingly enough, the same behavior (on the CPU side) can be found on Qualcomm versions of the Galaxy S 4 as well. In these select benchmarks, the CPU is set to the maximum CPU frequency available at app launch and stays there for the duration, all cores are plugged in as well, regardless of load, as soon as the application starts.
Note that the CPU behavior is different from what we saw on the GPU side however. These CPU frequencies are available for all apps to use, they are simply forced to maximum (and in the case of Snapdragon, all cores are plugged in) in the case of these benchmarks. The 532MHz max GPU frequency on the other hand is only available to these specific benchmarks.

------------------------------------------------------------
Digging Deeper
------------------------------------------------------------

You can see specific Android java naming conventions immediately in the highlighted section. Quadrant standard, advanced, and professional, linpack (free, not paid), Benchmark Pi, and AnTuTu are all called out specifically. Nothing for GLBenchmark 2.5.1 though, despite its similar behavior.
We can also see the files that get touched by TwDVFSApp while it is running: //sys/class/devfreq/exynos5-busfreq-int/min_freq//sys/class/devfreq/exynos5-busfreq-mif/min_freq+/sys/class/thermal/thermal_zone0/boost_mode2/sys/devices/platform/pvrsrvkm.0/sgx_dvfs_min_lock
When the TwDVFSApp application grants special DVFS status to an application, the boost_mode file goes from value 0 to 1, making it easy to check if an affected application is running. For example, launching and closing Benchmark Pi:shell@android:/sys/class/thermal/thermal_zone0 $ cat boost_mode 1shell@android:/sys/class/thermal/thermal_zone0 $ cat boost_mode 0
There are strings for Fusion3 (the Snapdragon 600 + MDM9x15 combo) and Adonis (the codename for Exynos 5 Octa): doBoostAlldoBoostForAdonisdoBoostForAdonis::doBoostForFusion3doBoostForFusion3::
What's even more interesting is the fact that it seems as though TwDVFSApp seems to have an architecture for other benchmark applications not specifically in the whitelist to request for BenchmarkBoost mode as an intent, since the application is also a broadcast receiver. 6Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver$1;6Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver$2;?Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver$IntentInfo;4Lcom/sec/android/app/twdvfs/TwDVFSBroadcastReceiver;boostIntent5com.sec.android.intent.action.DVFS_FG_PROCESS_CHANGED*com.sec.android.intent.action.SSRM_REQUEST
So we not only can see the behavior and empirically test to see what applications are affected, but also have what appears to be the whitelist and how the TwDVFSApp application grants special DVFS to certain applications.

------------------------------------------------------------
Why this Matters & What’s Next
------------------------------------------------------------
None of this ultimately impacts us. We don’t use AnTuTu, BenchmarkPi or Quadrant, and moved off of GLBenchmark 2.5.1 as soon as 2.7 was available (we dropped Linpack a while ago). The rest of our suite isn’t impacted by the aggressive CPU governor and GPU frequency optimizations on the Exynos 5 Octa based SGS4s. What this does mean however is that you should be careful about comparing Exynos 5 Octa based Galaxy S 4s using any of the affected benchmarks to other devices and drawing conclusions based on that. This seems to be purely an optimization to produce repeatable (and high) results in CPU tests, and deliver the highest possible GPU performance benchmarks.
We’ve said for years now that the mobile revolution has/will mirror the PC industry, and thus it’s no surprise to see optimizations like this employed. Just because we’ve seen things like this happen in the past however doesn’t mean they should happen now.
It's interesting that this is sort of the reverse of what we saw GPU vendors do in FurMark. For those of you who aren't familiar, FurMark is a stress testing tool that tries to get your platform to draw as much power as possible. In order to avoid creating a situation where thermals were higher than they'd be while playing a normal game (and to avoid damaging graphics cards without thermal protection), we saw GPU vendors limit the clock frequency of their GPUs when they detected these power-virus style of apps. In a mobile device I'd expect even greater sensitivity to something like this. I suspect we'll eventually get to that point. I'd also add that just like we've seen this sort of thing many times in the PC space, the same is likely true for mobile. The difficulty is in uncovering when something strange is going on.
What Samsung needs to do going forward is either open up these settings for all users/applications (e.g. offer a configurable setting that fixes the CPU governor in a high performance mode, and unlocks the 532MHz GPU frequency) or remove the optimization altogether. The risk of doing nothing is that we end up in an arms race between all of the SoC and device makers where non-insignificant amounts of time and engineering effort is spent on gaming the benchmarks rather than improving user experience. Optimizing for user experience is all that’s necessary, good benchmarks benefit indirectly - those that don’t will eventually become irrelevant.

原文到此为止。
用一个词来形容三星：Classy.

接下来威锋网
威锋网 7 月 31 日消息，卢森堡一名匿名黑客近日发布报告，指控三星特别增大了 Galaxy S 4 的时钟速度，以便能使其在跑分测试中获得超出实际的跑分结果。业内知名权威硬件评测网站 AnandTech 对这则消息进行了调查，最终确认三星在 Galaxy S 4 跑分上确实作弊了。
Galaxy S 4 搭载的是三星最新的 Exynos 5 Octa 处理器，这款处理器是三星在今年年初发布的，目的是为了应对苹果的 A6X。来自 AnandTech 网站的 Anand Lal Shimpi 和 Brian Klug 对 Galaxy S 4 的 Exynos 5 Octa 处理器做了专业的检测，最终发现在一般的使用中，Exynos 5 Octa 的主频为 480MHz，但是在进行 GLBenchmark 2.5.1、AnTuTu 、Quadrant 等跑分测试时，Exynos 5 Octa 的主频却自动提升至 532MHz。
Anand Lal Shimpi 和 Brian Klug 对控制 Exynos 5 Octa 主频的软件的相关文件进行了深挖，发现部分配置文件采用的是硬编码，其中甚至直接包括"BenchmarkBooster"之类的字符串。
除此之外，Anand Lal Shimpi 和 Brian Klug 在相关文件中还找到了“Fusion3（Snapdragon 600 + MDM9x15）”以及“Adonis（Exynos 5 Octa 的代号）”的字符串，因此他们怀疑三星在前几代处理器的跑分方面很可能也作弊了。

让我们来看看三星的story。
--------------------------------------------
外媒近日对三星Galaxy S4进行研究分析后发现，其系统文件中存在一份神秘的白名单，里面包含了一些常见的跑分应用，如安兔兔、Quadrant、Linpack 和 GLBenchmark 2.5.1 等。在运行一般应用时，GS4的GPU主频仅为480MHz，而在跑分测试时则提高到了533MHz，提升幅度高达11%，这样的“超频”自然能确保测试 成绩能够更加出色。昨晚，三星正式发表声明，称旗下智能手机Galaxy S4并未针对特定跑分软件而进行“优化”以提高分数。
　这样的事情在手机业界并不是第一次发生了，HTC等厂商就曾被爆料对跑分软件进行了针对性优化。然而，作为Android阵营的龙头老大，三星自然不会承认这样的事情在自己身上发生。
　　三星在昨晚的一份官方声明中否认Galaxy S4存在“作弊”行为：一般情况下，Galaxy S4 GPU 的最高频率为533MHz。但在处理特定游戏应用时，由于这些应用可能导致过加载，因此 GPU 频率会被降至480MHz。另一方面，对于一些需要在全屏模式下运行的应用，如浏览器、相册、照相机、视频播放器和特定跑分软件在运行时，GPU频率就会 提升到533MHz。
　　三星强调，这样的“超频”并非以提高跑分成绩为目的，而是为了提供给手机使用者更好的用户体验。