Infos sur la Vampire (suite)
-
Dans un nouveau fil, Gunnar précise que l’unité 3D est similaire au fonctionnement du Blitter.
Il doit falloir comprendre qu’elle travaille avec des registres mémoire, en parallèle des autres processeurs.
L’info est importante puisque, jusqu’ici, Gunnar semblait plutôt travailler sur des instructions outils facilitant les tâches 3D/Texture dans le 68080.Source: http://www.apollo-core.com/knowledge.php?b=5¬e=33906
A un moment j’avait suggéré a Gunnar que la vampire ait des TMU (texture management unit) où l’on définisse les paramètres de la texture (haut,large,format,pointeur) puis qu’on ait une seule instruction pour lire/écrire un pixel depuis/vers cette texture en faisant abstraction du format/taille de la texture lue /ecrite
Genre
RGBA32=ReadPixel(tex1, UV);
WritePixel(tex1,UV,RGBA32);J’espère que c’est ça
Je crois que l’unité de texture ne connait que des tailles fixes prédéfinies (genre 32×32 ou 256×256). C’était en tout cas ainsi à une époque, ce qui ne me convenait pas pour quake ou les jeux ayant des textures de toutes tailles. Gunnar voulait que je modifie le code de quake pour qu’il utilise des textures 256×256 ce qui est bien gentil, mais ce sont les assets du jeu qu’il faut modifier là, et pas le code. Bref je ne pouvais pas vraiment utiliser cette instruction AMMX « comme il faut ». Ca n’empêche pas mon quake de marcher à plus de 30fps de toute façon car ca n’est pas dans l’affichage des textures qu’on passe le plus de temps en vrai (résultat du profileur à l’appui: 3.792% du total seulement avec au moins 5 routines à plus de 4% au dessus).
Test date: Mon Oct 28 02:02:33 2019 Execution profile for: sam/quake.gcc-2.95.030_movel Time units: Percentual Sort order: Overall time Profiling mode: Separate Used commandline: -safe -usemode 0 +timedemo demo1 All symbols shown D_PolysetDraw 181030 0.000 5.952 R_ClipEdge 252602 0.000 5.836 @R_RenderFace 64954 0.000 4.859 @D_DrawNonSubdiv 180923 0.000 4.673 D_RasterizeAliasPolySmooth 74927 0.000 4.005 @D_DrawSpansXP4 19311 0.000 3.792 <=== _R_AliasPreparePoints 1947 0.002 3.749 R_AliasTransformFinalVert 154742 0.000 3.617 @R_RecursiveWorldNode 71172 0.000 3.462 R_EmitEdge 109328 0.000 2.923 @D_PolysetDrawSpans8 91914 0.000 2.547 R_GenerateSpans 63384 0.000 2.271 @D_DrawParticle 81930 0.000 2.157 @_R_ScanEdges 417 0.005 1.896 @Q_rand 80959 0.000 1.774 D_PolysetCalcGradients 74927 0.000 1.721 @Q_memcpy 66492 0.000 1.585 R_DrawSurfaceBlock8_mip0 16127 0.000 1.583 R_StepActiveU 62961 0.000 1.499 @_R_CleanupSpan 63384 0.000 1.341 strcmp 58944 0.000 1.293 R_DrawParticles 417 0.003 1.268 @D_DrawZSpans 19311 0.000 1.173 R_AliasTransformVector 45072 0.000 1.007Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
Oula un Vampire slayer est après la Vampire, soit disant 400mhz 68040.
https://www.buffee.ca/Nearing-production/
Un 68040 à 400 Mhz … j’aimerai bien voir comment ils vont résoudre le problème des échanges sur les BUS… quand on sait que par example la meilleur simulation logiquement est au cycle près pour justement ne pas avoir des problèmes de desync avec le hard qui a été conçu tout autour avec un cahier des charges à l’époque… car ici si j’ai bien compris … ce module va aller s’intercaler sur le socket du 680×0 de l’amiga.
Attention je ne dénigre pas … je salue l’effort car c’est un beau projet !
...::: Mist - Mister Addon - Fpga Arcade 060 - ZxUno :::...
...::: Amiga 1230 Gotek WiFi-CF 16GB - A3000 - A4000/30/64Mb/Vlab1.3/Oktagon :::...Donc 100 ou 200 wait-states à chaque accès mémoire sur le bus Zorro. Donc en vrai le 040 n’ira pas à la vitesse indiquée. C’est du bullshit marketing qui ne m’inspire pas confiance.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.) Donc 100 ou 200 wait-states à chaque accès mémoire sur le bus Zorro. Donc en vrai le 040 n’ira pas à la vitesse indiquée. C’est du bullshit marketing qui ne m’inspire pas confiance.
Laissons faire et lorsque le produit existera, il sera temps de voir ce qu’il fait. Ce qui est sur, c’est que le fait de se contenter de remplacer le 68000 bêtement risque de faire de cette carte une carte avec bien peu d’intérêt car sur A500 (habituellement dédié aux jeux) ca n’aura aucune utilité et dans un A2000 qui est généralement équipé d’une carte graphique + disque dur, on peut imaginer s’en servir pour des softs de productivité. Mais de nos jours, qui utilise ces softs? Personne.
Cette carte ne permettra même pas de faire tourner les grosses démos des 10 dernières années car celles qui demandent du CPU sont AGA. Les démos ECS sont taillées pour du 68k de base.Après, l’un des grands intérêts de cette carte sera sa compatibilité avec les autres ordinateurs à base de 68k. On peut imaginer que le DEV arrivera à en refourguer aux Ataristes et aux Maceux désireux de faire du classic par nostalgie comme nous. Cela dit, je pense que cette dernière communauté est bien plus mince que la communauté Amiga..
En gros, wait and see.RyZen Rulez 😉
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Infos sur la Vampire (suite)
