15.03.2020 19:06
[#121]
Re: Akiko 32
@sanjyuubi, post #120
Widać jasno po wynikach Glooma że oryginalne akiko daje i to sporo.
Zresztą https://www.ppa.pl/forum/amiga/26469/cd32-akiko
W grafice daje mocniejszego kopa niż 040.
Warto dorobić nawet niezwiązane z innym projektem.
Zresztą https://www.ppa.pl/forum/amiga/26469/cd32-akiko
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
W grafice daje mocniejszego kopa niż 040.
Warto dorobić nawet niezwiązane z innym projektem.
15.03.2020 19:59
[#123]
Re: Akiko 32
@recedent, post #122
Narzut c2p w przypadku 040 przy mądrym wykorzystaniu jest równy 0 (przy czekaniu na wygaszanie pionowe, 040 robiąc w międzyczasie c2p skopuje szybciej, niż normalne kopiowanie podczas rysowania ekranu bitplanów) i Akiko tylko by spowolniło operacje. Poza tym, oryginalne Akiko z tego co czytałem, nie daje rady nawet przy 030/50 jeżeli chcemy wrzucić piksele i od razu je odczytać, bo ma takie opóźnienia logiki.
Akiko ma sens przy prockach słabszych mniej więcej od 68030 33MHz.
Akiko ma sens przy prockach słabszych mniej więcej od 68030 33MHz.
15.03.2020 21:52
[#125]
Re: Akiko 32
@flops, post #123
...jeżeli chcemy wrzucić piksele i od razu je odczytać, bo ma takie opóźnienia logiki.
A motywem przewodnim tego wątku od samego początku jest sprawdzenie, jak będzie wyglądała sytuacja z Akiko bez opóźnień. To nie jest wątek "AKIKO w chipsecie VS algorytm szybkiego CPU", ktokolwiek myśli, że tak jest, to źle trafił.
Ostatnia aktualizacja: 15.03.2020 21:55:42 przez sanjyuubi
15.03.2020 22:19
[#128]
Re: Akiko 32
@sanjyuubi, post #125
Tylko jaki to wszystko ma sens skoro i tak chipset będzie blokował. Trochę mniej, ale jednak. I tego nie przeskoczysz, ani nie ominiesz. Z 5 FPS zrobisz 8 i co, sukces? Zaraz się okaże, że przerzucenie Alice do FPGA i podbicie prędkości DMA zrobiłoby 20FPS ;) A włożenie karty grafiki na Cyclone V z Cortex A7 nawet i 40 :P
15.03.2020 22:45
[#129]
Re: Akiko 32
@recedent, post #126
Myślenie od dupy strony za przeproszeniem. Prawidłowe pytanie powinno brzmieć, czy Akiko bez opóźnień spowoduje, że na 040 będzie więcej FPS niż na 040 bez AKIKO. Pytasz się, czy benzyna o większej kaloryczności sprawi, że Maluch prześcignie Ferrari, a co z samym Ferrari VS Ferrari? Segmentem, który może na tym skorzystać, jest obszar użytkowników do 030 50MHz, teoretycznie, ponieważ bez jakichkolwiek testów, nie da rady tego sprawdzić, chyba, że w winuae, gdyby AKIKO pracowało tam bez opóźnień.
Ostatnia aktualizacja: 15.03.2020 22:49:41 przez sanjyuubi
Ostatnia aktualizacja: 15.03.2020 22:49:41 przez sanjyuubi
15.03.2020 23:58
[#132]
Re: Akiko 32
@docent, post #131
To mnie trochę właśnie zastanawia, w jaki sposób, bo jedyne co mi przychodzi do głowy, to wrzucanie po kolei bajtów z kolejnych bitplanów, ale to wydaje się mało efektywne.
Chyba, że Gunnar sobie dorobił rejestry działające w drugą stronę i zapomniał, że to jego wstawka.
Chyba, że Gunnar sobie dorobił rejestry działające w drugą stronę i zapomniał, że to jego wstawka.
16.03.2020 01:36
[#133]
Re: Akiko 32
@docent, post #131
Jak się przyjrzysz dokładniej, to zauważysz, że procedura odwrotna P2C polega na dokładnie tych samych operacjach, ale wykonanych na danych podanych w innej kolejności.
Jeżeli zapodasz dane planarne bajtami w poniższy sposób uzyskach P2C (choć wynikowe piksele są w innej kolejności, ale nadal chunky):
Wynik:
Co do tematu, to zauważcie, jak Amiga musi się trudzić z chunky. Żeby uzyskać przepustowość Planarną (32-pikselowe zapisy) musi obrobić 256-bitowe dane! Uważam, że problem z Doomem na Amidze leży gdzie indziej i jestem zdania, że do tego potrzebne jest FPU.
Pamiętajcie, że oprócz grafiki - Doom ma bardzo zaawansowane algorytmy.
Ja bym raczej nastawiał się na odpowiednie efekty animacji na Amidze. Chunky się przydaje kiedy chcemy robić efekty na kolorach (niekoniecznie na żywo, ale np. w programie graficznym). Możliwość kompresji animacji i inne są po prostu nieodzowne! A w planar taką kompresję można łatwo wprowadzać.
Uważam, że Commodore zrobiło świetną robotę wprowadzając akcelerator graficzny w Akiko do Amigi CD32.
Róbcie jak uważacie za słuszne.
Ja sam chunky w moich grach nie potrzebuję, bo w Planar obrobisz piksele do 32 razy szybciej i to jest potrzebne do animacji. Chunky z reguły polega na spacerowaniu po pojedynczych pikselach - nie da się przerabiać wielu pikseli na raz.
W grafice 3D z kolei piksele nie grają już żadnej roli - bo nie ma między nimi związku. Polega to na mocy przerobowej jednostki 3D - ile danych obrobi w krótkim czasie. (A w Amidze 32 piksele w jednym bitplanie są powiązane.)
Ja bym zamiast 3D nastawiał się na szybkie i kolorowe 2D, co jest domeną Amigi. I do tego Akiko się również przyda.
Planuję by moje przyszłe, bardziej zaawansowane gry po Magazynie korzystały z kompresji animacji ekranu. Liczę na wiele obiektów animowanych.
Ostatnia aktualizacja: 16.03.2020 01:51:43 przez Hexmage960
Jeżeli zapodasz dane planarne bajtami w poniższy sposób uzyskach P2C (choć wynikowe piksele są w innej kolejności, ale nadal chunky):
a7b7c7d7e7f7g7h7 a6b6c6d6e6f6g6h6 a5b5c5d5e5f5g5h5 a4b4c4d4e4f4g4h4 a3b3c3d3e3f3g3h3 a2b2c2d2e2f2g2h2 a1b1c1d1e1f1g1h1 a0b0c0d0e0f0g0h0 i7j7k7l7m7n7o7p7 i6j6k6l6m6n6o6p6 i5j5k5l5m5n5o5p5 i4j4k4l4m4n4o4p4 i3j3k3l3m3n3o3p3 i2j2k2l2m2n2o2p2 i1j1k1l1m1n1o1p1 i0j0k0l0m0n0o0p0 ...
Wynik:
h7h6h5h4h3h2h1h0 p7p6p5p4p3p2p1p0 H7H6H5H4H3H2H1H0 P7P6P5P4P3P2P1P0 g7g6g5g4g3g2g1g0 o7o6o5o4o3o2o1o0 G7G6G5G4G3G2G1G0 O7O6O5O4O3O2O1O0 f7f6f5f4f3f2f1f0 n7n6n5n4n3n2n1n0 F7F6F5F4F3F2F1F0 N7N6N5N4N3N2N1N0 e7e6e5e4e3e2e1e0 m7m6m5m4m3m2m1m0 E7E6E5E4E3E2E1E0 M7M6M5M4M3M2M1M0 d7d6d5d4d3d2d1d0 l7l6l5l4l3l2l1l0 D7D6D5D4D3D2D1D0 L7L6L5L4L3L2L1L0 c7c6c5c4c3c2c1c0 k7k6k5k4k3k2k1k0 C7C6C5C4C3C2C1C0 K7K6K5K4K3K2K1K0 b7b6b5b4b3b2b1b0 j7j6j5j4j3j2j1j0 B7B6B5B4B3B2B1B0 J7J6J5J4J3J2J1J0 a7a6a5a4a3a2a1a0 i7j7k7l7m7n7o7p7 A7A6A5A4A3A2A1A0 I7I6I5I4I3I2I1I0
Co do tematu, to zauważcie, jak Amiga musi się trudzić z chunky. Żeby uzyskać przepustowość Planarną (32-pikselowe zapisy) musi obrobić 256-bitowe dane! Uważam, że problem z Doomem na Amidze leży gdzie indziej i jestem zdania, że do tego potrzebne jest FPU.
Pamiętajcie, że oprócz grafiki - Doom ma bardzo zaawansowane algorytmy.
Ja bym raczej nastawiał się na odpowiednie efekty animacji na Amidze. Chunky się przydaje kiedy chcemy robić efekty na kolorach (niekoniecznie na żywo, ale np. w programie graficznym). Możliwość kompresji animacji i inne są po prostu nieodzowne! A w planar taką kompresję można łatwo wprowadzać.
Uważam, że Commodore zrobiło świetną robotę wprowadzając akcelerator graficzny w Akiko do Amigi CD32.
Róbcie jak uważacie za słuszne.
Ja sam chunky w moich grach nie potrzebuję, bo w Planar obrobisz piksele do 32 razy szybciej i to jest potrzebne do animacji. Chunky z reguły polega na spacerowaniu po pojedynczych pikselach - nie da się przerabiać wielu pikseli na raz.
W grafice 3D z kolei piksele nie grają już żadnej roli - bo nie ma między nimi związku. Polega to na mocy przerobowej jednostki 3D - ile danych obrobi w krótkim czasie. (A w Amidze 32 piksele w jednym bitplanie są powiązane.)
Ja bym zamiast 3D nastawiał się na szybkie i kolorowe 2D, co jest domeną Amigi. I do tego Akiko się również przyda.
Planuję by moje przyszłe, bardziej zaawansowane gry po Magazynie korzystały z kompresji animacji ekranu. Liczę na wiele obiektów animowanych.
Ostatnia aktualizacja: 16.03.2020 01:51:43 przez Hexmage960
16.03.2020 06:00
[#134]
Re: Akiko 32
@sanjyuubi, post #130
Tak, tak... rozmyślasz nad protezą, która będzie blisko proca i fastu (zakładając, że już użytkownik ma turbo to gdzie to wsadzi, jak nie ma turbo to i tak ma spore koszty).
Ja rozumiem, że dla niektórych amiga to kanapki i protezy na protezę, ale kurka chyba już mamy "ciut" większe możliwości niż 30 lat temu.
Ja rozumiem, że dla niektórych amiga to kanapki i protezy na protezę, ale kurka chyba już mamy "ciut" większe możliwości niż 30 lat temu.
16.03.2020 07:59
[#137]
Re: Akiko 32
@swinkamor12, post #136
Ale tanie akiko dla słabych maszyn i tak nie spowoduje, że będzie wystarczająco płynnie, bo nie będzie. A jeśli chodzi o wyniki to na eab swego czasu był wątek na bodajze 13 stron i 040 nawet na 25mhz deklasowało akiko z palcem w DINie... i wreszcie wszystko się sprowadza do softu. Jeśli istniejący soft korzystający z akiko nie będzie wyraźnie szybszy na szybkich maszynach, a na wolniejszych nie da wystarczającej poprawy by dało się przyjemnie grać to jest mało sensowne, szczególnie że softu korzystającego aktualnie z akiko nie jest za dużo. Jeśli zaś chodzi o nowy soft lub soft gdzie łatwo zaimplementować obsługę to równie dobrze można zrobić lepszy układ akcelerujący więcej operacji i nowe biblioteki, np. c2p + p2c + simd int ...
16.03.2020 08:53
[#138]
Re: Akiko 32
@abcdef, post #137
Dobra Pany, inaczej, akiko to nie tylko te nieszczęsne gry FPP. To jest skrajny przypadek gdzie trzeba cały ekran konwertować, ale są też inne przypadki.
Jest masa innych zastosowań gdzie chunky jest niezbędne - skalowanie, obroty i inne transformacje, to też jest potrzebne w grach 2D. W OpenFire (gra 2D, widok z góry) mam obroty pojazdów w 64 kierunkach, faktycznych klatek mam 32 żeby oszczędzać RAM. To są obiekty 32x32, mam ich w porywach 16. Z popularnym, szybkim neo-akiko mógłbym to robić w locie przy mniejszych wymaganiach sprzętowych.
C2P też przydaje się przy systemie cząstek (particles). To można wsadzić w każdą grę jako dodatkowe efekty wizualne. Też fajnie by było mieć. Na przykład dynamicznie sypiący się grunt przy kopaniu w aminerze.
To są moje, wypisane na poczekaniu z głowy obszary zastosowań gdzie bym widział tego użycie w swoim kodzie. A w Waszym? Jak chcecie tylko gapić się na cyferki w timedemo Dooma czy innego Quake'a to to Wam to faktycznie różnicy nie zrobi. ;) Ale mi może zrobić.
Ostatnia aktualizacja: 16.03.2020 08:54:28 przez teh_KaiN
Jest masa innych zastosowań gdzie chunky jest niezbędne - skalowanie, obroty i inne transformacje, to też jest potrzebne w grach 2D. W OpenFire (gra 2D, widok z góry) mam obroty pojazdów w 64 kierunkach, faktycznych klatek mam 32 żeby oszczędzać RAM. To są obiekty 32x32, mam ich w porywach 16. Z popularnym, szybkim neo-akiko mógłbym to robić w locie przy mniejszych wymaganiach sprzętowych.
C2P też przydaje się przy systemie cząstek (particles). To można wsadzić w każdą grę jako dodatkowe efekty wizualne. Też fajnie by było mieć. Na przykład dynamicznie sypiący się grunt przy kopaniu w aminerze.
To są moje, wypisane na poczekaniu z głowy obszary zastosowań gdzie bym widział tego użycie w swoim kodzie. A w Waszym? Jak chcecie tylko gapić się na cyferki w timedemo Dooma czy innego Quake'a to to Wam to faktycznie różnicy nie zrobi. ;) Ale mi może zrobić.
Ostatnia aktualizacja: 16.03.2020 08:54:28 przez teh_KaiN
16.03.2020 09:10
[#139]
Re: Akiko 32
@teh_KaiN, post #138
skalowanie, obroty i inne transformacje, to też jest potrzebne w grach 2D
No dobrze, potrzebujesz w formacie chunky. I masz chunky. I przeliczasz skalarnie na motoroli. No właśnie. Może i względnie tanio, może i nawet ktoś na tym coś zyska ale to i tak tylko półśrodki.
16.03.2020 09:26
[#142]
Re: Akiko 32
@swinkamor12, post #141
Tak tak. AGA to dziadostwo, a Akiko z CD32 deklasuje 060 (które zresztą jest słabym NG, bo Commodore zbankrutowało zanim zdążyło użyć tego procesora w A4000). Wszyscy już to słyszeliśmy. A teraz marsz już do roboty. A potem, jak już wszystko będziesz miał gotowe to pokaż jak Akiko wymiata szybsze cepy.
16.03.2020 10:11
[#146]
Re: Akiko 32
@abcdef, post #137
Dokładnie, nawet 68030 50MHz jak widać nie potrzebuje wsparcia Akiko, bo jest szybciej bez niż z: Ta strona i kolejna z wynikami dla SX Pro, różne wersje z Akiko i bez.
Nie mogę znaleźć artykułu z c2p fast like mem copy, bo już serwer nie istnieje, a faktycznie z testów Don Adan wynika, że zerowy narzut jest od 68060 50MHz. Ale nie ma tam tricku z oczekiwaniem na wygaszanie pionowe.
Testy na samej górze są tendencyjne... To 68040 25MHz, to pewnie jest test na karcie A3640, która - jak każdy wie - ma zrąbane dostępy do fast ram i jest przez to mega wolna, niektóre testy na tej karcie wypadają wolniej niż na B1230 50MHz, a transfer do ram to połowa jak nie 1/4 transferu biednej 68030 50MHz.
#137
Nawet 68030 50MHz objeżdża Akiko, a co dopiero 68040 25MHz...
Ostatnia aktualizacja: 16.03.2020 10:14:50 przez flops
Nie mogę znaleźć artykułu z c2p fast like mem copy, bo już serwer nie istnieje, a faktycznie z testów Don Adan wynika, że zerowy narzut jest od 68060 50MHz. Ale nie ma tam tricku z oczekiwaniem na wygaszanie pionowe.
Testy na samej górze są tendencyjne... To 68040 25MHz, to pewnie jest test na karcie A3640, która - jak każdy wie - ma zrąbane dostępy do fast ram i jest przez to mega wolna, niektóre testy na tej karcie wypadają wolniej niż na B1230 50MHz, a transfer do ram to połowa jak nie 1/4 transferu biednej 68030 50MHz.
#137
Nawet 68030 50MHz objeżdża Akiko, a co dopiero 68040 25MHz...
Ostatnia aktualizacja: 16.03.2020 10:14:50 przez flops
16.03.2020 11:20
[#147]
Re: Akiko 32
@teh_KaiN, post #138
C2P też przydaje się przy systemie cząstek (particles). To można wsadzić w każdą grę jako dodatkowe efekty wizualne. Też fajnie by było mieć. Na przykład dynamicznie sypiący się grunt przy kopaniu w aminerze.
Pełna zgoda. Tylko, że na Planarach też to uzyskasz! Wystarczy przechowywać grafikę i współrzędne cząstek, potem wklejać za jednym razem. Pokazałem niedawno pełny kod, który to robi w wątku o "pixel plot".
Naprawdę C2P w zastosowaniach 2D nie jest na Amidze problemem.
Jest masa innych zastosowań gdzie chunky jest niezbędne - skalowanie, obroty i inne transformacje, to też jest potrzebne w grach 2D.
Obroty, jak i skalowanie na 2D wymagają również antialiasingu żeby wyglądało to dobrze.
Główne zastosowanie Chunky, to według mnie manipulacja kolorami. Szukasz w tablicy kolorów #RRGGBB pożądanego koloru i wklejasz indeks jemu przypisany. Da to efekty 24-bit na Amidze.
Ostatnia aktualizacja: 16.03.2020 11:25:04 przez Hexmage960
