Vous l’avez peut-être vu, j’ai proposé un test du DTK 2020 d’Apple. Et je vous publie un petit résumé sur un point précis du dossier : HandBrake.
Le premier test a été effectué avec Rosetta : compresser la version 2160p de Big Buck Bunny en 1080p avec le preset Apple TV 1080p30. Avec Rosetta 2 et la version x86, c’est assez lent : 1 558 secondes (~12 fps). Dans ce cas, le DTK utilise ses quatre coeurs rapides à 2,4 GHz, et le score est proche d’un Athlon 3000G ou d’un Pentium G5400, deux CPU x86 d’entrée de gamme, dotés de deux coeurs avec SMT (quatre threads, donc).
HandBrake a un avantage, c’est qu’il est open source. Et il existe une branche applesilicon des sources, qui permet de compiler le logiciel sur le DTK. Il n’y a pas d’optimisations particulières, mais en natif, on passe à 754 secondes (~25 fps), environ le double des performances. Le CPU utilise ses huit coeurs et c’est en gros les performances d’un Ryzen 5 3400G ou d’un Ryzen 3 3300X, des CPU AMD dotés de quatre coeurs avec SMT, donc huit threads. Pour une puce qui a deux ans, avec une fréquence plus faible et une consommation (beaucoup) plus faibles, c’est plutôt efficace. En pratique, c’est même un peu plus rapide qu’avec mon MacBook Pro 2017 et son Core i7 7700HQ (1 068 secondes, ~17 fps). Au passage, le graphique a été corrigé, suite à une erreur dans les benchs. La machine de Microsoft est assez ridicule, mais le SoC Snapdragon n’est pas très rapide dans l’absolu, et même si j’ai compilé HandBrake en natif pour Windows 10 ARM (et ce n’est pas évident), les résultats restent faibles.
Le dernier point intéressant vient de l’encodeur. HandBrake utilise les API VideoToolbox d’Apple et la version compilée pour ARM y a accès, contrairement à la variante x86 via Rosetta. J’avais déjà parlé de ça il y a quelques mois : mon MacBook Pro 2017 encode à ~105 fps en H.264 (via l’IGP Intel), à 45 fps en HEVC (via l’IGP Intel, toujours) ou à ~100 fps (via un eGPU Vega 64). Un Mac avec une puce T2, lui, encode à ~115 fps en H.264 (via l’IGP Intel plus rapide) et à ~115 fps avec la puce T2 en HEVC. Et c’est là que le DTK (et la puce A12Z) montre l’intérêt du passage en ARM : en intégrant l’encodeur directement dans le SoC, on passe à 150 fps dans les deux cas. C’est un gain assez important, avec une consommation plutôt faible.
« Un Mac avec une puce T2, lui, encode à ~115 fps en H.264 (via l’IGP Intel plus rapide) et à ~115 fps avec la puce T2 en HEVC. Et c’est là que le DTK (et la puce A12Z) montre l’intérêt du passage en ARM : en intégrant l’encodeur directement dans le SoC, on passe à 150 fps dans les deux cas. »
150 fps en h264 ET en h265 ? Impressionnant !
Il est possible de tester un encodage en AV1 ?
Bonjour,
La différence (115 fps vs 150 fps) entre le DTK (A12z) et la puce T2 (dérivé de l’A10), n’est elle pas lié aux 2 générations d’écart entre les 2?
@Rinchama : oui, 150 fps en HEVC aussi
@maxou56 : oui, sûrement, mais c’est pas pertinent : y a pas (encore ?) de T3 basés sur l’A12Z. Ce qui est pertinent, c’est que c’est plus rapide.