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.

Post's attachments

mtraing1.zip 4.71 kb, liczba pobrań: 10 (od 2015-02-24) 

Tylko zalogowani mogą pobierać załączniki.

2

Odp: 1 bitplanowy triangle filler na motoroli

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:)

Maciek
--------
Atari 65XE + Ultimate 1MB + Stereo + SIO2SD | Atari 520STE + 4MB + UltraSatan | Atari Falcon 030 + CT60e + 14MB ST + 256MB TT + 68882  + CF + Netusbee | Amiga 500 + 1MB + Gotek | Amiga 600 + 2MB Chip + 8MB Fast + CF

Odp: 1 bitplanowy triangle filler na motoroli

Zdecydowanie. Motorola tym razem pokazała pazur. :P

4

Odp: 1 bitplanowy triangle filler na motoroli

mkm napisał/a:

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.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

Odp: 1 bitplanowy triangle filler na motoroli

Cyprian napisał/a:

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)

6

Odp: 1 bitplanowy triangle filler na motoroli

Tomasz Wachowiak napisał/a:

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

Tomasz Wachowiak napisał/a:

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.

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

Odp: 1 bitplanowy triangle filler na motoroli

Cyprian napisał/a:

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)

Odp: 1 bitplanowy triangle filler na motoroli

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.

Atari: FireBee, (Falcon030 CT60e SuperVidel SvEthlana CTPCI), TT, (520ST Pak030 Frak PuPla Panther), (520ST 4MB ST RAM 8MB TT RAM CosmosEx SC1435), (1040STFM UltraSatan SM124), (1040STE 4MB ST RAM 8MB TT RAM CosmosEx NetUSBee SM144 SC1224), 260ST, 520 ST+, (MEGA ST SM125), (65XE Rapidus U1MB VBXE SIDE2 SIO2PC), (Jaguar SkunkBoard), Lynx II, 2x Portfolio

Odp: 1 bitplanowy triangle filler na motoroli

Adam Klobukowski napisał/a:

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? :(

10

Odp: 1 bitplanowy triangle filler na motoroli

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)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org