Komentowana treść: Nowa, szybka konwersja chunky-to-planar
16.11.2015 23:00
[#92]
Re: Nowa, szybka konwersja chunky-to-planar
@Don_Adan, post #91
Nie musisz niczego synchronizowac (poza czekaniem pomiedzy c2p) jezeli masz c2p podzielone na 2 etapy. pierwszy (na calym buforze przez cpu) robiacy 3 przebiegi/merge c2p a potem ostatni (tez na calym buforze) blitterem. Jedyne co trzeba zrobic to poczekac na poczatku c2p na ewentualne zakonczenie pracy blittera ale to tylko wtedy jezeli inne obliczenia wykonuja sie zbyt szybko. Cos w tym stylu:
- rendering
- c2p - cpu
- c2p - blitter (async)
- rendering
- waitforblit
- c2p - cpu
- ...
Oczywiscie bufory tez zamieniamy w odpowiednim momencie. "Problemem" tutaj jest tylko to, ze trudno zmierzyc czas takieco c2p bo czy czas to czas etapu cpu czy cpu + blitter?:)
PS. Od razu mowie, ze nigdy tego nie testowalem. Zrodlo: normal/c2p1x1_8_c3b1_030.s z paczki do ktorej linkowalem.
Ostatnia aktualizacja: 16.11.2015 23:02:17 przez kiero
- rendering
- c2p - cpu
- c2p - blitter (async)
- rendering
- waitforblit
- c2p - cpu
- ...
Oczywiscie bufory tez zamieniamy w odpowiednim momencie. "Problemem" tutaj jest tylko to, ze trudno zmierzyc czas takieco c2p bo czy czas to czas etapu cpu czy cpu + blitter?:)
PS. Od razu mowie, ze nigdy tego nie testowalem. Zrodlo: normal/c2p1x1_8_c3b1_030.s z paczki do ktorej linkowalem.
Ostatnia aktualizacja: 16.11.2015 23:02:17 przez kiero
17.11.2015 06:32
[#94]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #93
Ha ha! Udało mi się pomieścić c2p, który konwertuje chunky i przeskalowuje do 2x1 planar w 256 bajtach kodu. Nawet malutki bufor pomocniczy o rozmiarze 4 długich słów zmieściłem. Na styk. 
Procedura bazuje na moim dotychczasowym kodzie, pobiera 16 pikseli i produkuje 32 w jednym przejściu pętli. Wymaga analogicznego układu pikseli.
Oczywiście zapisuje do FAST wynik po kolei. W Asm-One jak nacisnę strzałkę w dół w debuggerze przy wywołaniu procedury dla 320x200 nie ma ani tyci opóźnienia. Wynik wystarczy teraz skopiować do CHIP i.. cieszyć się 50fps Doom. 
Procedura bazuje na moim dotychczasowym kodzie, pobiera 16 pikseli i produkuje 32 w jednym przejściu pętli. Wymaga analogicznego układu pikseli.Oczywiście zapisuje do FAST wynik po kolei. W Asm-One jak nacisnę strzałkę w dół w debuggerze przy wywołaniu procedury dla 320x200 nie ma ani tyci opóźnienia. Wynik wystarczy teraz skopiować do CHIP i.. cieszyć się 50fps Doom
. 17.11.2015 07:15
[#95]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #94
A oto kod tej pchełki.
Myślę, że rozmiar dla 020 i 030 ma znaczenie, bo program i dane leżą w obrębie pamięci kieszeniowej.
Wyszła mi chyba jedna z najmniejszych procedur c2p, która efektywnie konwertuje i przeskalowuje do 2x1.
Myślę, że rozmiar dla 020 i 030 ma znaczenie, bo program i dane leżą w obrębie pamięci kieszeniowej.
Wyszła mi chyba jedna z najmniejszych procedur c2p, która efektywnie konwertuje i przeskalowuje do 2x1.
17.11.2015 08:13
[#96]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #95
nie komentowalem, bo nie mam nic wiecej do dodania niz inni, ale to juz sie robi nudne - poprosze o jakies konkretne dane. najlepiej porownanie ze scoutowym c2p :)
mile widziane bedzie porownanie na statycznym obrazku w 8bpl i z dynamicznym, np losowe piksle
Ostatnia aktualizacja: 17.11.2015 08:16:09 przez juen
mile widziane bedzie porownanie na statycznym obrazku w 8bpl i z dynamicznym, np losowe piksle
Ostatnia aktualizacja: 17.11.2015 08:16:09 przez juen
17.11.2015 08:25
[#98]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #94
Wynik wystarczy teraz skopiować do CHIP i.. cieszyć się 50fps Doom
Nie wziąłeś pod uwagę tego, że pamięć chip jest stosunkowo wolna, więc konwersja do fastu a potem kopiowanie jest rozwiązaniem nieefektywnym. Jednym z istotnych zagadnień w amigowym c2p jest umiejętne przeplecenie ze sobą przetwarzania i zapisu do chipu.
Poza tym nadal nie zrobiłeś pomiarów. Wybacz szczerość, ale tekstem o tym, że naciskasz strzałkę i nie widzisz opóźnienia, po prostu się ośmieszasz. Puść całą procedurę w pętli np. 1000 razy, zmierz czas przy pomocy EClocka, policz średnią. Porównaj z kodem opublikowanym w sieci. Wyciągnij wnioski.
Nie wziąłeś pod uwagę tego, że pamięć chip jest stosunkowo wolna, więc konwersja do fastu a potem kopiowanie jest rozwiązaniem nieefektywnym. Jednym z istotnych zagadnień w amigowym c2p jest umiejętne przeplecenie ze sobą przetwarzania i zapisu do chipu.
Poza tym nadal nie zrobiłeś pomiarów. Wybacz szczerość, ale tekstem o tym, że naciskasz strzałkę i nie widzisz opóźnienia, po prostu się ośmieszasz. Puść całą procedurę w pętli np. 1000 razy, zmierz czas przy pomocy EClocka, policz średnią. Porównaj z kodem opublikowanym w sieci. Wyciągnij wnioski.
17.11.2015 16:05
[#100]
Re: Nowa, szybka konwersja chunky-to-planar
@Krashan, post #98
Jeśli chodzi o zapis do CHIP - można uruchomić małego "daemonka" (inny task lub przerwanie np. timer.device), który kopiuje co pewien okres czasu dane do CHIP wyprodukowane przez takie c2p i gotowe.
Ze względu na rozmiar pętli nie można rozłożyć tego zapisywania w pętli c2p. A tutaj właśnie o rozmiar chodzi.
Co do pomiarów, będę je wkrótce robił. Tak - za pomocą timer.device i EClock.
Ze względu na rozmiar pętli nie można rozłożyć tego zapisywania w pętli c2p. A tutaj właśnie o rozmiar chodzi.
Co do pomiarów, będę je wkrótce robił. Tak - za pomocą timer.device i EClock.
17.11.2015 17:12
[#103]
Re: Nowa, szybka konwersja chunky-to-planar
@recedent, post #101
Proszę mi wybaczyć opieszałość, takie życie. Miałem ciężki tydzień (zdrowienie...) i mam w tym tygodniu jeszcze parę ważnych spraw na głowie. Z dyskusji ja sam sporo się dowiedziałem, a mam nadzieję, że inni rozmówcy również. Podaję konkretne procedury c2p oraz własne pomysły, słucham opinii kolegów, nie rzucam słów na wiatr. Inaczej niż zazwyczaj, nie?
Na dniach porobię testy.
Na dniach porobię testy.
17.11.2015 18:04
[#104]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #100
Jeśli chodzi o zapis do CHIP - można uruchomić małego "daemonka" (inny task lub przerwanie np. timer.device), który kopiuje co pewien okres czasu dane do CHIP
Ale on też przecież będzie zabierał czas procesora, co więcej, znaczna część tego czasu zostanie zmarnowana na oczekiwanie na dostęp do pamięci chip. Więc jak mierzyć – to całość, bo procedura c2p, która zostawia dane w faście jest doskonale bezużyteczna.
Ale on też przecież będzie zabierał czas procesora, co więcej, znaczna część tego czasu zostanie zmarnowana na oczekiwanie na dostęp do pamięci chip. Więc jak mierzyć – to całość, bo procedura c2p, która zostawia dane w faście jest doskonale bezużyteczna.
17.11.2015 18:31
[#105]
Re: Nowa, szybka konwersja chunky-to-planar
@Krashan, post #104
Jeśli uda mi się przygotować takiego daemona to za wykonanie całości będziemy uznawali czas od uruchomienia procedury c2p aż do zakończenia zapisywania przez daemon.
A póki co obliczę czas konwersji c2p fast->fast oraz czas kopiowania do chip. W tym przypadku suma niekoniecznie będzie oznaczała optymalny czas konwersji.
A póki co obliczę czas konwersji c2p fast->fast oraz czas kopiowania do chip. W tym przypadku suma niekoniecznie będzie oznaczała optymalny czas konwersji.
17.11.2015 19:05
[#106]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #94
aż 256 bajtów?
zjedź do 128 bajtów a do kolejnego 128 wrzuć coś podobnego do: https://www.youtube.com/watch?v=cD49RXnEGNE (powinno się dać skoro 68K ma większe upakowanie kodu od X86)
wtedy będzie materiał na news
Ostatnia aktualizacja: 17.11.2015 19:06:17 przez XoR
zjedź do 128 bajtów a do kolejnego 128 wrzuć coś podobnego do: https://www.youtube.com/watch?v=cD49RXnEGNE (powinno się dać skoro 68K ma większe upakowanie kodu od X86)
wtedy będzie materiał na news
Ostatnia aktualizacja: 17.11.2015 19:06:17 przez XoR
18.11.2015 01:34
[#108]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #107
Jak zauważyłeś, generalnie o testy i przykłady wykorzystania Twojego c2p proszą cię ludzie którzy są programistami, czyli wydali oprogramowanie użytkowe, gry lub są koderami dem dla Amigi klasycznej. Optymalizacje mają oni w jednym paluszku.
Pamiętaj że nie negują twojej pracy, tylko proszą o testy które udowodnią że stworzyłeś najszybsze c2p.
Pokaż testy, może np. na przykładzie nowego portu Dooma lub innych gier. Oczywiście nie musisz pracować sam. Poszukaj innych ludzi, którzy pomogą ci swój kod wprowadzić w działające demo/program/grę. Po prostu pokaż, że twój kod działa nie tylko w teorii.
Pamiętaj że nie negują twojej pracy, tylko proszą o testy które udowodnią że stworzyłeś najszybsze c2p.
Pokaż testy, może np. na przykładzie nowego portu Dooma lub innych gier. Oczywiście nie musisz pracować sam. Poszukaj innych ludzi, którzy pomogą ci swój kod wprowadzić w działające demo/program/grę. Po prostu pokaż, że twój kod działa nie tylko w teorii.
18.11.2015 09:17
[#110]
Re: Nowa, szybka konwersja chunky-to-planar
@Andrzej Drozd, post #108
No i są pierwsze pomiary. :)
Jak jest włączony multitasking to pomiary są strasznie rozbieżne, różnice są ogromne. Po zastosowaniu Forbid() wyniki różnią się minimalnie i przedstawiają się następująco:
Procedura: cachec2p.s
Komputer: Amiga 1200. Karta turbo: Blizzard 1230-IV/50MHz + FAST RAM
Rozmiar 1 konwersji: 320x200 (64 000 pikseli)
Liczba konwersji: 100
Test 1: Przesył fast do fast
Czas 100 konwersji - 0,98 sekundy
Średni czas 1 konwersji - 0,0098 sekundy ~9 ms.
Test 2: Jakby moja konwersja zapisywała bezpośrednio do chip wynik byłby taki:
Czas 100 konwersji - 2,09 sekundy
Średni czas 1 konwersji - 0,02 sekundy ~20 ms.
Wynik jest zaledwie dwukrotny.
Wnioski wysnuwam następujące: kiedy wyłączony jest multitasking procedura korzysta w pełni z cache i wyniki różnią się minimalnie.
Wynik dla chip jest zaledwie dwukrotnie większy niż dla fast, co obrazuje, że problem duży nie jest.
Jak jest włączony multitasking to pomiary są strasznie rozbieżne, różnice są ogromne. Po zastosowaniu Forbid() wyniki różnią się minimalnie i przedstawiają się następująco:
Procedura: cachec2p.s
Komputer: Amiga 1200. Karta turbo: Blizzard 1230-IV/50MHz + FAST RAM
Rozmiar 1 konwersji: 320x200 (64 000 pikseli)
Liczba konwersji: 100
Test 1: Przesył fast do fast
Czas 100 konwersji - 0,98 sekundy
Średni czas 1 konwersji - 0,0098 sekundy ~9 ms.
Test 2: Jakby moja konwersja zapisywała bezpośrednio do chip wynik byłby taki:
Czas 100 konwersji - 2,09 sekundy
Średni czas 1 konwersji - 0,02 sekundy ~20 ms.
Wynik jest zaledwie dwukrotny.
Wnioski wysnuwam następujące: kiedy wyłączony jest multitasking procedura korzysta w pełni z cache i wyniki różnią się minimalnie.
Wynik dla chip jest zaledwie dwukrotnie większy niż dla fast, co obrazuje, że problem duży nie jest.
18.11.2015 09:44
[#112]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #110
super, fajnie ze wrzuciles juz jakies dane.
fast to fast mozesz mysle od razu wywalic, bo co to za c2p, gdzie wynik jest w fascie.
najwazniejsze pytanie, czy testy uwzgledniaja mappera, o ktorym pisales? to bardzo istotne, bo inaczej chyba nie ma sensu porownywac wynikow z tymi wynikami z pelni funkcjonalnych c2p.
idealnie jakby zobaczyc ja w uzyciu (np losowe piksle na ekranie + licznik ramek). wtedy kazdy by mogl odpalic na swojej maszynie i podac wyniki. mozna by tez podmieniac routynki do tych juz wszystkim znanych w celu porownania. moze na jakiejs maszynie uda sie uzyskac lepszy wynik?
fast to fast mozesz mysle od razu wywalic, bo co to za c2p, gdzie wynik jest w fascie.
najwazniejsze pytanie, czy testy uwzgledniaja mappera, o ktorym pisales? to bardzo istotne, bo inaczej chyba nie ma sensu porownywac wynikow z tymi wynikami z pelni funkcjonalnych c2p.
idealnie jakby zobaczyc ja w uzyciu (np losowe piksle na ekranie + licznik ramek). wtedy kazdy by mogl odpalic na swojej maszynie i podac wyniki. mozna by tez podmieniac routynki do tych juz wszystkim znanych w celu porownania. moze na jakiejs maszynie uda sie uzyskac lepszy wynik?
18.11.2015 10:32
[#113]
Re: Nowa, szybka konwersja chunky-to-planar
@kiero, post #111
Proszę. Oto użyty kod testujący. Odpalam sobie w asm-one, przechodzę przez procedurę test (albo uruchamiam program) i zczytuję z rejestrów wynik, po czym idę do kalkulatora. Niezbędne minimum.
W d0 mamy liczbę taktów na sekundę (709379), zaś w d3 liczbę taktów obliczoną podczas konwersji.
http://commodore-amiga.pl/test.s
@juen
Jeśli chodzi o mapowanie to rzeczywiście trzeba będzie wprowadzić je do testów. Co do testów z "fajerwerkami", będę nad tym pracował.
Ostatnia aktualizacja: 18.11.2015 10:45:56 przez Hexmage960
W d0 mamy liczbę taktów na sekundę (709379), zaś w d3 liczbę taktów obliczoną podczas konwersji.
http://commodore-amiga.pl/test.s
@juen
Jeśli chodzi o mapowanie to rzeczywiście trzeba będzie wprowadzić je do testów. Co do testów z "fajerwerkami", będę nad tym pracował.
Ostatnia aktualizacja: 18.11.2015 10:45:56 przez Hexmage960
18.11.2015 10:51
[#114]
Re: Nowa, szybka konwersja chunky-to-planar
@recedent, post #109
to już przegięcie z tą teoretycznością istnienia tej procedury bo masz podany kod asm
zarzut można mieć jedynie do:
1. braku działającego dema pokazującego procedurę w akcji
2. braku pomiarów prędkości na prawdziwym sprzęcie i porównania do istniejących rozwiązań a jedynie teoretyczne wyliczenia
3. brak dokumentacji
ad 1. nie musi być Doom albo Wolf3d, może być byle co, dwa obrazki zmieniające się na przemian i licznik fps pokazujący ile razy na sekundę wykonywana jest wspomiana konwersja
ad 2. takie teoretyczne wyliczenia nie biorą pod uwagę masy różnorakich zależności które wychodzą dopiero podczas testów prędkościowych i to takich faktycznie dokładnych.
ad 3. kod procedury jest ale już dokumentacji jak ją stosować niet. Powinna być porządna dokumentacja wraz z kodem programu używanego do benchmarkowania.
ps. Oczywiście testy prędkości przeprowadzać startując z danych które są ułożone liniowo.
EDIT://
zacząłem pisać komenta wcześniej tylko się nie wrzucił więc wrzuciłem jeszcze raz a tu widzę są jakieś testy
i trzeba było tak odrazu
Ostatnia aktualizacja: 18.11.2015 10:53:54 przez XoR
zarzut można mieć jedynie do:
1. braku działającego dema pokazującego procedurę w akcji
2. braku pomiarów prędkości na prawdziwym sprzęcie i porównania do istniejących rozwiązań a jedynie teoretyczne wyliczenia
3. brak dokumentacji
ad 1. nie musi być Doom albo Wolf3d, może być byle co, dwa obrazki zmieniające się na przemian i licznik fps pokazujący ile razy na sekundę wykonywana jest wspomiana konwersja
ad 2. takie teoretyczne wyliczenia nie biorą pod uwagę masy różnorakich zależności które wychodzą dopiero podczas testów prędkościowych i to takich faktycznie dokładnych.
ad 3. kod procedury jest ale już dokumentacji jak ją stosować niet. Powinna być porządna dokumentacja wraz z kodem programu używanego do benchmarkowania.
ps. Oczywiście testy prędkości przeprowadzać startując z danych które są ułożone liniowo.
EDIT://
zacząłem pisać komenta wcześniej tylko się nie wrzucił więc wrzuciłem jeszcze raz a tu widzę są jakieś testy
i trzeba było tak odrazu
Ostatnia aktualizacja: 18.11.2015 10:53:54 przez XoR
18.11.2015 16:16
[#115]
Re: Nowa, szybka konwersja chunky-to-planar
@XoR, post #114
Przygotowałem dużo wygodniejszą procedurę testującą.
Wyświetla komunikaty w oknie CLI i korzysta z bibliotek matematycznych (mathffp.library) do liczenia wyników.
Poza tym trochę przebudowałem strukturę funkcji testującej.
Program podaje w mikrosekundach czas konwersji 320x200.
Wyniki są nad wyraz interesujące. Teraz dla FAST to ~8 ms, a dla CHIP to ~17 ms.
Zaobserwowałem pewien czynnik wahania się, który czasem występuje. Wtedy wynik jest trochę inny (niepoprawny). Ciężko mi to wytłumaczyć.
Wyniki dla multitaskingu włączonego i wyłączonego różnią się trochę.
Jak ktoś chce przetestować na swoim komputerze może zasemblować kod i wykonać program. Jeśli ktoś chce plik wykonywalny niech da znać.
http://commodore-amiga.pl/test_2.s
W kolejności będę robił:
Wyświetla komunikaty w oknie CLI i korzysta z bibliotek matematycznych (mathffp.library) do liczenia wyników.
Poza tym trochę przebudowałem strukturę funkcji testującej.
Program podaje w mikrosekundach czas konwersji 320x200.
Wyniki są nad wyraz interesujące. Teraz dla FAST to ~8 ms, a dla CHIP to ~17 ms.
Zaobserwowałem pewien czynnik wahania się, który czasem występuje. Wtedy wynik jest trochę inny (niepoprawny). Ciężko mi to wytłumaczyć.
Wyniki dla multitaskingu włączonego i wyłączonego różnią się trochę.
Jak ktoś chce przetestować na swoim komputerze może zasemblować kod i wykonać program. Jeśli ktoś chce plik wykonywalny niech da znać.
http://commodore-amiga.pl/test_2.s
W kolejności będę robił:
- dopiszę mapowanie wymagane przez moją procedurę (myślę, że nie będzie bardzo kosztowne),
- dopiszę zapisywanie danych wyjściowych w pamięci CHIP,
- zrobię test graficzny.
18.11.2015 20:06
[#116]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #115
Pozostała jeszcze jedna najważniejsza sprawa. Skąd wiadomo że kod c2p jest poprawny ? Test, który przedstawiłeś to jedna możliwość. Pomijam, że w chunky masz same zera, o ile w Asm-One włączyłeś opcję clear ds data.
Podawanie wyników samej c2p bez mapowania jest nie fair. Bo Twoja c2p składa się z dwóch czynników, mapowania i samego c2p.
A propos czynnika wahania, to musisz dociec dlaczego tak jest, pewnie ma to związek z cachem, ale ja nie jestem ekspertem, trochę się znam na 68000. Bo chyba bardziej irytuje odbiorcę jak coś czasami się przycina niż chodzi płynnie acz wolniej.
Czy ktoś ma jakieś fajne doki na temat cache w 68020/68030, najlepiej z przykładami ?
Podawanie wyników samej c2p bez mapowania jest nie fair. Bo Twoja c2p składa się z dwóch czynników, mapowania i samego c2p.
A propos czynnika wahania, to musisz dociec dlaczego tak jest, pewnie ma to związek z cachem, ale ja nie jestem ekspertem, trochę się znam na 68000. Bo chyba bardziej irytuje odbiorcę jak coś czasami się przycina niż chodzi płynnie acz wolniej.
Czy ktoś ma jakieś fajne doki na temat cache w 68020/68030, najlepiej z przykładami ?
