Komentowana treść: Nowa, szybka konwersja chunky-to-planar
14.11.2015 16:07
[#31]
Re: Nowa, szybka konwersja chunky-to-planar
@Leon, post #26
"Ps. I nie słuchaj tych malkontentów, scenowcy przez 20 lat naklepali miliony linijek kodu a jakoś nie przełożyło się to na ilość wydanych gier na Amigę. Także nie patrz się na innych i realizuj swoje pomysły i marzenia."
Malkontentów? Serio? Komentujemy kawałek kodu który poza tym, że dał autorowi satysfakcję nic nie wnosi. Wynajduje koło na nowo w dziedzinie w której już nie ma dużo do powiedzenia (do tego kod jest publicznie dostępny) zamiast powalczyć nad pozostałymi 95% kodu takiego przysłowiowego wolfensteina. Tam jest duże pole do popisu (tak, nawet przy takim prostym silniku) i można się wykazać.
Ostatnia aktualizacja: 14.11.2015 16:08:42 przez kiero
Malkontentów? Serio? Komentujemy kawałek kodu który poza tym, że dał autorowi satysfakcję nic nie wnosi. Wynajduje koło na nowo w dziedzinie w której już nie ma dużo do powiedzenia (do tego kod jest publicznie dostępny) zamiast powalczyć nad pozostałymi 95% kodu takiego przysłowiowego wolfensteina. Tam jest duże pole do popisu (tak, nawet przy takim prostym silniku) i można się wykazać.
Ostatnia aktualizacja: 14.11.2015 16:08:42 przez kiero
14.11.2015 16:25
[#32]
Re: Nowa, szybka konwersja chunky-to-planar
@kiero, post #31
kawałek kodu który poza tym, że dał autorowi satysfakcję nic nie wnosi
No właśnie miałem zapytać po co to właściwie zostało zrobione. Jeżeli dla własnej przyjemności i ze względów treningowych/edukacyjnych to ok. Można coś takiego sobie spróbować zrobić. Jednak jakby się chciało na tym coś zrobić to chyba lepiej użyć istniejących od lat procedurek tego typu. W tej dziedzinie zrobiono i udowodniono już bardzo wiele. I zrobiła to czołówka amigowego świata koderskiego więc szybciej zrobić się już chyba nie da.
14.11.2015 16:42
[#35]
Re: Nowa, szybka konwersja chunky-to-planar
@Leon, post #34
Grzebac? Masz opisane parametry procedury. Co wiecej, masz napisane jak ich uzyc. W c2p nie ma czarów. Masz dane wejsciowe i miejsce na dane wyjsciowe. To taka nieco bardziej zlozona operacja kopiowania. Nie musisz wiedziec co robi kazda linijka. A teorie 'nowoczesnych' c2p masz wylozona np Tutaj. Proponuje zassac archiwum do ktorego linkowalem i przynajmniej popatrzyc co jest w srodku.
Ostatnia aktualizacja: 14.11.2015 16:43:10 przez kiero
Ostatnia aktualizacja: 14.11.2015 16:43:10 przez kiero
14.11.2015 16:45
[#36]
Re: Nowa, szybka konwersja chunky-to-planar
@MDW, post #32
Ćwiczyłem już od dosyć dłuższego czasu z procedurą c2p, od momentu kiedy zrozumiałem jej ideę. Postawiłem sobie pytanie - czy można użyć jakiejś lepszej struktury danych, by konwersja była efektywniejsza. Moja idea z odpowiednim ustawieniem pikseli celem szybszej konwersji jest co najmniej interesująca, jakby nie patrzeć.
Oczywiście zdaję sobie sprawę, że odpowiednie procedury do stawiania pikseli muszą być zmodyfikowane, ale wystarczy proste mapowanie posiłkowane 32-elementową tablicą.
Przyświeca temu cel, że każda procedura może być ulepszana.
Kod umieściłem, bo akurat KOGOŚ może zainteresować. Nie ukrywam, że satysfakcję z opracowania tej procedury mam, a sama ewentualność, że wprowadziłem jakąś innowację sprawia, że szybciej bije mi serce.
Nie wykluczone, że nic nowego nie wniosło w co wątpię.
W każdym razie dziękuję wszystkim za komentarze.
Oczywiście zdaję sobie sprawę, że odpowiednie procedury do stawiania pikseli muszą być zmodyfikowane, ale wystarczy proste mapowanie posiłkowane 32-elementową tablicą.
Przyświeca temu cel, że każda procedura może być ulepszana.
Kod umieściłem, bo akurat KOGOŚ może zainteresować. Nie ukrywam, że satysfakcję z opracowania tej procedury mam, a sama ewentualność, że wprowadziłem jakąś innowację sprawia, że szybciej bije mi serce.
Nie wykluczone, że nic nowego nie wniosło w co wątpię.
W każdym razie dziękuję wszystkim za komentarze.
14.11.2015 16:55
[#37]
Re: Nowa, szybka konwersja chunky-to-planar
@Leon, post #34
Pewnie sam wiesz jak to jest grzebać w czyimś kodzie.
Doskonale to rozumiem. Ja właśnie choruję na odrazę do grzebania w cudzym kodzie. Piszę sam wiele rzeczy, które są dostępne w postaci otwartego kodu, bo mam wrażenie, że tylko wtedy panuję w pełni nad tym co robię. Jednak od lat z tym wlaczę i jakieś efekty tego już są, bo już nie dostaję białej gorączki gdy widzę cudzą klasę/funkcję/procedurę.
Mimo tej odrazy myślę, że gdybym pisał na najsłabsze Amigi w assemblerze (raczej nigdy to nie nastąpi, bo to nie moje klimaty) to używałbym gotowych procedurek c2p. Jest to na tyle zamknięty i odseparowany kawałek kodu, że nie trzeba się w niego wgryzać. Po prostu użyć zogdnie z opisem i tyle. Tak mi się wydaje.
I taka mała ciekawostka. Polecam ściągnąć źródła dzisiejszego systemu operacyjnego Android i poszukać w nich wyrazu "Amiga". Trafi się na procedurkę chunky-to-planar w której w komentarzu będzie uwaga, że procedura inspirowana c2p Scouta.
To zresztą nie jedyne miejsce w którym wyraz "Amiga" istnieje w źródłach Androida.Ostatnia aktualizacja: 14.11.2015 16:58:38 przez MDW
14.11.2015 16:57
[#38]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #36
"Ćwiczyłem już od dosyć dłuższego czasu z procedurą c2p"
No i bardzo dobrze. Kazde kolejne cwiczenie powoduje wzrost umiejetnosci a w programowaniu jest nie niezbedne. Z tym, ze moim zdaniem powinienes cwiczyc jak najszybsze blitowanie tilesow na ekran 2d a nie procedury c2p do 3d.
Jak sie teraz zabierzesz za "pisanie Doom'a", to reszta tych projektow, ktore juz zaczales nigdy nie bedzie miala szansy na realizacje.
No i bardzo dobrze. Kazde kolejne cwiczenie powoduje wzrost umiejetnosci a w programowaniu jest nie niezbedne. Z tym, ze moim zdaniem powinienes cwiczyc jak najszybsze blitowanie tilesow na ekran 2d a nie procedury c2p do 3d.
Jak sie teraz zabierzesz za "pisanie Doom'a", to reszta tych projektow, ktore juz zaczales nigdy nie bedzie miala szansy na realizacje.
14.11.2015 17:11
[#40]
Re: Nowa, szybka konwersja chunky-to-planar
@kiero, post #35
Witam.
Czy moglibyście mi wyjaśnić przy okazji czy c2p w koprocesorze Akiko w cd32 jest jeszcze użyteczne , czy trzeba to robić najlepiej procesorem?
Drugie: czy taki kod mozna napisać na koprocesor 882 choćby częściowo?
Nie mogę pojąć że EC020 ma 16mHz a 882 można podkręcić do 50 i nikt nie chce pisać
optymalizacji pod niego.
Nie każdy ma 060@100 (zazdroszczę :D)
Pozdrawiam serdecznie
Czy moglibyście mi wyjaśnić przy okazji czy c2p w koprocesorze Akiko w cd32 jest jeszcze użyteczne , czy trzeba to robić najlepiej procesorem?
Drugie: czy taki kod mozna napisać na koprocesor 882 choćby częściowo?
Nie mogę pojąć że EC020 ma 16mHz a 882 można podkręcić do 50 i nikt nie chce pisać
optymalizacji pod niego.
Nie każdy ma 060@100 (zazdroszczę :D)
Pozdrawiam serdecznie
14.11.2015 17:16
[#41]
Re: Nowa, szybka konwersja chunky-to-planar
@asman, post #39
Koszt mapowania jest proporcjonalny do liczby pikseli i polega na 2 instrukcjach: pobraniu z tablicy wartości odpowiadającej danej pozycji piksela (w grupie 32 pikseli) i umieszczeniu piksela w odpowiednim miejscu. Jest to zwykła procedura mapowania, jak np. mapowanie kolorów. Zatem koszt znikomy, a umożliwia on dużo sprawniejszą konwersję.
Ostatnia aktualizacja: 14.11.2015 17:20:00 przez Hexmage960
Ostatnia aktualizacja: 14.11.2015 17:20:00 przez Hexmage960
14.11.2015 17:22
[#42]
Re: Nowa, szybka konwersja chunky-to-planar
@asman, post #39
Ogolnie chodzi o to, ze 060 ma 2 ALU i przy specjalnie przygotowanym kodzie potrafi rozdzielac instrukcje pomiedzy nie efektywnie wykonujac 2 instrukcje zamiast jednej w tym samym czasie. Np taki kod:
add.l d0, d1
add.l d2, d3
add.l d4, d5
add.l d6, d7
wykona sie w 2 cyklach procesora zamiast w 4 (samo add.l wykonuje sie w 1 cyklu). Niestety sprawa nie jest taka prosta przy bardziej skomplikowanym kodzie. Musimy starac sie eliminowac 'zaleznosci' pomiedzy instrukcjami. Np takie cos:
add.l d0, d1
add.l d1, a0
jest zle, bo druga instrukcja potrzebuje wyniku z pierwszej. Ale takie cos:
add.l d0, d1
add.l d2, d3
add.l d1, a0
add.l d3, a1
jest juz jak najbardziej ok. Dlatego tez np dobrym pomyslem jest rozwiniecie petli tak zeby obliczac 2 wyniki jednoczesniej. Wtedy duzo prosciej jest wlasnie parowac instrukcje tak zeby nie powstawaly pomiedzy nimi zaleznosci.
Oczywiscie ograniczen jest wiecej. Nie kazda instrukcja jest w stanie wykonac sie na drugim potoku (lista jest w user manual. sa to instrukcje typu pOEP-only). Rozdzial 10 w 68060UM.pdf jest ogolnie bardzo ciekawy. Przy optymalizacji pod 060 polecam wielokrotna lekture;)
68060UserManual
add.l d0, d1
add.l d2, d3
add.l d4, d5
add.l d6, d7
wykona sie w 2 cyklach procesora zamiast w 4 (samo add.l wykonuje sie w 1 cyklu). Niestety sprawa nie jest taka prosta przy bardziej skomplikowanym kodzie. Musimy starac sie eliminowac 'zaleznosci' pomiedzy instrukcjami. Np takie cos:
add.l d0, d1
add.l d1, a0
jest zle, bo druga instrukcja potrzebuje wyniku z pierwszej. Ale takie cos:
add.l d0, d1
add.l d2, d3
add.l d1, a0
add.l d3, a1
jest juz jak najbardziej ok. Dlatego tez np dobrym pomyslem jest rozwiniecie petli tak zeby obliczac 2 wyniki jednoczesniej. Wtedy duzo prosciej jest wlasnie parowac instrukcje tak zeby nie powstawaly pomiedzy nimi zaleznosci.
Oczywiscie ograniczen jest wiecej. Nie kazda instrukcja jest w stanie wykonac sie na drugim potoku (lista jest w user manual. sa to instrukcje typu pOEP-only). Rozdzial 10 w 68060UM.pdf jest ogolnie bardzo ciekawy. Przy optymalizacji pod 060 polecam wielokrotna lekture;)
68060UserManual
14.11.2015 17:46
[#48]
Re: Nowa, szybka konwersja chunky-to-planar
@asman, post #43
W praktyce remapowanie nie powinno dużo kosztować.
lea piksele,a0
lea cel,a2
lea tablica,a1 ; tablica remapowania
move.b (a1)+,d0
move.b (a0)+,(a2,d0)
move.b (a1)+,d0
move.b (a0)+,(a2,d0)
itd. tyle par instrukcji ile pikseli.
A! Ponieważ mamy tu do czynienia z tablicą stałych to kod upraszcza się:
move.b (a0)+,x(a2)
move.b (a0)+,y(a2)
move.b (a0)+,z(a2)
gdzie x, y, z to stałe itd. (32 razy)
Ostatnia aktualizacja: 14.11.2015 18:03:27 przez Hexmage960
lea piksele,a0
lea cel,a2
lea tablica,a1 ; tablica remapowania
move.b (a1)+,d0
move.b (a0)+,(a2,d0)
move.b (a1)+,d0
move.b (a0)+,(a2,d0)
itd. tyle par instrukcji ile pikseli.
A! Ponieważ mamy tu do czynienia z tablicą stałych to kod upraszcza się:
move.b (a0)+,x(a2)
move.b (a0)+,y(a2)
move.b (a0)+,z(a2)
gdzie x, y, z to stałe itd. (32 razy)
Ostatnia aktualizacja: 14.11.2015 18:03:27 przez Hexmage960
14.11.2015 18:03
[#49]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #48
To jest tylko najprostszy przyklad. Jest duzo przypadkow kiedy jest to bardziej skomplikowane. Ogolnie takie remapowanie:
- zasmieca ci data cache jezeli uzywamy duzej tablicy (tak jak tutaj)
- dodaje obliczen jezeli uzywamy tablicy malej (np tylko dla dolnych 8bitow). komplikuje kod
- kosztuje dodatkowy rejestr/rejestry
- wymaga sledzenia offsetu przy rysowaniu czegokolwiek (np kreslenie linii to nie sa liniowe dostepy do bufora)
Jezeli nie ma wymiernego zysku przy samym c2p to nie warto. A tak jak napisalem zysku w stosunku do 'konkurencyjnych' algorytmow nie ma.
EDIT:
To co podales pozniej to tylko najprostszy przypadek kiedy zapisujemy liniowo albo konwertujemy liniowo. Jezeli chcesz konwertowac caly bufor to dochodza ci koszty odczytow i zapisow do pamieci. To nie jest darmo. Szczegolnie przy odczytach i zapisach 8bit. Bez sensu skoro mozna to wrzucic do c2p (move.b + shifty)
Ostatnia aktualizacja: 14.11.2015 18:04:45 przez kiero
Ostatnia aktualizacja: 14.11.2015 18:06:01 przez kiero
Ostatnia aktualizacja: 14.11.2015 18:06:16 przez kiero
- zasmieca ci data cache jezeli uzywamy duzej tablicy (tak jak tutaj)
- dodaje obliczen jezeli uzywamy tablicy malej (np tylko dla dolnych 8bitow). komplikuje kod
- kosztuje dodatkowy rejestr/rejestry
- wymaga sledzenia offsetu przy rysowaniu czegokolwiek (np kreslenie linii to nie sa liniowe dostepy do bufora)
Jezeli nie ma wymiernego zysku przy samym c2p to nie warto. A tak jak napisalem zysku w stosunku do 'konkurencyjnych' algorytmow nie ma.
EDIT:
To co podales pozniej to tylko najprostszy przypadek kiedy zapisujemy liniowo albo konwertujemy liniowo. Jezeli chcesz konwertowac caly bufor to dochodza ci koszty odczytow i zapisow do pamieci. To nie jest darmo. Szczegolnie przy odczytach i zapisach 8bit. Bez sensu skoro mozna to wrzucic do c2p (move.b + shifty)
Ostatnia aktualizacja: 14.11.2015 18:04:45 przez kiero
Ostatnia aktualizacja: 14.11.2015 18:06:01 przez kiero
Ostatnia aktualizacja: 14.11.2015 18:06:16 przez kiero
Akiko nie od 040 wzwyż.15.11.2015 02:43
[#52]
Re: Nowa, szybka konwersja chunky-to-planar
@Mikrobi, post #51
Hej! Zapodaję wersję z dodaną optymalizacją zaproponowaną przez Don Adana oraz z zapisywaniem dla bitmap interleaved, jak poradził Kiero.
A1 teraz wskazuje na początek danych graficznych w bitmapie typu interleaved o rozmiarze 320x256. A2 pełni inną rolę i nie jest już argumentem.
Na Blizzardzie z 030/50MHz cały ekran konwertuje się bardzo szybko.
Jestem nadal otwarty na sugestie. Chciałbym by był to szybki chunky 2 planar dla Amig "low-end", czyli z 030 i FAST.
c2p_1.s
A1 teraz wskazuje na początek danych graficznych w bitmapie typu interleaved o rozmiarze 320x256. A2 pełni inną rolę i nie jest już argumentem.
Na Blizzardzie z 030/50MHz cały ekran konwertuje się bardzo szybko.
Jestem nadal otwarty na sugestie. Chciałbym by był to szybki chunky 2 planar dla Amig "low-end", czyli z 030 i FAST.
c2p_1.s
15.11.2015 10:49
[#56]
Re: Nowa, szybka konwersja chunky-to-planar
@Krashan, post #55
Tak, planuję zrobić dokładne benchmarki.
Ekran na 030/FAST konwertuje się "momentalnie" - nie widać procesu stawiania pikseli. Najlepiej sprawdzić na 320x200 (zmienić odpowiednią linijkę w kodzie procedury) i ustawić priorytet tasku na wysoki, żeby miał więcej cykli procesora.
Oczywiście sama gra korzystająca z grafiki w chunky to nie tylko c2p, ale wydaje mi się, że stosując moją procedurę można uzyskać całkiem zadowalające rezultaty. Mam jeszcze Blizzarda 1260/50MHz, ale na nim mojej procedury jeszcze nie testowałem.
Myślę, że stworzyłem coś wartościowego. No ale dzisiaj nie będę już rozmawiał na forum bo mam inne obowiązki. Życzę miłego dnia.
Ekran na 030/FAST konwertuje się "momentalnie" - nie widać procesu stawiania pikseli. Najlepiej sprawdzić na 320x200 (zmienić odpowiednią linijkę w kodzie procedury) i ustawić priorytet tasku na wysoki, żeby miał więcej cykli procesora.
Oczywiście sama gra korzystająca z grafiki w chunky to nie tylko c2p, ale wydaje mi się, że stosując moją procedurę można uzyskać całkiem zadowalające rezultaty. Mam jeszcze Blizzarda 1260/50MHz, ale na nim mojej procedury jeszcze nie testowałem.
Myślę, że stworzyłem coś wartościowego. No ale dzisiaj nie będę już rozmawiał na forum bo mam inne obowiązki. Życzę miłego dnia.
15.11.2015 11:26
[#59]
Re: Nowa, szybka konwersja chunky-to-planar
Ja zaoferuję do testów dwie swoje Ami1200. Jedną z Apollo i AGA 040/40, oraz drugą, też 040/40 z kartą GFX BVision.
15.11.2015 11:42
[#60]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #58
Dlatego właśnie nic nie zastąpi dokładnego pomiaru, bo to pozwala stwierdzić, czy idzie się w dobrym kierunku. Bardzo mi się to przydało przy optymalizowaniu szyfru AES-256 na PowerPC. Zacząłem od napisania pomiaru czasu i każda kolejna wersja była mierzona. Dzięki temu wyłapałem sporo niespodzianek.
BTW trzeba się pobawić AES-em na M68k...
BTW trzeba się pobawić AES-em na M68k...