Komentowana treść: Nowa, szybka konwersja chunky-to-planar
18.11.2015 21:09
[#121]
Re: Nowa, szybka konwersja chunky-to-planar
@strim_, post #120
Dzięki strim. No właśnie do wczoraj go nie znałem :). Po prawdzie trochę tylko przejrzałem go.
W User's Manual dla 68020 zastanawia mnie w przykładach podpunkt 3. Memory access occurs with no wait states. . Nie wiem czy dobrze rozumiem, bo w 68000 z prędkością do 8mhz nie ma wait states (gdzieś to chyba w necie wyczytałem ), ale już dla 68000 z 10mhz już wait state się pojawia. To wtedy o ile cykli wydłuża się instrukcja ?
Fajnie by było jakby te komentarze przenieść do działu programowania. Tak sobie myśle.
W User's Manual dla 68020 zastanawia mnie w przykładach podpunkt 3. Memory access occurs with no wait states. . Nie wiem czy dobrze rozumiem, bo w 68000 z prędkością do 8mhz nie ma wait states (gdzieś to chyba w necie wyczytałem ), ale już dla 68000 z 10mhz już wait state się pojawia. To wtedy o ile cykli wydłuża się instrukcja ?
Fajnie by było jakby te komentarze przenieść do działu programowania. Tak sobie myśle.
19.11.2015 00:40
[#122]
Re: Nowa, szybka konwersja chunky-to-planar
@juen, post #118
Pamiętajmy, że podstawowym celem testów tej procedury jest wykazanie na ile zmieszczenie procedury w cache procesora przekłada się na efektywność. Czy to będzie 1x1, czy 320x256, czy tworzenie 16 pikseli w przejściu pętli, czy nawet zupełnie inny algorytm (bez mapowania itp.) liczy się pewien stosunek a nie konkretna wartość.
Jeśli chodzi o mapowanie to teraz część operacji na pikselach (nie wszystkie) wymaga zajrzenia do 16-bajtowej tablicy celem znalezienia właściwej pozycji danego piksela.
Zatem jak mamy przykładowo skopiować prostokątny obszar, to dla każdej współrzędnej X odnajdujemy odpowiednie miejsce. Jest to jedna instrukcja procesora. Jeśli w d0 mamy pozycję X, w a1 tablicę to piszemy:
move.b (a1,d0),d0
by wyłuskać prawdziwą pozycję dla X. Koszt to 12 cykli procesora.
Myślę, że w praktyce nie trzeba będzie patrzeć do tablicy dla każdej pozycji X.
Na przykład należy zajrzeć zaledwie raz dla każdego pionowego bloku pikseli.
Zatem koszt mapowania to funkcja szerokości bloku, a nie pola bloku. Jest to bardzo ważne. Jak kopiujemy blok 320x200 to koszt mapowania jest proporcjonalny do szerokości, czyli 320 pikseli.
Ostatnia aktualizacja: 19.11.2015 00:55:38 przez Hexmage960
Jeśli chodzi o mapowanie to teraz część operacji na pikselach (nie wszystkie) wymaga zajrzenia do 16-bajtowej tablicy celem znalezienia właściwej pozycji danego piksela.
Zatem jak mamy przykładowo skopiować prostokątny obszar, to dla każdej współrzędnej X odnajdujemy odpowiednie miejsce. Jest to jedna instrukcja procesora. Jeśli w d0 mamy pozycję X, w a1 tablicę to piszemy:
move.b (a1,d0),d0
by wyłuskać prawdziwą pozycję dla X. Koszt to 12 cykli procesora.
Myślę, że w praktyce nie trzeba będzie patrzeć do tablicy dla każdej pozycji X.
Na przykład należy zajrzeć zaledwie raz dla każdego pionowego bloku pikseli.
Zatem koszt mapowania to funkcja szerokości bloku, a nie pola bloku. Jest to bardzo ważne. Jak kopiujemy blok 320x200 to koszt mapowania jest proporcjonalny do szerokości, czyli 320 pikseli.
Ostatnia aktualizacja: 19.11.2015 00:55:38 przez Hexmage960
20.11.2015 01:01
[#123]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #122
Uznawszy, że mapowanie po osi X nie jest wystarczająco naturalne (można polemizować, ponieważ mapowanie po Y jest nawet na liniowych danych) napisałem nową procedurkę, w założeniu ma mieścić się w 256 bajtach.
A teraz własności, które procedura już posiada:
Nie udało mi się takiej procedury zmieścić (jeszcze) w 256 bajtach (choć jest bardzo blisko). Do tego jeszcze ma błędy. Jak naprawię błędy i przetestuję to opublikuję. Może wtedy koledzy poradzą jak zmniejszyć rozmiar.
Jeśli nie uda mi się tego zmieścić to trzeba będzie pójść na kompromis. Rozważam jedną z pięciu opcji (jedna wystarczy by zmieścić już teraz):
Ciekawy jestem, jaki wpływ ma każdy z tych czynników na szybkość procedury.
Muszę przyznać, że użyte w moich dotychczasowych procedurach nieliniowe ułożenie pikseli jest szalenie wygodne i łatwo się taki c2p pisze. Koszt naprawdę zależy liniowo od szerokości, zaś wyłuskiwanie pozycji X może wyglądać tak:
lea tablica(pc,d0),a0
move.b (a0)+,d0
; zapisujemy kolumnę
move.b (a0)+,d0
; zapisujemy kolumnę
Jak myślicie, zostawić to mapowanie po osi X?
No bo mapowanie po Y występuje, wszak każda bitmapa jest pogrupowana na wiersze o np. 320 pikselach szerokości. No i łatwiej będzie mi pisać takie c2p.
Ostatnia aktualizacja: 20.11.2015 01:16:52 przez Hexmage960
A teraz własności, które procedura już posiada:
- Liniowe dane chunky
- 1x1
- zapis 32-bitowy do CHIP-RAM
Nie udało mi się takiej procedury zmieścić (jeszcze) w 256 bajtach (choć jest bardzo blisko). Do tego jeszcze ma błędy. Jak naprawię błędy i przetestuję to opublikuję. Może wtedy koledzy poradzą jak zmniejszyć rozmiar.
Jeśli nie uda mi się tego zmieścić to trzeba będzie pójść na kompromis. Rozważam jedną z pięciu opcji (jedna wystarczy by zmieścić już teraz):
- zapis 8- lub 16-bitowy do CHIP RAM
- zapis do FAST
- 2x1
- Nieliniowe dane
- Procedura >256 bajtów
Ciekawy jestem, jaki wpływ ma każdy z tych czynników na szybkość procedury.
Muszę przyznać, że użyte w moich dotychczasowych procedurach nieliniowe ułożenie pikseli jest szalenie wygodne i łatwo się taki c2p pisze. Koszt naprawdę zależy liniowo od szerokości, zaś wyłuskiwanie pozycji X może wyglądać tak:
lea tablica(pc,d0),a0
move.b (a0)+,d0
; zapisujemy kolumnę
move.b (a0)+,d0
; zapisujemy kolumnę
Jak myślicie, zostawić to mapowanie po osi X?
No bo mapowanie po Y występuje, wszak każda bitmapa jest pogrupowana na wiersze o np. 320 pikselach szerokości. No i łatwiej będzie mi pisać takie c2p.
Ostatnia aktualizacja: 20.11.2015 01:16:52 przez Hexmage960
20.11.2015 01:36
[#124]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #123
Jak myślicie
Ja się nie znam, ale myślę że to całe teoretyzowanie ma tylko taki efekt, jakby jakiś inżynier na papierze opracowywał turbo do Syrenki i zastanawiał się czy iść do zimnego garażu i modyfikować silnik, czy jednak woli przeżyć przygodę wirtualną w ciepłym pokoju i w kapciach (coś na zasadzie dobrej książki przygodowej lub detektywistycznej).
Jeżeli w tym c2p nie chodzi o szybszy port Dooma, to nie rozumiem o co chodzi.
U mnie Doom na 040/40 i AGA, działa 16 klatek w wymagających lokacjach. Czasami, miejscowo podskoczy nawet do 36 klatek.
Zastanawiam się ile twoje c2p przyspieszy Dooma na mojej A1200?
20.11.2015 01:38
[#125]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #123
Nie mogę już edytować. Myślę, że najlepszym rozwiązaniem będzie jak zintegruję mapowanie z moją procedurą c2p.
A mapowanie wygląda naprawdę prosto:
lea chunky,a0
move.w #3,d4
.map:
lsl.l #8,d0
lsl.l #8,d1
lsl.l #8,d2
lsl.l #8,d3
move.b (a0)+,d0 ; 0 4 8 12
move.b (a0)+,d1 ; 1 5 9 13
move.b (a0)+,d2 ; 2 6 10 14
move.b (a0)+,d3 ; 3 7 11 15
dbf d4,.map
A mapowanie wygląda naprawdę prosto:
lea chunky,a0
move.w #3,d4
.map:
lsl.l #8,d0
lsl.l #8,d1
lsl.l #8,d2
lsl.l #8,d3
move.b (a0)+,d0 ; 0 4 8 12
move.b (a0)+,d1 ; 1 5 9 13
move.b (a0)+,d2 ; 2 6 10 14
move.b (a0)+,d3 ; 3 7 11 15
dbf d4,.map
20.11.2015 07:23
[#129]
Re: Nowa, szybka konwersja chunky-to-planar
@WojT_GL, post #128
Hej! Przecież dążę do bardziej miarodajnych testów.
Moje procedury wymagają specyficznego układu pikseli, więc poproszono mnie o uwzględnienie tego w czasie wykonania, co też czynię. Poproszono mnie też o uwzględnienie zapisu do CHIP w czasie wykonania to również czynię.
Moje procedury wymagają specyficznego układu pikseli, więc poproszono mnie o uwzględnienie tego w czasie wykonania, co też czynię. Poproszono mnie też o uwzględnienie zapisu do CHIP w czasie wykonania to również czynię.
20.11.2015 07:54
[#131]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #129
Hej! Przecież dążę do bardziej miarodajnych testów.
Nie dążysz, bo nie zrobiłeś żadnego pomiaru. Skutek jest taki, że nas pytasz jaki jest wpływ takiego czy innego elementu procedury na szybkość. Gdybyś zaczął od opomiarowania procedury, nie musiałbyś zadawać takich pytań bo wiedziałbyś. Zabawa kodem jest przyjemna, ale bez konfrontacji z rzeczywistością (czyli wynikami pomiarów) i porównania tych pomiarów z wynikami innych rozwiązań – bezużyteczna.
Nie dążysz, bo nie zrobiłeś żadnego pomiaru. Skutek jest taki, że nas pytasz jaki jest wpływ takiego czy innego elementu procedury na szybkość. Gdybyś zaczął od opomiarowania procedury, nie musiałbyś zadawać takich pytań bo wiedziałbyś. Zabawa kodem jest przyjemna, ale bez konfrontacji z rzeczywistością (czyli wynikami pomiarów) i porównania tych pomiarów z wynikami innych rozwiązań – bezużyteczna.
20.11.2015 08:02
[#132]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #130
No to wstaw swoje c2p do tego AWolfa do którego na początku podawałem link i będzie widać ile robi fps.
AWolf 0.7 AGA BPPC 68060 66MHz
https://youtu.be/i_LVPvbQAgA
AWolf 0.7 AGA BPPC 68060 66MHz
https://youtu.be/i_LVPvbQAgA
20.11.2015 08:08
[#133]
Re: Nowa, szybka konwersja chunky-to-planar
@Krashan, post #131
W poście #115 załączyłem gotowy, działający szablon testujący.
Przed chwilą zrobiłem na szybko pomiar samej konwersji pikseli do wymaganego formatu (algorytm z postu #125). Teraz moja procedura będzie akceptować liniowe dane chunky zatem można ją porównywać bezpośrednio z innymi procedurami C2P.
Użyłem szablonu testu z postu #115.
Dla ekranu 320x256 wychodzi mi raz 1,5 ms, a raz 0,5 ms.
W kolejności będę, tak jak pisałem - integrować tą konwersję z moją procedurą C2P, żeby uzyskać test, którego wyniki można porównywać z innymi procedurami C2P.
Przed chwilą zrobiłem na szybko pomiar samej konwersji pikseli do wymaganego formatu (algorytm z postu #125). Teraz moja procedura będzie akceptować liniowe dane chunky zatem można ją porównywać bezpośrednio z innymi procedurami C2P.
Użyłem szablonu testu z postu #115.
Dla ekranu 320x256 wychodzi mi raz 1,5 ms, a raz 0,5 ms.
W kolejności będę, tak jak pisałem - integrować tą konwersję z moją procedurą C2P, żeby uzyskać test, którego wyniki można porównywać z innymi procedurami C2P.
20.11.2015 08:21
[#134]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #133
Jak nie lubisz Wolfa to DoomAttack ma zewnętrzne procedury c2p na aminecie są źródła, albo Gloom/Dx blackmagic_1.s tester procedur Glooma też jest na aminecie. Na 060 66MHz z c2p 040_1 w 8bit width:1 mam 8.5 ms, w 6bit EHB 6.2 ms.
Ostatnia aktualizacja: 20.11.2015 08:33:24 przez ] SKOLMAN_MWS ˇ agrEssOr [
Ostatnia aktualizacja: 20.11.2015 08:33:24 przez ] SKOLMAN_MWS ˇ agrEssOr [
20.11.2015 08:43
[#137]
Re: Nowa, szybka konwersja chunky-to-planar
@] SKOLMAN_MWS ˇ agrEssOr [, post #134
Eksperymentowałem z Gloomem dawniej, zanim jeszcze pojąłem ideę C2P. Dostosowanie C2P do Glooma to trochę pracy jest. Wiem, że wiele osób oczekuje od razu testów a'la Doom, ale proszę zauważyć, że to nie takie proste. Na razie chcę zrobić procedurę, która ma zintegrowaną wymaganą przez moją C2P obsługę liniowo ułożonych danych chunky, żeby rozpocząć porównywanie pomiarów. Jeśli ktoś zechce zrobić test z Doomem droga wolna - kod będzie dostępny publicznie.
20.11.2015 08:59
[#138]
Re: Nowa, szybka konwersja chunky-to-planar
@juen, post #135
Tak, na 060 nie testowałem dotychczasowych wyników pracy. Mam A1200 z 68060 w obudowie Tower ale musiałbym zrobić jej miejsce na biurku. :)
Choć z dyskusji wynikło, że optymalizacja dla 060 to zupełnie inna para kaloszy niż mieszczenie w cache 256 bajtów.
@Fazior
Zgadza się.
Choć z dyskusji wynikło, że optymalizacja dla 060 to zupełnie inna para kaloszy niż mieszczenie w cache 256 bajtów.
@Fazior
Zgadza się.
20.11.2015 22:02
[#142]
Re: Nowa, szybka konwersja chunky-to-planar
@hrw, post #141
Breathless był ładny graficznie ale technicznie nie najbardziej zaawansowaną "doomowanką". Nie wiem dlaczego tak mało osób zauważało na przykład to, że w Breathless nie ma ukośnych ścian. Wszystkie są ustawione względem siebie pod kątem 90 stopni. Nie wiem jaki był tego powód. Bardzo możliwe, że chodziło o to żeby kolizje ze ścianami były do bólu proste (a przez to nie obciążały i tak ledwo dyszącego przy tym zadaniu procesora).
Ostatnia aktualizacja: 20.11.2015 22:06:51 przez MDW
Nie wiem jaki był tego powód. Bardzo możliwe, że chodziło o to żeby kolizje ze ścianami były do bólu proste (a przez to nie obciążały i tak ledwo dyszącego przy tym zadaniu procesora).Ostatnia aktualizacja: 20.11.2015 22:06:51 przez MDW
21.11.2015 03:12
[#143]
Re: Nowa, szybka konwersja chunky-to-planar
@hrw, post #141
prawie umarłem ze śmiechu
No, jak każda wstrętna pecetowca, którą zżarła nostalgia i gdy dotarła do bezsensu swojej kariery na pececie, to teraz będzie nam sugerowała morały na tym portalu.
Spadaj dziadu! Niechaj cię doomowy cacodemon opluje!.
No i jak można grać kilka lat w Dooma? Ale schizmen!
21.11.2015 11:47
[#144]
Re: Nowa, szybka konwersja chunky-to-planar
heh, kurcze, chyba nie jest tak źle z amigowym światem, jeśli nowa procedura c2p budzi takie emocje i komentowy flejm 
obaczenie kiedyś jakiś ciekawych testów byłoby zaiste ciekawe
obaczenie kiedyś jakiś ciekawych testów byłoby zaiste ciekawe
21.11.2015 15:03
[#145]
Re: Nowa, szybka konwersja chunky-to-planar
@hrw, post #141
No to zobacz i zagraj trochę w Genetic Species, albo The Killing Grounds.
W The Killing Grounds mapa może mieć dwie kondygnacje, ściany pod dowolnym kątem, można patrzeć w górę i w dół, broń oraz niektórzy przeciwnicy nie są bitmapami, ale obiektami wektorowymi, na które wpływa oświetlenie. Do tego gra oferuje dynamiczne oświetlenie (np. czerwony robot z flarami rozświetla komnatę).
Genetic Species ma prostszy silnik, ale fajną grafikę, bronie i efekty wizualne.
Obie gry całkiem szybko działają na 060. Ja przeszedłem TKG na 030.
W The Killing Grounds mapa może mieć dwie kondygnacje, ściany pod dowolnym kątem, można patrzeć w górę i w dół, broń oraz niektórzy przeciwnicy nie są bitmapami, ale obiektami wektorowymi, na które wpływa oświetlenie. Do tego gra oferuje dynamiczne oświetlenie (np. czerwony robot z flarami rozświetla komnatę).
Genetic Species ma prostszy silnik, ale fajną grafikę, bronie i efekty wizualne.
Obie gry całkiem szybko działają na 060. Ja przeszedłem TKG na 030.
21.11.2015 15:12
[#147]
Re: Nowa, szybka konwersja chunky-to-planar
@Andrzej Drozd, post #143
1. DOOM wyszedł w 1993 roku.
2. Amigę kupiłem w 1995 roku (a600), w 1997 zmieniłem na a1200. Potem doszło 030, 040/40, fastata.
3. Amigowe porty Dooma wyszły w grudniu 1997 roku. Cztery lata po premierze wersji PC.
4. Pierwszego x86 kupiłem w 1999 roku sprzedając Amigę.
Więc mówienie o mnie "wstrętna pecetowca, którą zżarła nostalgia i gdy dotarła do bezsensu swojej kariery na pececie" niezbyt pasuje. No ale nie będę diagnozować jaki masz problem.
Kilka lat w Dooma? Na tym silniku wyszło kilka gier, do tego modyfikacje etc.
2. Amigę kupiłem w 1995 roku (a600), w 1997 zmieniłem na a1200. Potem doszło 030, 040/40, fastata.
3. Amigowe porty Dooma wyszły w grudniu 1997 roku. Cztery lata po premierze wersji PC.
4. Pierwszego x86 kupiłem w 1999 roku sprzedając Amigę.
Więc mówienie o mnie "wstrętna pecetowca, którą zżarła nostalgia i gdy dotarła do bezsensu swojej kariery na pececie" niezbyt pasuje. No ale nie będę diagnozować jaki masz problem.
Kilka lat w Dooma? Na tym silniku wyszło kilka gier, do tego modyfikacje etc.
21.11.2015 15:15
[#148]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #145
Wiem, że trudno w to uwierzyć większości użytkowników PPA ale Amigę kupiłem nie dla gier ale jak systemu operacyjnego. Sprzedałem gdy hardware był już zbyt ograniczony w porównaniu do taniego x86.
Dzisiaj jakbym miał zagrać w coś w stylu Dooma to pewnie Prboom + Ultimate Doom ;D
Dzisiaj jakbym miał zagrać w coś w stylu Dooma to pewnie Prboom + Ultimate Doom ;D
21.11.2015 16:23
[#149]
Re: Nowa, szybka konwersja chunky-to-planar
@hrw, post #147
Spoko, ale emotikony przecież pokazują że post był napisany z żartem.
Ja Amigi nigdy nie sprzedałem, a w drugiej połowie lat 90-tych nawet dokupiłem do niej PSXa. Pecetowcy aż silinili się na widok gier na szaraku.
Ja swojego pierwszego peceta kupiłem dopiero jakoś około 2005, natomiast Amigi nigdy nie sprzedałem.
Po prostu napisałeś brzydko o Breathless i stąd moja złośliwość. Moja zlośliwość (z żartem), za twoją złośliwość. I już.
Dodane:
Już wtedy miałem Apollo 040/40 MHz, ale jakoś nie miałem okazji zagrać, dopiero gdy doszedł do mnie BlizzardPPC w 1999, to wtedy całą grę przeszedłem na amigowym PPC + AGA.
Ostatnia aktualizacja: 21.11.2015 16:32:04 przez Andrzej Drozd
sprzedając Amigę
Ja Amigi nigdy nie sprzedałem, a w drugiej połowie lat 90-tych nawet dokupiłem do niej PSXa. Pecetowcy aż silinili się na widok gier na szaraku.
Ja swojego pierwszego peceta kupiłem dopiero jakoś około 2005, natomiast Amigi nigdy nie sprzedałem.
Po prostu napisałeś brzydko o Breathless i stąd moja złośliwość. Moja zlośliwość (z żartem), za twoją złośliwość. I już.
Dodane:
3. Amigowe porty Dooma wyszły w grudniu 1997 roku. Cztery lata po premierze wersji PC.
Już wtedy miałem Apollo 040/40 MHz, ale jakoś nie miałem okazji zagrać, dopiero gdy doszedł do mnie BlizzardPPC w 1999, to wtedy całą grę przeszedłem na amigowym PPC + AGA.
Ostatnia aktualizacja: 21.11.2015 16:32:04 przez Andrzej Drozd
21.11.2015 18:00
[#150]
Re: Nowa, szybka konwersja chunky-to-planar
@Hexmage960, post #146
Całej procedury c2p, gdzie nie ma iteracji nie uda mi się zmieścić w cache. Okazuje się jednak, że podział jednej dużej procedury na kilka mniejszych pętli powtarzanych wielokrotnie, gdzie każda mieści się w cache daje duży skok prędkościowy. Koszt nawet kilkukrotnego kopiowania fast->fast jest mniejszy aniżeli budowanie ogromnej pętli korzystającej z rejestrów. Przynajmniej takie mam obserwacje.
Obrazując:
pętla1: ; mieści się w cache
zapis do fast
bxx.s petla1
petla2: ; mieści się w cache
zapis do fast
bxx.s petla2
petla3: ; mieści się w cache
zapis do chip
bxx.s petla3
rts ; koniec
Kosztuje dużo mniej niż:
duza_petla: ; nie mieści się w cache
... ; dużo instrukcji
zapis do fast/chip
bxx.w duza_petla
Dobrze, że tak jest, zresztą to chyba powinna być oczywista własność pamięci cache.
Ostatnia aktualizacja: 21.11.2015 18:02:44 przez Hexmage960
Obrazując:
pętla1: ; mieści się w cache
zapis do fast
bxx.s petla1
petla2: ; mieści się w cache
zapis do fast
bxx.s petla2
petla3: ; mieści się w cache
zapis do chip
bxx.s petla3
rts ; koniec
Kosztuje dużo mniej niż:
duza_petla: ; nie mieści się w cache
... ; dużo instrukcji
zapis do fast/chip
bxx.w duza_petla
Dobrze, że tak jest, zresztą to chyba powinna być oczywista własność pamięci cache.
Ostatnia aktualizacja: 21.11.2015 18:02:44 przez Hexmage960