Temat: 1 bitplanowy triangle filler na motoroli
No i wielkie zaskoczenie! Motorola zrobiła to tak samo szybko, jak blitter! Wygląda na to, że blittera najlepiej używać do bardziej złożonych operacji z przesunięciami bitów, andami, xorami itd.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Cosmic Hero 2 Bohater ratujący Ziemię w kryzysowej sytuacji powraca po 30 latach.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
No i wielkie zaskoczenie! Motorola zrobiła to tak samo szybko, jak blitter! Wygląda na to, że blittera najlepiej używać do bardziej złożonych operacji z przesunięciami bitów, andami, xorami itd.
Tak jak przypuszczałem. Blitterem zyskałeś na długich liniach ale straciłeś na krótkich. Mógłbyś teoretycznie zrobić wersje mieszaną wywołującą kod cpu lub blitter'a w zależności od długości linii. Oczywiście taki warunek to dodatkowy koszt, ale pewnie na takim dużym trójkącie będzie na najszybsza wersja. Choć dla zyciowego case'a wypełniania obiektu 3d, który ma wiele face'ów ale długości linii będą relatywnie krótkie obstawiałbym lepsze wyniki wersji cpu. Ale to tylko guess:)
Zdecydowanie. Motorola tym razem pokazała pazur. :P
Mógłbyś teoretycznie zrobić wersje mieszaną wywołującą kod cpu lub blitter'a w zależności od długości linii. Oczywiście taki warunek to dodatkowy koszt
Wachu zrobił już detekcję w kodzie, są to procedury "line0_XXX" :) Wystarczy dla odpowiednio długich podmienić kod z CPU na BLiTTERa.
Myślę że dla cztero-bitplanowego fillera proporcje mogą ulec zmianie.
Jest jeszcze jedna niewykorzystana tutaj zaleta BLiTTERa. W czasie blittingu, CPU może wykonać jedną "długą" instrukcję, np rotacje, mnożenie/dzielenie itp. Z tego co widzę w kodzie, na każdy trójkąt przypadają trzy DIVSy. Być może dało by się je sprytnie przesunąć pod blitting.
Myślę że dla cztero-bitplanowego fillera proporcje mogą ulec zmianie.
Jest jeszcze jedna niewykorzystana tutaj zaleta BLiTTERa. W czasie blittingu, CPU może wykonać jedną "długą" instrukcję, np rotacje, mnożenie/dzielenie itp. Z tego co widzę w kodzie, na każdy trójkąt przypadają trzy DIVSy. Być może dało by się je sprytnie przesunąć pod blitting.
Można pomyśleć o tablicy divsów, to by jeszcze trochę przyspieszyło kod. Jeśli chodzi o wstawianie instrukcji w czasie działania blittera, to chyba zadziała to tylko w przypadku trybu BLIT, czyli trybu dzielonego (ale mogę się mylić). No ciekawe, jak wypadłby blitter w 4 planowym fillerze, ale zaczynam odnosić wrażenie, że mógłby być wolniejszy od motorli (jak sobie spojrzycie na 4 bitplanowego fillera z kilku tematów wstecz, to do wypełniania używam tam movemów i przy długich liniach robię bodajże 64 piksele na jednym movie - to może być już dla blittera za dużo).
Ostatnio edytowany przez Tomasz Wachowiak (2015-02-25 12:08:52)
Jeśli chodzi o wstawianie instrukcji w czasie działania blittera, to chyba zadziała to tylko w przypadku trybu BLIT, czyli trybu dzielonego
Działa w każdym wariancie - BLIT i HOG. Kwestia jest tylko w tym, by wystartować BLiTTERa instrukcją typu "Class 0", np BSET, ASL, ADD itp: http://pasti.fxatari.com/68kdocs/68kPrefetch.html
A tutaj mój mały przykład:
http://www.atari-forum.com/viewtopic.php?p=96197#p96197
No ciekawe, jak wypadłby blitter w 4 planowym fillerze, ale zaczynam odnosić wrażenie, że mógłby być wolniejszy od motorli (jak sobie spojrzycie na 4 bitplanowego fillera z kilku tematów wstecz, to do wypełniania używam tam movemów i przy długich liniach robię bodajże 64 piksele na jednym movie - to może być już dla blittera za dużo).
myślę że warto by to sprawdzić w praktyce. Z tego co widzę w w przypadku wariantu CPU i MOVEMów dla każdej linii dokonujesz jeszcze fline_m i lline_m które są dość kosztowne.
myślę że warto by to sprawdzić w praktyce. Z tego co widzę w w przypadku wariantu CPU i MOVEMów dla każdej linii dokonujesz jeszcze fline_m i lline_m które są dość kosztowne.
Fakt, pierwsza i ostatnia część linii - to koszmar. :P Przez ten kod można rzeczywiście upatrywać zwycięstwa blittera. Chociaż jeśli, to i tak z niewielką przewagą. Wypełnienie 16 pikseli w 4 planach na blitterze i motoroli zajmuje dokładnie tyle samo czasu: w przypadku blittera są to 4 cykle * 4 plany, w przypadku movema to 8 cykli * dwa rejestry, czyli też 16. :) Czyli o zwycięstwie zadecyduje z jednej strony narzut na inicjalizację blittera, a z drugiej narzut na odkodowanie movemów (6 movemów * 16 cykli + pierwsza i ostatnia linia).
Edit:
Policzyłem sobie:
Całkowity czas dla linii 320 pikseli na motoroli (według mojej procki), to: 2*96 + 5*(12 + 8*8) + (12+4*8) -> 616.
Dla blittera to: 320 + czas inicjalizacji na poszczególnych planach. Kurde, może jednak być trochę szybciej. Chyba, że o czymś zapomniałem, bo jakoś tak za szybko tutaj mi to wygląda... :P
Oczywiście wstępna inicjalizacja blittera zajmuje czas, więc chyba bez kodu się nie obejdzie... :D
Ostatnio edytowany przez Tomasz Wachowiak (2015-02-25 13:28:09)
Panowie, a w przypadku eor fill, nie da się Blitterem wypelnic polygona 1 operacją? odpada wówczes inicjalizacja per linie, ale dochodzi troche 'niechcianych' operacji, ale myślę że przy wypełnianiu kilku na raz, może wyjść na plus.
Panowie, a w przypadku eor fill, nie da się Blitterem wypelnic polygona 1 operacją? odpada wówczes inicjalizacja per linie, ale dochodzi troche 'niechcianych' operacji, ale myślę że przy wypełnianiu kilku na raz, może wyjść na plus.
Nie do końca orientuję się, jak działa eor fill, ale pamiątaj, że obrys trójkąta trzeba wyrysować, trzeba pobrać poprzednią linię (to w blitterze zajmuje 8 taktów na 16 pikseli, a nie cztery jak przy wypełnianiu) i zeorować ją z aktualną, to z kolei zajmie albo 8 albo 12 taktów na 16 pikseli. Jak sobie podliczymy, to wcale już to tak dobrze nie wygląda. Chyba, że eor fill działa nie tak, jak napisałem? :(
EOR to XOR?
"source XOR destination" zabiera trzy cykle szyny (odczyt źródła, odczyt celu, zapis celu) - 12 cykli procesora
Ostatnio edytowany przez Cyprian (2015-02-25 13:47:19)
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.067 sekund, wykonano 12 zapytań ]