1

czy macie jakies dane dotyczace tego ile cykli to wam zajmuje?
w tej chwili niezoptymalizowana procedurka jest w stanie obrocic 64 punkty na ramke
jestem ciekaw jak daleko jestem od sredniej

do obrotow uzywam macierzy rotacji (9 mnozen/punkt) fixed point 8.8

przechodze na tumiwisizm

2

jaka rozdzielczosc?
jesli jakas niewielka  to wygeneruj sobie tablice wynikow tych mnozen  i korzystaj z gotowych wymnozen.

3 Ostatnio edytowany przez Candle (2011-08-14 10:26:10)

docelowo 160x240
mnozenie mam for fri

przechodze na tumiwisizm

4

for free w sensie nie robi tego 6502? to w zasadzie jesli masz 9 mnozen na punkt to chyba maks jakie sie da uzyskac bez trikow i uproszczen.

5

nie liczy
patrzaj w gadu gadu

przechodze na tumiwisizm

6

nie mam gadu teraz, siedze na przetpotopowym kompie bo mam remont ;)

7

;--    s1*s3
    mwa    S1 Mul1
    mwa    S3 Mul2
    mwa    C3 Mul1
    mwa    Out1+1 S1S3
    ;--    c1*c3 & c2*c3
    mwa    C1 Mul2
    nop
    mwa    Out1+1 C1C3
    mwa    C2 Mul2
    nop
    mwa    Out1+1 C2C3

itd

przechodze na tumiwisizm

8

Hey,

po podliczeniu cykli wyszło jakieś 620 na punkt (razem z projekcją), a więc w tym wypadku jesteś daleko - do przodu (zwłaszcza że u Ciebie jest 8.8). Tutaj stary przykładzik (main.obx):

http://matlos.w.interii.pl/scena_umiera.rar

pozdrawiam

9

nie wiem, czy z tego korzystasz, ale na tej stronce jest opisane jak obliczyć macierz obrotu bez mnożenia

10

podkreslam, mnozenia mam w 1 cyklu, wiec nie ma tu o co walczyc, dluzej sie dodaje i pcha dane w rejestry

smiglo: dzieki, piszesz ze jest tam juz projekcja, ale nie widze w scenie zeby bylo widac perspektywe
tak czy owak 620 cykli/punkt to calkiem niezle

ktos da mniej? ;)

przechodze na tumiwisizm

11 Ostatnio edytowany przez pr0be (2011-08-14 15:32:29)

mi wychodzi na sama rotacje 8bit->16.8->16bit (8bit input, wyliczenia 16.8 i 16bit output bez projekcji) dokladnie 353/365 cykli (best/worst case) na punkt
teoretycznie da sie to jeszcze przyspieszyc i miec 8bit->16.8->16bit w jakies 250-300cykli ale jeszcze nie mialem czasu aby zaimplementowac taka rotacje (w Controlu caly czas jest "stara" lekko podrasowana rotacja z The Shrine...)
dla 8bit->8.8->8bit powinno byc w obu przypadkach jeszcze szybsze o jakies 30-50cykli...

EDIT: aha jeszcze zapomnialem dodac, ze w tych 353/365 sa 3 dzielenia przez 128, jak by dac dzielenie przez 256 to bylo by o jakies ~51cykli szybsze...

12

Candle: użyj macierzy 0.8.

https://www.youtube.com/watch?v=jofNR_WkoCE

13

zeby wspolczynniki byly 0.8? nie zacznie sie wszystko trzasc jak galareta?

przechodze na tumiwisizm

14

W tej rozdzielczosci nie powinno bardzo skakac. Oczywiscie obliczajac macierz uzywaj wiekszej dokladnosci i dopiero przed mnozeniem punktow obetnij.

https://www.youtube.com/watch?v=jofNR_WkoCE

15

mam 195 cykli na punkt (mnozenie i mnozenie z akumulacja w sprzecie)
oczywiscie, pod warunkiem, ze umiem te cykle liczyc

cod:

    mva    #0 Mode            ; 2 + 3    5 
    mwa    Xx Mul1            ; 4 + 6    10
    mva    PointIn_x,x Mul2+1    ; 3 + 3    6
    mva    #1 Mode            ; 2 + 3    5
    mwa    Xy Mul1            ; 4 + 6    10
    mva    PointIn_y,x Mul2+1    ; 3 + 3    6
    mwa    Xz Mul1            ; 4 + 6    10
    mva    PointIn_z,x Mul2+1    ; 3 + 3    6
    nop                ; 2    2
    mva    Out1+2 PointOut_x,x    ; 3 + 3    6    

i to samo x2 dla pozostalych współrzędnych
przechodze na tumiwisizm

16

ktos widzi jakies szanse na optymalizacje tego loopa?

    ldx    #0
    ldy    #Points
    sty    tmp
    ldy    #0
    stx    Mul2
RotateXYZ_l0:
    sty    Mode            ; 3
    iny                ; 2
    mwa    Xx Mul1            ; 10
    mva    PointIn_x,x Mul2+1    ; 6
    sty    Mode            ; 3
    mwa    Xy Mul1            ; 10
    mva    PointIn_y,x Mul2+1    ; 6
    mwa    Xz Mul1            ; 10
    mva    PointIn_z,x Mul2+1    ; 6
    dey                ; 2
    mva    Out1+2 PointOut_x,x    ; 6    
    sty    Mode
    iny
    mwa    Yx Mul1
    mva    PointIn_x,x Mul2+1
    sty    Mode
    mwa    Yy Mul1
    mva    PointIn_y,x Mul2+1
    mwa    Yz Mul1
    mva    PointIn_z,x Mul2+1
    dey
    mva    Out1+2 PointOut_y,x
    sty    Mode
    iny
    mwa    Zx Mul1
    mva    PointIn_x,x Mul2+1
    sty    Mode
    mwa    Zy Mul1
    mva    PointIn_y,x Mul2+1
    mwa    Zz Mul1
    mva    PointIn_z,x Mul2+1
    dey
    mva    Out1+2 PointOut_z,x

    inx
    dec    tmp
    jne    RotateXYZ_l0
przechodze na tumiwisizm

17

Fragment pętli dla każdej współrzędnej zajmuje 64 cykle:

RotateXYZ_l0:
    sty    Mode                    ; 3
    iny                            ; 2
    mwa    Xx Mul1                ; 10
    mva    PointIn_x,x Mul2+1    ; 6
    sty    Mode                    ; 3
    mwa    Xy Mul1                ; 10
    mva    PointIn_y,x Mul2+1    ; 6
    mwa    Xz Mul1                ; 10
    mva    PointIn_z,x Mul2+1    ; 6
    dey                            ; 2
    mva    Out1+2 PointOut_x,x  ; 6        2*2 + 2*3 + 4*6 + 3*10 = 64

   
W takim loopie trudno już zjechać jakoś znacząco w dół - 6 cykli da się zaoszczędzić np trzymając w rejestrze Y któryś PointIn_:

    ldy        #0
RotateXYZ_l0:
    sty        Mode                ; 3
    mwa        Xx Mul1                ; 10
    mvy        PointIn_x,x Mul2+1    ; 6        <- Y
    mva        #1 Mode                ; 5
    mwa        Xy Mul1                ; 10
    mva        PointIn_y,x Mul2+1    ; 6
    mwa        Xz Mul1                ; 10
    mva        PointIn_z,x Mul2+1    ; 6
    mva        #0    Mode            ; 5
    mva        Out1+2 PointOut_x,x ; 6        3+10+24+30=67
    
    mwa        Yx Mul1                ; 10
    sty        Mul2+1                ; 3        <- Y
    mva        #1 Mode                ; 5
    mwa        Yy Mul1                ; 10
    mva        PointIn_y,x Mul2+1    ; 6
    mwa        Yz Mul1                ; 10
    mva        PointIn_z,x Mul2+1    ; 6
    mva        #0    Mode            ; 5
    mva        Out1+2 PointOut_y,x ; 6        3+10+18+30=61

    mwa        Zx Mul1                ; 10
    sty        Mul2+1                ; 3        <- Y
    mva        #1 Mode                ; 5
    mwa        Zy Mul1                ; 10
    mva        PointIn_y,x Mul2+1    ; 6
    mwa        Zz Mul1                ; 10
    mva        PointIn_z,x Mul2+1    ; 6
    ldy        #0                    ; 2
    mva        Out1+2 PointOut_z,x ; 6        2+3+5+18+30=58

Czy tak będzie działać?
Może udałoby się więcej wykombinować gdybyś napisał dokładniej jak działają te rejestry - bo jeśli np. Mode rozróżnia jedynie zero-niezero, to zamiast:

    mva        #1 Mode

można - indeksując X'em od jedynki - zaoszczędzić kolejnych 6 cykli:

    stx        Mode

Czy hardware zmienia zawartość Mul1/Mul2+1?

18

mode = 0 - mul
mode = 1 - mac (multiply and accumulate)
mode = 2 - div

hardware nie rusza mul1/mul2
zapis do mul2+1 powoduje rozpoczecie obliczen

ze mnie dupa wolowa, a nie koder na 6502, wiec wybacz pytanie

a jest cos takiego jak ldy abs,x?

przechodze na tumiwisizm

19

Jest.

KMK
? HEX$(6670358)

20

Plwając jeszcze bezczelniej na estetykę kodu można próbować tak:

    ldx        #Points                ; 2
    mva        #0 Mode                ; 5
    mwa        Xx Mul1                ; 10
    mva        PointIn_x,x Mul2+1    ; 6
    mva        #1 Mode                ; 5
    mvy        #Xy_LO Mul1            ; 5        Y: #Xy_LO
    mva        #Xy_HI Mul1+1        ; 5
    mva        PointIn_y,x Mul2+1    ; 6
    mwa        Xz Mul1                ; 10
    mva        PointIn_z,x Mul2+1    ; 6
    mva        #0 Mode                ; 5
    mva        Out1+2 PointOut_x,x    ; 6        2+25+24+20=71

@x
    ; tutaj już mamy Xz w Mul1
    mva        PointIn_z-1,x Mul2+1    ; 6
    mva        #1    Mode                ; 5
    sty        Mul1                    ; 3
    mva        #Xy_HI Mul1+1            ; 5
    mva        PointIn_y-1,x Mul2+1    ; 6
    mwa        Xx Mul1                    ; 10
    mva        PointIn_x-1,x Mul2+1    ; 6
    mva        #0    Mode                ; 5
    mva        Out1+2 PointOut_x-1,x     ; 6        3+15+24+10=52

    ; a tu Xx
    mva        PointIn_x-2,x Mul2+1    ; 6
    mva        #1    Mode                ; 5
    sty        Mul1                    ; 3
    mva        #Xy_HI Mul1+1            ; 5
    mva        PointIn_y-2,x Mul2+1    ; 6
    mwa        Xz Mul1                    ; 10
    mva        PointIn_z-2,x Mul2+1    ; 6
    mva        #0    Mode                ; 5
    mva        Out1+2 PointOut_x-2,x     ; 6        3+15+24+10=52
    
    dex                                ; 2
    dex                                ; 2
    bpl        @x                        ; 4        8

(Analogicznie dla składowych Y i Z).

O ile jest OK, średnio na punkt daje to ze 172 cykle (troszkę mniej, jeśli nie ma przeciwwskazań aby robić inc/dec Mode). Jakbyś chciał porządniejszego kopa, to można okroić precyzję macierzy jak Fox radzi, rozpętlić kod i zaszyć tam współrzędne punktów (powinno dać się w <6kb przy tych 64-ech vertexach, a na atari nie takie kody derolowano :) ).

21

To może przeprogramuj hardware, żeby zamiast jednego rejestru mode były trzy, które wystarczy "zastrobować" (jak WSYNC). Kod 6502 powinien być wtedy krótszy.

22

śmigło .::. napisał/a:

Plwając jeszcze bezczelniej na estetykę kodu

Przepiękne stwierdzenie.

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

23

Skoro możesz zrobić część obliczeń w sprzęcie, to czemu tylko mnożenie, a nie np. całe obroty?

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

24

ach, bo to karta dzwiekowa
ja rozumiem 3d surround, ale nie rotacje

przechodze na tumiwisizm

25

Candle napisał/a:

ach, bo to karta dzwiekowa
ja rozumiem 3d surround, ale nie rotacje

A czemu nie?
XXL gral muzyczki na GTIA, to Ty mozesz sobie zaprogramowac grafike 3D na dzwiekowce :D