| Amiga Impact

  · Accueil
  · Actualités
   · Proposer une info
  · Agenda
   · Proposer une date
  · Articles
  · Forum
  · Petites Annonces
  · Chat IRC
  · À propos du site



 | Connexion


 | Nous suivre

Flux RSSGoogle+TwitterFacebook



 | En ligne

Illustration du profil de zeGouky Illustration du profil de k1200rs21 Illustration du profil de __sam__ Illustration du profil de lolof Illustration du profil de NordicPower Illustration du profil de stratocumulus Illustration du profil de Discor Illustration du profil de jbam Illustration du profil de Halifax


 | Recherche




Actualités


   Quand Cosmos s’attaque à Warp3D
   | 31 mai 2013 | Logiciels, ,

logiciels
Cosmos, l’homme qui sait manier le fer à souder comme personne (voir son blog dédié à ses réparations en tout genre), a aussi d’autres talents cachés, comme celui de savoir lire le code Assembleur comme si c’était le texte d’un roman de capes et d’épées.

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




Les commentaires appartiennent à leurs auteurs.
Nous ne sommes pas responsables de leur contenu.


Auteur Conversation
Foul Posté le 31 mai 2013

Photo du profil de Foul

Excellent, com d’hab ! GG Cosmos 🙂



jegougou Posté le 31 mai 2013

Photo du profil de jegougou

projet ambitieux a suivre !



Eggman Posté le 31 mai 2013

Photo du profil de Eggman

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 !



CrashMidnick Posté le 31 mai 2013

Photo du profil de CrashMidnick

Je t’aime Cosmocat ! 🙂



leo Posté le 31 mai 2013

Photo du profil de leo

Marrant 🙂 J’attends la suite!



elgringo Posté le 31 mai 2013

Photo du profil de

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 ?



sayasupacrew Posté le 31 mai 2013

Photo du profil de sayasupacrew

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.



Cosmos Posté le 31 mai 2013

Photo du profil de Cosmos

@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…



krabob Posté le 31 mai 2013

Photo du profil de krabob

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.



Cosmos Posté le 31 mai 2013

Photo du profil de Cosmos

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…



sayasupacrew Posté le 31 mai 2013

Photo du profil de sayasupacrew

oh zut !!!!

le rêve s’arrète là, pour moi 🙁



Lion Posté le 31 mai 2013

Photo du profil de Lion

et pour la BVisionPPC ? en tout cas tu te lances des challenges toi !
bon courage !



Lion Posté le 31 mai 2013

Photo du profil de Lion

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



JaY Posté le 2 juin 2013

Photo du profil de JaY

Cosmos est un rêveur … Et ça me plait de rêver avec lui 🙂



elwood Posté le 3 juin 2013

Photo du profil de elwood

Cosmos, j’espère que tu arriveras à vraiment faire une version plus rapide. ça me ferait plaisir de le montrer à 2 développeurs allemands… 🙂



Cosmos Posté le 3 juin 2013

Photo du profil de Cosmos

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…



Gilloo Posté le 3 juin 2013

Photo du profil de Gilloo

Hé bé!!! je croyais être tout seul à continuer à bricoler sur l’Amiga, ben la… chapeau l’artiste!



thellier Posté le 3 juin 2013

Photo du profil de thellier

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 😛



CrashMidnick Posté le 3 juin 2013

Photo du profil de CrashMidnick

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



thellier Posté le 4 juin 2013

Photo du profil de thellier

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



henes Posté le 4 juin 2013

Photo du profil de henes

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.



CrashMidnick Posté le 4 juin 2013

Photo du profil de CrashMidnick

Ok merci henes pour ses explications 😉



Jeffadam Posté le 5 juin 2013

Photo du profil de Doolittle

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



thellier Posté le 5 juin 2013

Photo du profil de thellier

@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



Cosmos Posté le 5 juin 2013

Photo du profil de Cosmos

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…



henes Posté le 5 juin 2013

Photo du profil de henes

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



Cosmos Posté le 5 juin 2013

Photo du profil de Cosmos

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à…



corto Posté le 10 juin 2013

Photo du profil de corto

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 …



Cosmos Posté le 11 juin 2013

Photo du profil de Cosmos

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…








Haut de page 

Copyright © 2004-2017 Amiga Impact. Tous droits réservés. Les marques citées sont déposées par leurs propriétaires respectifs.
Conditions d'Utilisation, Politique de Confidentialité et Information sur les cookies.


Fil RSS WordPressNicolas Gressard, Conseil et développement informatique

Do NOT follow this link or you will be banned from the site!