19.05.2012 01:12
[#65]
Re: Nadchodzi Doom 3 dla Arosa :P
@azazel44, post #62
konstrukcja AmigaOS w zasadzie nie pozwala na obsługę dwóch procesorów. AROS odziedziczył niestety to ograniczenie bo jest prawdziwym ami-systemem 
AROS prędzej się doczeka obsługi GPGPU przez OpenCL niż obsługi wielu rdzeni.
Jest też możliwość obsługiwania rdzeni przez OpenCL także, wtedy nie trzeba by zmieniać nic w systemie
AROS prędzej się doczeka obsługi GPGPU przez OpenCL niż obsługi wielu rdzeni.
Jest też możliwość obsługiwania rdzeni przez OpenCL także, wtedy nie trzeba by zmieniać nic w systemie
19.05.2012 03:04
[#66]
Re: Nadchodzi Doom 3 dla Arosa :P
@XoR, post #64
Wystarczy kompatybilność z 3.x, no chyba że to też zostało olane :)
UAE działa dobrze pod windą, UAE to tylko dodatek, jeśli chciałbyś użyć UAE jako argumentu kompatybilności :P :)
Doom3 nawet bez pixel shaders itd, to i tak będzie bardzo dużo.
Fajnie by było na MOSie go odpalić:)
UAE działa dobrze pod windą, UAE to tylko dodatek, jeśli chciałbyś użyć UAE jako argumentu kompatybilności :P :)
Doom3 nawet bez pixel shaders itd, to i tak będzie bardzo dużo.
Fajnie by było na MOSie go odpalić:)
19.05.2012 10:20
[#67]
Re: Nadchodzi Doom 3 dla Arosa :P
@kjb666, post #66
kompatybilność bez użycia amibridge zostanie dodana wraz z rozwojem AROSa 68K. Chwilowo leci to przez emulator z zainstalowanym AOS3.x W sumie działa dobrze więc tragedii nie ma 
a Doom3 na MOSa... cóż to tylko i wyłącznie kwestia rozwoju OpenGLa w tym OSie. Sprzęt na którym większość ludzi używa MOSa posiada możliwość odpalenia tej gry
ps. może jeszcze zajść potrzeba przepisania wstawek z ASM na C/asm_ppc...
a Doom3 na MOSa... cóż to tylko i wyłącznie kwestia rozwoju OpenGLa w tym OSie. Sprzęt na którym większość ludzi używa MOSa posiada możliwość odpalenia tej gry
ps. może jeszcze zajść potrzeba przepisania wstawek z ASM na C/asm_ppc...
19.05.2012 13:07
[#68]
Re: Nadchodzi Doom 3 dla Arosa :P
@XoR, post #65
konstrukcja AmigaOS w zasadzie nie pozwala na obsługę dwóch procesorów.
Hola, a co z custom chipami w Amigach?? Przecież pełnią rolę koprocesorów, które mają takie same uprawnienia jak główny procesor. Exec.library ma obsługę przerwań i semaforów, jest też wielozadaniowy. Myślę, że obsługa kilku (ko)procesorów nie sprawia trudności AmigaOS, chyba że czegoś nie wiem.
19.05.2012 13:23
[#69]
Re: Nadchodzi Doom 3 dla Arosa :P
@Robert-Minimat-Szacki, post #68
Raczysz zartowac, custom chipy to nie koprocesory. Specifika koprocesora (jak na razie sa tylko matematyczne :) ) w aos wymaga "przelaczenia" go w tryb koprocesora poprzez linie F.
Poczytaj sobie: http://mikro.naprvyraz.sk/docs/FPU/881_ASM.TXT
Poczytaj sobie: http://mikro.naprvyraz.sk/docs/FPU/881_ASM.TXT
19.05.2012 13:30
[#70]
Re: Nadchodzi Doom 3 dla Arosa :P
@AmiChris, post #69
Zgadzam się z Tobą, że procesor M680x0 musi przełączać się w tryb koprocesora zmiennoprzecinkowego M68881/2, żeby się z nim porozumieć, ale nie zgodzę się, że custom chipy to nie koprocesory. Jeden nazywa się nawet copperem (czyli koprocesorem) i pracuje niezależnie od procesora głównego i ma również DMA (bezpośredni dostęp) do pamięci CHIP.
P.S. Z dokumentu, który załączyłeś łatwo też wywnioskować, że FPU pracuje niezależnie i tylko sygnalizuje procesorowi głównemu o jakichś wydarzeniach lub prośbach.
Ostatnia aktualizacja: 19.05.2012 13:33:57 przez Robert-Minimat-Szacki
P.S. Z dokumentu, który załączyłeś łatwo też wywnioskować, że FPU pracuje niezależnie i tylko sygnalizuje procesorowi głównemu o jakichś wydarzeniach lub prośbach.
Ostatnia aktualizacja: 19.05.2012 13:33:57 przez Robert-Minimat-Szacki
19.05.2012 13:46
[#72]
Re: Nadchodzi Doom 3 dla Arosa :P
@Robert-Minimat-Szacki, post #68
jako koprocesor to może i tak tyle że mi się rozchodzi tutaj o prawdziwe SMP/SMT
rozwiązanie koprocesorowe jako takie może się okazać mocno uciążliwe dla programistów oprogramowania, na tyle że i tak ich nie użyją...
dlatego też imho OpenCL jest dobrym wyjściem bo byłby dostęp do wszystkich zasobów, zarówno pozostałych rdzeni CPU jak i ogromnego potencjału GPGPU a także nie trzeba by zaburzać struktury systemu. Też było by to deko uciążliwe ale w sumie że i tak świat IT idzie w tą stronę to...
Na szczęście OpenCL prędzej czy później będzie, przynajmniej aby używac GPGPU a co do rdzeni to może ktoś coś mądrego wreszcie wymyśli. Swoją droga bardzo mnie ciekawi jak to rozwiąże Hyperion w AmigaOS4
Ostatnia aktualizacja: 19.05.2012 13:48:48 przez XoR
rozwiązanie koprocesorowe jako takie może się okazać mocno uciążliwe dla programistów oprogramowania, na tyle że i tak ich nie użyją...
dlatego też imho OpenCL jest dobrym wyjściem bo byłby dostęp do wszystkich zasobów, zarówno pozostałych rdzeni CPU jak i ogromnego potencjału GPGPU a także nie trzeba by zaburzać struktury systemu. Też było by to deko uciążliwe ale w sumie że i tak świat IT idzie w tą stronę to...
Na szczęście OpenCL prędzej czy później będzie, przynajmniej aby używac GPGPU a co do rdzeni to może ktoś coś mądrego wreszcie wymyśli. Swoją droga bardzo mnie ciekawi jak to rozwiąże Hyperion w AmigaOS4
Ostatnia aktualizacja: 19.05.2012 13:48:48 przez XoR
19.05.2012 14:11
[#75]
Re: Nadchodzi Doom 3 dla Arosa :P
@Robert-Minimat-Szacki, post #70
ULA w ZX Spectrum też działała niezależnie od procesora głównego, a co więcej, rządziła nim, bo potrafiła zatrzymać jego pracę - czy też można powiedzieć, że to był dwuprocesorowy komputer? Różnica pomiędzy koprocesorem a drugim procesorem/rdzeniem jest zasadnicza. Na szynę można sobie wpinać róże układy (vel. Akiko w CD32), ale nie oznacza to wcale, że Amiga jest wieloprocesorowa...
19.05.2012 14:27
[#76]
Re: Nadchodzi Doom 3 dla Arosa :P
@Robert-Minimat-Szacki, post #70
To moze tak na szybko jeszcze, custom chipy to jednostki potrafiace wykonywac pewne wyspecjalizowane operacje. Koprocesory to uklady wyposazone w jakis instruction set, dlatego tez Copper nazwano koprocesorem bo posiada 3 instrukcje.
Jednakze nadal nie ma on uprawnien CPU.
Co do wielozadaniowosci i przerwania o ktorych wspomniales, wcale nie oznaczaja wieloprocesowsci kolego. Nie da sie aktualnie zaimplementowac wieloprocesowsci w aos bez utraty kompatybilnosci, co najwyzej za pomoca pewnego rodzaju wywlaszczenia.
Jednakze nadal nie ma on uprawnien CPU.
Co do wielozadaniowosci i przerwania o ktorych wspomniales, wcale nie oznaczaja wieloprocesowsci kolego. Nie da sie aktualnie zaimplementowac wieloprocesowsci w aos bez utraty kompatybilnosci, co najwyzej za pomoca pewnego rodzaju wywlaszczenia.
