AMD vs NVIDIA (OpenCL vs CUDA) pod obliczenia GPGPU

Chciałem się zapytać - co będzie lepszym wyborem: NVIDIA GTX ze swoją CUDA czy AMD Radeon obsługiwane (głównie) przez OpenCL?. Chciałbym się pouczyć programowania równoległego z wykorzystaniem kart GPU. Myślałem przede wszystkim o Pythonie gdzie dostępne są pyOpenCL oraz pyCUDA. Na jaką kartę lepiej postawić? NVIDIA GTX czy AMD Radeon? (w okolicach 1400-1800 zł).

Z jednej strony NVIDIA oferuje więcej: lepsze "zaplecze" CUDA (większe community, więcej softu, przykładów) oraz chyba bardziej dopracowane i rozbudowane biblioteki, ale z drugiej strony daje mniej w postaci sprzętu, tj. za podobne pieniądze AMD Radeon oferuje - przynajmniej na papierze - więcej rdzeni, pamięci, lepsze parametry,.....poza zużyciem prądu. "Radek" za podobne pieniądze do GTX970 oferuje 2x tyle pamięci (8 GB), więcej rdzeni, GFLOPS, większą przepustowość pamięci.

Tu jest porównanie danych tech: http://www.purepc.pl/karty_graficzne/premierowy_test_amd_radeon_r9_390x_vs_geforce_gtx_980

Rozważam zakup GTX 970 lub Radeon R9 390 lub Radeon R9 390X. Głównie pod GPGPU (85%), rzadziej chciałbym coś też zrenderować, etc. NIe gram w gry, więc nie interesuje mnie wydajność w Crysis ;) Kartę chcę kupić w okolicach kwietnia / maja.

Krwawy Kot

W czerwcu pojawi się NVIDIA PASCAL, warto czekać? Markitingowcy mówią, że PASCAL to 10x MAXWELL ;)

Ja bym wybrał Radeona. W GPGPU i renderowaniu radzą sobie świetnie. Do tego AMD daje wsparcie dla OpenCL 2.0, a samo OpenCL działa praktycznie na wszystkim.

Wieści o Pascalu są mocno naciągane, jak to zwykle bywa w przypadku nVidii, a poza tym w części odnoszą się do obliczeń o zredukowanej precyzji, tzn opartych o typ FP16 obsługiwany sprzętowo w Pascalu.

Na chwile obecna sklaniam sie ku Radeonowi R9 390X, ale nie wiem co bedzie najbardziej oplacalne za 2-3 miesiace.

To mnie zaskoczyliscie, myslalem, ze "Radki" sobie radza dobrze z linuxem. Pamietam wypowiedz Linusa T. odnosnie NVIDIA.

Glownie to bedzie GPGPU, przyjrzalem sie pyOpenCl i wyglada interesujaco. Co do renderu to glownie Blender Cycles, moze cos innego.

Klawy Kod

Linus narzekał na brak wsparcia dla open source ze strony nVidii. Sterowniki własnościowe nVidii działają bardzo dobrze na Linuksie.

Radeony radzą sobie z OpenCL generalnie równie dobrze pod Windowsem co pod Linuksem. O sytuacji z Blender Cycles pisałem w komentarzu.

Z tym blenderem troche nieciekawie, choc na polskim forum blendera pisza, ze render w blenderze dziala, ale nie w pelni (ograniczona funkcjonalnosc).
Mnie wiekszosc rzeczy w Linuxie dziala dobrze, poza ....Skype :( Nie mam dzwieku (Fedora). Ale przeniose sie na Ubuntu powinno byc lepiej.

Czy OpenCL pozwala na obliczenia jednoczesnie na CPU i GPU. Czy tylko na jednym z nich?

Czy ktos z Was dzialal na Anacondzie z Radeonem?

ja zawsze mialem problemy z radeonami. Nvidia czy na linuksie czy na windowsie ma lepsze sterowniki.

nvidia FTW

Czy OpenCL pozwala na obliczenia jednoczesnie na CPU i GPU. Czy tylko na jednym z nich?

Zależy co rozumiesz przez jednocześnie. Możesz odpalić niezależne programy w OpenCLu na CPU i GPU jednocześnie w każdej wersji OpenCLa. Jeżeli chcesz by te programy współdzieliły pamięć to ZTCW musisz użyć funkcji Shared Virtual Memory (SVM). SVM jest dostępne dopiero w OpenCLu 2.0 i musisz mieć GPU i sterowniki, które tą wersję OpenCLa obsługują.

Pytam sie odnosnie jednoczesnego wykorzystania obu jednostejk zeby zwiekszyc szybkosc renderowania. Jest juz kilka renderow hybrydowych, takze z tych niedrogich /za free (arion, spectral studio i inne). Na mnie wrazenie zrobil platny Bunkspeed (dzis jest to SW Visualization cos tam, DS ich wykupilo).

Dzieki za odpowiedzi! Na 99% kupie radka ze wzgledu na liczbe rdzeni i 8 GB pamieci.

Jeśli chcesz mieć jak największą prędkość renderowania to wybierz kartę, która osiąga najlepsze wyniki w programie który preferujesz. Żeby było jednoczesne renderowanie na CPU i GPU to program musi to obsługiwać. Samo się nie zrobi, więc to też musisz sprawdzić.

Autor nie miał ciśnienia głównie pod renderowanie, a sytuacja jest inna gdy kupujesz kartę pod wiele różnych obliczeń, a inna gdy kupujesz kartę pod konkretny zestaw programów.

Głównie pod GPGPU (85%), rzadziej chciałbym coś też zrenderować, etc. NIe gram w gry, więc nie interesuje mnie wydajność w Crysis ;)

Generalnie stawiam na obliczenia GPGPU. Jednak jak juz sie wykosztuje ;) to chcialbym sprobowac innych rzeczy jak rendering w CG czy w montazu filmow.

Czy ktos wie jak jest z obliczeniami GPGPU w przypadku polaczenia kilku kart (SLI itp.)?? Slyszalem, ze liczba dostepnych procesorow strumieniowych dodaje sie, ale wielkosc RAM dostepnego dla programow juz sie nie sumuje.

Wszystko zależy od rodzaju obliczeń i od implementacji. W przypadku gier połączone GPU działają tak, że renderują klatki obrazu na przemian, a każde GPU zawiera komplet danych (przez co dane się dublują). Klatki obrazu są od siebie niezależne, więc renderowanie na przemian na wielu GPU teoretycznie nie powinno być problemem (w praktyce problemem jest stworzenie dobrej heurezy do wyznaczania odstępów między generowaniem klatek, bo w przypadku pesymistycznym oba GPU zaczynają renderować w tym samym czasie i przez to generują to samo).

Praktyczną regułą może być takie coś: jeżeli dany problem można by wydajnie rozdzielić pomiędzy kilka komputerów, to można by go wydajnie rozdzielić pomiędzy kilka GPU.

Problem z łączeniem GPU jest taki, że te gadają do siebie poprzez szynę PCI-Express, która ma względnie małą przepustowość i duże opóźnienia w stosunku do pamięci lokalnej dla GPU. Trzeba więc tak pisać algorytmy, by GPU jak najmniej gadały między sobą.

Dokladnie nie wiem jak wyglada architektura GPU (pewnie: bloki skladajace sie z mniejszych blokow, a te jeszcze mniejszych blokow, itd.), ale z pewnoscia sa jakies ograniczenia co do wielkosci kodu? Jak one wygladaja i czy zaleza od modelu karty?

Zależą od modelu karty, ale są duże.

Dla nVidii są tutaj: https://en.wikipedia.org/wiki/CUDA#Version_features_and_specifications (pozycja: Maximum number of instructions per kernel)
Dla AMD są tutaj: https://community.amd.com/thread/158542