Komentowana treść: Nowa, szybka konwersja chunky-to-planar
15.11.2015 12:09
[#63]
Re: Nowa, szybka konwersja chunky-to-planar
@MDW, post #37
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ę.
Twoja intuicja cię nie zdradza i nigdy nie zdradzi. Bo to czyjeś, ma zawsze ukryte reklamy lub inne reklamacje.
"Swoja chatka, to swoja, bidna, ale solidna i wiadomo ze dach się nie zawali".
Tak czy inaczej, Robert robi dobrą robotę, ale czekamy już tyle lat na jej efekt. Problemem jest to, ze zmienia projekty i ich nie dokańcza. A jest ich chyba już ze 100...
Do Roberta: Robercie, nie łap wszystkich srok za ogon. Dzieło często wymaga całego życia. Wystarczy jedno w życiu. Nie potrzeba wielu.
15.11.2015 16:55
[#67]
Re: Nowa, szybka konwersja chunky-to-planar
@selur, post #65
A po co to leczyć? Amiga to hobby, i jako hobby ma przynosić przyjemność. Jeśli Robert z tego co robi ma frajdę, to już jest to bardzo dobry powód żeby to robić. Nawet jeżeli najczęściej nie kończy się to jakimś finalnym produktem - i co z tego? Najważniejsze jest to że chłopak się realizuje, rozwija, a kto wie, czy kiedyś, jak już będzie miał asemblera i mapę pamięci Amigi w jednym palcu nie powstanie z tego coś fajnego - mniejszy czas na pokonywanie problemów może oznaczać że starczy zapału na dokończenie projektu.
Tak więc brawo Robert, działaj dalej, a kto wie, do czego to zaprowadzi :) A co do samego zapału, o brak którego czasem jesteś oskarżany - to widzę, że masz go więcej niż się niektórym wydaje. Sam fakt że od kilku przynajmniej lat próbujesz pokazuje że ten zapał jest, i to duży :)
A póki co efekty tez są - choćby np sprowokowanie tej dyskusji na temat C2P, co niektórzy np dowiedzieli się czegoś na temat legendarnego AKIKO w CD32 :)
Tak więc brawo Robert, działaj dalej, a kto wie, do czego to zaprowadzi :) A co do samego zapału, o brak którego czasem jesteś oskarżany - to widzę, że masz go więcej niż się niektórym wydaje. Sam fakt że od kilku przynajmniej lat próbujesz pokazuje że ten zapał jest, i to duży :)
A póki co efekty tez są - choćby np sprowokowanie tej dyskusji na temat C2P, co niektórzy np dowiedzieli się czegoś na temat legendarnego AKIKO w CD32 :)
15.11.2015 19:42
[#68]
Re: Nowa, szybka konwersja chunky-to-planar
@vojo, post #67
No i jest kolejna wersja v1.2.
Przebudowałem nieco kod przeplatając sekcje dzielenia i łączenia dzięki czemu udało mi się zaoszczędzić 2 rejestry danych. Używane są teraz przed pętlą do przechowania masek.
Kod jest szybszy. Przepraszam za lekki bałagan w kodzie (parę EXG włożyłem, które trzeba będzie usunąć ;)
http://www.commodore-amiga.pl/c2p_2.s
Benchmarki, testy, dema wkrótce.
Przebudowałem nieco kod przeplatając sekcje dzielenia i łączenia dzięki czemu udało mi się zaoszczędzić 2 rejestry danych. Używane są teraz przed pętlą do przechowania masek.
Kod jest szybszy. Przepraszam za lekki bałagan w kodzie (parę EXG włożyłem, które trzeba będzie usunąć ;)
http://www.commodore-amiga.pl/c2p_2.s
Benchmarki, testy, dema wkrótce.
16.11.2015 09:56
[#69]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #68
Wpadłem na dość ciekawy pomysł odnośnie dalszej optymalizacji. Na 030 konwersja całego ekranu troszkę zajmuje, ale połowy OK.
Z tego co przeczytałem warto, gdy pętla wykonywana przez procesor mieściła się w cache procesora. Dla 68020 jest to 256 bajtów. Wtedy taka pętla jest ładowana w całości do cache i tam wykonywana. Jak jednak skrócić pętlę?
Otóż można wspomóc się Blitterem. Jak wiadomo może on robić konwersję C2P. Mój pomysł polega na tym, że podział i łączenie co 4 i co 2 bity byłyby wykonywane przez procesor, zaś wynik zapisywany byłby w pamięci CHIP. Po przekonwertowaniu całego bufora (lub jego części) do pracy zaprzęgnięty byłby Blitter (synchronicznie lub asynchronicznie). Wykonałby on ostatni etap konwersji, czyli łączenie parzystych i nieparzystych pikseli.
To co robiłby procesor mieściłoby się w cache 256 bajtów. Zatem zysk byłby podwójny.
Jest to trochę inne rozwiązanie niż dotąd stosowane, gdzie Blitter konwertuje połowę ekranu.
Będę nad tym pracował. Jeśli macie coś to piszcie.
Z tego co przeczytałem warto, gdy pętla wykonywana przez procesor mieściła się w cache procesora. Dla 68020 jest to 256 bajtów. Wtedy taka pętla jest ładowana w całości do cache i tam wykonywana. Jak jednak skrócić pętlę?
Otóż można wspomóc się Blitterem. Jak wiadomo może on robić konwersję C2P. Mój pomysł polega na tym, że podział i łączenie co 4 i co 2 bity byłyby wykonywane przez procesor, zaś wynik zapisywany byłby w pamięci CHIP. Po przekonwertowaniu całego bufora (lub jego części) do pracy zaprzęgnięty byłby Blitter (synchronicznie lub asynchronicznie). Wykonałby on ostatni etap konwersji, czyli łączenie parzystych i nieparzystych pikseli.
To co robiłby procesor mieściłoby się w cache 256 bajtów. Zatem zysk byłby podwójny.
Jest to trochę inne rozwiązanie niż dotąd stosowane, gdzie Blitter konwertuje połowę ekranu.
Będę nad tym pracował. Jeśli macie coś to piszcie.
16.11.2015 17:27
[#77]
Re: Nowa, szybka konwersja chunky-to-planar
@kiero, post #75
Procedury c2p Kalmsa, sa dobre jedynie dla 68060, ale i tak nie sa najszybsze. Najwieksze roznice w szybkosci sa na 68030, rzedu kilkudziesieciu procent. Potem dla 68040, a najmniejsze dla 68060. Pomysl Kalmsa zostal zoptymalizowany, chociazby przez meynafa (dla 68030) czy Jima Drew. Moje przerobki, tez sa szybsze szczegolnie dla 68040. Testy szybkosci tej nowej c2p mozna w prosty sposob zrobic, podmieniajac jakas rutynke w zrodlach z EAB. Ja sie nie spodziewam dobrych wynikow tej procedury, gdyz to wymaga odpowiedniego umieszczenia zapisow do chipu i odczytu z fastu.
16.11.2015 20:07
[#80]
Re: Nowa, szybka konwersja chunky-to-planar
@Don_Adan, post #77
Tia, uproscilem. Nie chcialem juz sie tutaj rozwodzic a dla 060 jestesmy na etapie praktycznie niemierzalnych roznic (060 jest ograniczone przez predkosc chip, nie przez predkosc c2p). Ogolnie chodzi o zasade i o to, ze ten temat jest mocno wyeksploatowany i sa gotowe rozwiazania po ktore wystarczy siegnac...
Ostatnia aktualizacja: 16.11.2015 20:19:03 przez kiero
Ostatnia aktualizacja: 16.11.2015 20:19:03 przez kiero
16.11.2015 20:13
[#81]
Re: Nowa, szybka konwersja chunky-to-planar
@kiero, post #80
To ja wrzucę komentarz Ostera, który oczywiście potwierdza to co mówi Kiero:
"Nigdy nie robiłem porównania wydajnosci . Myślę, ze jezeli chodzi o ilość samych transformacji, to jestesmy blisko optimum i nie ma co tu za dużo mieszać bo uzysk nie bedzie istotny.. Zresztą tak jak ktoś mądry pisze w tym watku, największym ograniczeniem jest szybkość chip ramu. Dlatego w tych wersjach na 040 w górę, zapisy do chip ram są tak poprzestawiane żeby mogły się wykonać w ich "cieniu" jakieś inne instrukcje przed kolejnym zapisem do chip (muszą one być od siebie jak najbardziej oddalone). Dodatkowo kolejność instrukcji jest tak ustawiona, zeby unikać sąsiadujących odwołań do tych samych rejestrów (superskalarność na 060 jest i trzeba to wykorzystywać).
Jednak to wszystko to i tak za mało - chip ram rozwala całkowicie wydajność.
Miałem tutaj kilka dość karkołomnych pomysłów, np.
- C2P robić do fast, a nastepnie przepisywac po kawałku do chip w czasie kiedy procesor robi coś innego, np. liczy scenę lub cokolwiek innego, za pomoca jakiejś procedury działającej np. w przerwaniu, itd.. Ale trzeba by dokładnie zbadać jaki by to miało wpływ na wydajnosc żeby coś sensownego powiedzieć.
- Można to zoptymalizować o kopiowanie do chip tylko regionów które się zmieniły od ostatniej ramki, ale w demie które ma pełnoekranowe pikselowe efekty najczęściej zmienia się 100% bufora, wiec tutaj też uzysk dyskusyjny...
- W zasadzie wszystkie współczesne podejścia powinny się koncentrować jak maksymalnie szybko przepisać coś z fast do chip - tu jest potencjał. O czym ludzie w temacie doskonale wiedzą.
- Ktoś w wątku pisze o wykorzystaniu MMU - trudno powiedzieć czy to właściwy trop, trzeba by pokombinować.
Cały czas mamy jedną ciekawą rzecz, która była innowacyjna przy ograniczeniach A500, a mianowicie wersję z ditheringien skali szarości 256 -> 16 kolorów. Było nawet intro z tym ;)
Temat C2P jest maksymalnie wyeksploatowany - nie sądzę żeby jakiś przełom miał się tutaj urodzić, bo czysta matematyka i architektura chip vs fast na to nie pozwala."
"Nigdy nie robiłem porównania wydajnosci . Myślę, ze jezeli chodzi o ilość samych transformacji, to jestesmy blisko optimum i nie ma co tu za dużo mieszać bo uzysk nie bedzie istotny.. Zresztą tak jak ktoś mądry pisze w tym watku, największym ograniczeniem jest szybkość chip ramu. Dlatego w tych wersjach na 040 w górę, zapisy do chip ram są tak poprzestawiane żeby mogły się wykonać w ich "cieniu" jakieś inne instrukcje przed kolejnym zapisem do chip (muszą one być od siebie jak najbardziej oddalone). Dodatkowo kolejność instrukcji jest tak ustawiona, zeby unikać sąsiadujących odwołań do tych samych rejestrów (superskalarność na 060 jest i trzeba to wykorzystywać).
Jednak to wszystko to i tak za mało - chip ram rozwala całkowicie wydajność.
Miałem tutaj kilka dość karkołomnych pomysłów, np.
- C2P robić do fast, a nastepnie przepisywac po kawałku do chip w czasie kiedy procesor robi coś innego, np. liczy scenę lub cokolwiek innego, za pomoca jakiejś procedury działającej np. w przerwaniu, itd.. Ale trzeba by dokładnie zbadać jaki by to miało wpływ na wydajnosc żeby coś sensownego powiedzieć.
- Można to zoptymalizować o kopiowanie do chip tylko regionów które się zmieniły od ostatniej ramki, ale w demie które ma pełnoekranowe pikselowe efekty najczęściej zmienia się 100% bufora, wiec tutaj też uzysk dyskusyjny...
- W zasadzie wszystkie współczesne podejścia powinny się koncentrować jak maksymalnie szybko przepisać coś z fast do chip - tu jest potencjał. O czym ludzie w temacie doskonale wiedzą.
- Ktoś w wątku pisze o wykorzystaniu MMU - trudno powiedzieć czy to właściwy trop, trzeba by pokombinować.
Cały czas mamy jedną ciekawą rzecz, która była innowacyjna przy ograniczeniach A500, a mianowicie wersję z ditheringien skali szarości 256 -> 16 kolorów. Było nawet intro z tym ;)
Temat C2P jest maksymalnie wyeksploatowany - nie sądzę żeby jakiś przełom miał się tutaj urodzić, bo czysta matematyka i architektura chip vs fast na to nie pozwala."
16.11.2015 21:06
[#84]
Re: Nowa, szybka konwersja chunky-to-planar
@selur, post #38
Jak sie teraz zabierzesz za "pisanie Doom'a", to reszta tych projektow, ktore juz zaczales nigdy nie bedzie miala szansy na realizacje
Fakt. :) Tym bardziej, że od procedurki c2p do grywalnego Dooma (czy choćby Wolfensteina) jest tak daleko jak od przedszkola do emerytury. :) Większość "Doomów na Amigę" skończyła na etapie sensownego rysowania ścian i podłóg. Coś co na pierwszy rzut oka wydaje się 90% gry w rzeczywistości nie jest nawet 5%.
16.11.2015 21:16
[#85]
Re: Nowa, szybka konwersja chunky-to-planar
@kiero, post #83
Ja nie mam 68060 do testow, wiec optymalizowalem glownie pod 68040, gdzie udalo sie osiagnac okolo 80% szybkosci kopiowania z fastu do chipu dla 68040. Ktores z testowych wersji byly z kolei szybsze niz samo kopiowanie z chipu do fastu na 68060, co przynajmniej w teorii nie jest mozliwe, ale moze obsluga data cache w 68060 byla tego przyczyna. Sama procedura Jima Drew do obliczania szybkosci jest ciekawa i moze byc uzywana do wyliczenia szybkosci kazdej procedury czy zmian w tej procedurze, po prostu wystarczy podmienic kod na wlasny, albo dodac nowy test do istniejacych. Ja czesto jej uzywalem wlasnie do obliczen szybkosci procedury po optymalizacji.
16.11.2015 21:19
[#86]
Re: Nowa, szybka konwersja chunky-to-planar
@Don_Adan, post #85
"Ktores z testowych wersji byly z kolei szybsze niz samo kopiowanie z chipu do fastu na 68060, co przynajmniej w teorii nie jest mozliwe, ale moze obsluga data cache w 68060 byla tego przyczyna"
Breaking copyspeed for c2p
Dokładnie obsługa datacache. Podobno zależy też od karty na której działa kod. Taka ciekawostka;)
Breaking copyspeed for c2p
Dokładnie obsługa datacache. Podobno zależy też od karty na której działa kod. Taka ciekawostka;)
16.11.2015 21:48
[#89]
Re: Nowa, szybka konwersja chunky-to-planar
Moim targetem będą słabsze Amigi (020/030). Czyli podstawowe cele: użyć cache procesora (256 bajtów) oraz użyć Blittera.