[Mollusk]

Moi oui

[thoduv]

J'ai une idée ! ^^

FIFO / PIPE Number of Entries
The FIFO has 256 entries, additionally, there is a PIPE with four entries (giving a total of 260 entries). If the FIFO is empty, and if the PIPE isn't full, then data is moved directly into the PIPE, otherwise it is moved into the FIFO. If the PIPE runs half empty (less than 3 entries) then 2 entries are moved from the FIFO to the PIPE. The state of the FIFO can be obtained in GXSTAT.Bit16-26, observe that there may be still data in the PIPE, even if the FIFO is empty. Check the busy flag in GXSTAT.Bit27 to see if the PIPE or FIFO contains data (or if a command is still executing).
Each PIPE/FIFO entry consists of 40bits of data (8bit command code, plus 32bit parameter value). Commands without parameters occupy 1 entry, and Commands with N parameters occupy N entries.

Donc, essaie de modifier le code qui copie tout une liste vers le FIFO, et vérifie à chaque valeur copiée si le FIFO n'est pas plein, et s'il l'est, attends qu'il ne le soit plus avant de copier la prochaine commande.

[Pitt]

Et ça fonctionnait après les commandes ?
EDIT : oups pas vu la 2ème page ^^ je lis ça

[thoduv]

J'ai pas essayé, je viens d'y penser :D

Autre idée: essaye d'utiliser le DMA pour copier les données, d'après Gbatek, ca ne bloque pas le système même si le FIFO est plein.

[Pitt]

@ Mollusk : Ah ? On peut voir ? ^^
@ Thoduv : excuse, c'est parce que j'avais pas vu vos posts sur la 2ème page ^^

Je teste et je vous dis !

[Mollusk]

Pour le code perso c'est le code 3DSprites de PAlib. Une partie du code est un fork de libnds, une partie (gestion des textures) est dérivée de ma gestion mémoire des sprites, une partie est basée sur gbatek et l'aide de davido ^^

[Pitt]

Oki Mollusk.
Hmmm Thoduv, c'est la méthode qu'ils utilisent les autres guignols ...
J'essaye en transférant autrement, en vérifiant si le FIFO n'est pas plein.

[thoduv]

T'es sûr ? Il me semble que la méthode DMA est commentée du genre "marche pas à chaque fois"... Je vérifie.
EDIT: Arf, y'a eu plein de changements que j'avais pas vu!

[Pitt]

Oui oui, y'a un gars qui a déboulé et qui a essayé de changer un peu le bordel ^^

J'ai essayé ça :

Code:

GL_STATIC_INL void glSecuredCallList(u32* list) {
u32 count = *list++;

while(count--) {
while (GFX_STATUS & BIT(24));
GFX_FIFO = *list++;
}
}

Sans plus de résultats ...

[thoduv]

T'as vu ce qu'y marquent dans le commentaire au dessus de leur fonction:

There is sometimes a problem when you pack the GFX_END command into a list, so don't. GFX_END is a dummy command and never needs called

Moi j'incluais GFX_END dans mes paquets de commandes... Ca vient peut être de là (si tu le fais aussi) ?

[Pitt]

En effet, je la mettais bien, mais ça continue de bugguer :|

[thoduv]

C'est vraiment chiant comme problème (je souffre avec toi j'ai eu le même, et ca m'a plombé un projet)...
Tu peux toujours essayer de récuperer le plus d'informations possibles depuis les registres d'info du GPU, ou bien d'essayer de localiser l'endroit exact où ca plante en foutant des "traces" partout.

[Pitt]

Si je trouve le problème, tu reprends ton dev' ? :P
Je vais commencer par les traces et autres debugs, et puis je vais voir si des gens n'ont pas eu le même pb ...

[Pitt]

Chez moi ça bug à la 10ème frame, pendant le CallList. Je teste à quelle commande ça bug ...
J'ai aussi essayé d'attendre que le FIFO ne soit plus plein / soit vide, mais ça ne change rien ...

EDIT:
c'est pas un problème de FIFO rempli ou pas ! j'ai rajouté des traces qui s'affichent à chaque commande (donc pour mon modèle plus de 12000 fois par frame), ce qui a du faire tomber mon compteur FPS à 0.5 FPS ^^
ça bug à la commande 179 de la frame 9 ... je continue mon enquête ^^

EDIT2:
je viens de penser à un truc : le flush vide le pipeline 3D ou pas ? question débile
A part ça c'est frame 10, pas 9 ^^

EDIT3:
que se passe-t-il lorqu'on envoit un pack de vertex qui contient des nombres supérieurs à 5 / inférieurs à -5 ?

[thoduv]

Vu que le flush est appelé en dernier, il est forcément executé en dernier, donc le pipeline est vide. réponse débile
Mais par contre, 12000 commande, c'est peut être un peu trop pour la DS non ?

EDIT: Après vérification, la DS mange maximum 6144 vertices par frame, tu serais pas au dessus ?