Jump to content
Jagware
Sign in to follow this  
Orion_

le GPU

Recommended Posts

Orion_    1

bon, déja un grand merci a GT Turbo pour toute ces explications, et ces bases de code qui m'ont permis de commencer ^^

 

helas je suis pas aller bien loins, je bloque déja sur le GPU :D

 

a mon avis c'est pas bien méchant mais je trouve pas le probleme ...

 

en effet, avant de me remettre au 68k je voudrais tester un peu l'assembleur GPU ^^

 

 

 

alors y'a mon code GPU qui ressemble betement a ça:

 

	.long

 

.GPU

 

.org $f03000

 

 

 

GpuCode:

 

movei #GpuCode, r29

 

nop

 

nop

 

jump (r29)

 

.long

 

GpuEnd:

 

.68000

 

 

 

 

(j'ai pas trouvé d'autre manière d'utiliser Jump, de toute façon ça fait pareil avec jr GpuCode)

 

 

 

 

 

visiblement sur l'émulateur (project tempest), le gpu fait soit un jump en mémoire, soit avance a toute vitesse pour arriver en 0xE00000 ou quelque chose le fait visiblement tourner en rond :D

 

 

 

pour charger mon code j'utilise ça:

 

[code] jsr GpuInit

 

jsr GpuStart

 

 

 

;****************************

 

; Init GPU

 

 

 

GpuInit:

 

move.l #0,G_CTRL ;arreter le GPU

 

move.l #0,G_FLAGS ;initialiser les FLAGS du GPU

 

move.l #$00070007,G_END ;GPU en mode BigEndian (mode compatible 68000)

 

move.w #%11010111001100,MEMCON2 ;memoire en mode BigEndian

 

 

 

move.l #GpuCode,a0

 

move.l #$f03000,a1

 

move.l #GpuEnd,d7

 

sub.l a0,d7

 

lsr.l #2,d7

 

copygpucode:

 

move.l (a0)+,(a1)+

 

dbra d7,copygpucode

 

rts

 

 

 

;*************

 

 

 

GpuStart:

 

move.l #$f03000,G_PC

 

lea G_CTRL,a0

 

move.l #1,(a0)

 

;waitgpu:

 

; move.l (a0),d0

 

; btst #0,d0

 

; bne.s waitgpu

 

rts

 

 

 

;**************

 

 

 

 

 

the question is, what is the problem ? :/

Share this post


Link to post
Share on other sites
SCPCD    0

Je pense en parti car il manque le nop après le jump dans le code GPU.

 

Je pense surtout qu'il y a une erreur dans le code 68000 :D :

 

tu fais :

 

 

move.l #GpuCode,a0

 

move.l #$f03000,a1

 

move.l #GpuEnd,d7

 

 

Or d'après le code GPU, GpuCode serais egal a $F03000.

 

Donc tu copies du code a l'adresse $F03000 a l'adresse $F03000 :unsure: (donc resultat imprevisible lors de l'execution du code GPU)

 

 

 

Pour que tu puisses faire un truc de ce genre, il faut ecrire :

 

[code]

 

.long

 

GpuCode:

 

.GPU

 

.org $f03000

 

 

 

Main:

 

movei #Main, r29

 

nop

 

nop

 

jump (r29)

 

nop

 

 

 

.long

 

.68000

 

GpuEnd:

 

 

C'est ce que je fais et ca fonctionne (sauf si j'ai fais une erreur en recopiant :P).

Share this post


Link to post
Share on other sites
GT Turbo    5
les bizarrerie de la jag ... en mode RGB16, mes couleurs sont dans l'ordre Rouge BLEU Vert :D

 

Les notres aussi je te rassures !!

 

[english]

 

Don't panic !! Mine too !!

 

 

 

GT Dans le mauvais ordre ;)

Share this post


Link to post
Share on other sites
cts    0
Je pense surtout qu'il y a une erreur dans le code 68000 :

 

tu fais :

 

Code:

 

move.l #GpuCode,a0

 

move.l #$f03000,a1

 

move.l #GpuEnd,d7

 

 

 

Or d'après le code GPU, GpuCode serais egal a $F03000.

 

 

 

nonon, c'est correct.

 

GpuCode est 'ORGé' à $F03000 mais pas encore recopié à cette adresse...

 

 

 

Tu t'es couché tard non ? ;)

 

 

 

Par contre, je me rapelle avoir eu quelque souscis en sautant direct à une adresse contenant un movei...

 

 

 

 

GpuCode:

 

nop

 

movei #GpuCode,r0

 

nop

 

jump (r0)

 

nop

 

GpuEnd:

Share this post


Link to post
Share on other sites
SCPCD    0

ben oui justement, vue que GpuCode est 'orgé' a $F03000, il vaut donc $F03000.

 

Et donc, le code 68000 copie ce qui est a l'adresse $F03000 a l'adresse $F03000 qui n'est pas ce que l'on veut faire...

 

Donc il faut faire comme je l'ai expliqué precedement.

 

 

 

Sinon, j'ai jamais eu de problemes avec un saut directement suivit pas un movei..

 

Peut-être qu'il pourait y avoir un probleme lorsque le movei n'est pas aligné sur un long et que par chance je n'ai jamais eu ce cas...:ermm:

Share this post


Link to post
Share on other sites
Orion_    1

pfff, j'ai commencer a coder au GPU et je pensais que ça ne fonctionnais pas (parcequ'evidement ça ne fonctionne pas pour changer ...) parceque ma routine (pourtant simple) etait mauvaise,

 

bon ben perso j'ai pas trouvé, apres quelques test j'en suis presque arrivé a la conclusion que mon stop de gpu ne fonctionnais même pas ...

 

et j'arrive a un resultat super bizarre a l'ecran (en utilisant BG)

 

si quelqu'un pouvais m'eclairer, je suis au bord de la depression la :/

 

 

 

 

jsr GpuInit

 

 

 

loop:

 

move.w #$AAAA,BG

 

 

 

jsr GpuStart

 

 

 

movea.l curscreen,a0 ; swap screen buffers

 

movea.l nxtscreen,a1

 

move.l a1,curscreen

 

move.l a0,nxtscreen

 

 

 

jsr Wait_vbl(pc) ; attends la VBL

 

jsr Build_list ; Reconstruit la liste

 

 

 

move.w #0,BG

 

 

 

bra loop ; et boucle

 

 

 

;****************************

 

; Init GPU

 

 

 

GpuInit:

 

move.l #0,G_CTRL ;arreter le GPU

 

move.l #0,D_CTRL ;arreter le DSP

 

move.l #0,G_FLAGS ;initialiser les FLAGS du GPU

 

move.l #0,D_FLAGS ;initialiser les FLAGS du DSP

 

move.l #$00070007,G_END ;GPU en mode BigEndian (mode compatible 68000)

 

move.l #$00070007,D_END ;DSP en mode BigEndian

 

move.w #%11010111001100,MEMCON2 ;memoire en mode BigEndian

 

; move.w #$ffff,BORD1

 

; move.w #$ffff,BORD2

 

 

 

move.l #GpuCode,a0

 

move.l #$f03000,a1

 

move.l #GpuEnd,d7

 

sub.l a0,d7

 

lsr.l #2,d7

 

copygpucode:

 

move.l (a0)+,(a1)+

 

dbra d7,copygpucode

 

rts

 

 

 

;*************

 

 

 

GpuStart:

 

move.l #$f03000,G_PC

 

lea G_CTRL,a0

 

move.l #1,(a0)

 

waitgpu:

 

move.l (a0),d0

 

asr #1,d0

 

bcs waitgpu

 

rts

 

 

 

;**************

 

 

 

.GPU

 

.long

 

GpuCode:

 

.org $f03000

 

nop

 

nop

 

 

 

movei #nxtscreen,r0 ; on veut recuperer le contenu de nxtscreen, donc d'abord on precharge son adresse

 

movei #newflare,r1 ; on interlace le temps que la fonction d'en haut s'execute, adresse du sprite

 

load (r0),r0 ; charge l'adresse du screen suivant (double buffering)

 

movei #128*128,r3 ; nombre de pixel a copier

 

gpuloop:

 

nop ; nop de suretée :D

 

load (r1),r2

 

nop

 

addq #4,r1 ; avance d'un pixel (et atten que r2 soit traité)

 

store r2,(r0)

 

nop

 

addq #4,r2 ; avance d'un pixel

 

subq #1,r3 ; nombre de pixel--

 

or r3,r3 ; fini ?

 

jr ne,gpuloop ; si non, on strop

 

 

 

nop

 

nop

 

 

 

moveq #0,r0

 

movei #G_CTRL,r1

 

nop ; au cas ou, mais j'ai vu dans une source d'atari il n'y est même pas donc bon ...

 

store r0,(r1)

 

 

 

nop

 

nop

 

 

 

.long

 

GpuEnd:

 

.68000

 

Share this post


Link to post
Share on other sites
GT Turbo    5

Plusieurs choses, tu est en train de tout faire en TC 24 bits ? Laisse tomber ce mode, le bus en prend plein la gueule et au niveau des sprites tu est super limité (Pas de zoom, etc...)

 

Attention que ton code 68000 viennent pas en conflit avec les procs, des mesures de Vbl que j'ai faites on été plombés a cause du //. Fait une boucle d'attente du 68000 jusqu'a que le Gpu est fini, ceci juste pour faire des essais, je vais pas te conseiller d'oublier d'utiliser le 'full //'.

 

    subq    #1,r3    ; nombre de pixel--
    or    r3,r3    ; fini ?
    jr    ne,gpuloop; si non, on strop

 

Tu peux dégager ton 'or r3,r3', tous mes codes tournent sans ce bricolage, mefie toi car beaucoup des conseils d'Atari que j'ai appliquer a la lettre ne change rien du tout.

 

le Subq avant le jr fonctionne sans rajout.

 

    moveq    #0,r0
    movei    #G_CTRL,r1
    nop        ; au cas ou, mais j'ai vu dans une source d'atari il n'y est même pas donc bon ...
    store    r0,(r1)
    nop
               nop

 

Le Nop avant le store change rien, jai essayé, par contre ce après il les faut.

 

C'est quoi le résultat a l'écran ?

 

Pourquoi tu veux faire de la copie de sprite ? A premire vue ton code est correcte vérifie peut etre tes adresses en r0 et r1 et n'oublies pas que celle ci doit etre aligné sur la taille des données lu / écrites, donc ici des longs. Car ce genre de blague j'ai assez donnée, résultats bizzares et le code est bon ! ;)

 

[english]

 

Some questions, are you working in TC 24 bits ? Forget this mode, the bus are too much used and with the sprites a lot of operations are non-working (Zoom, etc...)

 

Beware than our 68000 code doesn't make a colision with the procs, some Vbl measurements i have done was false because parallel working. Make a 'wait boucle' until Gpu has ended, just for some trys, i don't want to say forget parallel working.

 

    subq    #1,r3    ; nombre de pixel--
    or    r3,r3    ; fini ?
    jr    ne,gpuloop; si non, on strop

 

You can kill 'or r3,r3', all my codes run without it. Some atari documentations that i have used do anything in more or less...

 

'Subq' can work alone

 

    moveq    #0,r0
    movei    #G_CTRL,r1
    nop        ; au cas ou, mais j'ai vu dans une source d'atari il n'y est même pas donc bon ...
    store    r0,(r1)
    nop
    nop

 

 

Nop before Store doesn't change anything, i have yet tried, but after you need it.

 

What can you see on screen ?

 

Why do you want to do sprite copy ? A first sight, our code is right, just verify our adress in r0 and r1 and don't forget they must we aligned on data length, so here it must be long word aligned, if you don't align them, that will give some special effects !!

 

 

GT ;)

Share this post


Link to post
Share on other sites
Orion_    1

mon code sera plus lent en 16bits qu'en 24 ;)

 

pour l'instant je fait juste une recopie de sprite, mais c'est juste un debut, le but final est tout autre ^^

 

comme tu peu le voir dans mon code 68000 j'attend le GPU :)

 

le resultat a l'écran est .. noir :D c'est ça qui est super frustrant parcequ'on ne sais pas d'ou ça viens !

 

vu que y'a aucun debugger rien :/

Share this post


Link to post
Share on other sites
Orion_    1

a tiens je viens de m'apercevoir que le BJL faisait debugger quand ça plantait, pratique :D

 

par contre c'est possible de le planter expres pour voir les valeurs de registre a un certain moment ?

 

(je crois déja que mon loader GPU ne fonctionnais pas bien, parceque sur l'emulateur j'avais un PC de GPU faux, la ça a l'air de mieux fonctionner, mais toujours écran noir :D enfin je debug, je debug ^^)

 

 

 

au passage j'ai fait quelque test, sur ma télé pour avoir un fullscreen il faut que je place le sprite (qui est mon framebuffer en fait)

 

en: X=44, Y=35 pour etre au coin haut-gauche de mon écran

 

et j'ai une resolution d'environ 320x268

Share this post


Link to post
Share on other sites
GT Turbo    5

Tu fais un illegal pour planter le code, cela permet d'arreter ton code ou tu veux, et tu peut lire les vals des registres.

 

Tes adresses sont alignés ?

 

[english]

 

Just do an 'illegal', that stop the code and you can read registers on Bjl main screen.

 

Word aligned the adress ?

 

 

GT Planté ;)

Share this post


Link to post
Share on other sites
Orion_    1

bon, voila mon code GPU fonctionne !

 

et oui, on oublie trop souvent les NOP apres un JR !!!!

 

 

.long

 

GpuCode:

 

.GPU

 

.org $f03000

 

 

 

movei #nxtscreen,r2

 

movei #newflare,r1

 

load (r2),r0

 

 

 

movei #768,r5

 

movei #128,r3 ; Y

 

gpuloopY:

 

movei #128,r4 ; X

 

gpuloopX:

 

load (r1),r2

 

store r2,(r0)

 

addq #4,r1 ; avance d'un pixel

 

addq #4,r0

 

subq #1,r4 ; X--

 

jr ne,gpuloopX

 

nop

 

add r5,r0 ; next screen line

 

subq #1,r3 ; Y--

 

jr ne,gpuloopY

 

nop

 

 

 

moveq #0,r0

 

movei #G_CTRL,r1

 

store r0,(r1)

 

 

 

nop

 

nop

 

 

 

.long

 

.68000

 

GpuEnd:

 

 

 

 

le probleme, c'est que ce code ne tiens pas dans la VBL !!!

 

j'suis déçu la :mellow: ou est donc la rapiditée du GPU ...

Share this post


Link to post
Share on other sites
Orion_    1

bon laissez tomber ce que j'ai dit, ça tiens dans la VBL :D simplement le 68000 attendais que le GPU est fini et ensuite recontruisait la liste, la j'attend plus et la liste je la construit une fois, apres je la recopie avec 2 movem.l a chaque frame

Share this post


Link to post
Share on other sites
SCPCD    0

je me disais bien que ct bizarre que ca ne rentrée pas dans la VBL.

 

Vue qu'il y a des codes au GPU qui sont bien plus compliqué (native) qui rentre dans la VBL...

Share this post


Link to post
Share on other sites
Orion_    1

bon ça y est, maintenant que je commence a mieux comprendre le GPU ça commence a me plaire :)

 

je trouve que le GPU est génial, parceque on a l'avantage d'un RISC ! et contrairement aux processeur ARM, on peut charger des valeurs .long sans probleme ! (movei) alors qu'avec un arm non :/ (faut faire des décalages et autre parceque les instructions ARM faisant 32 bits on peut evidement pas caser uen valeur longue + un code d'instruction dedans :D)

 

et y'a une instructions que j'adore particulièrement et que j'ai jamais vu autre part, c'est SAT !

 

ça me permet de faire un petit effet pour pas un rond de temps CPU ! alors que sur n'importe kel autre processeur faut ce taper un cmp puis un jump conditionnel :/

Share this post


Link to post
Share on other sites
Orion_    1

j'emet une hypothése sur le prechargement du GPU. on part du fait qu'il est 64bits

 

il charge donc ces instructions par 64bits, chaque instruction faisant 32bits c'est pour ça qu'il en charge 2 a chaque fois :)

 

mais ça pose un probleme pour les instructions genre movei qui font elle 64bits (32bits pour l'instruction et 32bits pour la valeur a charger)

 

voila pourquoi:

 

movei #5,r5

 

loop:

 

subq #1,r5

 

jr ne,loop

 

addq #1,r5

 

 

 

fait une boucle infinie, et si on remplace addq par movei #5,r5, le compilateur nous insert automatiquement un nop entre jr et movei, vu que movei ne sera chargé qu'a moitier :D

Share this post


Link to post
Share on other sites
Zerosquare    10
Orion_ :
contrairement aux processeur ARM, on peut charger des valeurs .long sans probleme ! (movei) alors qu'avec un arm non :/ (faut faire des décalages et autre parceque les instructions ARM faisant 32 bits on peut evidement pas caser uen valeur longue + un code d'instruction dedans :D)




Déjà vécu aussi, et ce que ça peut être c...



Orion_ :


y'a une instructions que j'adore particulièrement et que j'ai jamais vu autre part, c'est SAT !

ça me permet de faire un petit effet pour pas un rond de temps CPU ! alors que sur n'importe kel autre processeur faut ce taper un cmp puis un jump conditionnel :/



Je proteste, ça existe aussi dans les instructions MMX (et tu peux même en faire 2 ou 4 en parallèle) :D

(Bon, avant que GT Turbo ne s'énerve, je ne pense pas que le Pentium le fasse en un cycle non plus ;) )



Au passage, Orion_, tu fais de l'assembleur x86 aussi ? Parce que si oui il ne va plus rien me rester :cry:

Share this post


Link to post
Share on other sites
Orion_    1

heu oui :D

 

un tout petit peu d'arm sur GP32 et pocketstation, du x86 sur pc et 186 sur wonderswan, du 68000 sur TI/atari st et jag, du GPU maintenant :D et de l'assembleur 8bits inconnu sur pokemon mini :)

Share this post


Link to post
Share on other sites
Orion_    1

bon et au passage je confirme, le code si dessus est limite, je l'ai converti pour qu'il copie chaque R G et B separement, en faisant un peu de traitement dessus, et mon truc tiens en 1.3 VBL :( sans compter qu'il faut que je rajoute le blitter pour effacer mon écran a chaque fois :/

 

pas si rapide que ça le gpu ...

Share this post


Link to post
Share on other sites
SCPCD    0
Orion_ :


j'emet une hypothése sur le prechargement du GPU. on part du fait qu'il est 64bits

il charge donc ces instructions par 64bits, chaque instruction faisant 32bits c'est pour ça qu'il en charge 2 a chaque fois :)

mais ça pose un probleme pour les instructions genre movei qui font elle 64bits (32bits pour l'instruction et 32bits pour la valeur a charger)

voila pourquoi:

movei #5,r5

loop:

subq #1,r5

jr ne,loop

addq #1,r5



fait une boucle infinie, et si on remplace addq par movei #5,r5, le compilateur nous insert automatiquement un nop entre jr et movei, vu que movei ne sera chargé qu'a moitier :D



En fait, les instructions GPU sont en 16bits.

et le bus des instructions du GPU est en 32bits.

Le bus des datas (le bus externe) est quand a lui en 64-bits. (simple non :D)



Et donc lorsque tu executes une instructions GPU, le GPU en charge 2 par cycles en général (prefetch) sauf pour l'instruction movei qui est une instruction sur 48bits. donc qui est chargé en 2 fois avec l'instruction qui suit ou qui precede selon l'alignement de movei sur une adresse 32bit ou 16bit.

Citation


bon et au passage je confirme, le code si dessus est limite, je l'ai converti pour qu'il copie chaque R G et B separement, en faisant un peu de traitement dessus, et mon truc tiens en 1.3 VBL sans compter qu'il faut que je rajoute le blitter pour effacer mon écran a chaque fois :/

pas si rapide que ça le gpu ...



en fait, c'est pas le GPU qui est lent c'est le bus qui est plombé par le 68000.

en plus, si tu utilises des accés a la ram sans arret avec des loadb,w et storeb,w ca ralenti a mort les accés car l'attente pour la lecture d'une valeur sur le bus (même si il est 64bit) est très long comparé a la mémoire interne : en interne c'est entre 3 et 4 cycles, en externe c'est bien plus long (tout depend de l'utilisation du bus par les autres processeurs)

En plus, les GPU/DSP ne sont pas concu pour faire des transferts de données mais pour calculer et faire des accés de temps a autre.

C'est pourquoi, il est bien plus interressant de faire des copies par le Blitter qui lui est concu pour la copie des données.;)

Share this post


Link to post
Share on other sites
SCPCD    0
Orion_ :


movei #5,r5

loop:

subq #1,r5

jr ne,loop

addq #1,r5



fait une boucle infinie [...]



En fait, dans ce cas, je pense qu'il y a peut être 2 sources d'erreur :

- il y a peut être un bug lors de la resynchro des instructions dans le cas où l'instruction de retour n'est pas aligné sur une adresse 32bit

- il ne faut pas oublié que le GPU/DSP execute toujours l'instruction qui suit un jump/jr donc dans ce cas, je ne sais plus trop comment il gere les flags pour le saut.

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×