Infos sur la Vampire
-
YES YES YES c’est une super bonne nouvelle
Salut,
Je vais essayé d’apporter quelques éléments de précision.
Au sujet du son 16 bits d’abord.
J’ai moi-même testé cette nouvelle fonctionnalité, et je vais donc donner quelques précisions. Pour situer le contexte, l’équipe travaille sur un core qui inclut ce dont une carte autonome a besoin pour démarrer AmigaOS. Ce core est développé sur les Vampire non-autonomes, pour des raisons d’implémentations itératives, chip après chip, et qui présentera aussi l’avantage de backporter plusieurs features de la standalone vers la génération actuelle (AGA sur V500/V600 pour être précis). A ce titre, Gunnar – mais pas seulement lui – travaille en ce moment sur le core-chipset, et donc sur l’intégration des différents copros de l’amiga (Agnus, Lisa, Paula, Cia, et j’en passe […]). Au moment de l’intégration de Paula dans le core, la team en a profité pour examiner ce qui pourrait être (éventuellement) amélioré tout en restant compatible et respectueux de l’architecture Amiga. A ce stade, nous avons décidé de ne pas toucher à l’existant, à savoir les 4 channels 8bits PCM classiques et leurs registres/interruptions associés (AUD0, AUD1, AUD3, AUD3), car nous on l’aime bien comme çà notre Amiga. En revanche! nous avons opté pour un channel supplémentaire, dans le même esprit finalement que ce que représente le core-chunky (mode RTG) pour la vidéo. Ce channel audio supplémentaire (AUD4) possède la même architecture que les 4 channels ‘classic’, donc la même ‘carte/map’ de registres (mais bien sûr à une nouvelle adresse de base), offrant ainsi la même programmabilité Amiga-ish (DMA/INT). Le son produit est dispatché en stéréo (L/R) sur la sortie audio. Les registres prennent un bloc de DATA PCM non-compressé 16Bits jusqu’à 55KHz, situé en ChipRAM ou même en FastRAM. Concrètement, çà permet de jouer un son AIFF 16Bits Stéréo 48KHz BigEndian, non-compressé, 0% cpu utilisé. Donc pour faire simple, nous avons là tout simplement une petite carte son bien sympa produisant du son 16bits stéréo et mixé automatiquement aux 4 voix natives. Il est possible de jouer un .module classique via un modplayer tout en jouant un son 16bits sur le channel additionnel. Reste la partie SW à développer, en cours.
EDIT:
Concernant les 4 canaux classiques, ils bénéficient eux aussi des améliorations suivantes :
– Supporte jusqu’à 55KHz (voir AUDxPER).
– Supporte ChipRAM ou FastRAM (donc les registres AUDxLCH acceptent maintenant 15bits et plus seulement 3bits ou 5bits pour adresser la mémoire).Il s’agit là d’informations préliminaires, et sont susceptibles d’évoluer.
Concernant le FPU cette fois.
Ce que Gunnar a ‘tenté’ d’expliquer c’est que les FPU Motorola étaient d’abord destinés à une industrie qui était à l’époque demandeur d’un chip du genre à très grande précision. Ensuite ce FPU est arrivé dans nos Amiga, tant mieux pour nous, mais qu’il est ceci dit bien trop précis (précis mais lent) pour les usages sur notre machine (quelque soit le domaine d’application, Calculs intensifs, 3D, Démos, Jeux, …) Donc Gunnar avait implémenté son FPU comme un vrai, un 80bits. Mais qu’il s’aperçoit finalement avec du recul que c’est du gâchis de gaspiller autant de place dans le FPGA actuel. Les démos n’ont pas besoin d’un FPU avec 80bits de précisions. Le FPU pourrait même être réduit à 32bits de précision que personne ne s’en apercevrait sauf pour de très rares cas, comme cela avait observé sur UAE à l’époque ou lui-même utilisait un FPU 32bits (plus facile à développer pour une machine cible x86 32bits). Ensuite, sur les gammes FGPA supérieures, genre ARRIA 10, il y a déjà une unité de calculs flottants (très rapide) inclut dans le FPGA et qu’il est donc à minima intéressant de se poser certaines questions. Ceci dit, pour l’heure, l’équipe est focalisé sur ce dont une carte autonome a besoin pour fonctionner, à savoir le core-chipset, le support software.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
salut flype,
J’ai suivis un peu les explications de Gunnar sur les forums en anglais…
Bon, maintenant je comprends mieux, c’est plus clair.
Mais ça ne répond pas à l’interrogation de pas mal de monde :
Y’aura t’il un FPU compatible 68882 dans une prochaine version du Core Appolo ?
Apparemment le FPU existe déjà à l’état de prototype 100% compatible, c’est à dire avec 80bits de précision, mais ça prends de la place dans le fpga, et il faudrait beaucoup de temps pour valider qu’il n’y ai pas de bug…
Bref, actuellement la Team travaille sur d’autre parties (chipset), peut on s’attendre ensuite à une implantation du FPU, même à 32bits de précision si il n’y a pas assez de place dans le FPGA ?Pourquoi beaucoup de monde réagis à propos de ce FPU ? (dont je fait partis)
Quand j’ai découvert la Vampire et les premiers Benchmarks, je me suis dit, chouette, vais pouvoir réutiliser Lightwave avec un vrai Amiga, avec un confort raisonnable. (les calculs seront toujours extrêmement plus rapide sur un x86)
Ensuite il existe pas mal de démo, jeux qui ont besoin du FPU…
J’ai compris que l’on pourrait simuler le FPU en software, que le Core Appolo était assez rapide pour le faire… Mais ce logiciel n’existe pas aujourd’hui, alors que le prototype de FPU (en Hard) existe…
De plus, si dans les prochaines version de FPGA, des unités de Calcul sont déjà intégrées, il faudrait réécrire les logiciels pour en profiter ? Un peu comme pour la MMU, qui n’est pas compatible avec celle de l’Amiga ?Donc pour moi, il serait dommage, de se priver d’une partie des softs qui à besoin du FPU; en attendant que soit développer des logiciels qui profiteraient des avancées du Core Appolo. En plus j’ai de sérieux doute que quelqu’un développe un soft à la hauteur de Lightwave 5 par exemple, ou alors dans un futur assez lointain…( si j’en avais les capacité, je n’hésiterais pas à le faire…)
Dit moi si je fais fausse route, si j’ai mal compris un truc, dans tout les cas c’est déjà un formidable boulot de dingue, j’ai déjà commandé une Vampire 500, et ça m’empêchera pas (même si ce serait dommage) de l’utilisé pleinement même sans FPU.
Enfin, pour terminer, il ya aussi quelques discutions à propos du développement de carte pour A3000 et A4000.
Certains doute de leur intérêt… Il y a, là aussi, plusieurs cartes seulement disponible sur bus zorro 3, et il serait dommage de les laisser au bord de la route, sachant pertinemment qu’il y aura beaucoup moins de demande pour cette version.
En sais tu un peu plus, à propos de versions autres que stand-alone et A1200 en préparation ?@bientôt
Les 4 channels historiques acceptent le 16 bits du coup? Gunnar parle de 32 bits aussi.
J’ai lu quelque part qu’on pouvait les paramétrer à droite ou à gauche. Je ne sais pas si c’était possible avec les canaux d’origine .
Sinon, c’est quoi l’idée du 5 ème canal? Je veux dire, pourquoi 5 et pas 6 ou 8? D’autant plus qu’un nombre impair de canaux n’est pas très “stéréo friendly”. Est-ce que c’est dans l’esprit d’avoir une carte son 5.1?
Concernant le fpu, on comprend que Gunnar souhaite utiliser les propriétés fpu natives d’un futur fpga. Cela permettrait d’avoir un fpu quasi ASIC à coté du core.
Pour ma part, je pense qu’il faut maintenir la compatibilité en ayant un bon fpu scientifique compatible. A coté de ça, il faudrait implémenter un fpu dédié à la 3D, donc 32 bits. Je pense que, comme l’idée est de changer de FPGA par un plus puissant, il pourra accueillir les 2 trucs. C’est juste mon avis.
Ce me divise cette histoire de FPU. On sent bien que Gunnar a expliqué un truc intelligent, à savoir que si on avait attendu un peu à l’époque, le FPU n’aurait eu aucune utilité sur Amiga, autant que ça l’est devenu (inutile) sur PC. Du coup cela aurait forcé les DEV à développer des choses qui n’ont pas besoin de FPU.
La on se retrouve avec une partie de la logitèque Amiga qui a besoin de ce FPU pour tourner, mais le truc intelligent ne serait probablement pas de proposer un FPU, mais plutôt que des mecs experts en DEV recodent ces programmes, ou en créent d’autres pour qu’ils n’aient plus besoin d’utiliser le FPU.
J’ai bon ? J’espère parce que dans ma tête c’est clair pour le moment :p
@Rod Pulsar
Pour résumer, Gunnar a implémenté un fpu 100% compatible avec le 060. Il est plus rapide que ce dernier. Il est pipeliné. Le nombre de cycles par instruction a été réduit (je crois). Reste plus qu’a lui appliquer une batterie de tests.
Parallèlement, Gunnar sait que son fpu pourrait être X fois plus rapide s’il cassait la compatibilité du fpu 060, dans le sens où il ferait des calculs “moins précis”, en réduisant la taille des registres et opérations à 32 bits au lieu des 64 bits et 80 bits (interne) actuellement. Pour lui, c’est un peu du gâchis compte tenu qu’on n’a pas besoin d’une telle précision pour toutes les applications fpu actuellement disponibles sur Amiga (sauf exception?).
Il ajoute qu’il pourrait encore améliorer les performances d’un fpu moins précis, en utilisant une technologie fpu intégrée (je ne sais pas comment la décrire autrement) aux fpga. Ce serait, comme je l’ai dit dans un post avant, une sorte de fpu ASIC intégré. Disons, que ça boosterait considérablement les performances mais, pour cela, il doit se caler sur une précision standard du calcul flottant. Donc, 32 bits. Là, je spécule un peu car je n’y connais rien aux fpga. C’est ce que je crois lire entre les lignes.
Ce cas de conscience, il l’a eu au fil du temps car cela fait un moment qu’il demande des procédures de tests aux amigaistes.
Et, compte tenu qu’il n’a pas eu de retours, il a donc relégué l’implémentation du fpu actuel en zone non prioritaire. Et donc, l’idée de faire un méga fpu pour plus tard lui ai apparu comme plus intéressant au fil des mois (Informations ici).Pour ma part, je considère le fpu comme un élément essentiel du cpu. A titre personnel, je l’ai utilisé dans quelques une de mes routines et c’est vraiment un bonheur de le manipuler par rapport aux calculs entiers. Un FMUL consomme que 3 cycles (en mode registres). Le FDIV pèse presque 40 cycles mais on peut s’arranger avec les inverses en utilisant les FMUL. De plus, les instructions fpu sont parallélisables avec les instructions integers sur le 060. Ce qui fait que, même en utilisant un FDIV, on pouvait caler des instructions integer après pour optimiser le code en fonction du pipeline.
Evidemment, le fonctionnement du 080 est encore plus bandant que celui du 060.J’ajoute qu’un fpu de la mort pourrait vraiment changer la donne en programmation 3D. L’integer c’est sympa, mais c’est parce qu’on n’avait le choix si on voulait que ça fonctionne sur toute la gamme amiga. Aujourd’hui, 25 ans se sont écoulés depuis la mort de Commodore. Si l’apollo core devenait le nouveau standard citoyen de la communauté Amiga Classic, on pourrait voir de très belles choses arriver. Surtout avec la tendance Vintage…
Pas de 16bits pour les 4 canaux originaux, sans quoi cela deviendrait incompatible avec l’existant. Si les canaux attendent du 16bits (2 octets) et que les jeux balancent du 8bits (1 octet), çà ne peut pas marcher. Autant les laisser tels quels. On pourrait imaginer une ‘option’ quelconque dans un registre mais çà prendrait beaucoup de place dans le fpga.
Pour le 5ème canal, prenons un exemple de base, celui que j’ai testé :
J’ai téléchargé un son AIFF 16Bits Stéréo 48KHz BigEndian d’environ 10MB. En entrée, on a donc un son Stéréo, donc 2 pistes audio de 5MB chacune dans un seul fichier. Les pistes sont entrelacées (interleaved). Le canal ‘avale’ les 2 pistes, chacune 16bits. En sortie, on a le son diffusé sur les 2 sorties audio, mixé par dessus les 4 voies originales et réparties équitablement à gauche et à droite. D’où la boutade de gunnar (en réponse à une question) sur les 2x16bits = 32bits. C’est un compromis compatibilité/place-dans-le-fpga qui offre suffisamment de valeur ajoutée pour l’utilisateur final. Çà offre tout de même un canal stéréo de qualité CD Audio, en plus de l’existant.A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns. Pour le FPU, beaucoup de remarques intéressantes.
Pour ma part, je suis utilisateur de la carte, comme vous, je suis donc en faveur d’un FPU sur la génération actuelle, et compatible avec l’existant, pour les mêmes raisons que vous : la logithèque Amiga utilisant un FPU est loin d’être anodine, et surtout concernant les démos (à mes yeux). Et tous les membres de l’équipe sont de cet avis. Et bien sûr recoder l’existant est juste une hérésie.
Mon opinion sur le sujet, je comprends bien sûr les contraintes techniques impliquées. Un 68882, donc 80bits, ou même le FPU intégré au 040/060, est de toutes façons un gros module, pas loin d’être aussi gros que le CPU lui-même (un bon 1/4 du fpga). Avec le nouveau chipset, un tel module ne rentre plus. Même réduit à 32bits, çà prend presque autant de place et quitte à recoder tout, je comprends bien sûr la position de Gunnar qui tendrait à se tourner vers les FPGA type ARRIA 10 pour çà.
Bon ok, mais et nous ? et nos démos qui ont besoin d’un FPU, on fait comment ? J’ai proposé à Gunnar une idée qui vaut ce qu’elle vaut :
A mon sens, même un FPU lent (par rapport à la vitesse globale d’une Vampire) mais compatible est suffisant. Cà ouvre au moins la possibilité de faire tourner la logithèque existante (c’est bien le but) même si çà envoie pas du pâté (en s’en fout, une démo qui tourne à 30 fps en utilisant le FPU n’a pas besoin de tourner à 75 fps, j’exagère exprès).
Donc j’ai demandé à Gunnar combien de place prendrait un FPU sans aucune instruction dedans (FMUL par ex), à part A) Les registres FPx (en 32bits) B) 2 ou 3 instructions stratégiques (FMOVE). Donc un module qui ne contient que la base registres ‘flottant’ et de quoi bien sûr les lire et écrire. Pour les autres, elles seraient 100% émulées par le CPU de façon totalement transparente (via une série de Traps + cuisine FPGA). Ce type de bébé FPU prendrait alors non plus 25% du FPGA mais à peine 5%. Donc çà rentre, facilement. Resterait ‘juste’ à implémenter toutes les instructions dans une lib software, en 68k/ammx. Le résultat serait suffisant je crois pour la génération actuelle. Cette solution ressemble beaucoup à ce qui avait été fait pour le 060 mais en beaucoup plus radical. Bien implémenté, çà serait 100% compatible (excepté peut-être le passage du 80 à 32bits). On a çà sous le coude, et on y réfléchira après notre roadmap actuelle.
Pour répondre à la question “aura-t-on un jour un FPU sur les vampires actuelles”, la réponse est donc j’espère bien que oui, d’une manière ou d’une autre.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.Merci pour tes infos mais j’ai pas tout bien compris.
Le fpu qui est dans les cartons de Gunnar contient toutes les instructions d’un 68882? Moi j’avais compris que ce devait être un fpu dans le style des 040/060, avec les instructions de base (FMUL, FADD, FDIV, FSQRT, etc), sans les instructions trigo, lesquels devaient être émulées par un Cyberpatcher ou un OxyronPatcher.
Du coup il me semblait que ce genre de fpu ne devait pas prendre énormément de place dans le fpga.
Concernant Paula, je comprends mieux le coup du 5 ème channel stéréo. Sinon, oui, je pensais à un switch pour basculer les canaux originaux en 16 bits, comme ça existe déjà pour certaines fonctionnalités AGA vs ECS. Ça aurait été cool.
Avec un seul canal stéréo 16 bits, le mixage devra se faire en soft. On perd un peu de philosophie Amiga mais ça ne change rien par rapport à ce qu’on a maintenant avec les cartes son additionnelles.
Sur le FPU, Oui tu avais bien compris, mais c’est pareil, çà prend toujours trop de place, et est sur 80bits.
Pour l’option paula 16bits sur les canaux originaux, çà demanderait à dupliquer le code de ces canaux, mais adapté pour du 16bits, plus un nouveau switch (1 bit) dans un registre quelconque; si j’ai bien compris, c’est donc trop gourmand dans le fpga (c3).
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns. Vu avec gunnar depuis longtemps, çà, ce n’est pas possible, architecturalement parlant, l’interface permettant de faire çà prendrait aussi beaucoup de place et serait trop complexe à mettre en oeuvre.
Edit1:
Et de toutes façons, ce ne serait pas une solution pour la gamme actuelle (nécessiterait une révision que les déjà-possesseurs de vampires ne pourraient profiter).Edit2:
Concernant les prix, je ne sais pas exactement.A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
- Le sujet ‘Infos sur la Vampire’ est fermé à de nouvelles réponses.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Infos sur la Vampire