aktualności

Nvidia CUDA 6 pojawi się za parę miesięcy

18
18 listopada 2013, 18:11 Piotr Gontarczyk

Firma Nvidia zapowiedziała nową wersję popularnej platformy programistycznej do obliczeń równoległych. Platforma CUDA 6 według Nvidii ma zapewnić łatwiejsze tworzenie programów wykorzystujących obliczenia równoległe, poprzez zmniejszenie nakładu czasu i pracy niezbędnego do przyspieszenia aplikacji naukowych, technicznych lub firmowych za pomocą procesorów graficznych.

Najważniejsze cechy platformy CUDA 6 to:

  • zunifikowana pamięć – Upraszcza programowanie, zapewniając aplikacjom dostęp do procesora centralnego i graficznego bez konieczności kopiowania danych między dwoma układami, a także ma ułatwiać wprowadzanie obsługi procesora graficznego w szerokiej gamie języków programowania.
  • biblioteki typu drop-in – Automatycznie przyspieszają obliczenia BLAS i FFTW nawet ośmiokrotnie, poprzez zastąpienie istniejących bibliotek, korzystających z procesora, odpowiednikami wykorzystującymi procesor graficzny.
  • skalowanie na wiele procesorów graficznych – przeprojektowane biblioteki BLAS i FFT automatycznie skalują swoją wydajność, dostosowując się nawet do ośmiu procesorów graficznych zainstalowanych w jednym węźle, umożliwiając tym samym osiągnięcie do dziewięciu TFLOPS wydajności obliczeniowej o podwójnej precyzji, a także obsłużenie większych zadań (do 512 GB). Skalowanie do wielu procesorów graficznych działa również w nowej bibliotece BLAS typu drop-in.

Oprócz nowych funkcji, platforma CUDA 6 zapewnia pełen zestaw narzędzi programistycznych, bibliotek matematycznych akcelerowanych przez procesory graficzne oraz poradników programistycznych.

Szósta wersja pakietu programistycznego CUDA zostanie udostępniona na początku przyszłego roku. Wszyscy uczestnicy programu CUDA-GPU Computing Registered Developer zostaną powiadomieni, gdy będzie ona dostępna do pobrania. Aby dołączyć do programu, należy zarejestrować się na stronie internetowej, którą znaleźć można pod adresem developer.nvidia.com/programs/cuda/register.

Źródło: Nvidia
aqvarioZobacz profil
Poziom ostrzeżenia: 0%
aqvario2013.11.18, 18:38
10#1
Zunifikowana pamięć? Czyżby coś na kształt HSA od AMD i ARM? Czyżby nVidia zrobiła rozwiązanie programowe, symulujące hardware? Mam nadzieję, że PCLab naskrobie coś potem na ten temat, po publikacji nowej wersji.
skoti48Zobacz profil
Poziom ostrzeżenia: 0%
skoti482013.11.18, 18:56
aqvario @ 2013.11.18 18:38  Post: 702590
Zunifikowana pamięć? Czyżby coś na kształt HSA od AMD i ARM? Czyżby nVidia zrobiła rozwiązanie programowe, symulujące hardware? Mam nadzieję, że PCLab naskrobie coś potem na ten temat, po publikacji nowej wersji.

Softwareowo teoretycznie mogliby oprzeć o Unified Virtual Addressing, który jest dostępny od Fermi sprzętowo, ale raczej ta nowość w CUDA 6 jest związana, z Nvidia Maxwell który ma mieć zunifikowaną pamięć wirtualną (nie tylko adresowanie), a który ma wyjść w przyszłym roku. Ogólnie rzecz biorąc to nic ciekawego i trzeba czekać na Nvidia Volta GPU, która potrafi wykorzystywać stos.
cyriakZobacz profil
Poziom ostrzeżenia: 0%
cyriak2013.11.18, 19:44
-3#3
na anandtechu był o tym artykuł - programista nie będzie musiał się martwić o kopiowanie/synchronizację danych teraz będzie to robił automat - ciekawe jak z wydajnością i zajętością pamięci.. ale może nie będzie trzeba tego używać?
es1oZobacz profil
Poziom ostrzeżenia: 0%
es1o2013.11.18, 21:11
A nie lepiej pisać w OpenCL? Zadziała wszędzie i też jest całkiem ok.
gregory003Zobacz profil
Poziom ostrzeżenia: 0%
gregory0032013.11.18, 21:41
-1#5
es1o @ 2013.11.18 21:11  Post: 702635
A nie lepiej pisać w OpenCL? Zadziała wszędzie i też jest całkiem ok.

Mniej wygodnie, mniejsze możliwości i nie wykorzystuje potencjału TESLI. No faktycznie lepiej.
SunTzuZobacz profil
Poziom ostrzeżenia: 0%
SunTzu2013.11.18, 23:19
-3#6
gregory003 @ 2013.11.18 21:41  Post: 702644
es1o @ 2013.11.18 21:11  Post: 702635
A nie lepiej pisać w OpenCL? Zadziała wszędzie i też jest całkiem ok.

Mniej wygodnie, mniejsze możliwości i nie wykorzystuje potencjału TESLI. No faktycznie lepiej.

Dokładnie
Bo problemem nie jest dostępność sprzętu, a dostępność softu. Co z tego, że masz Radeony nawet 10x wydajniejszy gdyby był, jak czas zrobienia softu jest dłuższy, droższy. Sprzęt możesz iść kupić masz... soft musisz wynaleźć.
skoti48Zobacz profil
Poziom ostrzeżenia: 0%
skoti482013.11.19, 01:03
gregory003 @ 2013.11.18 21:41  Post: 702644
Mniej wygodnie, mniejsze możliwości i nie wykorzystuje potencjału TESLI. No faktycznie lepiej.

W wersji OpenCL 2.0 tak samo wygodnie, te same możliwości i wykorzystasz potencjał Tesli... problemem jest to, że jeszcze nikt nie wspiera OpenCL 2.0, a z 1.2 jest tak jak mówisz.

Problemem była też wcześniej wydajność... tzn kompilowane kernele online (przez sterownik w czasie dzialania aplikacji jak w OpenCL) nie mogą się równać z kompilacją offline przez kompilator standalone (jak w wypadku CUDA, gdzie sama kompilacja może trwać kilka minut i nikt nie narzeka). Jednak i to się zmieni z OpenCL SPIR 1.2 (kompilacja offline gdzie optymalizuje się kod, do kodu pośredniego... coś jak shadery w DirectX)... ale tu jest tak jak z OpenCL 2... istnieje w planach na przyszłość.

PS. Swoją drogą kiedy już OpenCL SPIR 1.2 będzie gotowe to będzie można pisać w C/C++ a nawet CUDA, kernele dla OpenCL. SPIR 1.2 opiera się na LLVM, tak jak otwarto-źródłowa implementacja CUDA od Nvidii i nic nie będzie stało na przeszkodzie, aby skompilować CUDA do LLVM BC, a z LLVM BC stworzyć SPIR binary dla OpenCL.

SunTzu @ 2013.11.18 23:19  Post: 702662
Dokładnie
Bo problemem nie jest dostępność sprzętu, a dostępność softu. Co z tego, że masz Radeony nawet 10x wydajniejszy gdyby był, jak czas zrobienia softu jest dłuższy, droższy. Sprzęt możesz iść kupić masz... soft musisz wynaleźć.

Możesz uściślić o jaki soft ci chodzi?
wake_upZobacz profil
Poziom ostrzeżenia: 0%
wake_up2013.11.19, 10:03
-1#8
skoti48 @ 2013.11.19 01:03  Post: 702682
problemem jest to, że jeszcze nikt nie wspiera OpenCL 2.0

Nie można wspierać czegoś czego jeszcze nie ma.
Specyfikacja OpenCL 2.0 (podobnie jak SPIR) nie jest przecież finalna. Ciągle podlega ew. modyfikacjom i drobnym poprawkom, proces ten miał się zamknąć w czasie kilku miesięcy.
Ty, skoti, pewnie o tym wiesz, ale inni nie muszą...
skoti48Zobacz profil
Poziom ostrzeżenia: 0%
skoti482013.11.19, 12:50
wake_up @ 2013.11.19 10:03  Post: 702720

Nie można wspierać czegoś czego jeszcze nie ma.
Specyfikacja OpenCL 2.0 (podobnie jak SPIR) nie jest przecież finalna. Ciągle podlega ew. modyfikacjom i drobnym poprawkom, proces ten miał się zamknąć w czasie kilku miesięcy.
Ty, skoti, pewnie o tym wiesz, ale inni nie muszą...

Specyfikacja OpenCL 2.0 jest już finalna (14 listopada wydana, ale producenci sprzętu mieli mnóstwo czasu, na przygotowanie sterowników w czasie wersji prowizorycznej specyfikacji i mogli umieszczać w sterownikach beta - teraz to dopiero za miesiąc/dwa będzie w beta, a za pół roku jak dobrze pójdzie wejdzie do sterowników), a co do SPIR to jest faktycznie prowizoryczna specyfikacja (dlatego napisałem, że to dopiero plany na przyszłość), którą mimo wszystko już mogliby wspierać, aby przygotować programy na oficjalne wyjście (a tak, jak wyjdzie to do implementacji w sterownikach jeszcze będzie długa droga).
wake_upZobacz profil
Poziom ostrzeżenia: 0%
wake_up2013.11.19, 13:32
-1#10
skoti48 @ 2013.11.19 12:50  Post: 702741
wake_up @ 2013.11.19 10:03  Post: 702720

Nie można wspierać czegoś czego jeszcze nie ma.
Specyfikacja OpenCL 2.0 (podobnie jak SPIR) nie jest przecież finalna. Ciągle podlega ew. modyfikacjom i drobnym poprawkom, proces ten miał się zamknąć w czasie kilku miesięcy.
Ty, skoti, pewnie o tym wiesz, ale inni nie muszą...

Specyfikacja OpenCL 2.0 jest już finalna (14 listopada wydana, ale producenci sprzętu mieli mnóstwo czasu, na przygotowanie sterowników w czasie wersji prowizorycznej specyfikacji i mogli umieszczać w sterownikach beta - teraz to dopiero za miesiąc/dwa będzie w beta, a za pół roku jak dobrze pójdzie wejdzie do sterowników), a co do SPIR to jest faktycznie prowizoryczna specyfikacja (dlatego napisałem, że to dopiero plany na przyszłość), którą mimo wszystko już mogliby wspierać, aby przygotować programy na oficjalne wyjście (a tak, jak wyjdzie to do implementacji w sterownikach jeszcze będzie długa droga).

Ach to przepraszam i dzięki za aktualizację wiedzy :).
Podejrzewam że z OpenCL 2.0 nVidia nie będzie miała większych problemów biorąc pod uwagę że np dynamic parallelism jest obsługiwany przez CUDA.
Zastanawia mnie natomiast AMD - może wiesz jak będzie 2.0 wyglądał w wykonaniu AMD? Heh... AMD do tej pory nie wydało nawet wsparcia dla OpenGL 4.4...
Zaloguj się, by móc komentować
1