dempson

nguyenhm16 said:
According to everymac, 2015 iMacs use 5th (21.5") or 6th (27") gen CPUs, which do have Quick Sync:

The first version of Quick Sync was introduced in Sandy Bridge (2nd gen Core i3/i5/i7), initially supporting H.264, so some variant of Quick Sync exists in almost all 2011-2012 Macs (apart from the 2012 Mac Pro) and all 2013 and later Macs.

Later processor generations improved Quick Sync and added more video formats. 5th gen (Broadwell) added some VP8 support. 6th gen (Skylake) added 8-bit HEVC encode/decode. The 2015 21.5-inch iMac (5th gen) is excluded from the list of supported models, but the 2015 27-inch iMac (6th gen) is included so Quick Sync in Broadwell does not suffice, implying 8-bit HEVC encode/decode is the required feature.

aieronimo said:
I have a late 2015 iMac 27-inch, which is listed as one of the supported models for Sidecar, and I am pretty sure that it does not have HEVC encode/decode in hardware.  I think hardware support for HEVC encode/decode started with the 2017 iMac.

According to Apple's WWDC 2017 introduction of HEVC/HEIF, 8-bit HEVC hardware decode and encode support on a Mac requires a 6th generation or later Intel processor (i.e. Skylake or later). The Late 2015 27-inch Retina 5K iMac has a Skylake processor so should support 8-bit HEVC.

Skylake does not have hardware decode support for 10-bit HEVC. That was added in Kaby Lake (7th generation), which includes 2017 iMacs.

As of WWDC 2017 (therefore High Sierra), no Macs were going to use hardware support for 10-bit HEVC encode, but it appears Kaby Lake also added that feature.

Given the Skylake processor requirement, that probably means Sidecar is using 8-bit HEVC. In theory it could step up to 10-bit HEVC if the Mac and iPad are new enough.

The listed models have one feature in common: all have a Skylake or newer processor.

Skylake adds hardware encode/decode support for HEVC, so this might just be a case of the Sidecar feature being implemented with HEVC rather than H.264 to reduce bandwidth requirements or allow a higher frame rate. Older Mac models would have to do HEVC encode in software, so enabling the workaround might impose a significant CPU performance load when the display is rapidly changing.

If I'm right, this could impose a similar requirement on the receiving iPad: basic HEVC hardware decode is a feature of the A9 and later processors, so A8 models that can run iOS 13 (iPad Air 2 and iPad mini 4) may be unable to act as a sidecar receiver as they would have to decode the video stream in software.

There was a similar cutoff with the introduction of AirPlay video support: it required a Sandy Bridge or later processor to get H.264 hardware encode support. Third party software (AirParrot) implemented that feature on older Macs by doing the H.264 encode in software, but it caused a fair amount of CPU overhead.

Meanwhile in New Zealand, BNZ (owned by NAB) has had Apple Pay since October 2017, and Westpac NZ (owned by Westpac Australia) since April 2019.

ANZ was first in New Zealand to get Apple Pay, about the same time as ANZ Australia; ASB (owned by Commonwealth Bank) got Apple Pay in January 2019.

Perhaps NAB and Westpac Australia have technical issues they needed to resolve, or are they just being stubborn and trying to get a better deal due to size? I doubt Westpac Australia wants to be the odd one out for too long.

AppleInsider said:

While Apple's support page advises it is aimed at these models, it also notes the update is "recommended for all users."

That means "recommended for all users of the 2018 MacBook Pro". The update refuses to install on other models (looking at the script in the installer, it requires the specific board ID of the 13-inch or 15-inch 2018 MacBook Pro). The model requirement is implied by the page title of the support article but is not explicitly stated either in the body text or the System Requirements section. The first supplemental update was the same.