 |
Jeudi 01 mai 2025 - 13:17 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Note : traduction par David Brunet.
Juste avant le salon AmiWest 2018, j'ai eu la chance de m'entretenir avec le développeur néo-zélandais Hans de Ruiter. Hans nous a gracieusement donnés un aperçu du développement en cours des pilotes graphiques pour AmigaOS 4 ainsi que des défis auxquels il est confronté.
Pouvez-vous nous
rappeler votre parcours d'utilisateur d'Amiga ? Quand avez-vous découvert l'Amiga ? Qu'est-ce qui vous a
attiré dans cette machine ? Qu'est-ce qui vous motive encore sur cette plate-forme ?J'ai débuté sur un Commodore 64. Mais des amis ont commencé à utiliser une autre machine, appelée Commodore Amiga, qui fut clairement un pas en avant par rapport au C64. En fin de compte, mes parents ont acheté un A600. Plus tard, j'ai acheté un A1200 d'occasion, que j'ai ensuite mis à niveau avec une carte accélératrice 68030 et j'ai réalisé moi-même le montage en boîtier tour (l'ensemble de conversion et sa livraison depuis le Royaume-Uni était trop cher pour moi). L'A1200 m'a bien servi jusqu'à la fin de mes études d'ingénieur. J'ai ensuite décidé de passer une maîtrise/doctorat à l'université de Toronto. Je n'ai malheureusement pas pu emporter cette lourde tour avec moi au Canada, mais l'AmigaOne XE était sur le point d'être commercialisé. J'en ai donc acheté un et j'ai attendu avec impatience AmigaOS 4.0. Et j'ai continué avec AmigaOS depuis.
J'ai d'abord aimé l'Amiga pour ses jeux, mais j'ai rapidement apprécié son côté créatif. J'ai donc touché à tout, d'OctaMED à Real 3D et, bien sûr, à la programmation. Un autre atout de l'Amiga était son graphisme et ses capacités, qui étaient en avance sur son temps.
Ce qui me motive toujours sur cette plate-forme, c'est que j'aime relever le défi de faire avancer AmigaOS. Ce système conserve son charme d'origine, et nous (l'équipe de développement d'AmigaOS) l'avons poussé bien au-delà de sa conception originale.
Comment vous êtes-vous
retrouvé à développer des pilotes graphiques ? Avez-vous travaillé sur des pilotes graphiques pour d'autres plates-formes
avant l'Amiga ? Et en avez-vous développé pour d'autres plates-formes depuis que vous avez commencé ce travail pour Amiga ?Cela a débuté vers la fin de mon doctorat. AMD avait ouvert la documentation pour la série des Radeon X1000 (R500), et il y eut beaucoup de discussion sur les forums sur la possibilité de réaliser de nouveaux pilotes pour AmigaOS 4. On avait alors une documentation appropriée pour ce matériel, donc l'ancienne excuse de "l'Open Source ne concerne pas la documentation" ne s'appliquait plus ici.
A l'époque, je rêvais d'écrire mon propre logiciel de montage vidéo, et je voulais vraiment des pilotes pour des cartes graphiques plus récentes. J'ai remarqué que l'on parlait beaucoup, mais que personne ne faisait rien. Alors, j'ai téléchargé la documentation d'AMD et j'y ai jeté un coup d'oeil. Ensuite, j'ai jeté un coup d'oeil au nouveau pilote RadeonHD à code source ouvert pour Linux. Je me suis dit "Hmmm, ça a l'air faisable", "Y a-t-il des cartes graphiques qui pourraient se connecter sur mon AmigaOne XE pour un prix raisonnable ?". Sur ces deux points, la réponse était oui.
Alors, j'ai trouvé et commandé une carte Radeon X1300 PCI sur eBay, et je l'ai connectée à mon AmigaOne XE, j'étais un peu nerveux, espérant comme un fou qu'elle ne détruise pas la machine. À mon grand soulagement, non seulement la machine était toujours en bon état, mais la nouvelle carte m'accueillit avec un écran UBoot. Jusqu'ici, tout allait bien....
L'étape suivante consista à lui faire afficher quelque chose. Je n'avais jamais encore écrit de pilote graphique. En fait, les seuls "pilotes" que j'avais écrits furent pour de petits périphériques sur les microcontrôleurs PIC/Atmega. J'ai donc décidé d'écrire un programme qui puisse ouvrir un écran et afficher une image. Si je pouvais faire cela, je pouvais alors demander la documentation nécessaire pour écrire un pilote.
Hélas, la carte n'a semblé répondre à aucune écriture de registre que je faisais. Après un certain temps, j'ai découvert que la puce de pont PCI-to-PCIe était mal configurée. UBoot désactivait le pont, ce qui signifiait qu'il ne transmettait jamais aucun des accès à la carte graphique.
Sur ce, j'ai commencé à adapter le code source Linux. Les cartes graphiques Radeon sont pourvues d'un AtomBIOS dans la ROM avec un code indépendant de la plate-forme. Je voulais utiliser ce code, mais pour cela, j'avais besoin d'un interpréteur AtomBIOS. Il manquait ces détails dans la documentation, donc le seul endroit pour les obtenir était leur code source récemment publié.
Finalement, j'ai pu ouvrir un écran et afficher une image avec cette carte graphique, et j'ai fait une annonce sur mon site Internet.
Premier écran RadeonHD sur AmigaOS 4
Qu'est-ce qui vous a
poussé à développer des pilotes graphiques Amiga ? Comment cette occasion s'est-elle présentée ?Une fois mon programme de test fonctionnel, j'ai contacté Hyperion pour obtenir la trousse de développement des pilotes. Le fait d'avoir une preuve de faisabilité fonctionnelle les a convaincus qu'il valait la peine de me donner cette trousse, bien que cela ait quand même pris un certain temps. La communication avec Hyperion a été assez lente, et j'ai d'abord dû signer un contrat de non-divulgation. Finalement, cela a été fait, et j'ai pu me mettre à travailler sur un vrai pilote.
L'état d'avancement du développement est détaillé sur mon site Internet.
Pouvez-vous nous
raconter brièvement l'historique du développement de pilotes graphiques sur AmigaOS4 avant votre implication ?Je ne suis pas trop sûr des détails parce que je n'étais pas impliqué. Il y a eu de multiples tentatives d'ajout de cartes graphiques à AmigaOS par des tiers, qui ont toutes impliqué la mise à jour de la bibliothèque graphique. Les deux plus grandes sont CyberGraphics (utilisé par MorphOS) et Picasso96, qui est devenu la base du système de pilote graphique d'AmigaOS 4.x.
En 1998, Haage & Partner avait lancé Warp3D pour les cartes graphiques 3D. Cela fonctionnait avec CyberGraphics et Picasso96. Cependant, sa performance était limitée par deux facteurs :
- Il s'agissait d'un ajout externe à deux correctifs tiers de la graphics.library. En tant que tel, ce système graphique devait ruser pour limiter temporairement le contrôle de la carte graphique par CyberGraphics/Picasso96.
- Warp3D fut conçu autour des capacités des premières cartes graphiques 3D, qui étaient très basiques. Il s'agissait essentiellement de tramages 2D avec un tampon de profondeur. Il n'y avait pas de fonctions TCL matérielles (Transform, Clipping & Lighting), du coup Warp3D devint très rapidement obsolète.
Pouvez-vous nous
donner un aperçu de l'état actuel du développement des pilotes graphiques pour AmigaOS 4 ?Autant que je sache, je suis le seul qui travaille encore activement sur les pilotes graphiques sur AmigaOS. Nous disposons actuellement de pilotes 2D et 3D pour les cartes graphiques modernes. J'ai récemment terminé les pilotes pour les puces de la série Polaris (RadeonRX 5xx).
Nous disposons aujourd'hui de Warp3D Nova qui apporte à AmigaOS 4 des fonctionnalités graphiques modernes basées sur des nuanceurs, et nous avons aussi un adaptateur OpenGL ES 2.x (GLES2). L'adaptateur GLES2 était ma suggestion. OpenGL ES n'incorpore plus d'anciens éléments qui ne devraient plus être utilisés, tout en conservant les fonctionnalités les plus utiles. L'abandon de l'ancien système facilite également l'écriture des pilotes. De plus, Regal et GL4ES sont deux bibliothèques qui pourraient fournir un OpenGL complet par-dessus. C'était le moyen le plus rapide d'obtenir un OpenGL moderne.
Les graphismes à base de nuanceurs ouvrent un tout nouveau monde de possibilités. En plus d'activer le TCL matériel et d'améliorer les performances, il permet aux développeurs d'écrire du code personnalisé qui s'exécute sur la puce graphique elle-même. Seuls quelques jeux en profitent actuellement (Spencer et Amicraft), mais d'autres sont à venir.
Comment voyez-vous
le futur du développement de pilotes sur AmigaOS 4 ? Si la logistique (coût, taille du marché, etc.) n'était pas un
problème, où aimeriez-vous le voir se diriger ?Une partie de la tâche consiste à écrire des pilotes pour du matériel plus récent, ce qui nous permet d'acheter de nouvelles cartes (par exemple les pilotes Polaris récemment terminés). D'un autre côté, il faut améliorer les capacités des pilotes. Warp3D Nova s'est beaucoup amélioré au cours de l'année précédente, mais il manque encore certains choses ici et là (par exemple, des instructions de nuanceurs manquantes, des nuanceurs de géométrie et de calcul, etc.).
A part cela, j'aimerais que l'on puisse déverrouiller davantage de fonctionnalités des cartes graphiques. La plus grande étant l'utilisation de la GART (Graphics Address Remapping Table - Table de Reconfiguration d'Adresse Graphique) pour permettre à la carte graphique d'accéder aux données dans la mémoire principale via le DMA. En fait, de nos jours, la GART est plus une IOMMU complète (unité de gestion de la mémoire d'entrée-sortie). D'une façon ou d'une autre, permettre à la carte graphique de lire/écrire directement la mémoire principale augmenterait considérablement les performances.
L'autre gros élément serait l'utilisation du décodeur embarqué pour la lecture vidéo. Sans oublier l'encodeur pour l'encodage et l'enregistrement vidéo.
Oh, et j'aimerais voir l'API du pilote remplacée par une API moderne qui gère des choses comme : de multiples moniteurs, une VRAM à laquelle le processeur ne peut pas accéder, le branchement à chaud, etc.
Selon vous, quel est l'obstacle
le plus important, dans le développement des pilotes graphiques, dont l'utilisateur moyen n'est probablement pas au courant ?Les puces graphiques sont vraiment compliquées. La puce Vega 10 dispose de 12,5 milliards de transistors et embarque beaucoup de technologie. Même les premières cartes Radeon HD étaient incroyablement compliquées, avec de nombreux sous-systèmes, chacun devenant de plus en plus complexe.
Chaque génération a ajouté un nouveau niveau de complexité. J'ai aussi trouvé les cartes très pointilleuses. Une petite erreur, et elles se bloquent. J'ai l'impression que la course ATI/AMD contre nVidia pour le droit de se targuer d'avoir les cartes les plus rapides poussent l'utilisation de ces dernières à leur extrême limite, près du gouffre.
Un autre problème est le manque d'outils de débogage. Lorsque la puce graphique ou le pilote plante, vous perdez l'affichage, ce qui signifie qu'aucune sortie de débogage n'apparaît à l'écran. De plus, nous n'avons pas de débogueur à distance, donc je ne peux pas utiliser une autre machine pour passer en revue le code et analyser ce qui se passe. On est donc contraint d'insérer beaucoup d'instructions DebugPrintF(), puis passer par des cycles de plantages et de redémarrages.
Même si nous avions un bon débogueur, il ne pourrait pas déboguer le code des nuanceurs de la puce graphique, sans compter que la documentation peut se révéler inexacte. Cela signifie que le seul retour d'information que vous avez est "la puce graphique est verrouillée", avec quelques registres d'état donnant une vague idée des éléments verrouillés. Avec si peu de données sur ce qui ne va pas, le débogage se transforme en une routine minutieuse de "deviner et vérifier". Deviner, tester, planter. Deviner à nouveau, retester, et retestez encore, et planter à nouveau. Eh bien, vous voyez le tableau. Parfois, on a de la chance. D'autres fois, cela peut prendre des jours, voire plus longtemps, avant que vous ne trouviez la cause profonde du problème et que vous ne vous mettiez à l'oeuvre.
Que voudriez-vous dire
à la communauté au sujet du développement de pilotes graphiques ?Il y a une limite à ce qu'un développeur peut faire. Le développement d'un pilote graphique est normalement un travail d'équipe. Compte tenu de nos ressources limitées (il n'y a que moi qui travaille là-dessus), il faut établir des priorités. Donc, même si j'aimerais bien que toute la série des Radeon HD soit entièrement prise en charge, ce n'est tout simplement pas faisable avec un seul développeur qui travaille dessus.
Il en va de même pour l'ajout de fonctions telles que le décodage vidéo, la gestion de la GART, la gestion énergétique, etc. Des priorités doivent être établies sur ce à quoi il faut d'abord s'attaquer. J'ai vu des personnes insister sur le fait que la caractéristique qu'ils veulent le plus est ce que tout le monde veut. Il faut juste rappeler que ce n'est pas parce que c'est la plus importante pour vous qu'elle est la plus importante pour tout le monde.
Quels sont les
problèmes que vous avez rencontrés lors du développement de ces pilotes pour Amiga, et qui pourraient ne pas être
rencontrés sur d'autres plates-formes ?L'absence d'un débogueur à distance fonctionnel (ou juste un débogueur fonctionnel) est le plus important. J'ai également traité des problèmes au niveau d'UBoot/CFE/BIOS qui n'existent pas sur d'autres plates-formes. Les autres plates-formes disposent également d'API et de systèmes de pilotes graphiques plus modernes. Je dois ruser pour contourner la vieillissante conception de Picasso96.
Enfin, la plupart de ceux qui développent des pilotes pour d'autres plates-formes travaillent pour les entreprises qui conçoivent les puces graphiques**, c'est-à-dire qu'ils :
- Discutent avec les concepteurs du matériel.
- Ont accès à des outils de débogage matériel que nous ne pouvons pas nous payer.
- Travaillent en équipe pour écrire les pilotes.
- Sont payés beaucoup plus pour travailler dessus.
** Un employé d'AMD m'a dit que je suis l'une des rares personnes au monde à pouvoir écrire des pilotes graphiques qui ne travaille pas déjà pour eux ou un de leurs concurrents.
Outre l'achat des
pilotes et la participation à votre sondage annuel, comment l'utilisateur moyen peut-il vous aider, si cela est possible ?Achetez des logiciels/jeux d'autres développeurs et encouragez-les à développer davantage pour AmigaOS. Les pilotes graphiques sont assez ennuyeux à moins qu'il n'y ait d'autres logiciels qui les utilisent. Ceci est particulièrement vrai pour Warp3D Nova/GLES2. Nous avons besoin de plus de logiciels qui tirent parti des nouvelles capacités.
Prenez plaisir à utiliser vos machines AmigaOS, utilisez-les de manière créative et faites-en part aux autres. Plus il y aura d'utilisateurs AmigaOS, plus le marché grandira, et plus les programmeurs pourront développer des logiciels de tous types.
Oh, et si vous êtes un développeur et que vous aimeriez vous lancer dans l'écriture de pilotes graphiques, alors pensez à en toucher deux mots à A-EON Technology.
Il semble toujours
y avoir beaucoup de discussions et parfois une certaine confusion au sujet des tests de performances. Pouvez-vous
nous parler de ces tests de performances ainsi que de leur lien avec l'Amiga ? Quel est le meilleur logiciel pour
réaliser des tests de performances précis sur Amiga et comment l'utilisateur peut interpréter ces résultats ? Quelle
est la meilleure façon de comparer les résultats des tests de performances sur Amiga avec ceux obtenus sur d'autres
plates-formes ? Comment l'utilisateur peut comparer des "pommes avec des pommes" ?Ah, les tests de performances. Il y a tellement de discussions à ce sujet. J'ai vu certains insister sur le fait que les tests de performances synthétiques comme GfxBench2D sont invalides parce qu'ils "ne reflètent pas les performances du monde réel". Sauf votre respect, je ne suis pas d'accord. Les tests de performances "réels" ne sont pas plus valables ou informatifs. Par exemple, l'exécution de la démo "timedemo" de Quake III ne vous indique que les performances de cette démo ; vous ne pouvez pas déduire quelle serait la fréquence d'images pour un autre jeu, ou même pour une démo ou un niveau différent de Quake III. Ils ne vous donnent que des performances relatives sur différents matériels.
Je préfère les tests de performances simples comme ceux que j'ai utilisés dans GfxBench2D, car ils examinent les performances et les limites de certaines parties du matériel. Ce sont des données qui pourraient être utilisées pour identifier les goulots d'étranglement des pilotes et y remédier. Les développeurs d'applications et de jeux pourraient également les utiliser pour choisir les fonctions qu'ils utilisent (par exemple, en évitant celles dont vous savez qu'elles seront lentes). Si je devais créer un outil de tests de performances pour la 3D, alors je construirais des tests pour examiner des choses telles que le nombre d'opérations de dessin par seconde, de verticles, la vitesse de remplissage, et le nombre de nuanceurs par seconde. Ce genre de données est utile pour les développeurs.
Je n'ai pas de liste de tests de performances que les gens pourraient ou devraient utiliser, mais je vous conseille d'en utiliser plusieurs. Tirer de grandes conclusions à partir d'un seul test est une mauvaise idée. Par exemple, le fameux test Cow3D a été affecté par un goulot d'étranglement qui faisait croire que Warp3D Nova était mauvais : keasigmadelta.com/blog/warp3d-novas-performance-boost-partially-hidden-by-lazy-cow/.
Même en supprimant ce problème, les performances de Cow3D continuent de se heurter à un goulot d'étranglement particulier (très probablement des opérations de dessin), et ne disent rien sur les performances des autres logiciels. Il faut donc lancer plusieurs tests et ne pas se fier à un test en particulier.
En ce qui concerne la comparaison des tests de performances Amiga avec les autres plates-formes, je suggère d'essayer un large éventail de tests différents, et de faire attention aux versions des outils utilisés pour ces tests. Par exemple, il est inutile de comparer les temps de rendu de Blender 2.48 et de Blender 2.79. Sachez également que les optimisations du compilateur peuvent jouer un rôle important, et que les tests de performances peuvent être optimisés pour du matériel spécifique (ou avoir des optimisations programmées à la main pour plusieurs plates-formes).
En fin de compte, les gens doivent accepter les résultats. Si la machine A effectue un décodage H.264 plus rapidement que la machine B, alors la machine A est plus rapide que la machine B. Les raisons exactes de cette constatation, et ce qui pourrait être fait pour rendre la machine B plus performante, est une autre affaire...
Y a-t-il quelque chose
que vous aimeriez ajouter et qui n'a pas été traité ?Non. Je ne vois rien.
|
