Web Analytics
eXec.plMAGAZYN UŻYTKOWNIKÓW KOMPUTERÓW AMIGA
Amiga forum / Hyde Park / Amiga i CUDA....:)

Czytasz wątek: Amiga i CUDA....:)

radov
Nieaktywny użytkownik starego forum

Amiga i CUDA....:) wysłany: 2007-11-14 13:20

http://developer.nvidia.com/object/cuda.htm

CUDA - Compute Unified Device Architecture
Czyli możliwość wykorzystania GPU jako jednostki wektorowej w obliczeniach. Oczywiście - już wcześniej były podobne rozwiązania. Nawet samemu można to zrobić bez tego typu pakietów. Wystarczy odrobina umiejętności by zmusić kartę do liczenia. Jednak Z CUDA'mi tych umiejętności potrzeba jeszcze mniej )

Oczywiście - nie dla wszystkich algorytmów można takie rozwiązanie stosować. Jednak z chęcią zobaczyłbym coś podobnego na Ami. Wystarczyłby nawet prosty sterownik umożliwiający dobranie się do jednostek shaderów by spora część aplikacji zaczęła działać dużo szybciej.

Szybkie procesory PPC są dośc drogie. Po co w nie inwestować? Wystarczy tani (ale nowoczesny) układ graficzny. Czy taki sprzęt nie przypominałby Amig sprzed 15 lat? Relatywnie słaby CPU i wydajny układ 'towarzyszący' przejmujący na siebie część zadań





Odpowiedz

ministerq
Nieaktywny użytkownik starego forum

Amiga i CUDA....:) wysłany: 2007-11-14 18:32

@radov
http://developer.nvidia.com/object/cuda.htm
Szybkie procesory PPC są dośc drogie. Po co w nie inwestować? Wystarczy tani (ale nowoczesny) układ graficzny. Czy taki sprzęt nie przypominałby Amig sprzed 15 lat? Relatywnie słaby CPU i wydajny układ 'towarzyszący' przejmujący na siebie część zadań




Już coś takiego mieliśmy. I jak przyszło co do czego, to okazało się że Amiga jest pod względem prędkości i mocy obliczeniowej daleko w tyle, a wszyscy w około karmią się mitem kości specjalizowanych "odciążających" procesor główny.
Moim zdaniem lepiej jest jeśli WSZYSTKIE podzespoły są możliwie najszybsze jak tylko to możliwe.

Odpowiedz

amilech
Nieaktywny użytkownik starego forum

Re:Amiga i CUDA....:) wysłany: 2007-11-14 19:45

przy prędkości łącz graficznych pomiędzy amigami a kartami gfx (albo pci, albo agp2x) przesylanie danych zarżnie calą prędkość

Odpowiedz

radov
Nieaktywny użytkownik starego forum

Amiga i CUDA....:) wysłany: 2007-11-14 20:46

@ministerq

Już coś takiego mieliśmy. I jak przyszło co do czego, to okazało się że Amiga jest pod względem prędkości i mocy obliczeniowej daleko w tyle, a wszyscy w około karmią się mitem kości specjalizowanych "odciążających" procesor główny.
Moim zdaniem lepiej jest jeśli WSZYSTKIE podzespoły są możliwie najszybsze jak tylko to możliwe.




O architekturze klasycznej Amigi można napisać wiele. Wydaje mi się jednak, że głównym problemem był raczej wolny rozwój, niż budowa w swej istocie.
Tak czy siak parę CPU-GPU mamy w każdym komputerze. Czy jest to Amiga, czy nie. Faktem jest też, że drugą z tych jednostek można zmusić do wykonywania obliczeń. Sama idea przypomina architekturę sprzed 15 lat - jednak tym razem opartą na dynamicznie rozwijanych rozwiązaniach.

Dobry procesor PPC kosztuje sporo. Może lepiej zainwestować w układ graficzny? Układ ten może wykonywać większość złożonych algorytmów, a jest dużo tańszy. (i prawdę mówiąc - dużo szybszy od przeciętnego CPU)
Najnowsze układy nvidii uzyskują ponoć teoretyczną wydajność rzędu jednego teraFLOP'a....

@amilech
przy prędkości łącz graficznych pomiędzy amigami a kartami gfx (albo pci, albo agp2x) przesylanie danych zarżnie calą prędkość



A gdy okazuje się że AGP jest łączem niesymetrycznym i dla trybu ściągania danych (bodajże "FEEDBACK" dla OpenGL) szerokość szyny wynosi 32 bity to już w ogóle kiepsko. )
To że najszybsze układy wykorzystywane w Amigach obsługują co najwyżej shader model 1.4 - już w ogóle nie pomaga ) (co najwyżej 28 instrukcji...)

Ale na szczęście nie jest to bardzo dużą wadą. Możemy np. umieścić w pamięci graficznej stosunkowo niewielką ilość danych wejściowych (~10MB), a zyskiem będzie wykonywanie złożonego algorytmu przez shader.
Przykład: filtr splotowy o wielkości okna=10 wykonywany na zbiorze danych o wymiarach 2048x2048x4(float) bajtów.
Gdzie taka operacja wykona się szybciej: na EP440 taktowanym na 667MHz, czy na GPU taktowanym na 667MHz który ma tyle równoległych potoków co EP440 rejestrów ...i wykonuje iloczyn skalarny 2 wektorów (po 4 float'y każdy) w jednym takcie zegara

Ale nie to jest sednem mojej wiadomości. Myślę jednak o nowym sprzęcie. Szybki CPU będzie drogi. Więc może lepiej byłoby wybrać szybki, a tani, układ graficzny? Wystarczy żeby przejął na siebie te nieliczne, a obciążające zadania. Kompilacji programów wprawdzie nie przyspieszy, ale takie zadania jak rozpoznawanie obrazów, czy szyfrowanie danych - jak najbardziej.

Pozdrawiam!



Odpowiedz

LeniwyWilk
Nieaktywny użytkownik starego forum

Re:Amiga i CUDA....:) wysłany: 2007-11-14 23:49

Napisze ze to wlasnie bylo sila amigi,uklady specializowane ktory odwalaly cala robote a procesor tylko zarzadzal tym calym dranstwem,bledem bylo to ze nie doczekalismy sie jako amigowcy specializownego ukladu do grafiki 3d,oczywiscie nie zapominam o akiko cd 32,no i bankruvtwo samej firmy przyczynilo sie do tego,moim zdaniem firma amiga nie powinna nic kombinowac tylko robic to co robila do tej pory sp firma amiga produkowac komputery coraz lepsze,przestaje ci wystarczac twoj komputer to kupujesz nowy.Juz sobie wyobrazam notbooka amiga sniezno bialego z logo amigi.

Odpowiedz

tjindy
Nieaktywny użytkownik starego forum

Amiga i CUDA....:) wysłany: 2007-11-15 17:58



@
CIACH!

Więc może lepiej byłoby wybrać szybki, a tani, układ graficzny? Wystarczy żeby przejął na siebie te nieliczne, a obciążające zadania. Kompilacji programów wprawdzie nie przyspieszy, ale takie zadania jak rozpoznawanie obrazów, czy szyfrowanie danych - jak najbardziej.

Pozdrawiam!





Hmm... amigowce to takie zwierzątka "rozpieszczone" przez Amisię - nie lubią ograniczeń - podobało mi się (jeszcze za czasów A500) że mogłem zrobić praktycznie wszystko na Ami - a teraz będę wybierał? W końcu do liczenia grafiki (chodzi o Ray`e) rolę na siebie przejmuje procek. A jak się pojawi (tak oczekiwany przezemnie) jakiś host VST ?
Rozumiem wątek - ale wolałbym nie bawić się w półśrodki. Mamy już jakieś "entry" - czas na mid i high
Pozdrawiam


Odpowiedz

radov
Nieaktywny użytkownik starego forum

Amiga i CUDA....:) wysłany: 2007-11-16 11:59

@tjindy

Hmm... amigowce to takie zwierzątka "rozpieszczone" przez Amisię - nie lubią ograniczeń - podobało mi się (jeszcze za czasów A500) że mogłem zrobić praktycznie wszystko na Ami - a teraz będę wybierał? W końcu do liczenia grafiki (chodzi o Ray`e) rolę na siebie przejmuje procek. A jak się pojawi (tak oczekiwany przezemnie) jakiś host VST ?
Rozumiem wątek - ale wolałbym nie bawić się w półśrodki. Mamy już jakieś "entry" - czas na mid i high
Pozdrawiam




Zdaję sobie sprawę, że rozwiązania wykorzystujące wzajemną współprace kilku układów są ryzykowne - szczególnie gdy okazuje się że dane zadanie może być wykonywane tylko przez jeden z nich. I to akurat ten relatywnie najsłabszy. Na szczęście nie chcę zmieniać 'obowiązującej' architektury tylko proponuję jak ją wydajniej wykorzystać nie zwiększając zbytnio kosztu sprzętu.

Weźmy pod uwagę SAM440 - low end. Nie wiadomo czy będzie odtwarzać płynnie filmy z DVD. Ile kosztowałyby lepsze podzespoły, które te wątpliwości by rozwiały? Wydaje mi się, że więcej niż RV610 (radeon 2400pro), który te zadanie wykonuje sprzętowo. Dodatkowo (pomijając gry) układ oferuje możliwość wykorzystania go jako 40to potokową jednostkę wektorową. (8 jednostek shader, 5 niezależnych potoków każda)
Oczywiście taka jednostka ma swoje ograniczenia w zastosowaniach. Dodatkowo, jak już było wspominane wcześniej - potrzeba pewnych zmian (w odniesieniu do np. SAM440) by takie działanie było sensowne. Szybka pamięć, wydajny chipset i odpowiednie złącze. W związku z czym i tak okaże się że konstruujemy sprzęt "mid". Jest tylko pewna różnica: żaden amigowy system (na ile się orientuję) nie pozwoli w najbliższym czasie wykorzystać dobrodziejstwo posiadania wielu rdzeni w CPU. Za to liczenie z GPU, to 'tylko' kwestia sterownika.
Z technicznego punktu widzenia - jest zupełnie obojętne, czy algorytm jest zrównoleglany dla CPU, czy dla GPU. GPU narzuca jedynie bardziej restrykcyjne wymagania co do postaci struktury danych.

Można się zastanawiać - jeśli to tak dobry pomysł, to dlaczego nikt go nie stosuje komercyjnie w świecie x86? Nie mam pojęcia. Może koszty produkcji takiego oprogramowania są większe? Jakkolwiek na stronie [url=www.gpgpu.org]>>GPGPU<< można znaleźć wiele przykładów zastosowań.

A odnosząc się do renderowania: jest możliwe przeniesienie algorytmów śledzenia promieni na GPU. Jest to dość kłopotliwe - ale możliwe. Swego czasu słyszałem o dwóch rozwiązaniach:
- w jednym z nich na GPU przeniesiono jedynie algorytm wykrywania 'kolizji promieni'. Na sprzęcie PIV 3GHz (1 rdzeń - było to z 3 lata temu) i gf6800 obliczenia przyspieszyły o ok. 60%. Oczywiście mowa tu o porównaniu samego CPU i tego samego procka współpracującego z kartą.
- w drugim rozwiązaniu przeniesiono większość algorytmu - jakkolwiek tylko podstawowe funkcje. Nie pamiętam zupełnie kto za to odpowiadał. Wydaje mi się zę to chaos group z ich v-ray'em. Nie wiem tez jakiej konfiguracji dotyczył sprzęt. Podobno przerobiona wersja wykazała 6-8 krotny wzrost wydajności.

Pozdrawiam!


Odpowiedz

tjindy
Nieaktywny użytkownik starego forum

Re:Amiga i CUDA....:) wysłany: 2007-11-17 19:08

Ok, Radov. Zainteresowałeś mnie tematem. Poszperałem po sieci i znalazłem kilka rendererów na GPU. Wzrost wydajności to od 10 do 50 razy szybciej a w niektórych przypadkach nawet 100... Wybitnym przykładem może być produkt NVidii dla ich kart - http://www.nvidia.com/page/gz_learn.html
Coraz więcej na sieci się o tym mówi - i bardzo dobrze. Oczywiście jeste wiele problemów z przeniesieniem kodu na GPU - ale jak widać, skoro można to się to robi (vide CUDA).
Gelato, jak na złość, działa tylko na kartach NVidia - ja akurat dzierżę Radeona. Gdzieś znalazłem buszując po sieci że komuś się to udało odpalić na radku. No w każdym razie - dzięki CUDA istnieje szansa na niezależny od wykonawcy GPU, renderer. Wypada tylko czekać. Oczywiście - te rozwiązania nie dają tak spektakularnych efektów jak przy wykorzystaniu CPU - aczkolwiek widać że z kolejnymi wersjami jest coraz lepiej
Wracając do tematu tego wątku i trochę przewrotnie myśląc - jeśli faktycznie mogłoby się stać że GPU przejmie pewne obliczenia z CPU - to co stoi na przeszkodzie by w końcu całe systemy pisać na GPU ? (no może trochę przesadziłem - ale chciałem zobrazować sytuację ).
No nic, biorę się za blenderka, mam nadzieję że będzie kiedyś osobna kompilacja pod Ami

I jeszcze jeden projekcik - http://www.bee-www.com/projects.htm - robi wrażenie...



Odpowiedz

Menu
Baza wiedzy
AmigaOS.pl