2 ms·
> the calculus has changed in favour of power savings and against flexibility This has always been a trade-off. For instance even with desktops, once video han
by photojosh 9y ago
> the calculus has changed in favour of power savings and against flexibility
This has always been a trade-off. For instance even with desktops, once video handling became common we first had video decode/encode being handled by GPU acceleration. But now most CPUs include dedicated h264 (and more recently hevc) decode/encode support, eg [0].
Although it's much lower computation, hardware acceleration is also offered for audio, and I'd take a guess the reason the Apple APIs for checking which hardware supports hardware-based audio encode/decode [1] has been deprecated is now because all supported devices provide all possible capabilities.
[0]: https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
[1]: https://developer.apple.com/documentation/audiotoolbox/1620452-hardware_codec_capabilities?language=objc https://developer.apple.com/documentation/audiotoolbox/16204...
- TD-Linux 9y agoIn the case with audio, it might be the opposite - even with a modern audio codec like Opus, an Apple CPU can decode an entire song into RAM in a fraction of a second. At that point, the CPU has to wake up anyway to download another song from Spotify or read one from disk.