1. 20
  1.  

  2. 1

    The results show that Safari is able to take better advantage of the different core types, presumably because it can direct the tasks to the appropriate cores because it has better knowledge of the platform it is running on. I wonder if this means more generic software (Chrome, VLC) that has to work cross platform needs more than just recompiling for Apple Silicon to take proper advantage of the capabilities i.e. platform specific APIs. It would also be interesting to run a comparison tests with the non-Apple Silicon compiled versions of Chrome and VLC to see if that makes any difference.

    1. 1

      I’d like to see more measurements too, like what happens when the M1 is in a laptop on battery power.

    2. 1

      These bits seem interesting:

      “In Safari hardware decoding, the GPU frequency is 0 Hz for a sustained period of time. Does this mean the M1 chip can turn the GPU off? “

      “In Safari, the GPU is clocking up and down (zoom in on the details), while in Chrome, the GPU is constantly running around 710 MHz.”

      I don’t understand how things work at this level. Can anyone advise if this ‘trick’ of letting the GPU sit idle is likely to be a major contributor here, and if it’s possible that Chrome could copy the behaviour of Safari to bring it closer in power usage?

      edit: I use Firefox so I’m more interested in whether Firefox can copy this.

      1. 5

        The way this is accomplished is to offload compositing to the OS’s compositor — and if the system compositor uses hardware planes, it would be possible to avoid the GPU entirely for whole frames where only a browser video updates. It seems that Chrome already tries to do this on Windows, and so does Firefox (though oddly this is still open). They also do it on macOS e.g., though further improvements are yet to land in Firefox. Looking at the notes attached to the last link above, it seems that “detached mode” in AVSampleBufferDisplayLayer is the maximum power saving possible, for when there’s nothing drawn over the video.

        1. 2

          There’s a lot to learn in these links, thank you!

          1. 1

            So, no Apple magic here, just “holy crap there’s a lot of APIs and a lot of flags and a lot of ways to skin the cat of putting anything on the screen in 2021, and we haven’t caught up to the right one yet.”

            I wonder when “HTML layout engine” (or at least a good chunk of the box model stuff) becomes an OS facility.

          2. 2

            I do think racing to idle on the GPU is a contributor to Safari’s lower power consumption. I’m not sure what’s required to do that. If Apple has built this behavior into the standard SDK components that accept a video source and composite it — and I think they would; they ship other video-playing apps — then third party apps could get this advantage too. One way to test is to build a basic video playing app from SDK components and measure again. To get the benefit an app may have to be built from stock components and not roll too much of its own rendering where video is concerned. Cross-platform browsers might have a challenge there. Any lower level interfaces that enable that high level component to work well could be reverse engineered and mimicked, but they also could be private and unsupported.