La bande passante, ça peut être un bon candidat. Il faudrait mesurer ... je ne sais pas s'il y a un mode dans MiniGL qui donne ça.

Sur l'exemple de BSzili, il y a bien une quantité accrue de données à transférer mais ce qu'il a fait impacte aussi directement les caches du CPU.
Bon, à voir précisément.

Sinon, il faudra que je recompile MiniGL en mode debug et que je teste Cow3D avec Hieronymus pour essayer de montrer ce qui se passe. J'ai ajouté un mode dans Hieronymus qui permet en plus de voir qui cause les cache misses sur le L2, en plus de profiling l'execution des instructions.

Pour info mes sources et binaires sont là
http://thellier.free.fr/src-02-jul-2015.zip
Pas de changements dans src/glu (on s'en fout de GLU)
23 fichiers modifiés dans src/ la plupart juste pour corriger les warnings
En fait j'ai juste travaillé sur hclip.c light.c texture.c et surtout sur draw.c
include/mgl/context.h a été un peu modifié aussi

La bogue dans draw.c/DrawStoredLines() est toujours là : je laisse tomber
Au final ça marche pas mieux = aucun intérêt

Sur amigans.net la nouvelle piste est de faire baisser la bande passante :
soit en diminuant la taille de la structure MGL_Vertex (un sommet de triangle quoi...) qui est trop grosse à 224 octets
soit en recopiant pas 2 fois les mêmes sommets (quand un sommet est partagé sur plusieurs triangles)

Ansi j'y écrivais
"Cow3D sur Sam440 atteint 38 fps ou 41 fps avec l'animation bufferisée
Cow3D fait 5813 triangles . Cela fait donc 5813*3 sommets tracés 41 fois par seconde cela demande 715 000 sommets / seconde
Nous pouvons donc dire que ce débit est la vitesse maximale pour la Sam440 car Cow3D est un programme très simple
Donc, faire la même chose avec la grande structure de MGL_Vertex aurait besoin de 160 Mo/s "

Ainsi BSzili écrivait
"J'ai fait un test rapide, et en ajoutant 256 octets à la structure Point3D dans Cow3D, mon framerate s'effondre de 58 à 40 fps"
Ce qui prouve que cela a bien un impact

Alain Thellier

@thellier : La conclusion de mes commentaires n'était pas du tout que tu avais été vaniteux :-)

@crisot : On va y arriver, à trouver !

Désolé, je file prendre l'apéro au parc ...

Dacodac, bonne chose!

Je n'ai pas assez décortiqué MiniGL au dela de ça. Maintenant où ça merde...

MiniGL est très influencé par le CPU, un jeu comme Quake2 tourne bien sur un gros CPU mais rame à mort sur une Sam440, même EP malgré le "bon" GPU. Il y a très peu de polygones dans un Q2, j'ose donc supposer que le problème ne se situe pas dans le T&L, clipping, et toutes ces maths relativement "simples". Alors ou peut se trouver le méga bottleneck?

@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

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

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

Effectivement il n'y a pas que ioquake

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?

>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