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?

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

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

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.