)Faut arrêter de dire qu'il y a "over bourrée de bugs" : il n'y a pas tant que ça de bugs pour un hardware aussi complexe, ils sont tous référencés et pour la majeure partie ils sont contournables. Il y a quelques majeurs et y en a que très peut qui sont bloquant.
Va voir une errata de PIC Microchip et là on en reparle
lorsque le GPU exécute du code en DRAM, le pipeline est complètement inhibé ! Prefetch compris !Non c'est faux, il n'y a absolument aucune différence entre le mode local et le mode externe sur le pipeline d’exécution.
La différence se fait uniquement et seulement sur le délai de lecture des données causé par le nombre de couches à traverser pour lire la DRAM.
En local, t'as la garantie que le prefetch est rempli en 1 cycle, ce qui fait que tu as quelques chose comme ça : (non contractuel)
En externe, le GPU doit accéder au bus externe, donc passer la gateway, prendre la priorité sur le bus ce qui va ensuite déclencher la lecture de la DRAM.
Le contrôleur (si c'est un accès DRAM) va commander la lecture de la DRAM, puis latcher les datas, puis le mettre à la disposition du GPU, qui va ensuite enregistrer dans le prefetch.
Ce qui va donner un truc comme ça : (non contractuel : ce n'est pas exactement ce qui se passe au cycle près, mais c'est l'idée qui compte)
* legend :
R : lecture
W : ecriture
RH : read high word
RL : read low word
Oui, le GPU reste plus performant car ses instructions tiennent (quasi) tous dans 16-bit et la majeur partie font les opérations en 1 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 !!
Sur la jag, les accès mémoire 68k sont sur 5cycles (en vitesse 68k) car le bus de la jag est 64-bit donc il faut réaligner les données en lecture et en écriture ce qui est fait proprement via un cycle supplémentaire.
Après y a peut-être moyen de le faire de manière transparente mais je vois pas comment ça peut être fait proprement tout en restant dans l'idée d'avoir un bus CPU générique.
En supposant que l'on garde le prefetch de 32-bit et que l'on burst des lectures en se disant que de toute façon ça sera exécutés : ça n'est pas viable car dès qu'il y aura un conflit de registre, une instruction longue (div, ou autres) tout ce qui sera lue sera poubelle et faudra relire. (en gros la plus grande partie du temps quand c'est pas optimisé ou sur des traitements génériques) Sans compter que ça complexifie aussi pas mal vu qu'il faut garder un suivit de ce qui est lue du PC.
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.
Ajouter un plus grand prefetch, outre le fait que ça complexifie beaucoup pour un gain pas spécialement transcendant, pose aussi d'autres problèmes.
Admettons que l'on passe juste à 64-bit le prefetch :
En local, ça veut dire qu'il faut faire 2 requêtes de lecture (vu que la ram interne est 32-bit), ça veut dire que tu ne peux pas commencer à exécuter les instructions tant que ton prefetch n'est pas chargés => tu perds 1 cycles à chaque jump par rapport à la solution actuel.
On peut se dire "pourquoi attendre le 2eme LW?", car y a les cas où on jump sur le 2eme LW, ça voudrait dire de détecter tous les cas différents de gestion du flux d'instructions dont probablement des cas tordus.
On peut se dire aussi "pourquoi ne pas charger le prefetch aligné en LW au lieu de Phrase en local", mais dans ce cas, ça veut dire d'avoir une logique complexe pour gérer 2 cas différents de remplissage du prefetch (ie ram interne et la ram externe), vu que en externe les accès 64-bit sont uniquement possible alignés sur 64-bit.
Sinon l'autre solution ça serait de faire exclusivement des burst de 2 LW pour unifier le traitement local et externe, on ne perd plus le cycle, mais ça complexifie pas mal les accès mémoires.
En conclusion, il n'y a aucune autres solutions viable et efficace qu'un cache.