16.03.2020 21:55
[#184]
Re: Akiko 32
@Hexmage960, post #147
Napiszę jeszcze o dwóch fajnych technikach w Amidze, które mogą pomóc w obróbce grafiki Chunky - z Akiko lub bez:
1. Od procesora MC68020 wzwyż wprowadzono pola bitowe. Można wyciągnąć (extract) lub włożyć (insert) dowolne przedziały bitowe. Może to być wręcz zbawienne dla danych chunky, które są upakowane w rejestry 32-bitowe.
Przykład: jak mamy w 32-bitowym rejestrze 8 pikseli 4-bitowych, to możemy wyjąć dowolny piksel (lub piksele) jedną operacją CPU:
Gdzie offset to początek pola bitowego, a width to jego szerokość (tutaj 4). Przykładowo, jak chcemy wyciągnąć piksel 4-bitowy na offsecie 8-11 to piszemy:
Oczywiście możemy wyciągać paczki wielu pikseli. Np. dla offsetu 4-27:
Pola bitowe są dość kosztowne, ale na dłuższą metę mogą skrócić znakomicie dostęp do wybranych pikseli, bo nie trzeba robić kilku instrukcji: przesuw bitowy, skopiowanie i maska.
Można też umieszczać dowolne wartości w polach bitowych instrukcją BFINS. Przykładowo poniższa instrukcja na powrót umieści wartość w polu bitowym:
2. Można traktować bitplany jako bity w liczbie i dokonywać dowolnych operacji logicznych lub arytmetycznych na tych bitach, co skutkuje szybkimi operacjami na obszarach bitmap.
Przykładowo jeżeli chcemy dodać wartość 1 do wybranych 32 pikseli można to zrobić za pomocą krótkiej pętli iterowanej po bitplanach. Dla każdego bitplanu mamy jeden odczyt i zapis.
Liczymy po prostu sumę (operacja EOR) i przeniesienie (operacja AND).
To tylko poglądowy przykład i można go rozwijać.
1. Od procesora MC68020 wzwyż wprowadzono pola bitowe. Można wyciągnąć (extract) lub włożyć (insert) dowolne przedziały bitowe. Może to być wręcz zbawienne dla danych chunky, które są upakowane w rejestry 32-bitowe.
Przykład: jak mamy w 32-bitowym rejestrze 8 pikseli 4-bitowych, to możemy wyjąć dowolny piksel (lub piksele) jedną operacją CPU:
BFEXTU <ea>{offset:width},DnGdzie offset to początek pola bitowego, a width to jego szerokość (tutaj 4). Przykładowo, jak chcemy wyciągnąć piksel 4-bitowy na offsecie 8-11 to piszemy:
BFEXTU D0{8:4},D1Oczywiście możemy wyciągać paczki wielu pikseli. Np. dla offsetu 4-27:
BFEXTU D0{4:24},D1Pola bitowe są dość kosztowne, ale na dłuższą metę mogą skrócić znakomicie dostęp do wybranych pikseli, bo nie trzeba robić kilku instrukcji: przesuw bitowy, skopiowanie i maska.
Można też umieszczać dowolne wartości w polach bitowych instrukcją BFINS. Przykładowo poniższa instrukcja na powrót umieści wartość w polu bitowym:
BFINS D1,{4:24}D02. Można traktować bitplany jako bity w liczbie i dokonywać dowolnych operacji logicznych lub arytmetycznych na tych bitach, co skutkuje szybkimi operacjami na obszarach bitmap.
Przykładowo jeżeli chcemy dodać wartość 1 do wybranych 32 pikseli można to zrobić za pomocą krótkiej pętli iterowanej po bitplanach. Dla każdego bitplanu mamy jeden odczyt i zapis.
Liczymy po prostu sumę (operacja EOR) i przeniesienie (operacja AND).
To tylko poglądowy przykład i można go rozwijać.
; Dodanie 1 do wartości 32 pikseli: ; D6: Szerokość linii w bajtach MOVEQ #-1,D0 ; Wejściowe przeniesienie (Carry) CLR.W D3 ; Przesunięcie do bitplanu CLR.B D4 ; Numer bitplanu MOVEQ #8,D5 ; Liczba bitplanów .nastBitplan: MOVE.L (A0,D3.W),D1 ; Odczyt pikseli z bitplanu MOVE.L D1,D2 EOR.L D0,D1 ; Zastosowanie przeniesienia MOVE.L D1,(A0,D3.W) ; Zapis AND.L D2,D0 ; Nowe przeniesienie ADDI.W D6,D3 ; Przejście do nast. bitplanu ADDQ.B #1,D4 CMP.B D5,D4 BLT.S .nastBitplan RTS ;Tabelka: ; A Carry A+C Nowe Carry ; 0 0 0 0 ; 0 1 1 0 ; 1 0 1 0 ; 1 1 0 1 ;
17.03.2020 08:23
[#187]
Re: Akiko 32
@sanjyuubi, post #183
Np musetcachemode z mmulib. Przykład z
https://www.exxoshost.co.uk/forum/viewtopic.php?f=70&t=1875&start=20
musetcachemode ADDRESS B80000 SIZE 80000 CACHEINHIBIT
https://www.exxoshost.co.uk/forum/viewtopic.php?f=70&t=1875&start=20
musetcachemode ADDRESS B80000 SIZE 80000 CACHEINHIBIT
17.03.2020 23:47
[#188]
Re: Akiko 32
@sanjyuubi, post #179
Nawiązując do wcześniejszego wątku o akiko - mały cytat posta Skolman'a
Mój konfig: Amiga CD32 SX32 Pro 030/50, 68882/50, Fast 64 MB
Poniżej macie wyniki moich wypocin:
1. Sysinfo DataCache właczone
2.DataCache właczony c2p 020
3.DataCache włączony c2p 030
4.SysInfo DataCache wyłączone
5.NoDataCache c2p Akiko
Co prawda odpalając grę z powyższymi ustawieniami, nie widzę zbytniej różnicy pomiędzy 030 z data cache a akiko bez data cache.
Tym niemniej cyferki jakie są każdy widzi i może wyciągać swoje wnioski.
Ostatnia aktualizacja: 17.03.2020 23:49:34 przez mikecios
c2p Gloom 1x1 256 kol.
68020/14 - 61.6 ms
68020/14+fast - 54.6 ms
68020/14+akiko - 24.2 ms
68030/50+fast - 21.7 ms
68040/25+fast - 18.6 ms
68020/14+fast+akiko - 17.6 ms
Mój konfig: Amiga CD32 SX32 Pro 030/50, 68882/50, Fast 64 MB
Poniżej macie wyniki moich wypocin:
1. Sysinfo DataCache właczone
2.DataCache właczony c2p 020
3.DataCache włączony c2p 030
4.SysInfo DataCache wyłączone
5.NoDataCache c2p Akiko
Co prawda odpalając grę z powyższymi ustawieniami, nie widzę zbytniej różnicy pomiędzy 030 z data cache a akiko bez data cache.
Tym niemniej cyferki jakie są każdy widzi i może wyciągać swoje wnioski.
Ostatnia aktualizacja: 17.03.2020 23:49:34 przez mikecios
18.03.2020 09:39
[#190]
Re: Akiko 32
@sanjyuubi, post #189
Sprawdziłem. Faktycznie teraz nie trzeba w Gloomie wyłączać z palca datacache.
Po wybraniu c2p akiko gra odpala normalnie :>
Tak jak pisalem wcześniej, "na oko" nie widzę żadnej różnicy w dzialaniu gry.
Co wiecej , teraz timec2p akiko, pokazuje wynik o parę microsekund gorszy niż przy wczesniejszym wylaczaniu datacache'u.
Po wybraniu c2p akiko gra odpala normalnie :>
Tak jak pisalem wcześniej, "na oko" nie widzę żadnej różnicy w dzialaniu gry.
Co wiecej , teraz timec2p akiko, pokazuje wynik o parę microsekund gorszy niż przy wczesniejszym wylaczaniu datacache'u.
18.03.2020 10:59
[#192]
Re: Akiko 32
@RokiS, post #191
Ano cały.
Tak więc nie wiem co o tym myśleć ;)
Czyżby oryginalne akiko faktycznie dawało radę w 020 ?
Bo taki powoli mi się wniosek nasuwa.
W takim przypadku Amigą którą najlepiej by korzystała z akiko byłaby CD32 turbo 020/33 mhz plus fast.
Ostatnia aktualizacja: 18.03.2020 10:59:45 przez mikecios
Tak więc nie wiem co o tym myśleć ;)
Czyżby oryginalne akiko faktycznie dawało radę w 020 ?
Bo taki powoli mi się wniosek nasuwa.
W takim przypadku Amigą którą najlepiej by korzystała z akiko byłaby CD32 turbo 020/33 mhz plus fast.
Ostatnia aktualizacja: 18.03.2020 10:59:45 przez mikecios
18.03.2020 11:11
[#193]
Re: Akiko 32
@mikecios, post #192
Na pewno ustaliliśmy, żę AKIKO ma problem z DATA CACHE.
NIestety, ten typ CACHE, a raczej jego brak, mocno wypływa na szybkość procków od 030 w górę.
Natomiast, jeśli ktoś ma 040 i ponownie zrobi ten test, także z wyłączonym DATA, a mimo to będzie szybciej, to sądzę żę AKIKO jako takie nie spowalnia procka i nadal pomaga w konwersji.
Taką mam teorię.. i tak wiem, że te procki same mogą szybciej wykonać c2p, ale chodzi o analizę.
Ostatnia aktualizacja: 18.03.2020 11:23:01 przez marianoamigo
NIestety, ten typ CACHE, a raczej jego brak, mocno wypływa na szybkość procków od 030 w górę.
Natomiast, jeśli ktoś ma 040 i ponownie zrobi ten test, także z wyłączonym DATA, a mimo to będzie szybciej, to sądzę żę AKIKO jako takie nie spowalnia procka i nadal pomaga w konwersji.
Taką mam teorię.. i tak wiem, że te procki same mogą szybciej wykonać c2p, ale chodzi o analizę.
Ostatnia aktualizacja: 18.03.2020 11:23:01 przez marianoamigo
18.03.2020 11:57
[#198]
Re: Akiko 32
@RokiS, post #197
Na sys info biorę poprawkę. Od 96r co rusz mi inaczej pokazuje mipsy, raz więcej raz mniej ;)
Dotatkowo jako smiechawostke mogę dodać że mam wrażenie, że po założeniu wiatraka w cd32, gdy procek nie jest obciążony a non stop chłodzony powietrzem, to jego wydajnosc obniza sie - patrząc na sysinfo wlasnie :>
Ale gdy go czyms mocniej obciaze np adp4 44khz stereo, wydajnosc wraca do normy
Taki underclocking troche ;)
Dotatkowo jako smiechawostke mogę dodać że mam wrażenie, że po założeniu wiatraka w cd32, gdy procek nie jest obciążony a non stop chłodzony powietrzem, to jego wydajnosc obniza sie - patrząc na sysinfo wlasnie :>
Ale gdy go czyms mocniej obciaze np adp4 44khz stereo, wydajnosc wraca do normy
Taki underclocking troche ;)
18.03.2020 12:08
[#199]
Re: Akiko 32
@mikecios, post #198
Zgadzam się że sysinfo nie mam wiarygodnych testów- drobne chwilowe odchyłki ma -ale jak się test powtórzy kilka razy i też po kilku restach Amigi wynik nie wraca do "normy" to chyba różnica jest.
Po za tym gdzieś w necie były testy / wnioski że uruchomienie mmu powoduje zmniejszenie wydajności procka - przynajmniej na 030 (taki procek mnie interesuje bo taki jest na tf330 ).
Po za tym gdzieś w necie były testy / wnioski że uruchomienie mmu powoduje zmniejszenie wydajności procka - przynajmniej na 030 (taki procek mnie interesuje bo taki jest na tf330 ).
18.03.2020 12:48
[#203]
Re: Akiko 32
@mikecios, post #201
Jemu chodzi o mmu.library ktore spowalnia a nie o same MMU. U mnie tez duzo spowalnialo dzialanie 68040 pod systemem. Dlatego mmu.library nie uzywam. W porownaniu z innymi 68040.library te od Thora jest duzo wolniejsze. Nie wiem co on tam az tak namieszal albo przedobrzyl. Ale to jest zdecydowanie do poporawy, tym bardziej, ze niby jest chyba obowiazkowe od kicku 3.1.4 wzwyz.
18.03.2020 15:58
[#206]
Re: Akiko 32
@BULI, post #205
Zatem kłania się teoria konkurencyjna do kwantowej, czyli Zmiennych Ukrytych. ;)
19.03.2020 07:57
[#210]
Re: Akiko 32
@mikecios, post #207
To się trochę kupy nie trzyma, że w uruchomionym systemie mogłeś sobie skonfigurować coś przez MMU bezkolizyjnie, a podczas startu jakieś cuda na kiju nagle wyskakują i fajnie, że komunikat jest ucięty, chyba ktoś wziął słowo "doszlifować" program zbyt dosłownie.
Ostatnia aktualizacja: 19.03.2020 07:59:17 przez sanjyuubi
Ostatnia aktualizacja: 19.03.2020 07:59:17 przez sanjyuubi