Update on GPU Optimizations in Galaxy S 4by Anand Lal Shimpi & Brian Klug on July 31, 2013 10:11 AM EST
- Posted in
Yesterday we posted our analysis of the Exynos 5 Octa's behavior in international versions of the Galaxy S 4 in certain benchmarks first discovered by Beyond3D user @Andreif7. Samsung addressed issue on their blog earlier today:
Under ordinary conditions, the GALAXY S4 has been designed to allow a maximum GPU frequency of 533MHz. However, the maximum GPU frequency is lowered to 480MHz for certain gaming apps that may cause an overload, when they are used for a prolonged period of time in full-screen mode. Meanwhile, a maximum GPU frequency of 533MHz is applicable for running apps that are usually used in full-screen mode, such as the S Browser, Gallery, Camera, Video Player, and certain benchmarking apps, which also demand substantial performance.
The maximum GPU frequencies for the GALAXY S4 have been varied to provide optimal user experience for our customers, and were not intended to improve certain benchmark results.
Samsung Electronics remains committed to providing our customers with the best possible user experience.
The blog seems to confirm our findings, that the 533MHz GPU frequency is available for certain benchmarks ("a maximum GPU frequency of 533MHz is applicable for running apps that are usually used in full-screen mode, such as the S Browser, Gallery, Camera, Video Player, and certain benchmarking apps"). The full screen statement doesn't make a ton of sense (both GLBenchmark 2.5.1 and 2.7.0 are full screen apps, but with different GPU behavior). Samsung claims however that a number of its first party apps (S Browser, Gallery, Camera and Video Player) can also run the GPU at up to 532MHz, which actually explains something else we saw while digging around.
Looking at resources.arc inside TwDVFSApp.apk we find the following reference to pre-loaded Samsung apps:
This is what we originally assumed was happening with GLBenchmark 2.5.1 (that it was broadcasting boost intent to Samsung, but Kishonti told us that wasn't the case when we asked).
As we mentioned in our original piece, there's a flag that's set whenever this boost mode is activated: +/sys/class/thermal/thermal_zone0/boost_mode. None of the first party apps get that flag set, only the specific benchmarks we pointed out in the original article. Of those first party apps, S Browser, Gallery and Video Player all top out at a GPU frequency of 266MHz (which makes sense, none of the apps are particularly GPU intensive). I tried running WebGL content in S Browser to confirm (I ran Aquarium with 500 fish), as well as edited some photos in Gallery - 266MHz was the max observed GPU frequency.
|Max Observed GPU Frequency|
|S Browser||Gallery||Video Player||Camera||Modern Combat 4||AnTuTu|
The camera app on the other hand is a unique example. Here we see short blips up to 532MHz if you play around with the live filters aggressively (I just quickly tapped between enabling all of the filters, the rugged/oil pastel/fish eye filters seemed to be the more likely to trigger a 532MHz excursion). I never saw 532MHz for more than a second though. The chart below plots GPU frequency vs. sampling time to illustrate what I saw there:
What appears to be happening here is the boost routine grants access to raised thermal limits, which makes it possible to sustain the 532MHz GPU frequency for the duration of certain benchmarks. Since the camera app doesn't get the boost mode flag, it doesn't seem to sustain 532MHz - only 480MHz.
Otherwise the Samsung response is consistent with our findings and we're generally in agreement. Games aren't given access to the 532MHz GPU frequency, while certain benchmarks are. Samsung's pre-loaded apps can send boost intent to the DVFS (dynamic voltage and frequency scaling) controller, but they don't appear to be given the same thermal boost ability as we see in the benchmarks. Their reasoning for not giving games access to the higher frequency makes sense as well. Higher frequencies typically require higher voltage to reach, and power scales quadratically with voltage so that's typically not the best way of increasing performance - especially at the limits of one's frequency/voltage curve. In short, you wouldn't want to for thermal (and battery life) reasons. The debate is ultimately about what happens within those specified benchmarks.
Note that we're ultimately talking about an optimization that would increase GPU performance in certain benchmarks by around 10%. It doesn't sound like a whole lot, but in a very thermally limited scenario it's likely the best you can do.
I stand by the right solution here being to either allow the end user to toggle this boost mode on/off (for all apps) or to remove the optimization entirely. I suspect the reason why Samsung wouldn't want to do the former is because you honestly don't want to run in a less thermally constrained mode for extended periods of time in a phone. Long term I'm guessing we'll either see the optimization removed or we'll see access to view current GPU clock obscured. I really hope it's not the latter as we as an industry need more insight into what's going on underneath the hood of our mobile devices, not less. Furthermore, I think this also highlights a real issue with the way DVFS management is done presently in the mobile space. Software is absolutely the wrong place to handle DVFS, it needs to be done in hardware.
Since our post yesterday we've started finding others who exhibit the same CPU frequency behavior that we reported on the SGS4. This isn't really the big part of the discovery since the CPU frequencies offered are available to all apps (not just specific benchmarks). We'll be posting our findings there in the near future.
Post Your CommentPlease log in or sign up to comment.
View All Comments
watersb - Thursday, August 1, 2013 - linkAgreed.
Seems like Samsung is trying to maintain a whitelist of apps that are almost all GPU, minimal CPU, and and staying inside the thermal envelope.
They somehow can't get proper cache coherency in this weird big.little octa-core beast, so they have to do gonzo tricks in software to deliver a stable platform.
Actually maybe they are being conservative with this thing. But it's the best they can do right now.
It seems to be an engineering thing, not a cheating-on-tests thing.
Rezurecta - Wednesday, July 31, 2013 - linkWrong, benchmarks are a measure of theoretical performance, and, as we see with PC, the only way to test gaming performance is to test the game.
bronze_elephant - Wednesday, July 31, 2013 - linkRezurecta, you should perhaps change that comment to say "theoretical peformance within thermal constraints" and then it would be more accurate. Professionaly written 3D graphics benchmarks like the one being discussed here exist to serve as a predictor of the relative performance for real world applications like games or in some caes GUI. Games are seldom a practical way for reviewers like AnandTech to quantify the relative performance of one platform vs. another...note I say "quantify", as in having a frame rate number that is repeatable irrespective of who is doing the testing, and reported numerically in a manner that can be compared from one platform to the next. You are correct that games should ALSO be tested to round out the analysis (noting at least the qualitative results), but Kishonti's GLBenchmark tests are a reasonable and repeatable proxy for actual game testing. So too are the graphics benchmark tests from Rightware, Futuremark and others. Antutu's so-called graphics tests are a joke by comparison today, but I'm told that it will get better in a future future release.
Detecting a gaming style benchmark like GLBenchmark and invoking a GPU clocking scenario that is unattainable for sustained use games just to obtain a benchmark higher score is cheating. I think everybody can understand why that's the case. Therefore Samsung should amend their statement to read as follows:
"Under ordinary conditions, the GALAXY S4 Exynos 5410 has been designed to run at a GPU frequency of 480MHz. However, the maximum GPU frequency is rasied to to 532MHz primarly for benchmarks but also for any application where the graphics rendering workload is substantial only for a period of a few seconds or less."
Another form of cheating on benchmarks is if the workload of a benchmark itself is changed through application detection software, with an "optimization" that would not be applied for a similar scenario with a real world application. Kudos to AnandTech for exposing both of them.
SteelRing - Wednesday, July 31, 2013 - linkClearly it is not safe for samsung to allow users/developers to access the higher frequency that would demand higher power and generate higher heat. A rogue behavior from a bug, intentional or not, could make it a safety issue for a handheld device to get overheated real quick and then who would be blamed? the developer? It's gonna be samsung's ass on the line and I'd side with them to be safe than sorry.
doobydoo - Wednesday, July 31, 2013 - linkThe point being that if that performance isn't safe to utilise, it shouldn't be the one which is benchmarked.
HighTech4US - Wednesday, July 31, 2013 - linkBINGO we have a winner/
melgross - Wednesday, July 31, 2013 - linkBut even a 10% boost in several benchmarks, if the reason for it isn't known, can be enough to move a device to the top of the chart. And there will always be enough people to think that it's a good reason to buy the product.
And then, of course, that top rating will be written about, and even used in promotional materials, etc. overall, it's simply not proper, and somewhat slimey
James5mith - Wednesday, July 31, 2013 - linkMuch like their choice of plastic for the back of the phone!
GokieKS - Wednesday, July 31, 2013 - linkSo they're claiming that they're not boosting clock speeds for higher benchmarks, but it just happens that those benchmarks are given access to the maximum GPU clock speed but other non-Samsung apps aren't. Yeah, somehow that comes off as no less shady.
milans - Wednesday, July 31, 2013 - linkShame on you Shamesung! This is clearly cheating... and there should be consequences. And they even lie about it, as you guys clearly showed in this Update.