Bonjour

Le mois dernier, je me suis efforcé de recompiler la dernière source de MiniGL pour l'optimiser

J'ai donc un cross compilateur basé sur Cygwin

1) j'ai corrigé tout les warnings "obsolete" concernant les MsgPort, etc .. dans les sources gl & glut

2) j'ai corrigé tout les warnings "obsolete" concernant AllocVec dans les sources gl & glut
Donc plus aucuns avertissements "obsolete" sur les sources sur gl &glut (sauf un allocvec pour la mémoire chip qui ne peut pas être retiré)
Compilation parfaitement propre et conforme à OS41FE désormais de gl & glut
(J'ai pas vérifié les sources de glu parce que glu est pas si important)
Mais ça accélére pas le IoQuake d'Huno

3) J'ai tenté de réécrire la partie ?transform? pour utiliser les registres
==> Mais ça accélére pas le IoQuake d'Huno

4) Appliquer les fonctions transform, codepoints (test du clip), LightVertices, VerticesToScreen à l'ensemble de la primitive et non pas pour chaque triangle
==> Mais ça accélére pas le IoQuake d'Huno

5) réécrit tous les fonctions draw qui tracent des "primitives" pour bufferiser les triangles non clippée (ou les points ou lignes) permettant ainsi de tracer une primitive (clippée) en une seule passe
==> Mais ça accélére pas le IoQuake d'Huno

6) Test si primitive pas clippée du tout (entièrement à l'écran), alors la dessiner immédiatement
==> Mais ça accélére pas le IoQuake d'Huno

7) J'ai aussi essayé d'enlever complètement le "lighting" (cad les sommets sont alors simplement colorée avec du blanc)
==> Mais ça accélére presque pas le IoQuake d'Huno ===> Donc l'éclairage a presque aucune influence sur ce programme

Tout ces changements ont introduit de nouvelles erreurs: alors maintenant Glexcess crashe sur le tracé de lignes : C'est certainement une bug facile, mais je suis trop fatigué pour m'en occuper
Heureusement Ioquake, qui sert de test, fonctionne encore parfaitement, mais presque à la même vitesse (même un peu plus lent)

Bilan:
Sources propres
Nouvelles bogues
Pas plus rapide avec Ioquake et même un peu plus lent
Peut être plus rapide sur d'autres prog mais long à tester...

Maintenant, je suis très fatigué: ceux qui disaient "MiniGL peut être facilement plus rapide? ont tort = j'y ai passé beaucoup de temps pour zéro progrès

Alain Thellier - Wazp3D

Note: Ioquake timedemo sur la Sam440 fait 18.4 fps (vs 18.7 avec l'original) (18.6 sans lighting)
Note2: Ioquake timedemo parfois fait 20.7 fps sans raison apparente


Message édité par : thellier / 01-07-2015 16:07

Bien dommage :-( Merci pour ton travail acharné.

>La question reste entière donc : pourquoi MiniGL est autant à la ramasse par rapport à TinyGL

La réponse classique c'est "car MiniGL gére pas le TCL avec le GPU" c'est à dire que le Transform,Clipping et Lighting est pas fait par la carte 3D mais par le CPU

Transform est mettre les triangles dans la position actuelle du point de vue
Clipping est tester si les triangles sont dans l'écran sinon enlever/redécouper les triangles.
Lighting est calculer l'éclairage de chaque sommets des triangles (cad leur couleur)

Néanmoins je suis pas convaincu que cela soit vraiment ça le problème quand on voit que carrément désactiver le lighting ne change presque rien à la vitesse...

Je sais plus trop quoi en penser ...

Alain

Alain,

>Donc pour toi le problème serait dans OS4, c'est ça ?
Honnétement j'en sais rien :-/

Déjà on est tous parti (dont moi) sur le postulat que c'étais mal écrit et qu'il suffirait de faire du code (apparement) meilleur pour que ça aille magiquement plus vite
Alors qu'il aurait fallu benchmarker pour voir où était vraiment le problème : après tout c'est peut être notre ioquake os4 qui est lent ailleurs (je veut dire dans le code pas dans le tracé 3D) ... Je dis ça mais j'en sais rien

Par exemple désactiver toutes les opérations de tracage de minigl pour voir si c'est le tracage qui le ralentit serait un bon test. Seul probleme : comment le metttre en oeuvre si plus rien ne s'affiche à l'écran dans Quake alors meme lancer timedemo deviendra impossible

Alain

C'est peut-être idiot mais au lieu d'utiliser quake3 pour faire des tests, pourquoi ne pas écrire un simple programme test utilisant toutes les fonctions intéressantes de Minigl?

Effectivement il n'y a pas que ioquake

@thellier

Bravo pour tes efforts. Je vais reprendre tes points pour te partager mon expérience sur ce genre d'exercice que j'ai pratiqué souvent ... avec souvent le même sentiment final (déception après beaucoup de temps et l'impression d'avoir modifié là où je pensais que ça allait améliorer la performance ... sans succès visible).



Retirer des warnings ne contribue pas à de l'optimisation (sauf peut-être de rares cas comme ceux concernant l'aliasing comme on évoquait l'autre jour).


Pour le reste, j'ai l'impression que tu as procédé avec méthode mais un peu à tâtons sur quoi modifier. Attention aux prétendues causes de problèmes de performances. Tout comme sur ffmpeg et la demande initiale "qui peut optimiser pour AltiVec ?" alors qu'on ne sait pas du tout si ce sont bien ces parties-là qui sont en cause. Pour mplayer, est-ce que c'est le décodage qui présente des problèmes ? l'utilisation de la mémoire ? le filesystem ? l'affichage ? le pilote de la carte graphique ? son bus ?



En premier lieu, il faut mesurer et analyser, dresser un constant. Qu'est-ce qui est limitant ?
Ca serait sympa d'utiliser Hieronymus avec une version debug de MiniGL.



Puis définir un plan de tests et les données de tests, dans notre cas, quels jeux par exemple.



Puis faire des modifs en consignant à chaque fois, les changements que cela produit.



Et utiliser un système de gestion de version pour pouvoir naviguer dans les patchs, refaire des tests (ou permettre à d'autres d'en faire sur une autre machine ...).



Ca ne fait pas forcément rêver mais on peut pourtant y trouver son compte :-)


YesCop souligne un point très important. Peut-être que des modifs que tu as faites aurait été visibles sur d'autres jeux, et éventuellement d'autres plateformes (même si travaillant sur un Sam440, il y a peu de chances).



J'ai vu que tu avais ouvert la même discussion sur amigans ... le commentaire de Hans est intéressant. Les modifs qui amélioreraient sont peut-être à faire plus en profondeur (reprendre des parties plus larges). J'ai parcouru le thread rapidement ...



De mon expérience, l'optimisation est rarement simple ! Et il n'y a pas une ou deux modifications magiques qui améliorent d'un coup les choses.



Courage ! Il faut persévérer.

MiniGL est lent parcequ'il est infoutu de passer des grands batchs de triangles à Warp3D. Les développeurs des jeux s'enquiquine à paquer les polygones par dizaines/centaines pour faire un minimum d'appels graphiques, mais derrière, MiniGL découpe tout en batchs minuscules.

Ce truc est fondamentalement foutu.

Mais merci d'avoir essayé Alain :)

@Corto
Je suis d'accord avec toi j'ai été vaniteux : j'aurai du analyser le pb avant de commencer à faire des modifs

> un jeu s'enquiquine à paquer les polygones par dizaines/centaines pour faire un minimum d'appels graphiques, mais derrière, MiniGL découpe tout en batchs minuscules.
@Crisot
Justement c'est la modif que j'ai faite:

Avant:
Il y avait 3 cas possible quand un prog demandait à tracer disons un TriStrip de 300:
1) Tout est hors de l'écran = fait rien
2) Tout est à l'écran = trace tout en une passe
3) Une partie des triangles sont clippés/dehors = alors trace les triangles qui sont ok, traite le(s) poly(s) à clipper, le clippe, le trace, continue avec les autres triangles,etc..

Ma version:
1) Idem
2) Idem
3) Une partie des triangles sont clippés/dehors = alors stocke ces triangles, traite le(s) poly(s) à clipper, le clippe, stocke les triangles générés, stocke les autres triangles ,etc..
puis trace tout les triangles stockés en une passe

>pourquoi ne pas écrire un simple programme test utilisant toutes les fonctions intéressantes de Minigl?
Par flemme : non content de devoir écrire un prog qui utilise les 10 primitives de traçage (points,lines,triangles, quads,etc...) il faut qu'il le fasse avec un gros volume de données cad que le prog puisse charger un gros modéle 3D et le bouger hors de l'écran pour que le clipping joue
En plus il y a le risque d'écrire +- volontairement un prog qui me soit favorable

Alain