The Google Pixel 3 Review: The Ultimate Camera Testby Andrei Frumusanu on November 2, 2018 11:00 AM EST
- Posted in
- Snapdragon 845
- Pixel 3
Pixel phones have been known to be among the best performing Android devices in the market. This is mainly due to the Pixel’s performance team taking the time and attention to tweak the software stack – kernel and userspace alike. This is one of the benefits of being one of the last flagships out of the gate for a given generation, as it gives time to optimize the performance. The Pixel 3 comes with the Snapdragon 845, and I’ve written many times this year how Qualcomm’s software, and in particular the kernel scheduler was a very significant factor as to why this year’s Snapdragon phones performed so marvellously.
One of the big questions I posed myself early in the year is exactly how Google planned to handle Qualcomm’s great divergence from upstream, and the divergence from the Google common kernel. As a reminder, the Google common kernel is now the “official” branch on which SoC vendors should be basing their BSP (board support packages, essentially the software stack) for their own products. This is a collaborative effort between vendors (Mainly Google, Qualcomm and Arm), and it’s also the target where Arm pushes its own EAS patches.
The matter of fact is, for the Pixel 3, Google is simply using Qualcomm’s custom scheduler. This is both a great win for Qualcomm given the expected device performance of the Pixel 3, and quite a blow to Arm’s own efforts, as the EAS improvements over the last year are just simply not being used. Qualcomm’s efforts as well as the resulting product are just too good to pass on, and I’m very much expecting next year to finally be a watershed moment where other vendors finally abandon attempts to keep things minimalistic, and in line with upstream Linux, and finally see the immense value in investing in actual immediate benefits for consumer devices of a given generation.
Starting with PCMark’s Web Browsing 2.0 test, the Pixel 3 leads the pack, with a slight advantage over other Snapdragon 845 phones. The reason here is that Google seemingly uses the most up-to-date scheduler, as well as has some possible file I/O advantages which I’ll get into a bit later. There are also possible OS side improvements in the libraries, as the Pixel 3’s ship with Android 9.
I’ve updated the performance results for past Pixels with the newest OS updates, as well as for devices like the OnePlus 6 as these have received their OS updates as well.
In the writing test, which is probably PCMark’s most important as well as representative benchmark, the Pixel 3 saw a big leap in performance over the previous Pixels – however I think this was due to Android 9 itself, as we also saw a big jump in the OnePlus 6’s performance with the latest OS update.
The photo editing test is very much a scheduler responsivity test as modern devices are able to complete the workloads relatively fast at their peak performance states. Here the score wildly fluctuates depending on how fast the DVFS mechanism is, and we see the Pixel 3 among the best performers.
The data manipulation score is extremely high on the Pixel 3 compares to other phones, including the OnePlus 6. I wasn’t able to verify this empirically, but glancing over the scheduler the Pixel has some unique updates to it which facilitate better responsiveness and scheduling of single big tasks, and the data manipulation test is such a workload with a big single-threaded component.
Overall, the Pixel 3 takes the top position in PCMark, all thanks to its scheduler improvements as well as a slight advantage due to it running Android 9.
Moving onto web browser tests, the Pixel 3 largely matches the other Snapdragon 845 devices. This is no surprise as Speedometer 2.0 is a high constant throughput ST benchmark, and as such isn’t as affected by scheduler as PCMark.
Apple still has a considerable performance lead here. After our recent iPhone XS review and SoC deep-dive, I’m more leaning towards the explanation that a big part of the advantage here is purely due to hardware and the microarchitectural advantages of Apple’s CPUs, with part of it also being Apple’s Nitro JS engine.
WebXPRT also looks in line with other Snapdragon 845 devices.
Pixel 3 – Now using F2FS
Section with credit and input by Park Ju Hyung (@arter97)
The Pixel 3 now has switched over from an EXT4 filesystem, to the F2FS filesystem. Google explains this switch due to the fact that F2FS now supports inline block encryption which has been the last major roadblock as to why Google hadn’t made the switch earlier.
Inline block encryption uses the SoC’s inline cryptographic engines, which just serve as an intermediate hardware layer to the NAND and offload any encryption workloads that were initially in past devices performed by the CPU.
The switch to F2FS now gives the Pixel 3 a number of advantages over previous filesystem; Previously, SQLite (which is used by almost all database files under Android) used another 'journaling' on its own to prevent corruption. This caused “double journaling” on top of EXT4, which in itself is a journaling filesystem. Since F2FS doesn’t need this kind of protection and the Pixel 3 includes Google’s SQLite changes in Android 8.1, the Pixel 3 is able to take advantage of this, as well as any other F2FS based device from other vendors which have the corresponding OS patches.
The result is that this will enable much higher write/commit speeds for SQLite, not to mention less wear and tear to the underlying UFS storage. Also, the Pixel 3 turned off barriers for fsync() system calls, which will improve general random I/O write speeds by a significant margin.
Another big improvement for file I/O is the implementation of “Host Performance Booster” in the kernel and UFS controller firmware stack. HPB is essentially caching of the NAND chip’s FTL (flash translation layer) L2P (logical to physical) mapping tables into the hosts (SoCs) main memory. This allows the host driver to look up the target L2P entry directly without betting on UFS’s limited SRAM to have a cache-hit, reducing latency and greatly increasing random read performance. The authors of the feature showcase an improvement of 59-67% in random I/O read performance due to the new feature. It’s worth to mention that traditional Android I/O benchmarks won’t be able to show this as as those tend to test read speeds with the files they’ve just created.
Overall, the Pixel 3 is the fastest Android device on the market right now. The one thing that puts it above other devices such as the OnePlus 6 is a noticeable faster response-time when opening applications – either a framework related boost or just an effect of the faster file I/O.
Post Your CommentPlease log in or sign up to comment.
View All Comments
Impulses - Saturday, November 3, 2018 - linkThey're not using bad sensors, I mean, they often manufacture everyone else's, the post processing is often horrid for Sony tho. You think they could get someone from their dedicated camera division to better tune that (they don't have the greatest JPEG engine either but it's gotten better every year).
Edwardmcardle - Friday, November 2, 2018 - linkAwesome review as always. Will there be a mate 20 pro review? Have one and am considering returning because of odd screen issue. Also the new performance mode seems to suck battery, but animations seem laggy when not engaged...would be great to have a professional insight!
luikiedook - Friday, November 2, 2018 - linkExcellent review, and comparison photos galore! I think a lot of the day light photos is a matter of opinion. Personally I find the iPhone Xs and Samsung photos over exposed and less pleasing than the pixel photos. The outdoor seating area for example, the black table tops look reflective and almost white in the iphone Xs and Samsung photos.
Most of the time the Pixel photos are darker, but I'm not convinced there is less detail, most of the time.
The p20 pro seems to crush everything in 5x zoom.
melgross - Sunday, November 4, 2018 - linkThe shadows on the Pixel are all blocked up. It’s pretty obvious. Some people mistakenly equate black shadows with better contrast, as Google apparently does, but that’s wrong. You can always darken the shadows later in a quick edit. But if the detail is killed on the photo, you can never retrieve it.
Dr. Swag - Friday, November 2, 2018 - linkHey Andrei, you got the displays mixed up. The 3XL uses a Samsung amoled panel whereas the 3 uses a p-oled from LG. The table on the first page says the opposite.
warrenk81 - Friday, November 2, 2018 - linkhaven't even read the article yet, just want to say i'm so happy to see smartphones review return to Anandtech!!
spooh - Friday, November 2, 2018 - linkPixel XL used in the review has optics issue affecting corner sharpness, and light fallof. I think it's also slightly less sharp than good unit.
I've had one with the same issue, but returned it.
id4andrei - Friday, November 2, 2018 - linkThe Verge reviewer Vlad Savov is a big fan of Google's computational photography. He makes it seem like the Pixel is clearly above the latest flagships. Your expansive review paints a different picture, that of a phone that tries to keep up with a single camera module.
On a personal level I have a dilemma. Isn't computational photography basically post-processing? Even if it produces a subjectively better outcome out of stitching several shots, isn't it "fake" somehow as it is not an accurate representation of a frame?
Andrei Frumusanu - Friday, November 2, 2018 - link> Even if it produces a subjectively better outcome out of stitching several shots, isn't it "fake" somehow as it is not an accurate representation of a frame?
Not really. If a sensor fails to have sufficient dynamic range by itself, then even with no processing that's also going to lead no an "inaccurate representation".
Impulses - Friday, November 2, 2018 - linkIt's a little fancier than the post processing you could (easily) manage yourself, mostly cause of the way they chop up frames in tiles to then stack them intelligently... You could say it's "fake" in instances where their algorithm just decided to drop a tile to avoid artefacts or movement etc., but wouldn't you just clone those out yourself if you were anal about the overall end result?
It's an interesting question without a straightforward answer IMO. It's just gonna vary by shot and usage case, if you're getting consistently better DR then you're consistently closer to "what you see", but all photography is ultimately an interpretation.