Questions ? [eng]

With the well known utility SnoopDos, it seems to be possible to know which libraries are used by which programs what is useful. We can see here that two versions of LE and BE of W3D_Avenger.library are open by the Warp3D.library:

LE and BE letters mean Little Endian and Big Endian. they just are order of reading. For example, the hexadecimal number $12345678 is Big Endian (the same way of reading in french or english language) then Little Endian is $78563412.

PPC and 68k are Big Endian then x86 are Little Endian like the 3dfx by default. There is a needed conversion of BE => LE for our 68040/060 that take a little bit of procesor time because it has to use three instructions (rol.w/swap/rol.w) each time. The 3dfx drivers use about 4440 times these three instructions.

Always with the LibraryTimer utility, I can see that no W3D_AvengerBEMU.library function is called by the game Quake 2!

What's the use of this library? Thank you if you can answer with some commentary if you have the answer or just an idea that can help me to know and understand!

         (translated by johnz)
   

Interrogation ? [fr]

Avec l'utilitaire bien connu SnoopDos, il est possible de savoir quelles librairies sont chargées par tels ou tels programmes, ce qui est bien pratique. Ici, nous pouvons voir que les deux versions LE et BE de la W3D_Avenger.library sont ouvertes par la Warp3D.library :

Les lettres LE et BE signifient Little Endian et Big Endian. Ce sont tout simplement des ordres de lecture. Par exemple, le nombre hexadécimal $12345678 est Big Endian (le même que le sens de lecture de la langue française ou anglaise), alors qu'en Little Endian, c'est $78563412.
   

Les PPC et les 68k sont Big Endian, alors que les x86 sont Little Endian, ainsi que les 3dfx par défaut. Il y a donc une conversion BE => LE nécessaire pour nos 68040/060 qui prends hélas un peu de temps processeur, puisqu'il faut utiliser trois instructions (rol.w/swap/rol.w) à chaque fois. Les drivers 3dfx utilisent environ 4440 fois ces trois instructions de conversion.

Toujours avec l'utilitaire LibraryTimer, je m'aperçois qu'aucune fonction de la W3D_AvengerBEMU.library n'est appelée avec Quake 2 !

A quoi sert cette librairie alors ? Merci de répondre dans les commentaires ci-dessous si vous avez la réponse, ou même un idée qui pourrait m'aider à comprendre !

   

The beta 2 [eng]

The beta 2 is currently only a simple clearing with all internal connections routed through the Function Table too. In fact, here are the main steps that I can use to finally modify the programs as I want:

1. Disassembling a program or a library using InGo (available on Aminet),
2. Correctly format the source obtained using Ced, in order to have a clear listing,
3. Assembling the source using Phxass to check if everything is ok.

From here, the source is readable and writable. As an evidence, the more the ptogram is big, the more the source will be bigger too! For example, the W3D_AvengerLEMU.library has more than 152 610 code lines! I spent many days to put everything in good order, line by line! You have to see it to believe it, trust me... The fat Cosmos is crazy, isn't it?

 

Then, the first thing to do for this kind of very large library is what I call clearing stuff. This step is usefull to remove all unnecessary code, which is not used. As always, with this very same W3D_AvengerLEMU.library; there were many trigonometric math functions that were not in use at all into the library itself. Only two trigos were used. Moreover, all these functions are the same as those already present into the 68040 and 68060.library written by Motorola in 1990/91. In other words, the authors have included all the large package into the whole library. However, keeping only the two useful functions, leads to saving space: the library lost about 25,50 KB. It mean that less loading time is required from hard drive to ram and less fastram used.

It's better than nothing !

(translated by CrashMidnick)
 

La béta 2 [fr]

La version béta 2 est pour le moment un simple débroussaillage avec aussi tous les branchements internes redirigés par la Table de Fonctions (Function Table en anglais). En effet, voici les différentes étapes par lesquelles je peux pour finir modifier les programmes à ma guise :

1. Désassemblage du programme ou de la librairie avec InGo (sur Aminet),
2. Mise en forme du source obtenu avec Ced, de façon à avoir un listing clair,
3. Assemblage du source avec Phxass pour vérifier que tout est correct.

A partir de là, le source est exploitable et modifiable. Plus le programme est gros, plus le source le sera aussi bien évidement ! La W3D_AvengerLEMU.library par exemple fait plus de 152 610 lignes de code !! J'ai mis des jours et des jours à tout bien ordonner, ligne par ligne ! Il faut le vivre pour le croire, croyez-moi... L'est un peu crazy le gros Cosmos !!

  

Ensuite, le tout premier truc à faire pour ce genre de librairie très volumineuse, c'est ce que j'appelle le débroussaillage. Cette étape vise tout simplement à ôter tout le code inutile, celui qui n'est pas utilisé. Toujours avec cette même W3D_AvengerLEMU.library, et bien il y avait de nombreuses fonctions mathématiques trigonométriques qui ne servaient pas du tout dans la librairie. Seules deux trigos étaient utilisées. D'ailleurs, toutes ces fonctions étaient les mêmes que celles présentes dans la 68040 et 68060.library, écrites par Motorola en 1990/91. Bref, les auteurs ont inclus tout le gros paquet dans son entier. Or, en ne gardant que les deux fonctions utiles, en bien la librairie a rétrécie à vue d'oeil, et fait maintenant environ 26,50 Ko de moins.

26.50 Ko de moins, ça fait déjà un peu moins de temps de chargement du disque dur à la ram, et moins de fastram utilisée aussi. Toujours ça d'économiser !

 

LibraryTimer (II) [eng]

Looking closer at the source of the W3D_AvengerLEMU.library, I noticed that the internal functions are called directly by the bsr and not by the FunctionTable:

However, the LibraryTimer patches the library's FunctionTable to insert a counter and even a measure of time. Well, LibraryTimer will not add it in its statistics using this bsr. The solution is simple, just replace it with a jsr, being sure that a6 is the basis address of the W3D_AvengerLEMU.library:

All in all, there were less than a dozen of bsr calls. Now, we have more understandable statistics with LibraryTimer:

The -$3C function seems to be the most used one: it will be necessary to be sly as a fox to reduce instructions as much as possible. Here, every saved cycle is very important.

Here are the new statistics:

• fonction -$24: 382 fois
• fonction -$36: 1 fois
• fonction -$3C: 367 558 fois
• fonction -$5A: 110 fois
• fonction -$90: 23 fois
• fonction -$AE: 1 fois
• fonction -$B4: 845 fois
• fonction -$BA: 884 fois
• fonction -$D8: 2 357 fois
• fonction -$DE: 452 fois
• fonction -$E4: 383 fois
• fonction -$EA: 228 fois
• fonction -$108: 10 fois
• fonction -$10E: 382 fois
• fonction -$114: 383 fois
• fonction -$144: 5 054 fois
• fonction -$14A: 1 fois
• fonction -$162: 354 fois
• fonction -$180: 1 fois
• fonction -$198: 24 233 fois
• fonction -$19E: 113 013 fois
• fonction -$1B6: 150 286 fois
• fonction -$1C2: 6 524 fois

Now, using the very same method for the Warp3D.library, with the same game Quake 2:

• W3D_SetState: 7 932  fois
• W3D_LockHardware: 387 fois
• W3D_UnLockHardware: 386 fois
• W3D_WaitIdle: 386 fois
• W3D_AllocTexObj: 1 fois
• W3D_SetFilter: 3 fois
• W3D_SetTexEnv: 2 318 fois
• W3D_SetWrapMode: 1 fois
• W3D_SetBlendMode: 1 011 fois
• W3D_SetDrawRegion: 387 fois
• W3D_ClearZBuffer: 387 fois
• W3D_SetZCompareMode: 387 fois
• W3D_SetCurrentColor: 4 257 fois
• W3D_DrawTriFanV: 68 170 fois
• W3D_DrawTriStripV: 19 480 fois
• W3D_DrawArray: 142 166 fois

Now, work of re-programming can begin seriously, the coder knows exactly where to start in order to obtain results in terms of speed, visible to the naked eye.

(translated by CrashMidnick)
  

LibraryTimer (II) [fr]

En regardant de plus près le source de la W3D_AvengerLEMU.library, je m'aperçois que les fonctions internes sont appelées directement par des bsr et non par la FunctionTable :

Or, LibraryTimer patch la table des fonctions de la librairie afin d'y insérer un compteur et même une mesure de temps. Avec ce bsr, et bien LibraryTimer ne pourra l'ajouter dans ses statistiques. La solution est simple, il suffit de le remplacer par un jsr en étant sûr qu'a6 soit bien l'adresse de base de la W3D_AvengerLEMU.library :

Il y avait moins d'une dizaine d'appel bsr en tout et pour tout. Maintenant, nous allons obtenir des statistiques plus complètes et plus précises avec LibraryTimer :

La fonction -$3C fait alors son apparition comme étant la plus utilisée : il va falloir ruser comme un sioux afin de diminuer au maximum ses instructions nécessaires. Ici donc, chaque cycle gagné est très important.

Voici les nouvelles statistiques :

• fonction -$24 : 382 fois
• fonction -$36 : 1 fois
• fonction -$3C : 367 558 fois
• fonction -$5A : 110 fois
• fonction -$90 : 23 fois
• fonction -$AE : 1 fois
• fonction -$B4 : 845 fois
• fonction -$BA : 884 fois
• fonction -$D8 : 2 357 fois
• fonction -$DE : 452 fois
• fonction -$E4 : 383 fois
• fonction -$EA : 228 fois
• fonction -$108 : 10 fois
• fonction -$10E : 382 fois
• fonction -$114 : 383 fois
• fonction -$144 : 5 054 fois
• fonction -$14A : 1 fois
• fonction -$162 : 354 fois
• fonction -$180 : 1 fois
• fonction -$198 : 24 233 fois
• fonction -$19E : 113 013 fois
• fonction -$1B6 : 150 286 fois
• fonction -$1C2 : 6 524 fois

Maintenant, très exactement la même méthode pour la Warp3D.library, avec toujours le même jeu Quake 2 :

• W3D_SetState : 7 932  fois
• W3D_LockHardware : 387 fois
• W3D_UnLockHardware : 386 fois
• W3D_WaitIdle : 386 fois
• W3D_AllocTexObj : 1 fois
• W3D_SetFilter : 3 fois
• W3D_SetTexEnv : 2 318 fois
• W3D_SetWrapMode : 1 fois
• W3D_SetBlendMode : 1 011 fois
• W3D_SetDrawRegion : 387 fois
• W3D_ClearZBuffer : 387 fois
• W3D_SetZCompareMode : 387 fois
• W3D_SetCurrentColor : 4 257 fois
• W3D_DrawTriFanV : 68 170 fois
• W3D_DrawTriStripV : 19 480 fois
• W3D_DrawArray : 142 166 fois

Voilà, le travail de re-programmation peut commencer sérieusement, le codeur sait avec précision par où débuter de façon à obtenir des résultats en terme de vitesse visibles à l'oeil nu.

      

LibraryTimer (I) [eng]

LibraryTimer v1.1 is a program available on aminet is really interesting for our goal. It gives the possility to know with accuracy the usage frequency of any kind of Amiga library.

A reminder for beginners: libraries for our Amiga are made of many functions that have a special use. For example, the function R_CacheFlush of exec.library allows to undo everything in the CPU code and data cache. For who is interested in this article: Warp3D drivers have functions too and LibraryTimer allows to know how many time programs using Warp3D (like Quake 2 for example) call a lot of available functions. The use for coders is to rework the most important functions: the ones that are often called. Of course, statistics change according to launched programs and possibly according to a game sequence. So for the time, we launch Quake 2 and its beginning.

Its usage is very easy. You just have to launch the game:

Then go back to the Workbench with Amiga-M then click on LibraryTimer program. Once loaded, you have to choose a library to examinate. For our example, it's WD3_AvengerLEMU.library and after click on "Patch":

Go back to the game, then play it for a short time: something like two minutes in order to have a statistic sample. Go back to the workbench then click on "Update". Here is the number of "calls" displayed for every function (Offset) :

We can already see that few functions are called for the short play of Quake 2. Function -$24 and -$40 have been used 571 time ($23B in hexadecimal) and 572 time ($23C). We can observe that "Time ticks" give the average time taken by the executed function: I don't know now if these results are serious and accurate.

Another function has been used many time. It's the -$6C with 6769 calls ($1A71) :

But there is something stronger for our example! -$19E called 206 387 times ($32633) !! It's incredible! -$1BC and -$1C2 around 108 390 times ($1A766) and 14 307 ($37E3) for the other :

It's perfectly clear: it's -$19E that need to be optimized as much as possible!! it's called by W3D_GetDriverTexFmtInfo from Warp3D.library :

So you have understood: LibraryTimer is useful for locating used function and what's most important the ones that are the most requested.

(translated by johnz)

     

LibraryTimer (I) [fr]

Le programme LibraryTimer v1.1 disponible sur Aminet est vraiment très intéressant pour notre sujet. En effet, il permet de connaître avec précision la fréquence d'utilisation de telle ou telle fonction de n'importe quelle librairie Amiga.

Rappel pour les débutants : les librairies sur nos Amiga sont toutes composées de plusieurs fonctions ayant chacune une utilité bien spécifique. Par exemple, la fonction R_CacheFlush de l'exec.library permet de remettre le code et le data cache du CPU à zéro. Pour ce qui nous intéresse dans cet article aujourd'hui, et bien les drivers Warp3D possèdent eux aussi des fonctions, et LibraryTimer permet de savoir combien de fois les programmes utilisant Warp3D (comme Quake2 par exemple, ou n'importe quel autre) ont appelé chacune de ses nombreuses fonctions disponibles. L'utilité pour le coder est bien sûr de retravailler déjà les fonctions les plus importantes, celles qui sont les plus souvent appelées. Bien évidement, ces statistiques varient suivant les jeux lancés et même peut-être aussi suivant la séquence du jeu. Enfin bref, ici pour le moment, nous prenons Quake2 et le tout début de l'aventure.

Son utilisation est très simple. Il suffit déjà de lancer le jeu :

Ensuite, revenir sous le Workbench avec Amiga-M et cliquer sur le programme LibraryTimer. Une fois celui-ci chargé, il faut tout d'abord choisir la librairie à examiner. Pour cet exemple, c'est WD3_AvengerLEMU.library en cliquant alors après sur "Patch" :

Revenir au jeu, et y jouer pendant une courte durée, comme deux minutes, afin d'obtenir un échantillon statistique. Re-switcher ensuite au Workbench et cliquez sur "Update". Voilà, le nombre de "Calls" s'affiche pour chaque fonctions (Offset) :

Déjà, la constatation criante est que peu de fonctions sont appelées pour la portion de Quake2 jouée. Les fonctions -$24 et -$40 ont été utilisées respectivement 571 ($23B en hexadécimal) et 572 ($23C) fois. Notez que "Time ticks" donne aussi la moyenne de temps qu'a prise la fonction a été exécutée : j'ignore pour le moment si ces résultats sont probants et/ou précis.

Une autre fonction a été utilisé encore bien plus souvent, la -$6C avec 6769 ($1A71) appels :

Mais il y a bien plus fort pour notre exemple ! La -$19E appelée 206 387 ($32633) fois !! Incroyable ! Et les -$1BC et -$1C2 environ 108 390 ($1A766) et 14 307 ($37E3) fois :

Là, c'est clair et net : c'est la -$19E qu'il faut optimiser le plus possible !! Elle est appelée par W3D_GetDriverTexFmtInfo de la Warp3D.library :

Bref, vous l'avez compris, LibraryTimer est très utile pour déjà localiser les fonctions utilisées, et surtout celles qui sont le plus souvent sollicitées.

   

Various libraries [eng]

Here is a summarization of numerous available Warp3D libraries:

3dfx Mediator A1200T v4.2

• W3D_Picasso96MU.library (= MMU)
• W3D_AvengerBEMU.library (= BigEndian MMU)
• W3D_AvengerLEMU.library (= LittleEndian MMU)

• W3D_Picasso96M.library (= noMMU)
• W3D_AvengerBEM.library (= BigEndian noMMU)
• W3D_AvengerLEM.library (= LittleEndian noMMU)

3dfx Mediator A1200T with BlizzardPPC v4.2

• W3D_Picasso96M.library (= noMMU)
• W3D_AvengerBEM.library (= BigEndian noMMU)
• W3D_AvengerLEM.library (= LittleEndian noMMU) 

3dfx GRex A1200T/A4000 v4.2

• W3D_CyberGfx4.library
• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian)

3dfx Mediator A3000/A4000 v4.2

3dfx Prometheus A3000/A4000 v4.2

• W3D_Picasso96.library
• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian)

Permedia2 BVision/CyberVisionPPC A1200/A3000/A4000 v4.2

• W3D_CyberGfx4.library
• W3D_Permedia2.library

Virge CyberVision64 3D A1200/A2000/A3000/A4000 v3.0

• W3D_Virge.library

MMU expansion has no link with the 68k physical MMU:

• MMU = Warp3D is passing through P96 to control the graphic memory,
• noMMU = Warp3D use video card memory that is not used by Picasso96.

noMMU drivers won't be supported, there is so many work to do, along with the CyberVision 64/3D that just have 4 Mb of ram.

(translated by johnz)
  

Les différentes librairies [fr]

Voici un récapitulatif des nombreuses librairies Warp3D 68k originales et classées ici en fonction du matériel nécessaire :

3dfx Mediator A1200T v4.2

• W3D_Picasso96MU.library (= MMU)
• W3D_AvengerBEMU.library (= BigEndian MMU)
• W3D_AvengerLEMU.library (= LittleEndian MMU)

• W3D_Picasso96M.library (= noMMU)
• W3D_AvengerBEM.library (= BigEndian noMMU)
• W3D_AvengerLEM.library (= LittleEndian noMMU)

3dfx Mediator A1200T avec BlizzardPPC v4.2

• W3D_Picasso96M.library (= noMMU)
• W3D_AvengerBEM.library (= BigEndian noMMU)
• W3D_AvengerLEM.library (= LittleEndian noMMU) 

3dfx GRex A1200T/A4000 v4.2

• W3D_CyberGfx4.library
• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian)

3dfx Mediator A3000/A4000 v4.2

3dfx Prometheus A3000/A4000 v4.2

• W3D_Picasso96.library
• W3D_AvengerBE.library (= BigEndian)
• W3D_AvengerLE.library (= LittleEndian)

Permedia2 BVision/CyberVisionPPC A1200/A3000/A4000 v4.2

• W3D_CyberGfx4.library
• W3D_Permedia2.library

 
Virge CyberVision64 3D A1200/A2000/A3000/A4000 v3.0

• W3D_Virge.library

L'extension MMU ici n'a rien à voir avec la MMU physiques des CPUs 68k :

• MMU = Warp3D passe par Picasso96 pour la gestion de la mémoire graphique,
• noMMU = Warp3D prends la mémoire de la carte graphique inutilisée par Picasso96.

Les drivers noMMU ne seront pas supportés, c'est trop de boulot, ainsi que ceux de la CyberVision 64/3D qui ne possède que 4 Mo de video ram à son bord...

   

The 3dfx cards [eng]

Here is a summary of various Pci 3dfx recommended for the Mediator or the GRex. all of them have, at least, 16 Mo of Video memory on board:

• 3dfx Voodoo3 2000 GPU@143 Avenger and 16Mo of SGRam 6ns memory

• 3dfx Voodoo3 2000 GPU@143 Avenger and 16Mo of SDRam 6ns memory

• 3dfx Voodoo3 3000 GPU@166 Avenger and 16 Mo of SGRam 6ns memory

• 3dfx Voodoo3 3000 GPU@166 Avenger and 16Mo of SGRam 6ns memory

• 3dfx Voodoo4 4500 GPU@166 Napalm and 32 Mo of SDRam 6ns memory

• 3dfx Voodoo5 5500 GPUs@166 Avenger and 64 Mo of SDRam 6ns memory

 
Note: The Grex support for the 3D only the Avenger cards.

(translated by johnz)

     

Les cartes 3dfx [fr]

Voici un résumé des différentes cartes 3dfx Pci recommandées pour le Médiator ou les GRex. Elles ont toutes un minimum de 16 Mo de mémoire graphique à bord :

• 3dfx Banshee GPU@100 Banshee et 16 Mo de mémoire Fpm à 25ns

• 3dfx Voodoo3 2000 GPU@143 Avenger et 16Mo de mémoire SGRam 6ns

• 3dfx Voodoo3 2000 GPU@143 Avenger et 16Mo de mémoire SDRam 6ns

• 3dfx Voodoo3 3000 GPU@166 Avenger et 16 Mo de mémoire SGRam 6ns

• 3dfx Voodoo3 3000 GPU@143 Avenger et 16Mo de mémoire SDRam 6ns

• 3dfx Voodoo4 4500 GPU@166 Napalm et 32 Mo de mémoire SDRam 6ns

• 3dfx Voodoo5 5500 GPUs@166 Napalm et 64 Mo de mémoire SDRam 6ns

Note : les GRex ne supportent la 3D que pour les Avenger.
   

Romability [eng]

The romability is the possibility to put a program in the Kickstart rom.

In fact, every programs that everyone of us is using with a Classic isn't romable. A rom is a Read Only Memory.

The big majority of Amiga programs are coded in order to be executed in the ram chip or fast, "peu importe" Gainsbourg :D. Ram accept the reading and the writing of datas.

To make a soft romable, it needs to have a difference in writing. For us, the goal is to modify Warp3D drivers in order to only read their content.

     

Advantages of the romabilty are very important. We have to remember some reasons of the formidable succes of the Amiga 500 at its beginning: it was the simplicity of use. Almost everything was in the Kickstart 1.3 rom and users had a very simple computer to use without installation of additionnal programs. For example the sound driver (audio.device) was inside the kickstart, of course, it was useless to install or load it form a floppy disk or an external hard drive.

When everything is in the Rom, there's just to switch on the machine... and that's all! The computer is ready to work within a fraction of second without any kind of waiting for a loading from an hard disk drive or an USB key...

To cope with an important size of Warp3D drivers, it's possible to compact them in the rom. There's just to add a routine of decompression. At the boot, the content of Warp3D drivers will be unpacked in the fastram in order to make them usable and ready for the OS!

The romability is an important key for unsatisfied users with a Workbench 3.9 difficult to install and to use correctly.

(translated by johnz)
   

Romabilité [fr]

La romabilité est tout simplement la possibilité de mettre un programme dans la rom Kickstart.

En effet, tous les programmes que chacun de nous utilisent sur son Classic ne sont pas romable. Il faut bien voir que la ROM est une Read Only Memory, c'est à dire en bon français qu'elle ne fonctionne qu'en lecture seule.

La très grande majorité des programmes sur Amiga sont codés pour s'exécuter dans la ram (chip ou fast, peu importe) qui, elle, accepte la lecture et l'écriture des données.

Pour rendre donc un soft romable, il est donc obligatoire d'avoir cette différence d'écriture bien en tête, et pour ce qui nous concerne aujourd'hui de modifier les drivers Warp3D afin qu'ils n'utilisent que la lecture en leur sein.

 

Les avantages de la romabilité sont très importants. Rappelons qu'une des raisons du formidable succès de l'Amiga 500 à ses débuts, c'était justement sa simplicité d'utilisation. Presque tout était dans la rom Kickstart 1.3, et les utilisateurs avaient ainsi un ordinateur simple à utiliser, sans installation supplémentaire de logiciels additionnels. Par exemple, le driver sonore (audio.device) était bel et bien dans le Kickstart, nul besoin était de l'installer ou de le charger d'une disquette 3.5, d'un disque dur externe ou que sais-je encore...

Lorsque tout est en rom, il n'y a qu'à allumer la machine... et c'est tout ! L'ordinateur est prêt à l'emploi en une fraction de seconde, sans aucune attente comme un chargement plus ou moins long depuis un disque dur ou même une clé USB...

Pour finir, face à la taille relativement imposante des drivers Warp3D, il est tout à fait possible de les compacter dans la rom bien sûr. Il y a juste une routine de décompression a ajouter, et à l'allumage de la machine, celle-ci décompactera les drivers en fastram afin de les rendre utilisables et disponibles pour le système d'exploitation !

La romabilité est une des clés importantes pour satisfaire les utilisateurs qui ronchonnent en toute légitimité face à un Workbench 3.9 compliqué à installer et à utiliser correctement.

   

Introduction [eng]

Welcome to my new Blog, let's go to the Warp3D area, ship's apprentices!

 

Unfortunatly we have slow 3D on Amiga Classic in spite of having powerful GPUs on PCI RTG board.

After dismantling and examining Warp3D drivers code, it appears that they have slow and not well optimised driver routines: in actual fact, compilers C/C++ on our Amigas produce a little efficient code helped with the special 68k architecture that needs an hand made programming in order to obtain the best.

The principal fonction of GPUs is to free of many calculations our weak 68040/68060 CPUs: it's theoratically possible to have fast 3D games with low frequency CPUs.

This time we need to improve Classic Amiga Warp 3D drivers that are not very fast. The topic is very wide that's why a Blog is a great idea in order to share questions, informations and advances of that new process.

Moreover, with the possibility of putting commentaries, everyone will be able to give ideas, to test/contribute in improving libraries and, of course, to add informations that I don't know actually.

That initiative came from my person. Everything isn't offical. Offered patches are, of course, free for all.

These new versions are built and then modified with a "reverse engineering", a technic that consists in rewriting sources from existing programs which are the only solution in order to upgrade librairies and 3D drivers. Remember, one more time, that GPUs of 3dfx and BlizzardPPC/CyberVisionPPC cards work with higher frequency than our 68040/68060 CPUs and are dedicated to 3D calculations. And they also have their own memories.

The goals are very simple: to optimize Warp3D from 20% to 30% (from the source, it seems to be doable), and to add the romability. All these modifications will be made for the 68060 by taking into account specs and advantages in being 100% compatible with 68040 and 68030. Nowaday, there's no interest in optimizing other CPUs than the 68060. For 68040 owners, these new versions will be faster than the originals. Now, only 68k versions are rebuilt, PPC one will maybe come later. Is the PPC the Amiga future? Good question and thank you for asking!!

A dantesque work has already been made in rebuilding sources that need a lot of time because of the big size of libraries. Permedia2 ones are around 580 Kb, it represents more than 276 000 lines of assembler code! Time that is less important than rewriting from zero a new 3D standard for our beloved computers: optimization of existing code is the best solution because there is already many games using Warp3D.

Happy Reading!

(translated by johnz)
    

Introduction [fr]

Bienvenu sur mon nouveau Blog, à l'abordage de Warp3D moussaillon !!

  

Nous avons hélas sur Amiga Classics de la 3D lente malgré de puissants GPUs présents sur nos cartes graphiques RTG au format PCI.

Après désassemblage et examen du code des drivers Warp3D, il apparaît que ceux-ci sont dotés de routines lentes et donc peu optimisées : en effet, les compilateurs C/C++ sur nos Amiga produisent du code peu efficient, accentué encore avec l'architecture particulière des 68k qui nécessite une programmation "à la main" pour en obtenir sa quintessence.

La fonction principale des GPUs est de décharger nos CPUs 68040/68060 peu costauds de beaucoup de calculs : de cette manière, il est théoriquement tout à fait possible d'obtenir des jeux 3D rapides, même avec des CPUs à faible fréquence.

Il s'agit donc cette fois d'améliorer les drivers Amiga Classics Warp3D qui sont peu véloces. Le sujet est assez vaste, c'est pourquoi un Blog est une excellente idée afin de partager les questions, les informations et les avancées de ce nouveau chantier. De plus, avec la possibilité de laisser des commentaires, tout à chacun pourra apporter des idées, tester/contribuer à l'amélioration des librairies, et aussi apporter des informations dont je n'ai pas connaissance à l'heure actuelle.

Cette initiative est venue de ma propre personne, tout est ici non-officiel. De plus, les patchs proposés sont bien entendu gratuits pour tout à chacun.

Ces nouvelles versions sont donc construites et ensuite modifiées en utilisant le "reverse engineering", technique qui consiste en la recréation de sources à partir des programmes existants, qui est la seule et unique solution afin d'améliorer ces librairies et drivers 3D. Rappelons encore une fois que les GPUs des cartes 3dfx et des BlizzardPPC/CyberVisionPPC fonctionnent à des fréquences supérieure à nos CPUs 68040/68060, et sont dédiées spécifiquement aux calculs 3D en possédant même leur propre mémoire sur leurs cartes.

Les buts sont très simples : optimiser Warp3D de 20 à 30% (ce qui à la vue des sources est faisable), ainsi qu'ajouter la romabilité. Toutes les modifications seront pensées pour le 68060 en tenant compte de ses spécificités et avantages, tout en restant bien sûr 100% compatible avec le 68040 et le 68030. Au jour d'aujourd'hui, il n'y a plus aucun intérêt à optimiser pour un autre CPU que le 060. Pour les possesseurs de 68040, ces nouvelles versions seront tout de même plus rapides que les versions originales. Pour l'instant, seules les versions 68k sont retravaillées, les PPC viendront peut-être plus tard... Est-ce que le PPC est l'avenir de l'Amiga ? Bonne question, merci de me l'avoir posée !!

Un travail colossal a déjà été réalisé dans la recréation des sources, qui a nécessité un temps très important ces dernières semaines vu la taille conséquente des librairies. Celle du Permedia2 par exemple pèse environ 580 Ko, ce qui représente plus de 276 000 lignes de code assembleur ! Temps qui est de toute façon moins gigantesque que de reprogrammer de zéro un nouveau standard 3D pour nos ordinateurs chéris : l'optimisation de l'existant est donc la meilleure solution, puisqu'il existe de plus déjà des jeux utilisant Warp3D.

Bonne lecture !