C’est grâce à ce second talent qu’il s’est mis en tête d’améliorer les pilotes Warp3D des Amiga dits Classic, avec le 68060 en tête (les pilotes seront par conséquent optimisés pour ce processeur mais fonctionnels avec le 68040 et 68030). Les pilotes optimisés pour PowerPC arriveront après.
Pour le moment, il a commencé le débroussaillage des sources qu’il a obtenu par « reverse engineering« . Il espère obtenir une augmentation des performances de l’ordre de 20 à 30% par rapport aux pilotes originaux, avec comme objectif final de pouvoir mettre ces derniers dans une future rom 3.9.
Cosmos raconte tout cela via l’introduction disponible sur son nouveau blog, blog intitulé « We Want Warp3D Faster ». Huit articles sont déjà disponibles sur son site, en français ainsi qu’en anglais.
Site Internet : http://warpclassic68k.blogspot.fr
29 Commentaires
Passer au formulaire de commentaire
Excellent, com d’hab ! GG Cosmos 🙂
projet ambitieux a suivre !
Extra ! J’ai hâte de lire la suite.
Gros boulot en perspective pour Cosmos, mais excellent lecture pour nous. Sans compter l’utilité de sons travail. Miam !
Chapeau l’artiste !
Je t’aime Cosmocat ! 🙂
Marrant 🙂 J’attends la suite!
Super boulot, mais les 68K, même le 060 sur cadencé ne sont-ils pas très très « justes » pour pouvoir « alimenter » des cartes 3dfx ? ou même le Permedia 2 ?
pouaaaa, je suis bluffé !
moi qui n’y croyais plus. voilà que le rêve redémarre.
when the dream come true, c’est vraiment ça.
@elgringo
J’ai débuté tout ça sur le fait que les 3dfx fonctionnent à des fréquences bien supérieures à un 060 de base. Et avec de la mémoire très rapide pour leur GPU. Après, comment est géré les communications 68k-GPU, je l’ignore… Je ne sais pas tout tu sais… Par exemple, les Mediators ont une « plage » de 8 Mo pour les échanges avec les cartes gfx, ce que n’ont pas les GRex…
En théorie, je dis bien en théorie, il serait possible d’avoir de la 3D bien plus rapide je suppose… La 3D sur Amiga est une partie qui a été très peu utilisée et exploréé, arrivant trop tard et avec les Pegasos qui ont ensuite débarqués…
Mes nouveaux drivers sont un gros hack, n’ayant aucune doc, je dois tout deviné, j’ay vais un peu au pif… J’ai tout de même réussi à trouver les datasheet des puces 3dfx et j’ai quelques registres documentés que je peux rajouter dans mes sources pour les rendre plus « professionnels » et sérieux…
oui, mais sur quelle implementation et avec quelles puces graphiques ?
par exemple, les driver « virge » warp3D 68k pour cybervision 64 3D, n’ont absolument jamais été fonctionnels. (alors que cette carte 3D était répandue.) Donc je pense qu’il ne va ‘optimiser’ que pour *un* matos avec *une* puce.
Ensuite, l’api warp3D, dezigné vite fait a la fin des années 90, montre une incompréhension totale de la façon dont fonctionne une puce 3D.
Que je sache, le warp3D de l’époque (et surement celui d’aujourd’hui) ne permet qu’un dessin de polygone « par appel cpu », l’api ne permet pas de déferrer les données à la carte une bonne fois pour toute, les vertex buffer ou même les simple « glDrawElements » qui permettent de tracer tout un objet en un seul appel sont absents. M**de, c’est comme si on blindait son code de WaitBlits.
Et comme tout les « jeux » warp3D on été compilés sur cette api, ils sont irrécupérables de mon point de vue. C’est pas en optimisant un code de driver existant que ça va changer quelque chose.
Évidemment, fallait pas réinventer la pluie: Ces puces sont faites pour exécuter du OpenGL 1.2 (avec surement 2 ou 3 extensions genre pixelbuffer, bump et autre a cette époque), point barre.
… pour ce vieux matos, mieux vaut reverse-engeneerer des bons drivers OpenGL1.x permedia/virge/… existant sur intel ou en opensource, et faire une bonne fois pour toute une opengl.library: mais ça fait beaucoup plus de boulot.
La CyberVision64 3D ne sera pas supportée puisqu’elle n’a que 4 Mo de ram… On ne peut plus rien faire aujourd’hui avec ça…
Pour Warp3D, ce qui m’a motivé aussi, c’est qu’il y avait déjà quelques jeux dispos…
Après, créer une nouvelle opengl.library en partant de zéro, c’est certe une bonne idée, mais je n’en suis pas capable aujourd’hui, trop de boulot et pas assez de connaissances…
oh zut !!!!
le rêve s’arrète là, pour moi 🙁
et pour la BVisionPPC ? en tout cas tu te lances des challenges toi !
bon courage !
bon, après avoir survolé le blog, il y a des chances que la BVPPC soit supportée ! je me dis aussi que plusieurs personnes pourraient te filer un coup de main comme Crisot, Alain Thellier et Karlos (la personne qui s’occupe du pilote W3D du permedia2 pour AOS4).
Cosmos est un rêveur … Et ça me plait de rêver avec lui 🙂
Cosmos, j’espère que tu arriveras à vraiment faire une version plus rapide. ça me ferait plaisir de le montrer à 2 développeurs allemands… 🙂
Matthey l’américain a déjà retravaillé les drivers mais que pour son 4000 + Mediator 4000Di… On gagne environ 10 fps avec la petite démo starshipW3D de ce vieux calamar d’Alain Thellier…
Hé bé!!! je croyais être tout seul à continuer à bricoler sur l’Amiga, ben la… chapeau l’artiste!
Soir les gars
>le warp3D de l’époque (et surement celui d’aujourd’hui) ne permet qu’un dessin de polygone « par appel cpu »,[…] « glDrawElements » qui permettent de tracer tout un objet en un seul appel sont absents. M**de, c’est comme si on blindait son code de WaitBlits.
C’est faux : Warp3D posséde glDrawElements/DrawArray depuis la v4 d’OS3
Pour rappel ces fonctions permettent de tracer des centaine (milliers) de triangles en une seule fonction ==> si le materiau change pas on peut alors tracer un objet 3D complet en UNE fonction Warp3D (W3D_DrawArray)
>Et comme tout les « jeux » warp3D on été compilés sur cette api, ils sont irrécupérables de mon point de vue. C’est pas en optimisant un code de driver existant que ça va changer quelque chose.
Effectivement beaucoup de jeux sont programmés de manière bourrine : ils tracent un ou qques triangles à la fois
Mais on peut quand meme améliorer ça : notamment il est possible que le driver implémente un « state tracker » qui fait un truc du genre « si les states ne changent pas alors je bufferize les triangles » puis les trace en bloc
Wazp3D a un StateTracker de ce genre et dans WinUAE en rendu « hard » OpenGL ça dépote 🙂
Après je sais pas si le vrai hard sur du vrai 68k en profiterait autant…
Mais je pense que ça peut se tenter donc j’encourage Cosmos dans son projet 🙂
Un peu de pub (pour ceux qui ont un Amiga avec Warp3D ou WinUAE) et pour voir ce que peut faire Warp3D
Sur Aminet essayer Microbe3D.lha avec LaraCroft3D.lha
http://aminet.net/search?readme=thellier&sort=date&ord=DESC
Alain Thellier – Wazp3D
>ce vieux calamar d’Alain Thellier
??? j’ai pas de tentacules 😛
Un petit peu hors sujet (quoique), mais pourquoi les jeux W3D proposant un mode fenêtré sont plus rapides dans ce mode qu’en plein écran ??! Je n’ai jamais compris pourquoi… Cf ici : http://obligement.free.fr/articles/accelerer_jeux_powerpc_warp3d.php
Honnetement je sais pas pourquoi les jeux en fenetre sont plus rapide
Des jeux cites dans Obligement j ai juste Blitzquake : a l occasion je testerai en fenetre/ecran
Alain
Parce qu’ils sont mal programmés, suivant les cas :
– double buffering au lieu de triple buffering donc FPS potentiellement divisé par 2
– triple buffering implémenté de manière stupide avec warpup incapable d’appels 68k asynchrones. Donc une rafale de changements de context au lieu d’un seul pour les trucs fait correctement (voir même zéro pour FastQuake mais ce n’est pas du W3D).
Alors qu’afficher dans une fenêtre sans aucune synchronisation VBL, c’est fait en un seul appel 68k donc un seul changement de context.
Et le pire c’est que, malgré tout cela, un jeu comme Wipeout tente d’économiser les appels 68k (par incompétence ?) et n’implémente que la moitié de ce qu’il faut pour gérer le multibuffering. Du coup, il peut corrompre son affichage dans certaines conditions.
Ok merci henes pour ses explications 😉
– Bonjour Docteur, je me sent pas très bien j’ ai mal à la tête.
– A oui je vois. Ce n’est rien : vous allez prendre 500mg de paracetamol en 3 doses espacées d’une heure et vous ferez 20 min de kick off 2, et un rick dangerous. Tout devrait rentrer dans l’ ordre.
-Merki.
@henes
Tu peut nous en dire plus sur « comment bien faire un triple buffering plein écran » ? un listing ou un site décrivant la méthode serait bienvenu
MERCI
Alain
Tiens, je viens de découvrir un truc : avant avec StarShipW3D, j’avais environ 114 fps et maintenant environ 210… Avec Cow environ 7 et maintenant 10… Je vais faire plus de tests et expliquer tout ça sur mon blog…
@thellier
Ce n’est pas caché, c’est dans les autodocs. Tu peux regarder graphics.library/AllocDBufInfo() qui contient un petit exemple.
Je me souviens qu’il y a aussi de multiple exemples dans les sources publiés par CBM.
Rapidement, j’ai au moins vu sur le dev cd 2.1 NDK/NDK_3.1/Examples1/intuition/doublebuffer.c qui, malgré son nom, explique le multibuffering.
Ah non zut, il y a des dizaines de paramètres en tout (P96, Warp3D, Pci.library…)
Me suis un peu embrouiller les pinceaux là…
Je suis admiratif de l’effort fourni et j’ai trouvé des choses intéressantes dans le blog. Par contre, je reste sceptique quant à l’efficacité de telles optimisations. D’accord pour le fait de gratter quelques cycles dans une fonction qui est appelée plusieurs dizaines de milliers de fois mais quand j’ai suivi ce genre d’approche, les gains ont toujours été limités.
Et là, il est question de gagner 20% en modifiant du code qui fait faire le travail par le hardware, donc sur la partie la moins gourmande …
Quand tu réduis le temps de communication CPU => GPU, tu « augmentes la vitesse du GPU » puisque nos 68k fonctionnent bien moins vite… En théorie en tout cas…