Display Measurement

Apple first introduced OLED panels in the iPhone X last year – and this year’s iPhone XS and XS Max are a continuation of the same designs. The XS’s panel ticks off all the features that are possible to have in a display – OLED, high resolution, wide gamut with colour management, and HDR display with official support of HDR10 and Dolby Vision. The panel is manufactured by Samsung Display, but is said to be a contracted design as blueprinted by Apple.

Among one of the questions I’m still asking myself, is who designed and is providing the display’s DDIC? OLED displays' DDICs are even more important than LCDs', because they not only control colour, but also have to control the active matrix power delivery, and thus the DACs that actually power on the individual pixels.

The iPhone’s display is still a scanning PWM powered panel, meaning the pixels are not actually continuously on, but pretty much work the same way a CRT beam would work – only instead of a single pixel, we have a partial vertical band across the display. The reason for this is just the sheer complexity of running the active-matrix: each subpixel needs to be controlled to 1024 voltage levels to represent the colours of the 10-bit panel. On top of that, the DACs need to have sufficient bit-depth to also provide a seamless range of brightness levels. Here saving on the DAC bit-depth by controlling brightness by PWM is a good workaround the issue.

The iPhone XS’ displays are really excellent at first sight, offering fantastic viewing angles. Personally however, I still have some reservation about the bezel design; Apple has been bested when it comes to screen-to-body ratio by other Android vendors, and I expect to see even more devices come out with what are true full device face screens.

The display’ pixel density doesn’t quite match other 1440p smartphones in terms of sharpness, but it’s still plenty sharp enough for the vast majority of people.

As always, we thank X-Rite and SpecraCal, as measurements are performed with an X-Rite i1Pro 2 spectrophotometer, with the exception of black levels which are measured with an i1Display Pro colorimeter. Data is collected and examined using SpectraCal's CalMAN software.


SpectraCal CalMAN
 XS  :      
XSM:      

In terms of greyscale accuracy, both the iPhone XS and iPhone XS Max present outstanding accuracy, coming in at an astonishing deltaE2000 of 0.79 for the XS and 1.64 for the XS Max. My Max unit seemed to lack intensity in the green channel, which reduced its accuracy score.

Both phones came in very close to the target 6500K of the D65 illumination point, in practice they’re very much perfect white.

Brightness wise, my XS maxed out at 646cd/m², while my XS Max came in at 668cd/m². There is no auto-brightness boost, however at such high brightness levels, there’s no need. Minimum brightness goes down to a little under 2 nits, allowing for comfortable night-time reading.


iPhone XS - iPhone XS Max
SpectraCal CalMAN

If one were to nit-pick, then it’s about the gamma measurement as the XS seemed to undershoot the 2.2 target, resulting in ever so slightly darker images, while my XS Max overshot it, resulting in brighter images. Still both were very much within imperceptible levels, so it’s not a great concern.


iPhone XS - iPhone XS Max
SpectraCal CalMAN

By default, the XS display and software interpret non-wide gamut tagged content as sRGB. Measuring the saturation accuracy here, we see some amazing results from both phones. The XS posted an amazing dE2000 of 0.79 – this is so low that it’s nigh-impossible to get much better, even when manually calibrating a display. The XS Max fared a bit worse at 0.95, but still below 1 which still deserves it the commendation of being excellently accurate.


iPhone XS - iPhone XS Max
SpectraCal CalMAN

When the application supports it, and the media has a wide gamut profile embedded, the iPhone XS displays are able to showcase the higher colour intensities of this wider colour gamut. Apple pretty much standardised “Display P3” in the mobile world – a display mode with the gamut of DCI P3, yet with an identical gamma target of 2.2 of sRGB, ensuring seamless interoperability of both gamuts within a display.

Again, both the iPhone XS and the XS Max showcase outstanding calibration with respective dE2000 of 1.19 and 1.03.


iPhone XS - iPhone XS Max
SpectraCal CalMAN


iPhone XS - iPhone XS Max
SpectraCal CalMAN

The Gretag Macbeth colour targets contain commonly encountered colours, such as skin tones and other colour samples. This test checks not only if the display is able to display the correct colour hue, but also the luminosity.

Again, the iPhones are able to show outstanding figures. The 0.74 score of the iPhone XS is I think the lowest figure we’ve measured on any kind of display, which is amazing. My XS Max figures scored a bit worse, it’s likely that the green channel weakness is part of what’s causing it to be better.

Overall, the iPhone displays are just outstanding. These are the best calibration results we’ve come to measure not only in a smartphone, but likely any display. I have literally nothing negative to say about them, and in terms of picture quality, they are just the best displays on the market.

Display Power

I was curious to see how the new XS fared against last year’s X – as it’s possible there might have been some under-the-hood improvements in terms of panel or emitter materials.

Unfortunately, it looks like the iPhone XS is nigh identical to the iPhone X when it comes to the power characteristics of the panel. My iPhone X had reached just a bit higher brightness and extended up the power curve a bit, but otherwise any differences can just as well be attributed to random manufacturing fluctuations.

Screen Luminance Power Efficiency
100% APL / White @ 200nits
Device Screen Luminance Power
at 200cd/m²
Luminance Power (mW) /
Screen area (cm²)
Efficiency
LG G7 257 mW 2.93
LG G6 363 mW 4.43
P20 411 mW 4.86
Galaxy S9 563 mW 6.69
P20 Pro 601 mW 6.74
Galaxy S8 590 mW 7.01
iPhone X ~671 mW ~8.31
iPhone XS ~736 mW ~9.11

Comparing the power efficiency at 200cd/m² and normalising the luminance power of the devices for their screen area, we see that the iPhone X and XS fall a tad behind other Samsung OLED panels. I think what this could be attributed to is the 10-bit colour depth of the Apple phones, as their DDIC and the active matrix would need to do more work versus the 8-bit counterparts.

One thing to also very much to take into account is the base power consumption of the phones. The iPhone X, XS and XS Max all fluctuate around 480-500 mW when on a black screen, which is around 150mW more than the iPhone 8 LCD models. This might not sound much, but’s it’s an absolutely huge figure when taking into account that it’s an unavoidable power consumption of the phone whenever the screen is on. I do hope Samsung and Apple alike would be able to focus more on optimising this, as like we’re about to see, it will have an impact on battery life.

GPU Performance & Power Battery Life
Comments Locked

253 Comments

View All Comments

  • Andrei Frumusanu - Friday, October 5, 2018 - link

    Pixels and Mate 20 are next in line.
  • name99 - Friday, October 5, 2018 - link

    Hi Andrei,

    A few comments/questions.

    - the detailed Vortex and GPU die shots seem to bear no resemblance to the full SoC die shot. I cannot figure out the relationship no matter how I try to twist and reflect...

    Because I can't place them, I can't see the physical relationship of the "new A10 cache" to the rest of the SoC. If it's TIGHTLY coupled to one core, one possibility is value prediction? Another suggested idea that requires a fair bit of storage is instruction criticality tracking.

    If it's loosely coupled to both cores, one possibility is it's a central repository for prefetch? Some sort of total prefetching engine that knows the usage history of the L1s AND L2s and is performing not just fancy prefetch (at both L1s and L2s) but additional related services like dead block prediction or drowsiness prediction?
  • Andrei Frumusanu - Friday, October 5, 2018 - link

    The Vortex and GPU are just crops of the die shot at the top of the page. The Vortex shot is the bottom core rotated 90° counter-clockwise, and the GPU core is either top left or bottom right core, again rotated 90° ccw so that I could have them laid out horizontally.

    The "A10 cache" has no relationship with the SoC, it's part of the front-end.
  • name99 - Friday, October 5, 2018 - link

    OK, I got ya. Thanks for the clarification. I agree, no obvious connection to L2 and the rest of the SoC. So value prediction or instruction criticality? VP mostly makes sense for loads, so we'd expect it near LS, but criticality makes sense near the front end. It's certainly something I'm partial to, though it's been mostly ignored in the literature compared to other topics. I agree it's a long shot, but, like you said, what else is that block for?
  • name99 - Friday, October 5, 2018 - link

    "The benchmark is characterised by being instruction store limited – again part of the Vortex µarch that I saw a great improvement in."

    Can you clarify this? There are multiple possible improvements.
    - You state that A12 supports 2-wide store. The impression I got was that as of A11, Apple supported the fairly tradition 2-wide load/1-wide store per cycle. Is your contention that even as of A11, 2 stores/cycle were possible? Is there perhaps an improvement here along the lines of: previously the CPU could sustain 3 LS ops/cycle (pick a combination from up to 2 loads and up to 2 stores) and now it can sustain 4 LS ops/cycle?

    - Alternatively, are the stores (and loads) wider? As of A11, the width of one path to the L1 cache was 128 bits wide. It was for this reason that bulk loads and stores could run as fast using pair load-store integer as using vector load stores (and there was no improvement in using the multi-vector load-stores). When I spoke to some Apple folks about this, the impression I got was that they were doing fancy gathering in the load store buffers before the cache, and so there was no "instruction" advantage to using vector load/stores, whatever instruction sequence you ran, it would as aggressively and as wide as possible gather before hitting the cache. So if the LS queue is now gathering to 256 bits wide, that's going to give you double the LS bandwidth (of course for appropriately written, very dense back to back load/stores).

    - alternatively do you simply mean that non-aligned load/stores are handled better (eg LS that crossed cache lines were formerly expensive and now are not)? You'd hope that code doesn't do much of these, but nothing about C-code horrors surprises me any more...

    BTW, it's hard to find exactly comparable numbers, but
    https://www.anandtech.com/show/11544/intel-skylake...
    shows the performance of a range of different server class CPUs on SPEC2006 INT, compiled under much the same conditions. A12 is, ballpark, about at the level of Skylake-SP at 3.8 to 4GHz...
    (Presumably Skylake would do a lot better in *some* FP bcs of AVX512, but FP results aren't available.) This gives insight across a wider range of x86 servers than the link Andrei provided.
    The ideal would be to have SPEC2006 compiled using XCode for say the newest iMac and iMac Pro, and (for mobile space) MacBook Pro...
  • Andrei Frumusanu - Friday, October 5, 2018 - link

    > Is your contention that even as of A11, 2 stores/cycle were possible?

    Yes.

    > - Alternatively, are the stores (and loads) wider?

    Didn't verify, and very unlikely.

    > - alternatively do you simply mean that non-aligned load/stores are handled better

    Yes.
  • remedo - Friday, October 5, 2018 - link

    Can you please review the massive NPU? It seems like NPU deserves a lot more attention given the industry trend.
  • Andrei Frumusanu - Friday, October 5, 2018 - link

    I don't have any good way to test it at the moment.
  • Ansamor - Friday, October 5, 2018 - link

    Aren't these (https://itunes.apple.com/es/app/aimark/id137796825... tests cross-platform or comparable with the ones of Master Lu? I remember that you used it to compare the Kirin 970 against the Qualcomm DSP.
  • Andrei Frumusanu - Friday, October 5, 2018 - link

    Wasn't aware it was available on iOS, I'll look into it.

Log in

Don't have an account? Sign up now