lundi 5 octobre 2020

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 !  
    

mardi 29 septembre 2020

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 !  
    

vendredi 18 septembre 2020

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 !
   

samedi 12 septembre 2020

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 !
   

samedi 5 septembre 2020

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...
    

lundi 24 août 2020

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 !
   

dimanche 16 août 2020

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 !
  

mercredi 27 mai 2020

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 !
      

samedi 16 mai 2020

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 !
     

samedi 9 mai 2020

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 !
     

vendredi 8 mai 2020

Wazp3D 1.0 (WinUAE)

Dans la foulée, voici la version pour WinUAE tout en assembleur 68k maintenant. Cette version de Wazp3D beta 56 spécifique à l'émulateur utilise deux spécificités des PC :
  1. utilisation du GPU de votre carte graphique ("Hard" et "Hard (overlay)")
  2. ou rendu calculé par les CPUs x86 ("Soft to bitmap")
 
Attention sur ma configuration, j'ai été obligé de sélectionner ces deux paramètres afin d'obtenir les bonnes couleurs à l'écran, sachant que le rendu "Hard" ne fonctionne qu'en 32bit :
 
Le speedup est assez décevant, en mode "Hard" :
  • StarShipW3D v1.2 : 327/342 fps => 327/342 fps
  • CavalleryW3D v1.2 : 266/276 fps => 266/288 fps
  • CoW3D v5.3 : 116/118 fps => 118/122 fps

Et en mode "Soft to bitmap" :
  • StarShipW3D v1.2 : 300/313 fps => 313/327 fps
  • CavalleryW3D v1.2 : 248/266 fps => 257/276 fps
  • CoW3D v5.3 : 77 fps => 79 fps 

Alors pour quelle(s) raison(s) ? Mon PC déjà est équipé d'une petite GT740. Ensuite, est-ce que le système RTG Picasso96 ralentirait l'affichage de la 3D ?

Disponible ici, et gratuit comme toujours !

(Le fichier de configuration est toujours le même que l'original, à savoir "Wazp3D.cfg". Je vais faire machine arrière avec la version -full, en supprimant le _v10 dans la prochaine version)
      

vendredi 1 mai 2020

Wazp3D beta 56 1.0

Wazp3D beta 56 a été complètement retranscrit en 47 600 lignes d'asm 68k : plus un seul source en C/C++, ça fait du bien... Pour ceux qui débarquent, rappelons que Wazp3D est une réécriture complète de Warp3D en n'utilisant cette fois que le CPU pour tous les calculs 3D :

Tout d'abord, saluons tous ensemble l'esprit chevaleresque de notre petit génie national cocorico Alain Thellier pour avoir diffusé son code source m'ayant beaucoup aidé. De plus, sachez que c'est mon tout premier projet software 100% professionnel avec maintenant un unique source asm 68k complet incluant toutes les structures, et même les commentaires de son auteur : mériterait la Légion d'Honneur de l'Amiga cet Alain quand même...

Le soucis majeur du C/C++ est que le programmeur se met sous la dépendance d'un compilateur dont nous ignorons tout du code qu'il va alors produire. Voilà ce qui me chagrinait avec le source C mis à disposition. Wazp3D est enfin "sauvé" des méandres d'un obscur gcc... Maintenant plus aucune surprise : le source est en pure asm 68k.

Wazp3D est surtout destiné aux CPUs puissants, car les mathématiques prennent beaucoup de temps aux processeurs et coprocesseurs : j'ignore au jour d'aujourd'hui s'il est possible d'obtenir une librairie rapide pour nos Amiga 68k originaux : sans l'aide des GPUs, la tâche est bien plus difficile pour arriver à des fps décents...

Pour cette version 1.0, tous les debugs ont été supprimé car realtime : en effet, le petit programme de préférence Wazp3D-Prefs permet de sélectionner en temps réel bon nombre d'options de débogage. Le problème est que même lorsqu'elles sont désactivées, les tests sont toujours exécutés par la librairie, donc prennent du temps CPU inutile...

Bref, si un développeur a besoin des informations de debug, il peut toujours utiliser la dernière version d'origine disponible sur Aminet, tandis que les utilisateurs s'en fichant, la mienne :
  
Nouvelle version 1.0 basée sur la béta 56 donc, un peu plus rapide sur ma configuration PC :

Avec un écran WinUAE 32 bit en RGBA sous Picasso96
  • StarShipW3D v1.2 : 360/378 fps => 378/400 fps
  • CavalleryW3D v1.2 : 184/189 fps => 189/194 fps
  • CoW3D v5.3 : 32 fps => 33 fps
  
Avec un écran WinUAE 24 bit en RGB sous Picasso96
  •  StarShipW3D v1.2 : 720 fps => 800 fps
  •  CavalleryW3D v1.2 : 248 fps => 266 fps
  •  CoW3D v5.3 : 33 fps => 34 fps

Attention, le fichier de sauvegarde des préférences de Wazp3D va être obligatoirement sauvegardé de Wazp3D.cfg en maintenant Wazp3D_v10.cfg, tout en utilisant le même Wazp3D-Prefs !

Vieux projet de fin 2018 que je mets enfin à disposition : je voulais au départ rendre le source open, mais les vampires vont utiliser mon travail pour me rendre complice de leur entreprise de pompage d'énergie afin d'achever notre machine préférée. Voilà où nous ne sommes arrivé aujourd'hui à cause de leur division AMMX... Et ils ont même infecté le 1200 dernièrement, incroyable...

Disponible ici !