17.04.2019 22:49
[#722]
Re: Nowe Turbo A1200/060 - WARP 1260
@tbone, post #721
Oxypatcher był włączony.
Tyle tylko, że jak sobie liczę: SysSpeed podaje prędkość kopiowania chip->fast 5.8MB/s i to gdy workbench jest wyświetlany na RTG, czyli CHIP'u nie obciąża DMA od wyświetlania obrazu. Nie wiem z ilu bitplane'ów korzysta demo, ale nawet biorąc pod uwagę wykorzystywanie trików takich jak kopiowanie w przerwach na wygaszanie itp. to i tak szału nie będzie. Lekko licząc samo kopiowanie obrazu to przynajmniej ~15ms. To całkiem sporo.
Inna sprawa jeszcze, chociaż pełen szacun i demo jest naprawdę super, to ciężko powiedzieć, czy kod nie zawiera jakichś elementów, które dałoby się zoptymalizować.
Nie mam w ogóle orientacji jak wygląda architektura Atari, jaka tam jest prędkość dostępu do szyny i pamięci graficznej. Być może tam po prostu można przepchnąć więcej danych i chodzi to nieco lepiej.
Kolejna rzecz, to nikt nie powiedział, że np. aktualny kontroler pamięci w Warp jest wersją ostateczną. Jest już pomysł na kolejną wersję cache dla ddr'a, ale nie chcemy w nieskończoność tworzyć nowych wersji i przeciągać wypuszczenia karty na świat. Z resztą nie można powiedzieć, że obecna wersja działa wolno(wynik AIBB np. to 44.6 MB/s) i naprawdę wątpię, że w tym akurat wypadku optymalizacja sprawi, że Kioea nagle osiągnie znacznie więcej FPS'ów.
No i mam pytanie, może ktoś z was się orientuje - czy to demo da się w ogóle puścić na RTG?
Gdzieś czytałem, że niby tak, ale jeśli tak jest to nie mam pomysłu w jaki sposób.
Na moim systemie demo odpala się zawsze na AGA.
Tyle tylko, że jak sobie liczę: SysSpeed podaje prędkość kopiowania chip->fast 5.8MB/s i to gdy workbench jest wyświetlany na RTG, czyli CHIP'u nie obciąża DMA od wyświetlania obrazu. Nie wiem z ilu bitplane'ów korzysta demo, ale nawet biorąc pod uwagę wykorzystywanie trików takich jak kopiowanie w przerwach na wygaszanie itp. to i tak szału nie będzie. Lekko licząc samo kopiowanie obrazu to przynajmniej ~15ms. To całkiem sporo.
Inna sprawa jeszcze, chociaż pełen szacun i demo jest naprawdę super, to ciężko powiedzieć, czy kod nie zawiera jakichś elementów, które dałoby się zoptymalizować.
Nie mam w ogóle orientacji jak wygląda architektura Atari, jaka tam jest prędkość dostępu do szyny i pamięci graficznej. Być może tam po prostu można przepchnąć więcej danych i chodzi to nieco lepiej.
Kolejna rzecz, to nikt nie powiedział, że np. aktualny kontroler pamięci w Warp jest wersją ostateczną. Jest już pomysł na kolejną wersję cache dla ddr'a, ale nie chcemy w nieskończoność tworzyć nowych wersji i przeciągać wypuszczenia karty na świat. Z resztą nie można powiedzieć, że obecna wersja działa wolno(wynik AIBB np. to 44.6 MB/s) i naprawdę wątpię, że w tym akurat wypadku optymalizacja sprawi, że Kioea nagle osiągnie znacznie więcej FPS'ów.
No i mam pytanie, może ktoś z was się orientuje - czy to demo da się w ogóle puścić na RTG?
Gdzieś czytałem, że niby tak, ale jeśli tak jest to nie mam pomysłu w jaki sposób.
Na moim systemie demo odpala się zawsze na AGA.
17.04.2019 23:29
[#724]
Re: Nowe Turbo A1200/060 - WARP 1260
@Sellen, post #722
W tym przypadku CHIP ram, a raczej DMA jest wąskim gardłem i trzeba się z tym pogodzić... Falcon ma 'niestety' tryb chunky wbudowany w swój układ graficzny i podpięty bezpośrednio do szyny procesora.
Nigdy nie miałem RTG i trudno jest mi powiedzieć na ile RTG w tym konkretnym przypadku byłoby w stanie przyspieszyć, ale jeśli na RTG zapisy idą przez systemowy sterownik to i tak będzie wolniej niż na Falconie.
W tym przypadku na pewno możliwość zwiększenia FPS to zaimplementowanie w WARPie czegoś w rodzaju write buffera do pamięci CHIP. Pisałem kiedyś o tym, ale rozumiem, że to nie jest coś niezbędnego. Z tego co wiem to A4000 ma właśnie coś takiego w swojej architekturze i dlatego to właśnie A4000 jest najlepszą maszyną do oglądania dem na AGA.
Druga sprawa OxyPatcher... Mi się nie udało go odpalić na 68060.library innym niż ten od phase5 (korzystam z bodajże w wersji 46.15) . Ciekawe, że nawet moje Apollo działa lepiej na tym 68060.library niż na ich własnym.
Kiedyś pytałem Cizara z jakiego 68060.library będziecie korzystać i miało być to 'generyczne' z MMULib. Jeśli tak faktycznie jest to OxyPatcher wg mnie nie ma prawa działać. Inna sprawa, że OxyPatcher raczej w tym demie nie pomoże bo Britelite raczej nie korzysta z instrukcji FPU nie zaimplementowanych w 060.
Nigdy nie miałem RTG i trudno jest mi powiedzieć na ile RTG w tym konkretnym przypadku byłoby w stanie przyspieszyć, ale jeśli na RTG zapisy idą przez systemowy sterownik to i tak będzie wolniej niż na Falconie.
W tym przypadku na pewno możliwość zwiększenia FPS to zaimplementowanie w WARPie czegoś w rodzaju write buffera do pamięci CHIP. Pisałem kiedyś o tym, ale rozumiem, że to nie jest coś niezbędnego. Z tego co wiem to A4000 ma właśnie coś takiego w swojej architekturze i dlatego to właśnie A4000 jest najlepszą maszyną do oglądania dem na AGA.
Druga sprawa OxyPatcher... Mi się nie udało go odpalić na 68060.library innym niż ten od phase5 (korzystam z bodajże w wersji 46.15) . Ciekawe, że nawet moje Apollo działa lepiej na tym 68060.library niż na ich własnym.
Kiedyś pytałem Cizara z jakiego 68060.library będziecie korzystać i miało być to 'generyczne' z MMULib. Jeśli tak faktycznie jest to OxyPatcher wg mnie nie ma prawa działać. Inna sprawa, że OxyPatcher raczej w tym demie nie pomoże bo Britelite raczej nie korzysta z instrukcji FPU nie zaimplementowanych w 060.
17.04.2019 23:50
[#726]
Re: Nowe Turbo A1200/060 - WARP 1260
@Sellen, post #716
Wiem co potrafi AGA, na youtube znajdziesz mój filmik z Duke Nukem 3d (WarpOS) w 640x400 na AGA.
Efiki CPU nie jest demonem prędkości bazuje na tej samej architekturze PPC 603e, który jest w kartach BlizzardPPC
Pierwsze to ja tego dema na Efice czy na innym sprzęcie pod MorphOS nie uruchamiam na UAE, na UAE nie uruchomisz tego dema w 640x480, tylko pod MorphOS i AmigaOS4, oczywiście mogę uruchomić to demo również w 320x240.
Efiki CPU nie jest demonem prędkości bazuje na tej samej architekturze PPC 603e, który jest w kartach BlizzardPPC
Pierwsze to ja tego dema na Efice czy na innym sprzęcie pod MorphOS nie uruchamiam na UAE, na UAE nie uruchomisz tego dema w 640x480, tylko pod MorphOS i AmigaOS4, oczywiście mogę uruchomić to demo również w 320x240.
18.04.2019 00:15
[#727]
Re: Nowe Turbo A1200/060 - WARP 1260
@Sellen, post #722
Konwersja ekranu 320x256 wraz z kopiowaniem pożera czas ok. jednej ramki na 060 AGA, z czego 3/4 to kopiowanie do chip. Mówiąc inaczej, nie da się zrobić czegokolwiek pełnoekranowego co będzie działać szybciej niż 25fps.
Kopiowanie podczas przerw na wygaszanie, gdy można wyłączyć ruch na DMA działa, ale wtedy trzeba zmniejszyć ekran w pionie.
Rozwiązanie z dodatkowym buforem do chip brzmi świetnie, drążcie temat.
Kopiowanie podczas przerw na wygaszanie, gdy można wyłączyć ruch na DMA działa, ale wtedy trzeba zmniejszyć ekran w pionie.
Rozwiązanie z dodatkowym buforem do chip brzmi świetnie, drążcie temat.
18.04.2019 01:41
[#729]
Re: Nowe Turbo A1200/060 - WARP 1260
@dante, post #724
Dość ciekawe to co piszesz o A4000, ale patrzę na testy w sysspeed i porównuję do A4000/060@50 i zapis/odczyt/kopiowanie CHIP-RAM mam dokładnie takie same. Przełączyłem u siebie zegar na 50MHz i też wyniki identyczne. Prędkość samej szyny i chipsetu jest tu po prostu wąskim gardłem i tyle.
Ale tak dla ciekawości, odpaliłem DOOM'a w trybie AGA i praktycznie cały czas FPS'y około 25-30 – chodzi idealnie (wrzucę filmik za niedługo). Wychodzi więc na to, że da się liczyć 3D i kopiować w całkiem sensownym czasie :)
Dlaczego część efektów w Kioea nie powala prędkością? Nie wiem i nie bardzo już mam czas drążyć. Patrząc jednak na to jak chodzi DOOM czy Quake na tym sprzęcie, wydaje mi się, że coś w samym kodzie można tam było lepiej zoptymalizować ;)
Co do bufora zapisu, naprawdę – biorąc pod uwagę przepaść pomiędzy prędkością takiej 060-tki, a CHIP-ram, nie ma to sensu. Używamy bufora zapisu, ale w mostku CPU->pamięć RTG. Tam ma to sens, bo zapisy są buforowane w momencie oczekiwania na kontroler DDR'a, ale jak DDR zaskoczy to wsysa dane z prędkością nawet do 1600MB/s. I cały zapis leci płynnie. W przypadku CHIP-ramu dostęp jest tak wolny, że bufor zapisu momentalnie się zapełni i tyle. Może byłby jakiś minimalny zysk, ale to gra naprawdę nie warta świeczki. Tu jedynym sposobem to zastąpienie CHIP'u szybszą pamięcią i osobny mostek dla CPU. Tylko, że zmierzamy w tym momencie w kierunku całej Amigi zaimplementowanej w FPGA + pamięć DDR i... na moje czar retro pryska gdzieś w cholerę. Jest to bądź co bądź stary komputer i ma swoje ograniczenia - na swój sposób to jest w nim właśnie fajne.
Ale tak dla ciekawości, odpaliłem DOOM'a w trybie AGA i praktycznie cały czas FPS'y około 25-30 – chodzi idealnie (wrzucę filmik za niedługo). Wychodzi więc na to, że da się liczyć 3D i kopiować w całkiem sensownym czasie :)
Dlaczego część efektów w Kioea nie powala prędkością? Nie wiem i nie bardzo już mam czas drążyć. Patrząc jednak na to jak chodzi DOOM czy Quake na tym sprzęcie, wydaje mi się, że coś w samym kodzie można tam było lepiej zoptymalizować ;)
Co do bufora zapisu, naprawdę – biorąc pod uwagę przepaść pomiędzy prędkością takiej 060-tki, a CHIP-ram, nie ma to sensu. Używamy bufora zapisu, ale w mostku CPU->pamięć RTG. Tam ma to sens, bo zapisy są buforowane w momencie oczekiwania na kontroler DDR'a, ale jak DDR zaskoczy to wsysa dane z prędkością nawet do 1600MB/s. I cały zapis leci płynnie. W przypadku CHIP-ramu dostęp jest tak wolny, że bufor zapisu momentalnie się zapełni i tyle. Może byłby jakiś minimalny zysk, ale to gra naprawdę nie warta świeczki. Tu jedynym sposobem to zastąpienie CHIP'u szybszą pamięcią i osobny mostek dla CPU. Tylko, że zmierzamy w tym momencie w kierunku całej Amigi zaimplementowanej w FPGA + pamięć DDR i... na moje czar retro pryska gdzieś w cholerę. Jest to bądź co bądź stary komputer i ma swoje ograniczenia - na swój sposób to jest w nim właśnie fajne.
18.04.2019 08:41
[#730]
Re: Nowe Turbo A1200/060 - WARP 1260
@Sellen, post #729
Bufor w postaci kolejki danych do chip ma sens tylko wtedy gdy kod dema czy gry będzie przeplatał zapis z obliczeniami. W przypadku konwersji c2p tak jest robione. Powstaje jednak problem synchronizacji z ramką. Można bardzo szybko zapełnić bufor który dalej sam się opróżnia do chipu, tylko że po zapisie ostatniej danej do bufora aplikacja będzie zakładać że już wszystko jest w chip i wyświetli nową klatkę obrazu na której będziemy widzieć jak spływają ostatnie dane z bufora. Jednak gdyby użyć kilku buforów ekranu to będzie to działać, dane z bufora będą spływać do chip w czasie liczenia kolejnej klatki. Opóźni to wyświetlanie o jedną klatkę ale będzie możliwe 50fps.
Drugi problem pojawia się po uświadomieniu że chip to nie tylko obraz. Jeżeli dane dźwięku będą trafiać do chip po odczekaniu w kolejce do bufora zamiast natychmiast np. podczas przerwania vblank po zdekodowaniu mp3, to dźwięk będzie się zacinałjak na zxspectrum.
Dlategosens ma bufor mały, powiedzmy z 1kb . Zysk będzie wtedy polegał tylko na wyeliminowaniu czasu dostępu do pamięci chip i zastąpienie go czasem dostępu do szybkiego bufora, oczywiście tylko wtedy gdy obliczenia będą przeplecione z zapisem ale to chyba potrafi już procesor 030? Według mnie warto spróbować.
Ostatnia aktualizacja: 18.04.2019 08:58:41 przez Kefir_Union
Drugi problem pojawia się po uświadomieniu że chip to nie tylko obraz. Jeżeli dane dźwięku będą trafiać do chip po odczekaniu w kolejce do bufora zamiast natychmiast np. podczas przerwania vblank po zdekodowaniu mp3, to dźwięk będzie się zacinałjak na zxspectrum.
Dlategosens ma bufor mały, powiedzmy z 1kb . Zysk będzie wtedy polegał tylko na wyeliminowaniu czasu dostępu do pamięci chip i zastąpienie go czasem dostępu do szybkiego bufora, oczywiście tylko wtedy gdy obliczenia będą przeplecione z zapisem ale to chyba potrafi już procesor 030? Według mnie warto spróbować.
Ostatnia aktualizacja: 18.04.2019 08:58:41 przez Kefir_Union
18.04.2019 11:01
[#731]
Re: Nowe Turbo A1200/060 - WARP 1260
@dante, post #724
Falcon ma 'niestety' tryb chunky wbudowany w swój układ graficzny i podpięty bezpośrednio do szyny procesora.
Nie, nie ma dla trybów innych niż truecolor, czyli 16-bit w przypadku falcona. 256 kolorów jest planar. Transfery przez szynę też są słabe - po prostu dopalacz CT to naprawdę dobra karta.
Transfer do ramu mają do prawie 100 MB/s, więc jeszcze sporo roboty w Warpie jest.
link
Ostatnia aktualizacja: 18.04.2019 11:05:48 przez marianoamigo
18.04.2019 13:03
[#733]
Re: Nowe Turbo A1200/060 - WARP 1260
@WojtekX, post #732
Hej,
Super karta! Jako, iż pojawiło się porownanie z falconem (na którego popełniłem kilka dem) i kilka błednych imho informacji to postaram napis jak to wygląda wg mojej wiedzy:
- C2P jest podobne do amigowego; jest to copy-speed więc transformacje wykonują się miedzy zapisami do st/chip ram; koszt C2P to więc koszt skopiowanie danych do st/chip
- tryb TC jest 16bit i w przypadku uzywania CT60 jest zawsze złym rozwiazaniem, dużo bardziej przy 060 opłaca sie i tak robić 8bit C2P. render efektu bezposrednio do st/chip (TC) odpada. render do bufora TC w fast ram i pozniej kopia do st/chip bedzie 2 razy wolniejsza niz tryb 8bit plannar z C2P; nie ma więc tutaj zysku w stosunku do amigi
- szyna danych (do chip/st) jest 16bit'owa ale i tak jest odrobine szybsza niz w amidze z tego co wiem i to moze mieć drobny wpływ na plus falcona
- muzyka jest grana przez DSP przy 0% udziale CPU co jest kolejnym plusem, choc z tego co wiem ADPCM na amidze to tez minimalny koszt, wiec kolejny tylko minimalny plus dla falcona
- powyższe różnice są moim zdaniem jednak bardzo małe i znaczenie ma tak naprawdę to że CT60 to nowsza konstrukcja niż Blizzardy i Apollo umożliwiajaca wyższe taktowanie zegara oraz szybszy transfer do tt/fast ram; te dwie glowne przewagi właśnie niweluje Warp'a więc rożnica między F060 a Amiga będzie się imho zacierać.
MKM
Amiga rulez, Atari rulez, Warp rulez;)
PS tryb TC ma za to OGROMNE znaczenie przy demach/grach na 030 i tam rożnica dzięki niemu jest ogromna
Super karta! Jako, iż pojawiło się porownanie z falconem (na którego popełniłem kilka dem) i kilka błednych imho informacji to postaram napis jak to wygląda wg mojej wiedzy:
- C2P jest podobne do amigowego; jest to copy-speed więc transformacje wykonują się miedzy zapisami do st/chip ram; koszt C2P to więc koszt skopiowanie danych do st/chip
- tryb TC jest 16bit i w przypadku uzywania CT60 jest zawsze złym rozwiazaniem, dużo bardziej przy 060 opłaca sie i tak robić 8bit C2P. render efektu bezposrednio do st/chip (TC) odpada. render do bufora TC w fast ram i pozniej kopia do st/chip bedzie 2 razy wolniejsza niz tryb 8bit plannar z C2P; nie ma więc tutaj zysku w stosunku do amigi
- szyna danych (do chip/st) jest 16bit'owa ale i tak jest odrobine szybsza niz w amidze z tego co wiem i to moze mieć drobny wpływ na plus falcona
- muzyka jest grana przez DSP przy 0% udziale CPU co jest kolejnym plusem, choc z tego co wiem ADPCM na amidze to tez minimalny koszt, wiec kolejny tylko minimalny plus dla falcona
- powyższe różnice są moim zdaniem jednak bardzo małe i znaczenie ma tak naprawdę to że CT60 to nowsza konstrukcja niż Blizzardy i Apollo umożliwiajaca wyższe taktowanie zegara oraz szybszy transfer do tt/fast ram; te dwie glowne przewagi właśnie niweluje Warp'a więc rożnica między F060 a Amiga będzie się imho zacierać.
MKM
Amiga rulez, Atari rulez, Warp rulez;)
PS tryb TC ma za to OGROMNE znaczenie przy demach/grach na 030 i tam rożnica dzięki niemu jest ogromna
18.04.2019 14:05
[#735]
Re: Nowe Turbo A1200/060 - WARP 1260
@] SKOLMAN_MWS ˇ agrEssOr [, post #713
Na Efice pod MorphOS na emulacji procesora 68k to demo chodzi szybciej w 640x480, a tutaj jest tylko 320x240.
Gwoli sprawiedliwości, na Efice (czy generalnie na MorphOSie) demo i tak chodzi w 320x240, a do skalowania do 640x480 jest użyty zwykły pixel-doubling.
18.04.2019 14:15
[#736]
Re: Nowe Turbo A1200/060 - WARP 1260
@Sellen, post #729
CyberStorm MKII miałą ponoć jakieś cachowanie CHIPu, ale nie mam pojęcia jak to działało.
Generalnie bez przeprojektowania płyty głownej A1200 dużo zrobić się nie da.
Amiga Reloaded od Jensa miała mieć szybsze pamięci CHIP:
http://wiki.icomp.de/wiki/Amiga_reloaded
Ale projekt chyba padł.
Generalnie bez przeprojektowania płyty głownej A1200 dużo zrobić się nie da.
Amiga Reloaded od Jensa miała mieć szybsze pamięci CHIP:
http://wiki.icomp.de/wiki/Amiga_reloaded
Ale projekt chyba padł.
18.04.2019 16:13
[#738]
Re: Nowe Turbo A1200/060 - WARP 1260
@marianoamigo, post #731
Nie mam nic przeciwko (rzetelnym) porównaniom i jak już pisałem wcześniej – jest jeszcze pole do popisu w sensie optymalizacji 'wsadu' do karty Warp. Pisałem o nowym cache, który się pojawi i nie powstanie on z nudów, ale właśnie dlatego, że w niektórych operacjach będzie znacznie szybszy.
Zwróćcie tylko uwagę, że często rzucanie numerkami z wiki czy innych źródeł jest kompletnie bez sensu. Piszesz:
To np. proszę bardzo, oto transfery (kopiowanie danych obrazu) z odpalonej na A1200+Warp gry Quake:
częstotliwość samplowania szyny w tym wypadku to 200MHz, czyli 5ns na próbkę.
Tutaj obliczenia prędkości transferu z serii 14 operacji CPU na szynie:
133,5MB/s
No i co? Mógłbym powiedzieć,
Tyle tylko, że takie wyrwane z kontekstu porównania są kompletnie bez sensu.
Dlaczego? – bo SDRAM czy DDR to nie pamięć statyczna z takim samym czasem dostępu w każdym wypadku. Prędkość jest mocno uzależniona od tego jakie operacje i w jakiej kolejności są wykonywane. Czy te 100MB/s w CT to był zapis czy odczyt, sekwencyjny, czy może losowy, z różnych rzędów SDRAM'u? A może naprzemiennie z różnych banków?.
Zobacz np. inny przykład: wyniki sysspeed rysowania lini truecolor (karta CV64):
linie poziome : 15309 /s
linie pionowe : 6585 /s
2,3 krotna różnica prędkości (!!)
Czy algorytm rysowania pionowej linii jest bardziej skomplikowany niż poziomej? O ile mi wiadomo to nie. Skąd więc aż taka różnica? Wynika właśnie z tego że przy poziomej linii dane lecą do pamięci sekwencyjnie, a przy pionowej trzeba co piksel skakać po adresach. Co już dla pamięci innych niż statyczna jest mniej efektywne. I co jeśli np. na jednej platformie zapuścimy test, który bada zapis/odczyt sekwencyjnie, a na drugiej platformie np. adresy będą generowane pseudolosowo? Różnice będą ogromne, ktoś później sobie porówna dwie cyferki i powie Oooo, ta karta świetna, a tamta do d.... A w rzeczywistości oba sprzęty mogą mieć identyczną wydajność.
Jakikolwiek sens miałby tylko test napisany w asm – identyczny linia w linię na jednej i drugiej platformie. Najlepiej jeszcze przy wyłączonych przerwaniach itp. żeby uniknąć wpływu różnej ich obsługi na całkiem różnych systemach operacyjnych.
I na koniec jeszcze: nie mam tu na celu jakiejkolwiek krytyki kart CT, są to świetne, dobrze przemyślane i z tego co wiem dopracowane sprzęty.
Tylko jako osoba, która od miesięcy siedzi prawie w dzień w dzień (czy raczej noc w noc) do 4-tej rano nad projektem, wkurzam się jak ktoś bez merytorycznych podstaw rzuca mi jakimś numerkiem z wikipedii wyrwanym z kontekstu.
Zwróćcie tylko uwagę, że często rzucanie numerkami z wiki czy innych źródeł jest kompletnie bez sensu. Piszesz:
Transfer do ramu mają do prawie 100 MB/s, więc jeszcze sporo roboty w Warpie jest.
To np. proszę bardzo, oto transfery (kopiowanie danych obrazu) z odpalonej na A1200+Warp gry Quake:
częstotliwość samplowania szyny w tym wypadku to 200MHz, czyli 5ns na próbkę.
Tutaj obliczenia prędkości transferu z serii 14 operacji CPU na szynie:
133,5MB/s
No i co? Mógłbym powiedzieć,
więc jeszcze sporo roboty w CT jest.
Tyle tylko, że takie wyrwane z kontekstu porównania są kompletnie bez sensu.
Dlaczego? – bo SDRAM czy DDR to nie pamięć statyczna z takim samym czasem dostępu w każdym wypadku. Prędkość jest mocno uzależniona od tego jakie operacje i w jakiej kolejności są wykonywane. Czy te 100MB/s w CT to był zapis czy odczyt, sekwencyjny, czy może losowy, z różnych rzędów SDRAM'u? A może naprzemiennie z różnych banków?.
Zobacz np. inny przykład: wyniki sysspeed rysowania lini truecolor (karta CV64):
linie poziome : 15309 /s
linie pionowe : 6585 /s
2,3 krotna różnica prędkości (!!)
Czy algorytm rysowania pionowej linii jest bardziej skomplikowany niż poziomej? O ile mi wiadomo to nie. Skąd więc aż taka różnica? Wynika właśnie z tego że przy poziomej linii dane lecą do pamięci sekwencyjnie, a przy pionowej trzeba co piksel skakać po adresach. Co już dla pamięci innych niż statyczna jest mniej efektywne. I co jeśli np. na jednej platformie zapuścimy test, który bada zapis/odczyt sekwencyjnie, a na drugiej platformie np. adresy będą generowane pseudolosowo? Różnice będą ogromne, ktoś później sobie porówna dwie cyferki i powie Oooo, ta karta świetna, a tamta do d.... A w rzeczywistości oba sprzęty mogą mieć identyczną wydajność.
Jakikolwiek sens miałby tylko test napisany w asm – identyczny linia w linię na jednej i drugiej platformie. Najlepiej jeszcze przy wyłączonych przerwaniach itp. żeby uniknąć wpływu różnej ich obsługi na całkiem różnych systemach operacyjnych.
I na koniec jeszcze: nie mam tu na celu jakiejkolwiek krytyki kart CT, są to świetne, dobrze przemyślane i z tego co wiem dopracowane sprzęty.
Tylko jako osoba, która od miesięcy siedzi prawie w dzień w dzień (czy raczej noc w noc) do 4-tej rano nad projektem, wkurzam się jak ktoś bez merytorycznych podstaw rzuca mi jakimś numerkiem z wikipedii wyrwanym z kontekstu.
18.04.2019 16:40
[#739]
Re: Nowe Turbo A1200/060 - WARP 1260
@makarsky, post #737
Da się, trzeba zrobić bufor 2MB mapowany na pamięć chip. Tylko wtedy jest problem z opóźnieniami związanymi z asynchronicznym działaniem bufora i aplikacji oraz wynikające z tego rozjeżdżanie się danych, które są w dwóch miejscach.
Dodałbym rejestr kontrolny na karcie, którym można bufor w dowolnym momencie wyłączać a także sprawdzać czy skończył mapować do chipu. Sam bufor miałby postać kolejki do której wstawiałyby się dane podczas próby zapisu do niego.
Programista chcąc zapisać obraz z funkcji c2p robiłby to do mapowanego obszaru pamięci na karcie, a następnie zajmował się następną klatką obrazu. Potem na przerwaniu VBLANK sprawdzi w rejestrze kontrolnym czy bufor został opróżniony, jeśli tak to można ustawić coppera na nową klatkę, która już w całości znalazła się w prawdziwym chip. Jeśli algorytm generowania obrazu na to pozwoli można też przeplatać kod konwersji z kodem rysowania dzieląc ekran to poziome pasy. To da karcie czas na kopiowanie do chip w czasie gdy będzie liczony następny pas obrazu.
Tak, w ogóle, skoro programista musiałbny przerobić kod pod Warpa, to od razu dać logikę konwersji c2p, niech karta asynchronicznie mapuje bufor od razu z konwersją na bitplany
. To byłoby nawet jeszcze prostsze, programista kopiuje do bufora, wskazuje go karcie i karta w tle konwertuje i zapisuje do chipu a następnie ustawia bity w rejestrze kontrolnym albo wywołuje przerwanie że już skończyła. Takie lepsze Akiko, algorytm konwersji przecież jest banalny do implementacji w hardware.
Ostatnia aktualizacja: 18.04.2019 17:00:15 przez Kefir_Union
Dodałbym rejestr kontrolny na karcie, którym można bufor w dowolnym momencie wyłączać a także sprawdzać czy skończył mapować do chipu. Sam bufor miałby postać kolejki do której wstawiałyby się dane podczas próby zapisu do niego.
Programista chcąc zapisać obraz z funkcji c2p robiłby to do mapowanego obszaru pamięci na karcie, a następnie zajmował się następną klatką obrazu. Potem na przerwaniu VBLANK sprawdzi w rejestrze kontrolnym czy bufor został opróżniony, jeśli tak to można ustawić coppera na nową klatkę, która już w całości znalazła się w prawdziwym chip. Jeśli algorytm generowania obrazu na to pozwoli można też przeplatać kod konwersji z kodem rysowania dzieląc ekran to poziome pasy. To da karcie czas na kopiowanie do chip w czasie gdy będzie liczony następny pas obrazu.
Tak, w ogóle, skoro programista musiałbny przerobić kod pod Warpa, to od razu dać logikę konwersji c2p, niech karta asynchronicznie mapuje bufor od razu z konwersją na bitplany
. To byłoby nawet jeszcze prostsze, programista kopiuje do bufora, wskazuje go karcie i karta w tle konwertuje i zapisuje do chipu a następnie ustawia bity w rejestrze kontrolnym albo wywołuje przerwanie że już skończyła. Takie lepsze Akiko, algorytm konwersji przecież jest banalny do implementacji w hardware.Ostatnia aktualizacja: 18.04.2019 17:00:15 przez Kefir_Union
18.04.2019 16:46
[#741]
Re: Nowe Turbo A1200/060 - WARP 1260
@Kefir_Union, post #739
Kefir: Nie chodziło mi o bufor, tylko odcięcie powolnej pamięci fabrycznej i obsługę tego obszaru przez pamięć na karcie.
Być może pomocne by tu było złącze rozszerzenia pamięci przewidziane przez C= a finalnie nieużyte ?
Ostatnia aktualizacja: 18.04.2019 16:46:31 przez makarsky
Być może pomocne by tu było złącze rozszerzenia pamięci przewidziane przez C= a finalnie nieużyte ?
Ostatnia aktualizacja: 18.04.2019 16:46:31 przez makarsky
18.04.2019 18:02
[#743]
Re: Nowe Turbo A1200/060 - WARP 1260
@Sellen, post #738
Panowie, nie zapominajcie, że Sellen obecnie sam ogarnia ten kawał pracy.
Czasu na optymalizację jeszcze będzie.
Pięknie ujęte
Czasu na optymalizację jeszcze będzie.
nie chcemy w nieskończoność tworzyć nowych wersji i przeciągać wypuszczenia karty na świat
Tu jedynym sposobem to zastąpienie CHIP'u szybszą pamięcią i osobny mostek dla CPU. Tylko, że zmierzamy w tym momencie w kierunku całej Amigi zaimplementowanej w FPGA + pamięć DDR i... na moje czar retro pryska gdzieś w cholerę. Jest to bądź co bądź stary komputer i ma swoje ograniczenia - na swój sposób to jest w nim właśnie fajne
Pięknie ujęte
18.04.2019 20:10
[#745]
Re: Nowe Turbo A1200/060 - WARP 1260
@Sellen, post #729
Prędkość szyny, chipsetu oraz operacji na CHIP-RAM nie będą się różnić. Taktowanie cykli DMA jest dokładnie takie samo (o ile pamiętam to 3,54MHz) i różnice w wynikach testów mogą wynikać jedynie z obciążenia DMA i ilości slotów, które są w danym momencie do dyspozycji CPU.
Co do bufora w A4000 to możliwe, że to było faktycznie tylko na kartach CyberStorm, a nie w samej architekturze A4000 - jak odszukam źródło tej informacji to się podzielę.
Co do samego pomysłu na write buffer do pamięci CHIP-RAM - to w żadnym wypadku moją intencją nie było przekonywanie, że to jakoś przyspieszy operacje na samej pamięci CHIP-RAM, ale to czego jestem pewien to na pewno pozwoliłoby to rozwinąć skrzydła procesorowi 060 w trybie AGA.
Postaram się to wytłumaczyć na uproszczonym przykładzie efektu 3D pod 060+AGA ze wskazaniem jakie zasoby są w danym kroku wykorzystywane i jak wygląda utylizacja CPU, przy następujących założeniach:
- efekt działa z prędkością 25 FPS (idealne warunki - stałe FPS)
- działamy wg 'nowożytnego' podejścia, czyli robimy C2P FAST-RAM->FAST-RAM i tylko kopiujemy do CHIP-RAM (ogólnie kopiowanie odbywa się przy wyłączonym DMA bitplane'ów i jest rozbite na kilka ramek - w dużym uproszczeniu można powiedzieć, że kopiowanie do CHIP-RAM odbywa się tylko podczas VBLANK - ale dla tego przykładu to pomijam bo to by mocno skomplikowało)
- czasy poszczególnych kroków podane w nawiasach są przykładowe, żeby mniej więcej pokazać proporcje ile na co potrzeba czasu i podane są w 'ramkach', a 1 ramka to oczywiście 1/50 sekundy
- celowo pomijam double buffer dla bitplane'ów, co w rzeczywistości jest tylko zmianą adresu w pamięci CHIP-RAM pod który kopiowane są dane bufora plannar
W krokach 1 i 2 utylizacja CPU i szyny do FAST-RAM na 100%.
Natomiast krok 3 w uproszczonym rozkładzie na operacje wyglada tak:
W momencie kiedy CPU komunikuje się z DMA, nie działa architektura superscalar i wszystkie te operacje są wykonywane sekwencyjnie.
W kroku 1 można odczytać dane do kilku rejestrów jednocześnie, ale kroki 2-5 i tak będą wykonywane sekwencyjnie jeden po drugim dla każdego rejestru więc celowo to uprościłem w tym przykładzie.
A teraz do rzeczy...
Ideą write buffera CHIP-RAM jest pozbycie się bezpośredniej komunikacji CPU z DMA przez zastąpienie powyższych kroków 2-5 jedną operacją zapisu do write buffera, który byłby widoczny dla CPU w taki sam sposób jak FAST-RAM (w przypadku WARP'a z 0 wait state, dzięki kolejkowaniu zapisów do DDR).
Po takiej zmianie krok 3 w uproszczonym rozkładzie na operacje wyglada tak:
Jako że nie ma bezpośredniej komunikacji z DMA pozbywamy się wszystkich stalli CPU i wtedy nasz efekt wygląda tak:
Odzyskujemy 0.5 ramki, w których de facto nasze ulubione 060 i tak nic nie robiło bo czekało na DMA, które możemy spożytkować na bardziej wyrafinowany RenderFrame, albo przynajmniej mieć pewność że dzięki temu odzyskanemu czasowi nasz efekt będzie chodził ze stałą prędkością 25FPS, a nie 'szarpał' od czasu do czasu jak to zwykle się dzieje gdy jedziemy z timingami po bandzie.
W praktyce czas potrzebny na C2P może być jeszcze mniejszy niż te łączne 0.5 ramki - kiedyś liczyłem i z tego co pamiętam wychodziło mi, że samo C2P FAST-RAM->FAST-RAM na 060, Amiga jest w stanie wykonywać z prędkością ok. 200 FPS czyli właśnie 0.25 ramki - więc mając write buffer do CHIP-RAM odpowiedniej wielkości, zachowujący się jak pamięć FAST-RAM można by wrócić do robienia C2P klasycznie czyli konwersja z zapisem bezpośrednio do write buffera CHIP-RAM i zmieścić cały C2P (konwersja + bezpośredni zapis) w 0.25 ramki.
Pozostaje kwestia kiedy dane planarne przechowywane w write bufferze w rzeczywistości trafią do CHIP-RAM żeby układ graficzny mógł je wyświetlić. To oczywiście musi się dziać asynchronicznie i nawet niech sobie trwa te 0.75 ramki - to nie wpłynie na płynność działania efektu bo i tak na wyrenderowanie jednej klatki efektu potrzebne jest 1.5 ramki. A w szczegółach od zakończenia zapisu do write buffera danych klatki 1 do rozpoczęcia zapisu do write buffera danych klatki 2 upłynie minimum 1.25 ramki w tym przypadku, więc jeśli bufor jest odpowiedniej wielkości np. 64KB (czyli pomieści 320x200 8bit w palecie indeksowanej) to nie ma co się martwić o jego przepełnienie. Oczywiście najlepiej jakby bufor był wielkości 128KB bo wtedy to i 320x200 w 18bit true color (czyli 640x200 HAM8) dałoby się przez niego przepychać.
Na koniec... Uważam, że przy tym rozwiązaniu nie są potrzebne żadne dodatkowe rejestry na karcie czy przerwania mówiące o stanie write buffera CHIP-RAM. Nie grozi nam żaden tearing. Wszystko to kwestia odpowiedniego zakodowania efektu (HINT: double plannar buffer w FAST-RAM + stary dobry Copper'owy double buffering danych skopiowanych do CHIP-RAM)
Zastosowanie mechanizmu tego typu, nie wymaga żadnych ingerencji w chipset Amigi, a mogłoby w rzeczywistości 'upłynnić' wiele demek 060+AGA i w ostatecznym odbiorze użytkownika zbliżyć je wydajnościowo do 060+RTG lub Falcona, jako że na RTG czy Falconie demka też nie chodzą w 50 FPS, ale działają płynniej - bo CPU przez cały czas jest utylizowane na 100%, a tylko wtedy jest w stanie pokazać na co faktycznie go stać, a nie wtedy gdy przez ok. 35% czasu renderowania klatki CPU jest stalled czekając na operacje DMA...
Ostatnia aktualizacja: 18.04.2019 20:24:36 przez dante
Co do bufora w A4000 to możliwe, że to było faktycznie tylko na kartach CyberStorm, a nie w samej architekturze A4000 - jak odszukam źródło tej informacji to się podzielę.
Co do samego pomysłu na write buffer do pamięci CHIP-RAM - to w żadnym wypadku moją intencją nie było przekonywanie, że to jakoś przyspieszy operacje na samej pamięci CHIP-RAM, ale to czego jestem pewien to na pewno pozwoliłoby to rozwinąć skrzydła procesorowi 060 w trybie AGA.
Postaram się to wytłumaczyć na uproszczonym przykładzie efektu 3D pod 060+AGA ze wskazaniem jakie zasoby są w danym kroku wykorzystywane i jak wygląda utylizacja CPU, przy następujących założeniach:
- efekt działa z prędkością 25 FPS (idealne warunki - stałe FPS)
- działamy wg 'nowożytnego' podejścia, czyli robimy C2P FAST-RAM->FAST-RAM i tylko kopiujemy do CHIP-RAM (ogólnie kopiowanie odbywa się przy wyłączonym DMA bitplane'ów i jest rozbite na kilka ramek - w dużym uproszczeniu można powiedzieć, że kopiowanie do CHIP-RAM odbywa się tylko podczas VBLANK - ale dla tego przykładu to pomijam bo to by mocno skomplikowało)
- czasy poszczególnych kroków podane w nawiasach są przykładowe, żeby mniej więcej pokazać proporcje ile na co potrzeba czasu i podane są w 'ramkach', a 1 ramka to oczywiście 1/50 sekundy
- celowo pomijam double buffer dla bitplane'ów, co w rzeczywistości jest tylko zmianą adresu w pamięci CHIP-RAM pod który kopiowane są dane bufora plannar
1. RenderFrame (1 ramka) - CPU czyta z FAST-RAM, wykonuje obliczenia, zapisuje do FAST-RAM (bufor chunky) 2. C2P (krok 1 - konwersja) (0.25 ramki) - CPU czyta z FAST-RAM (bufor chunky), wykonuje konwersję, zapisuje do FAST-RAM (bufor plannar) 3. C2P (krok 2 - kopiowanie) (0.75 ramki) - CPU czyta z FAST-RAM, zapisuje do CHIP-RAM 4. GOTO 1
W krokach 1 i 2 utylizacja CPU i szyny do FAST-RAM na 100%.
Natomiast krok 3 w uproszczonym rozkładzie na operacje wyglada tak:
1. CPU czyta komórkę FAST-RAM do rejestru 2. CPU czeka na wolny slot DMA (CPU stalled) 3. CPU zapisuje dane z rejestru do wystawionego slotu DMA 4. DMA zapisuje dane ze slotu do pamięci CHIP-RAM (CPU stalled) 5. CPU dostaje potwierdzenie zapisu danych do pamięci CHIP-RAM 6. GOTO 1
W momencie kiedy CPU komunikuje się z DMA, nie działa architektura superscalar i wszystkie te operacje są wykonywane sekwencyjnie.
W kroku 1 można odczytać dane do kilku rejestrów jednocześnie, ale kroki 2-5 i tak będą wykonywane sekwencyjnie jeden po drugim dla każdego rejestru więc celowo to uprościłem w tym przykładzie.
A teraz do rzeczy...
Ideą write buffera CHIP-RAM jest pozbycie się bezpośredniej komunikacji CPU z DMA przez zastąpienie powyższych kroków 2-5 jedną operacją zapisu do write buffera, który byłby widoczny dla CPU w taki sam sposób jak FAST-RAM (w przypadku WARP'a z 0 wait state, dzięki kolejkowaniu zapisów do DDR).
Po takiej zmianie krok 3 w uproszczonym rozkładzie na operacje wyglada tak:
1. CPU czyta komórkę FAST-RAM do rejestru 2. CPU zapisuje dane z rejestru do write buffera CHIP-RAM 3. GOTO 1
Jako że nie ma bezpośredniej komunikacji z DMA pozbywamy się wszystkich stalli CPU i wtedy nasz efekt wygląda tak:
1. RenderFrame (1 ramka) - CPU czyta z FAST-RAM, wykonuje obliczenia, zapisuje do FAST-RAM (bufor chunky) 2. C2P (krok 1 - konwersja) (0.25 ramki) - CPU czyta z FAST-RAM (bufor chunky), wykonuje konwersję, zapisuje do FAST-RAM (bufor plannar) 3. C2P (krok 2 - kopiowanie) (0.25 ramki) - CPU czyta z FAST-RAM, zapisuje do write buffera CHIP-RAM 4. GOTO 1
Odzyskujemy 0.5 ramki, w których de facto nasze ulubione 060 i tak nic nie robiło bo czekało na DMA, które możemy spożytkować na bardziej wyrafinowany RenderFrame, albo przynajmniej mieć pewność że dzięki temu odzyskanemu czasowi nasz efekt będzie chodził ze stałą prędkością 25FPS, a nie 'szarpał' od czasu do czasu jak to zwykle się dzieje gdy jedziemy z timingami po bandzie.
W praktyce czas potrzebny na C2P może być jeszcze mniejszy niż te łączne 0.5 ramki - kiedyś liczyłem i z tego co pamiętam wychodziło mi, że samo C2P FAST-RAM->FAST-RAM na 060, Amiga jest w stanie wykonywać z prędkością ok. 200 FPS czyli właśnie 0.25 ramki - więc mając write buffer do CHIP-RAM odpowiedniej wielkości, zachowujący się jak pamięć FAST-RAM można by wrócić do robienia C2P klasycznie czyli konwersja z zapisem bezpośrednio do write buffera CHIP-RAM i zmieścić cały C2P (konwersja + bezpośredni zapis) w 0.25 ramki.
Pozostaje kwestia kiedy dane planarne przechowywane w write bufferze w rzeczywistości trafią do CHIP-RAM żeby układ graficzny mógł je wyświetlić. To oczywiście musi się dziać asynchronicznie i nawet niech sobie trwa te 0.75 ramki - to nie wpłynie na płynność działania efektu bo i tak na wyrenderowanie jednej klatki efektu potrzebne jest 1.5 ramki. A w szczegółach od zakończenia zapisu do write buffera danych klatki 1 do rozpoczęcia zapisu do write buffera danych klatki 2 upłynie minimum 1.25 ramki w tym przypadku, więc jeśli bufor jest odpowiedniej wielkości np. 64KB (czyli pomieści 320x200 8bit w palecie indeksowanej) to nie ma co się martwić o jego przepełnienie. Oczywiście najlepiej jakby bufor był wielkości 128KB bo wtedy to i 320x200 w 18bit true color (czyli 640x200 HAM8) dałoby się przez niego przepychać.
Na koniec... Uważam, że przy tym rozwiązaniu nie są potrzebne żadne dodatkowe rejestry na karcie czy przerwania mówiące o stanie write buffera CHIP-RAM. Nie grozi nam żaden tearing. Wszystko to kwestia odpowiedniego zakodowania efektu
(HINT: double plannar buffer w FAST-RAM + stary dobry Copper'owy double buffering danych skopiowanych do CHIP-RAM) Zastosowanie mechanizmu tego typu, nie wymaga żadnych ingerencji w chipset Amigi, a mogłoby w rzeczywistości 'upłynnić' wiele demek 060+AGA i w ostatecznym odbiorze użytkownika zbliżyć je wydajnościowo do 060+RTG lub Falcona, jako że na RTG czy Falconie demka też nie chodzą w 50 FPS, ale działają płynniej - bo CPU przez cały czas jest utylizowane na 100%, a tylko wtedy jest w stanie pokazać na co faktycznie go stać, a nie wtedy gdy przez ok. 35% czasu renderowania klatki CPU jest stalled czekając na operacje DMA...
Ostatnia aktualizacja: 18.04.2019 20:24:36 przez dante
18.04.2019 20:19
[#746]
Re: Nowe Turbo A1200/060 - WARP 1260
@makarsky, post #741
to złącze jest nie użyte ( nawet nie ma wlutowanych pinów ) ponieważ tam nie ma już wolnych adresów, A1200 miała mieć 1MB chip i przez to złącze miało się dać rozbudować do 2MB.
Jak Masz A1200 z 1MB to można z niego skorzystać do rozbudowy CHIPu, jak jednak Masz "trochę" popularniejszy model z 2MB to jest ono bezużyteczne ( chyba że w ogóle Wywalisz CHIP z płyty), poza tym wydaje mi się że wstawienie szybszych pamięci tam nic by nie przyśpieszyło bez ingerencji w chipset Amigi.
Też uważam że nie ma co ruszać chipsetu Amigi, posypie się kompatybilność z dotychczasowym softem ( szczególnie dema i gry ), nie potrzebnie skomplikuje cały projekt, a i tak dużo by to nie dało, w pełni takie "fjuczery" wykorzystywał by nowy soft, a ten można już pisać pod RTG gdzie nie ma takich ograniczeń.
No i kto by pisał soft na tak niszowe rozwiązanie ? AGA/ECS czy RTG to jednak standard, a to rozwiązanie ograniczałoby się do Warpów
Ostatnia aktualizacja: 18.04.2019 20:32:20 przez UJP
Jak Masz A1200 z 1MB to można z niego skorzystać do rozbudowy CHIPu, jak jednak Masz "trochę" popularniejszy model z 2MB to jest ono bezużyteczne ( chyba że w ogóle Wywalisz CHIP z płyty), poza tym wydaje mi się że wstawienie szybszych pamięci tam nic by nie przyśpieszyło bez ingerencji w chipset Amigi.
Też uważam że nie ma co ruszać chipsetu Amigi, posypie się kompatybilność z dotychczasowym softem ( szczególnie dema i gry ), nie potrzebnie skomplikuje cały projekt, a i tak dużo by to nie dało, w pełni takie "fjuczery" wykorzystywał by nowy soft, a ten można już pisać pod RTG gdzie nie ma takich ograniczeń.
No i kto by pisał soft na tak niszowe rozwiązanie ? AGA/ECS czy RTG to jednak standard, a to rozwiązanie ograniczałoby się do Warpów
Ostatnia aktualizacja: 18.04.2019 20:32:20 przez UJP
18.04.2019 20:43
[#747]
Re: Nowe Turbo A1200/060 - WARP 1260
Byłoby super, gdyby ta lista była w spoilerze, albo tylko w pierwszym poście.
Czy ona ma w ogóle jakieś znaczenie dla producentów? Czy jest to tylko wykaz zainteresowania kartą?
Czy osoby spoza listy kupią kartę na identycznych warunkach? Pytam o zasadność wpisywania się.
Czy ona ma w ogóle jakieś znaczenie dla producentów? Czy jest to tylko wykaz zainteresowania kartą?
Czy osoby spoza listy kupią kartę na identycznych warunkach? Pytam o zasadność wpisywania się.
18.04.2019 20:50
[#748]
Re: Nowe Turbo A1200/060 - WARP 1260
@Ralpheeck, post #747
Byłoby super, gdyby ta lista była w spoilerze, albo tylko w pierwszym poście.
Czy ona ma w ogóle jakieś znaczenie dla producentów? Czy jest to tylko wykaz zainteresowania kartą?
Czy osoby spoza listy kupią kartę na identycznych warunkach? Pytam o zasadność wpisywania się.
Ja z takiej listy kupiłem kartę Wicher - kolejność była honorowana przez producenta.
18.04.2019 20:53
[#749]
Re: Nowe Turbo A1200/060 - WARP 1260
@UJP, post #746
Też uważam że nie ma co ruszać chipsetu Amigi, posypie się kompatybilność z dotychczasowym softem
Na kompatybilności najbardziej mi zależy.
Kombinacje "Alpejskie" zostawmy dla FPGA.
Drużyna WARPA nie jest duża i "grzebanie" przy szynie Chipsetu, może powodować nieoczekiwane problemy. Nie obędzie się bez testów,testów i testów. Wg mnie szkoda na to czasu... dla kilku klatek więcej w demie? Nowy soft? Wszyscy by chcieli, a mało kto pisze.
Zostańmy bliżej ziemi.
Chłopaki i tak odwalili kawał dobrej roboty. Z natury jestem bardzo krytyczny, ale tutaj nie mam na co. Może później ponażekam na kolor laminatu
żeby chłopakom nie urosły za duże skrzydła Ostatnia aktualizacja: 18.04.2019 20:54:18 przez snifferman
