Wazp3D beta 56 1.6

Nouvelle version avec quelques glitchs graphiques sur certaines textures fixés pour GLBlitzQuake :

Bouh !

J'arrive maintenant à presque 16 fps constants avec la vache :

Disponible ici, et gratuit comme toujours !

  

Wazp3D beta 56 1.5

Comme pour le driver 3fdx, j'ai finalement supprimé tous les fameux fintrz émulés par la 68040.library, ainsi que tout le code d'émulation que j'avais rajouter dans la version 1.2 si un 040 était détecté. Je ne distingue aucune différence entre la version 1.4 et cette nouvelle 1.5 :

Avec tous les fintrz

Sans tous les fintrz

Avec tous les fintrz

Sans tous les fintrz

Disponible ici, et gratuit comme toujours !

   

Wazp3D beta 56 1.4

Nouvelle version 1.4 avec quelques fonctions optimisées : je gagne 1 fps avec la démo CoW3D, à 15 fps constants maintenant :

Comme d'habitude, tout est disponible ici...

   

Wazp3D beta 56 1.3

Une nouvelle version de Wazp3D avec du code realtime de débug supprimé et aussi de nombreuses instructions 040/060 remplacées par des compatibles 68881/68882 : cette fois, la librairie devrait aussi fonctionner avec les 68020/030.

Comme d'habitude, tout est disponible ici...

   

3dfxVoodoo.chip 7.17

Je n'ai plus aucune nouvelle d'Hédeon, après environ un mois et demi d'attente, le mainteneur actuel de ce driver 3dfx pour le Prometheus, à l'origine écrit par MastaTabs. J'avais eu d'ailleurs des problèmes avec ce dernier à qui j'avais envoyé une vingtaines d'€ pour un composant. Ne m'a jamais rien posté, et il a ensuite été très difficile de me faire rembourser.

Bref, voici donc un patch qui active le fameux Swizzle bit, il n'y a que de légers changements :

J'ai testé GLBlitzQuake, W3D_Cavallery et Quake 2 avec WinUAE :

Tout semble bien fonctionner à priori. Attention, vous devez avoir installé la W3D_Picasso96.library 4.4a et la W3D_AvengerLE.library 4.4b, 4.4c ou 4.3 beta 4a...

D'ailleurs, il me faudrait toujours savoir si la 4.4b est plus ou moins rapide que la 4.4c : un simple test avec W3D_Cavallery pour connaitre les fps me serait suffisant avec le hardware réel. Merci d'avance !

Comme d'habitude, tout est disponible ici...

   

Prometheus Swizzle 3dfx

Bonne nouvelle ce matin, je viens juste de modifier le fichier 3dfxVoodoo.chip 7.16 pour activer le fameux Swizzle bit des GPUs 3dfx qui les switchent en mode Big Endian comme tous nos 68k.

J'ai vite testé quelques jeux Warp3D et tout fonctionne à merveille avec mes nouvelles versions W3D_AvengerLE.library sous WinUAE !

 

L'auteur de ce driver a été contacté par mes soins pour une nouvelle version, certainement 7.17 je pense...

 

Un peu de patience, il est en cours de déménagement !

Différences

Des différences apparaissent avec l'émulation 3dfx sous WinUAE comparativement aux GPUs réels, après difficile d'obtenir un résultat software 100% identique au hardware d'origine...

J'ai donc changé 4 paramètres dans cette nouvelle version 4.4c et rien d'autre : les performances sont plus lentes qu'avec la version précédente 4.4b sous WinUAE, par contre elles devraient être meilleures sur le hardware original.

version 4.4c beaucoup plus lente sous WinUAE

Il faudrait tester les deux versions b et c sur un Mediator 1200 ou 4000. Rappel des librairies ici !

Dans la prochaine version, j'ajouterai une détection WinUAE pour utilisation du code le plus rapide sous cette émulation.

Comme d'habitude, tout est disponible ici...

   

W3D_AvengerLE.library 4.4b

Même légère update que pour la version LEMU. Avec l'émulation Mediator 4000 sous WinUAE, j'obtenais 156/160 fps avec la dernière 4.2a officielle. Maintenant 180 fps. Là encore, je pense que les améliorations seront moindres sur le hardware réel :

Comme d'habitude, tout est disponible ici...

   

W3D_AvengerLEMU.library 4.4b

Quelques légers soucis trouvés et fixés pour cette version 4.4b du 15/01/2023 : marche mieux encore avec une fonction comportant une grande loop optimisée.

Sous WinUAE et l'émulation du Mediator 1200, j'obtiens environ 43/44 fps avec la dernière version 4.2a officielle. Maintenant 60 fps. A mon avis, le speedup sera hélas moindre sur le vrai hardware :

L'excellente nouvelle concerne surtout le 040 : j'ai en effet finalement supprimé complètement l'instruction fintrz émulée par la 68040.library : en resultera une très légère différence au niveau de certaines couleurs. Personnellement, je ne vois aucun écart.

 

Après, je suis obligé de le faire, aucune envie de proposer deux versions différentes : une pour le 030/060 et une autre pour le 040. Il y avait aussi la possibilité d'insérer une détection 040 en temps réel juste avant cette fameuse instruction, mais qui prenait encore des précieux cycles CPU...

Comme d'habitude, tout est disponible ici...

    

W3D_CyberGfx4.library 4.4

Oh là là, j'ai trouvé un énorme bug dans la version précédente... Enfin bref, tout fonctionne correctement maintenant avec cette nouvelle 4.4 !

Il est possible de tester sous WinUAE avec l'émulation 1200 BlizzardPPC GRex 3dfx :

De plus, j'ai aussi essayé de modifier le driver Voodoo3 de CyberGraphX 4 pour switcher la 3dfx en mode BigEndian comme nos 68k, mais sans succès hélas... Dur dur sans les sources originaux...

 

Comme d'habitude, tout est disponible ici...

 

miniGL 1.26

Nouvelle version avec 7 routines retravaillées :

• _GLCullFace (de 72 à 50 octets)
  
• _GLDepthRange (de 90 à 62 octets)
  
• _GLDisableClientState et _GLEnableClientState (de 120 à 40 octets)
  
• _GLLoadIdentity (de 128 à 90 octets)
  
• _GLOrtho (de 1460 à 360 octets)
  
• _m_DoInvert (de 508 à 246 octets)
  

  

La réduction de taille n'offre que des avantages pour ce genre de petites routines :

• prends moins de cycles CPU,
  
• prends moins de place dans le disque dur,
• prends moins de temps à se transférer du disque dur dans la mémoire,
  
• prends moins de place dans sa mémoire,
  
• prends moins de temps à se transférer de la mémoire dans le code cache du CPU,
• et le plus important : prends moins de place dans son code cache.

Y'a pas de p'tites économies, ma p'vre Lucette...

 

Sources et librairies compilées disponibles ici !  

    

miniGL 1.25

 Nouvelle avancée avec 5 routines retravaillées :

• _GLRotatef (de 3208 à 612 octets)
• _GLLoadMatrixd et _GLLoadMatrixf (de 528 à 92 octets)
• _GLTranslated (de 900 à 170 octets)
• _GLScalef (de 782 à 150 octets)
  

 

Etant moi même un cas spécial, je n'ai rien contre les cas spéciaux : MGLMAT_0001 a été supprimé de _GLLoadMatrixd et _GLLoadMatrixf car n'apporte que trop peu tout en compliquant beaucoup. Les cas spéciaux ne doivent être utilisés qu'avec des gains réels. Rassurez-vous, toutes ces petites modifications restent 100% compatibles avec tout le software utilisant cette librairie miniGL.

Sinon, j'ai encore réussi à optimiser les deux _GLPopMatrix et _GLPushMatrix, passant alors de 332 octets à maintenant seulement 80 octets, comme quoi en cherchant un peu...

  

Sources et librairies compilées disponibles ici !  

    

miniGL 1.24

Trois nouvelles routines de faites, ça avance :

1. _GLFrustum (de 1440 octets à 364 bytes)
   
2. _GLScaled (de 806 octets à 142 octets)
3. _GLInitMatrix (de 218 octets à 86 octets)
   

 

Je vous avais bien dit à plusieurs reprises que nos compilateurs C Amiga 68k ne produisaient que du code de moyenne qualité, et personne ne voulait me croire...

 

Comme dans tous projets complexes, des décisions importantes sont à prendre et les bonnes de préférence : neuf cas spéciaux (les _m_MatMultA0001_xxx avec MGLMAT_0001) d'autres cas spéciaux compliquent beaucoup, et déjà le dispatcher _m_Mult, je vais les supprimer aussi des sources originaux, car n'apportent que trop peu selon moi, voire même ralentissent dans certains cas...

J'y pensais déjà depuis un moment et puis la _GLFrustum m'a finalement convaincu...

Pour donner une idée, voici plus de précisions sur l'utilisation des routines minigl dans GLBlitzQuake :

 

Là encore, si vous voyez à optimiser davantage, contactez-moi de toute urgence. Chaque cycle est important et compte. Par exemple, la _GLColor4fv peut-elle être convertie toute en integer ?

    

Sources et librairies compilées disponibles ici !

   

miniGL 1.23

Une nouvelle version de miniGL avec deux routines optimisées (_GLRotatefEXT et _GLRotatefEXTs) qui passent toutes deux de 21 076 octets à seulement 436 octets... Arf, j'ai bien bossé ! gcc avait produit tout un pataquès incroyable, avec de nombreuses sous-routines inutiles... Bref, un beau méli-mélo qui a été très bien simplifié pour ne garder que le strict minimum nécessaire.

 

La routine _GLTranslatef passe également au régime minceur de 876 octets à 156 octets...

 

miniGL 1.2 contient 289 routines, déjà 18 de retravaillées tout de même !

  

Y'a encore du boulot !

   

Sources et librairies compilées disponibles ici !

   

WinUAE 4.4.0 bug fix

J'ai trouvé un bug assez sérieux entrainant un reset et ensuite un guru dans certaines circonstances avec l'émulation FPU JIT de WinUAE 4.4.0 que j'utilise quotidiennement sur mon PC.

Alors, deux solutions pour y remédier :

• le bug n'apparait que lorsque "More compatible" est sélectionné. Donc à décocher :
  

 

•  ou utiliser la nouvelle version 4.5.0 qui le corrige dans tous les cas, l'auteur contacté l'ayant fixé.

 

Ah les bugs sur Amiga 68k, une sacrée épine dans le pied...

    

miniGL 1.22

Bon, aucun coder ne semble être intéressé pour convertir cette librairie en asm, c'est dommage...

Bien souvent, lorsque personne ne veut vous aider à réaliser un projet, vous critique ou même vous décourage, c'est que vous êtes sur le bon chemin... A méditer !

Même les routines minuscules, gcc 2.95.3-4 est incapable de bien les coder... Incroyable mais vrai :

1. _GLClearColor : 102 octets économisés par rapport à gcc
2. _GLDepthFunc : 58 octets économisés par rapport à gcc
3. _MGLLockDisplay : 26 octets économisés par rapport à gcc
4. _MGLUnlockDisplay : 4 octets économisés par rapport à gcc
5. _m_MatCopy : 32 octets économisés par rapport à gcc
6. _GLPopMatrix : 108 octets économisés par rapport à gcc
7. _GLPushMatrix : 96 octets économisés par rapport à gcc
8. _GLAlphaFunc : 72 octets économisés par rapport à gcc
9. _GLShadeModel : 24 octets économisés par rapport à gcc
10. _GLBindTexture : 32 octets économisés par rapport à gcc
11. _GLColor4f : 138 octets économisés par rapport à gcc
12. _GLColor4fv : 126 octets économisés par rapport à gcc
13. _GLFinish : 18 octets économisés par rapport à gcc

J'ai choisis celles-ci car elles sont utilisées par Quake2, bien pratique pour tester ensuite.

Une espèce de "protection" a été ôté des _GLPopMatrix et _GLPushMatrix. La nouvelle libmgl.a fait toujours la même taille pour l'instant, les octets gagnés ont été remplacé par des nop.

Librairie testée avec Quake 2 et GLBlitzQuake. Encore beaucoup de travail avant un speed up (seulement 0.5 seconde sous Q2), car toutes les routines retravaillées ci-dessus sont assez peu utilisées.

Sources et librairies compilées disponibles ici !

   

Wazp3D beta 56 1.2

La précédente 1.1 avait un petit talon d'Achille avec le 68040, je dois l'admettre : 37 fintrz et 2 fint étaient présents dans la librairie de façon à favoriser plutôt le 060, entrainant de fait une dépendance à la 68040.library puisqu'elles sont absentes des transistors de ce CPU.

Alors, même si Wazp3D fonctionnera sur 68040 forcément plus lentement que sur son grand frère le 68060, j'ai tout de même consacré environ 5 jours à remplacer la totalité de ces 2 instructions manquantes par du code cette fois bien présent dans le cœur du 040, histoire de fignoler un peu plus l'excellente librairie de notre Maréchal Thellier...

Et comme je conseillais ici de ne jamais utiliser les instructions absentes des 040/060, il est de bon ton de montrer l'exemple il me semble...

Peut-être qu'un talentueux développeur hardware sortira un carte 040 très rapide un jour, qui sait...

Bref, une détection du 68040 a été ajouté et redirige alors toutes les routines utilisant les fintrz et fint vers d'autres équivalentes spéciales 040, le tout de façon automatique, les utilisateurs n'ont rien à faire... De cette manière, les 68881/68882/68060 utilisent ainsi leurs fintrz et fint, et le 68040 ses propres routines sans : tous les 020+/881+ sont ainsi contents ! Et ce dans un unique fichier Warp3D.library !

La sous-routine _AntiAliasImage (ne fonctionnant qu'avec le rendu "soft68k to Image") a été entièrement refaite, entrainant un gain impressionnant de 59 fps avec la version 1.1 à maintenant 93 fps (soit +34 fps) sous la petite démo CavalleryW3D et ma config PC personnelle :

 
Sachez que beaucoup est encore optimisable, mais le boulot à consacrer est aussi assez important pour un speedup général à mon humble avis ensuite assez faible...

Vous comprenez tous mieux maintenant pourquoi j'avais retranscrit toute la librairie en asm68k : tout ceci est impossible à réaliser en C/C++...

   

Disponible ici, et gratuit comme toujours !

  

Wazp3D beta 56 1.1

Petit soucis de fichier configuration corrigé dans cette nouvelle version, il est maintenant le même que la version beta 56 sur Aminet (c'est à dire Wazp3D.cfg au lieu de Wazp3D_v10.cfg de ma version 1.0)... Je pensais qu'il était incompatible avec la dernière d'Alain mais non en fait...

J'ai sous-estimé l'Amiral Thellier, ouh là, il va m'en vouloir...

Quelques fonctions ont été légèrement oprimisées, StarShipW3D monte un peu plus haut, à 400/423 fps contants cette fois...

Disponible ici, et gratuit comme toujours !
      

miniGL 1.21

Voici une nouvelle version de l'open source miniGL 1.2 sur Aminet.

Sachant que le succès de l'Amiga à ses débuts était dû à une bonne partie de sa logithèque programmée en asm, retour donc aux fondamentaux maintenant avec pour objectif le passage total du code C de miniGL tout en assembleur 68k. Rien n'est prévu pour le PPC, ce CPU n'a plus aucun avenir de toutes les façons...

Si des codeurs veulent se joindre à moi, allez-y contactez-moi : attention, un niveau assez élevé est requis.

Bref, l'Amiga mérite du code de qualité, ras-le-bol des compilos C...

  

Voici les règles générales d'optimisations que je m'applique et que je recommande à tous :

• utiliser le moins d'instruction possible dans presque tous les cas. Rares exceptions pour les loops importantes,
• ne jamais utiliser les instructions manquantes des 040/060, c'est-à-dire celles émulées par la 68040.library et 68060.library,
• n'inliner que les petites sous-routines, jamais les moyennes ni les grandes,
• toujours utiliser les pipelines du 060 en ordonnant correctement les instructions entres elles,
• toujours préférer le mode PC relatif, jamais ou très rarement les adressages absolues,
• ne jamais pré-charger les datas dans les registres internes de façon à ce que le CPU utilise au mieux son datacache,
• toujours utiliser les six registres scratchs (d0, d1, a0, a1, fp0 et fp1) le plus judicieusement possible,
• passage des args par les registres plutôt que par la pile,
• utilisation des boucles le plus souvent possible.

Les sources d'Aminet ont été compilé avec gcc 2.95.3-4. La librairie est compatible avec gcc 3.4.0 et le dernier gcc 6.5.0b. J'ai déjà optimisé 4 petites routines :

1. _GLPushMatrix : 72 octets économisés par rapport à gcc
2. _GLPopMatrix : 54 octets économisés par rapport à gcc
3. _TMA_Check : 24 octets économisés par rapport à gcc
4. _TMA_Start : 22 octets économisés par rapport à gcc

  

Notez que je recherche les sources de la version précédente à la 1.2 (peut-être nommée 1.15 ?) ayant servit pour la compilation du jeu commercial bien connu Quake2.

Sources et librairies compilées disponibles ici !
     

soft3d.library 53.1

La soft3d.library fait partie du package Wazp3D et sert de pont entre l'Amiga et la soft3d.dll en x86. Attention, cette dernière est maintenant à déplacer de votre répertoire WinUAE/ à WinUAE/winuae_dll/ sinon vous aurez un message d'erreur.

Là encore avec le passage en full assembleur, un sacré paxon de code inutile a été dégagé, la librairie passe de 98 032 octets à seulement 3012 !

Petite peine cependant avec le mode "Hard" : aucun speedup. Mais avec le "Soft to bitmap", les fps explosent avec les programmes comportant peu de triangles :

Regardez par vous même :

• StarShipW3D v1.2 : 313/327 fps => 514/533 fps
• CavalleryW3D v1.2 : 257/276 fps => 342/360 fps
• CoW3D v5.3 : 79 fps => 79 fps 

Toujours la même déception avec la CoW3D et ses nombreux 5813 triangles. Il y a un problème quelque part, j'avais le même soucis avec les vrais drivers Warp3D sur le vrai hardware...

Disponible ici, et gratuit comme d'habitude !