En dépit de quelques efforts de la part d'Apple et d'une part de marché du Mac qui augmente année après année, les portages de jeux PC ou consoles vers macOS restent finalement assez rares. Pour ne rien arranger, ces portages souffrent parfois de performances en retrait. Pourquoi ce désamour ? Voici nos explications.
Une architecture atypique
Du temps des Mac Intel, Apple employait les mêmes GPU que les PC, avec des puces AMD, Intel ou même Nvidia dans une époque lointaine. Avec les Mac Apple Silicon, les GPU proviennent des GPU des iPhone, qui dérivent de l'architecture de PowerVR. Et pour les développeurs, c'est un souci. De façon extrêmement simplifiée, les GPU classiques effectuent un rendu dit immédiat : un triangle (la base dans une scène 3D) est pris en charge, rendu sous la forme de pixels et écrit en mémoire. Si un second triangle arrive et se place devant le précédent dans la scène, le premier a été calculé inutilement. Cette solution est efficace, mais gâche parfois de la bande passante mémoire.
Dans les GPU d'Apple et dans quelques GPU mobiles, le rendu est dit différé : les triangles sont traités dans une première passe (avec un découpage dans de petites zones appelées tuiles, tiles en anglais) pour vérifier ceux qui sont invisibles et le reste du rendu est ensuite appliqué uniquement sur les visibles dans une seconde passe. Cette solution a l'avantage de réduire la bande passante mémoire — ce qui explique ce choix dans les appareils mobiles — et d'obtenir un bon ratio entre performances théoriques et pratiques, mais empêche la mise en place de certaines techniques modernes.
Cette voie pose par ailleurs un problème quand la géométrie est plus complexe que le reste du rendu et nécessite donc parfois quelques ajustements au niveau du moteur 3D. En fait, c'est précisément ce point qui a probablement poussé Apple à offrir le Game Porting Toolkit et qui permet justement de mettre en avant les opérations bloquantes.
Si les différences entre les architectures peuvent sembler anecdotiques, elles ne le sont pas en pratique : dans le monde PC, les développeurs ont déjà du mal à proposer des titres qui fonctionnent aussi bien avec les GPU de Nvidia que ceux d'AMD et depuis quelques mois d'Intel. Il n'est pas rare de voir des mises à jour qui accélèrent certains jeux de façon très significative sur une marque précise de GPU et (surtout) les fabricants de cartes graphiques offrent régulièrement des pilotes qui améliorent les performances sur le dernier AAA à la mode. Et si les développeurs peuvent tenter de corriger les goulets d'étranglement dans leurs moteurs 3D, espérer un comportement proactif de la part d'Apple reste un doux rêve : la société met rarement à jour ses pilotes (au mieux, vous aurez une nouvelle version dans une mise à jour mineure d'iOS ou macOS) et encore plus exceptionnellement pour améliorer les performances dans les jeux.
Tout cela implique que les développeurs doivent bien comprendre le fonctionnement des GPU Apple, ce qui n'est pas une évidence dans le cas d'un portage, et doivent aussi parfois essayer d'adapter un code qui n'a pas du tout été pensé pour la manière de faire des puces d'Apple, ce qui peut amener l'absence de certains effets ou des résultats nettement plus faibles, et ce même si les GPU offrent une puissance brute à peu près similaire.
L'obstination d'Apple avec Metal 3
Le cas des API 3D est un problème un peu particulier. Historiquement, elles étaient très nombreuses : dans les années 1990, chaque fabricant avait sa propre API, c'est-à-dire un ensemble de commandes standardisées, pour ses cartes, et parfois même plusieurs en fonction des puces. Assez rapidement, le marché s'est resserré et deux API ont pris l'ascendant : DirectX (plus exactement Direct3D, le pendant lié à la 3D, bravo, vous suivez) et OpenGL. Apple a choisi à l'époque OpenGL, pour la bonne et simple raison que DirectX était propriétaire et appartenait à Microsoft.
