Avec les récentes discussions sur Atariage sur le GPU in main, ainsi que la relecture des différents timings que SCPD avait fait il y a plusieurs années avec son analyseur logique et compte tenu de ce que je n'arrête pas de dire : que la Jaguar est certes une machine intéressante mais over bourrée de bugs et d'un manque flagrant d'optimisation matériel, donc une conclusion semble m'être évidente sur les performances du GPU in main.
Je me trompe peut être, je n'ai pas assez d'information sur le sujet, je n'ai pas d'analyseur logique (sinon j'aurai décortiqué tous les timings de la Jaguar en long en large et en travers probablement) ou peut être encore que c'est connu depuis longtemps et que vous allez me répondre : bah oui ! Tu savais pas ?"
Donc pour moi au vu des timings de SCPD une chose semble clair : lorsque le GPU exécute du code en DRAM, le pipeline est complètement inhibé ! Prefetch compris ! Certes la DRAM est moins rapide que la local RAM, mais pas à ce point ! D'ailleurs, en FPM il ne faut que 2 cycles pour un accès sur une même page, et ça se voit clairement sur les diagrammes : que fait le GPU pendant 10 cycles entre 2 accès DRAM pour exécuter seulement 2 instructions !!?
Voila comment je déchiffre le diagramme des timings que SPCD avait fait lors de l'exécution d'un code (simple) en DRAM (2 addq)
On part donc du principe après réflexion sur les timings, que le prefetch et le pipeline sont désactivé.
On voit d'abord que RAS est constamment au niveau bas, ce qui signifie que lors de la capture on était et on reste sur la même page, donc on ne compte pas ni la précharge ni le RAS to CAS qui de toute façon ne sont pas signifiant lors d'accès continu (3 cycles)
On part donc du moment au CAS passe au niveau bas qui correspond à la demande de chargement des instructions en cours. On peut voir avec les signaux OE que 32bit sont demandés. On est en FPM il ne faut donc que 2 cycles.
je ne sais pas où sont chargés ces 32bits, soit dans un tampon, soit dans la mémoire prefetch peu importe.
Le cycle suivant, les 1er 16 bits sont chargé dans le 1er étage du pipeline
de là il y a alors 4 cycles correspondant au 4 étages du pipeline pour l'exécution de l'instruction.
ensuite 1 nouveau cycle pour charger les 16bit suivant dans le 1er étage du pipeline, puis de nouveau 4 cycles pour exécuter l'instruction.
On retourne au début avec un nouvel accès à la DRAM en mode FPM
2 cycles d'accès + 1 cycle de chargement + 4 cycles d'instructions + 1 cycle de chargement + 4 cycles d'instruction : 12 cycles
Quand certains disent que le GPU in main est moins performant que le 68000, d'une certaines façon c'est vrai ! En terme d'instructions par cycle c'est indéniable, heureusement que le JRISC tourne 2 fois plus vite !
Dans le meilleurs des cas avec le prefecth le 68000 peut exécuter 1 instruction tous les 4 cycles (bon ok, comme sur la Jaguar c'est mal foutu je crois que c'est 5) on est quand même à environ 2.7 mips à 13,3Mhz
Ici avec le GPU in main 1 instruction tous les 6 cycles, environ 4,433 mips, certes c'est mieux mais bordel, quel manque d'optimisation !!
j'ai étudié un peu le problème rapidement il aurait pourtant été possible selon moi de faire en sorte que le GPU tourne aussi vite en DRAM qu'en RAM local. Dans le meilleurs des cas bien sûr : quand il à le BUS pour lui seul ou assez longtemps, pas de rupture de flux d'instructions (JMP, etc) pas d'instruction avec accès à la DRAM (encore que...)
Avec notamment : un plus grand tampon (64bit ou 2*64bit... + ?) , rétablir le prefech pour l'accès en DRAM, rétablir le pipeline, voir même charger le 1er étage du pipeline avec les 1er 16bit de l'accès DRAM si nécessaire (bah, ça fait gagner 1 cycle dans certains cas...) le but du jeu étant de faire en sorte de toujours avoir une instruction à charger dès que le 1er étage du pipeline est vide.
Bref, SPCD ton avis ?
)
.
