NVidia udostępnia kod źródłowy nowego kompilatora dla architektury NVidia CUDA

[adek]

Firma NVIDIA poinformowała dziś o udostępnieniu kodu źródłowego nowego kompilatora dla architektury NVIDIA CUDA opartego na LLVM. Kod zostanie przekazany badaczom akademickim i dostawcom programów narzędziowych, aby ułatwić im wprowadzenie obsługi procesorów graficznych w większej liczbie języków programowania, a także obsłużenie aplikacji CUDA na alternatywnych architekturach procesorów. Więcej w rozwinięciu informacji prasowej...

 

Pełna treść wiadomości znajduje się na

stronie głównej serwisu pod adresem:

http://www.max3d.pl/news.php?id=2140

 

 

[adek]

Zamieściłem informację prasową bo pamiętam, że ostatnio wywiązała się całkiem niezła dyskusja osób programujących i takich tutaj też nie brakuje. Mam nadzieję, że komuś informacja się przyda.

[olaf]

nawet chciałem przekleić. Nie mogę się doczekać chwili wolnego od roboty. Ten temat c prawda do konca mnie nie interesuje ale zjajomi mówili, że jest Pytong w wersji gpu i też chciałbym liznąć. Teraz pojawi się pewnie wszystko, co dobrze wróży niezależnym projekto takim jak kupiona przez appla Siri.

[n-pigeon]

No i super :) Tak myślałem, że z czasem otworzą tą technologie, by była bardziej konkurencyjna przy OpenCL, ale kiedy ten się rozwinie, a nie tak wcześnie. Może dmuchają na zimne, by nie robić wszystkiego na hura...

 

AMD ostro pracuję by propagować OpenCL, wspiera nawet oficjalnie różne projekty open source. Pewnie chcą by posłużyły im jako przykłady możliwości i chęci wykorzystania tej technologi. Wyciągnęli rękę do developerów GEGLa, Gimpa i Blendera, ciekawe gdzie jeszcze.

 

Tak czy inaczej, dobra nasza.

[SYmek]

Trudno w to uwierzyć, ale najwyraźniej ludzie nie podeszli zbyt entuzjastycznie do pomysłu, że ich kod ma się wykonywać *tylko* na procesorach NVIDII:). No i mamy OpenC(uda)L?

[Skoti]

@SYmek: akurat programiści często wolą pisać tylko dla CUDA niż borykać się z problemami sterowników AMD i tłumaczeniu się za pół roku przed klientami dlaczego ich program który dostosowali do Nvidii i AMD nie działa na GPU intela i ich sterownikach (bo jak wyjdzie IB, sterowniki z pewnością będą miały braki i podobnie jak AMD dziś wywalały się w nieoczekiwanych miejscach). Dodatkowo Nvidia ma tu nowego "wroga" czyli microsoftowy C++AMP (w kodzie C++ wstawki się robi podobne do OpenMP i już ten kod wykonuje się na GPU... nie jest to tak wydajne jak kernele w CUDA/OpenCL/DirectCompute, ale szybciej można to dodać) z tego powodu Nvidia i współpracujące firmy zrobili OpenACC (też pragmy do kodu C++ jak OpenMP)... jednak aby to spopularyzować i być konkurencyjnymi trzeba albo oddać do Khronos Group (tak jak Apple oddało OpenCL) i Khronos Group musi mieć środki, żeby rozwijać, jak i główne firmy muszą chcieć to wspierać (AMD ze względu, że Nvidia już ma gotowe wsparcie mogła by się nie zgodzić) lub właśnie zachęcić konkurencyjne firmy do wspierania CUDA (przez co OpenACC będzie i tam działał) - z tego co pamiętam AMD dla swojego GPU kompilator opiera na LLVM (GLSL i OpenCL) więc będą mogli szybko dodać swój target.

[SYmek]

Rozumiem, o czym piszesz, ale wydaje mi się, że programiści woleliby raczej, żeby sterowniki OpenCL od AMD były jakości CUDA, albo chociaż dorównywały tym od Nvidii (i Intela). Pisanie tylko pod Cuda jest (było?) co najwyżej mniejszym złem.

 

Może "akademikom" to rybka, ale end-userskie aplikacje wyraźnie czekały na stabilizacje OpenCL, nie ładując się w Cuda dalej, niż to zrobił np. VRay.

[Skoti]

Rozumiem, o czym piszesz, ale wydaje mi się, że programiści woleliby raczej, żeby sterowniki OpenCL od AMD były jakości CUDA, albo chociaż dorównywały tym od Nvidii (i Intela). Pisanie tylko pod Cuda jest (było?) co najwyżej mniejszym złem.

 

Może "akademikom" to rybka, ale end-userskie aplikacje wyraźnie czekały na stabilizacje OpenCL, nie ładując się w Cuda dalej, niż to zrobił np. VRay.

Wszyscy by chcieli, żeby sterowniki OpenCL były dopracowane, ale też wszyscy wiedzą jak to wygląda ze sterownikami OpenGL i kompilatorami GLSL (intel siedzi w prehistorii, a w amd wiele rzeczy działa źle lub nie działa wcale). Najlepiej w OpenGL i OpenCL wygląda Nvidia, ale OpenCL na ich kartach nie działa tak dobrze jak CUDA (która daje niższy poziom dostępu i lepiej da się zoptymalizować kod). Producenci oprogramowania GPGPU olewa w tej chwili OpenCL jeszcze ze względu, że karty AMD są słabe w obliczeniach takich jak rendering, a na Nvidię lepiej pisać w CUDA. Dlatego dziś mamy takie Octane, IRay (to naturalne bo właścicielem Mentala jest Nvidia), Indigo, Cycles i inne mają sprawne renderery CUDA, a OpenCL albo olewają, albo są wczesne wersje które muszą się zmagać z AMD. Akademikom nie przeszkadza OpenCL - piszą na dane urządzenie i działa, a właśnie twórcą oprogramowania dla użytkownika końcowego wolą CUDA (bo działa, w porównaniu do OpenCL szybciej, a karty AMD i tak się nie liczą w GPGPU). AMD może się liczyć w GPGPU od nowych kart z rdzeniami "ala Fermi" czyli 16 rdzeni w SIMD (zamiast 80 lub 64) czyli GCN i kartami z serii 79xx (może nowa arch zahaczy o 78xx).

 

Możliwość wsparcia przez AMD i innych CUDA to dobra wiadomość dla GPGPU (inna sprawa, że AMD mimo korzyści dla swoich klientów przez udostępnienie im aplikacji dla CUDA, może nie chcieć wspierać tego API (bo porównanie w aplikacjach pisanych z myślą o NV byłyby bardzo niekorzystne dla ich kart)).

 

Ja bardzo lubię OpenCL i piszę w nim i wiąże z nim duże nadzieje na przyszłość ze względu na wsparcie praktycznie wszędzie już dziś (od x86, przez arm w telefonach i ppc w konsolach, na kartach graficznych w pc i mobilnych w telefonach/tabletach), jednak jeśli sterowniki amd nie potrafią skompilować poprawnego kodu w OpenCL i się wywalają bo jest za długi (a przypominam, że od HD2000 podobno karty AMD mają nieograniczoną ilość instrukcji w programach (wymogi SM4 w DX10)) to całe obliczenia OpenCL tracą sens, jeśli się nie da w nim napisać programu przez problemy których nie spotkasz w CUDA (ofc w wersji CUDA dla AMD też mogłyby być problemy podobne, bo muszą napisać backend (zapewne ten sam co z OpenCL wstawić) do LLVM i problemy byłyby te same - tylko na NV wydajniej ;p). CUDA mnie nie ciągnie, ale zawszę wolę mieć wybór z kilku API działających na wszystkim (niezależnie od systemu i sprzętu), niż być skazany na jedno (inna sprawa, że tak czy tak jesteśmy skazani na Nvidię bo zarówno rozwojem CUDA zajmuje się Nvidia jak i OpenCL (przewodniczy grupie pracującej nad OpenCL i prezesem całego Khronos Group jest wiceprezes Nvidii Neil Trevett)).

[SYmek]

Aplikacje, o których wspominasz, nie miały wyboru, bo powstawały, kiedy OpenCL raczkowało, o czym doskonale wiesz. Niektóre już się przesiadają na OpenCL, nie oglądając się na jakość wsparcia AMD z powodów, o których także wspominasz. Swoją drogą Octane czy Cycles to może i aplikacje dla użytkowników, ale raczej zabawki, niż poważne narzędzia. Można je przepisać w tydzień. Ale taki Bullet czy Houdini to już inna sprawa. Zdziwiłbym się, gdyby ktoś z własnej woli opierał przyszłość swojej aplikacji na bibliotece należącej do dostawcy hardware'u. Oczywiście otwarcie CUDA może to zmienić. Nie jestem pewien, czy to dobrze. Ciekaw jestem reakcji Intela, pewnie to zleją po wydaniu własnego OpenCL'a (nie wiem wprawdzie, ile jest warta implementacja Cuda na x86 od Nvidii).

[danilo2]

Gdyby Nvidia nie czuła zagrożenia ze strony OpenCL, to nie otwierałaby Cudy.

 

Tak jak pisze SYmek, żaden producent dużego oprogramowania nie będzie się opierał na technologii jednej firmy.

[Skoti]

Aplikacje, o których wspominasz, nie miały wyboru, bo powstawały, kiedy OpenCL raczkowało, o czym doskonale wiesz. Niektóre już się przesiadają na OpenCL, nie oglądając się na jakość wsparcia AMD z powodów, o których także wspominasz.

Nie tyle nie miały wyboru, co wolały wybrać coś stabilnego i działającego maksymalnie szybko. Niektóre programy przyglądają się OpenCL i będą przechodzić z prostego powodu - karty AMD jeśli będą takie jak je zapowiadają (najwyższe modele GCN) to będą się nadawać do GPGPU, więc wersja OpenCL powstanie (jednak nikt nie mówi o zamiast tylko o obok, bo CUDA daje większe możliwości optymalizacji). Ale żeby poważnie OpenCL weszło to AMD musi poprawić sterowniki.

 

Ale taki Bullet czy Houdini to już inna sprawa. Zdziwiłbym się, gdyby ktoś z własnej woli opierał przyszłość swojej aplikacji na bibliotece należącej do dostawcy hardware'u..

Taki Bullet czy Houdini? Z Houdini nie jestem na bieżąco, więc prosiłbym o podanie kiedy dostał akcelerację GPGPU i jaką. Co do Bullet to korzystam z tego silnika fizyki i GPGPU ma od 2008 roku akcelerację CUDA i później po kolei dostawał fluidy, softbody, cloth dla CUDA. Teraz przechodzi na OpenCL prace pewnie jeszcze przez rok będą zanim coś sensownego wyjdzie, a twórcy narzekają na sterowniki i sprzęt AMD i ciężko mówić o tym, że przechodzenie na OpenCL to ich całkowicie autonomiczny wybór... tzn chcą z pewnością, żeby działało w OpenCL, bo Bullet ma po kilka implementacji na x86, po kilka na ppc (razem z spu dla sony), osobno na arm, osobno na cuda... i OpenCL miał być kolejnym targetem, jednak skupienie się na OpenCL całkowicie to pomysł AMD który od kilku wersji ma prawie całkowity wpływ na Bullet (wszyscy aktywni programiści są teraz pracownikami AMD, przez co nie można podawać tego przykładu jako pokazówkę, że przechodzą na OpenCL (AMD ma tylko OpenCL więc nad OpenCL rozkazuje pracować)).

[SYmek]

Nie tyle nie miały wyboru, co wolały wybrać coś stabilnego i działającego maksymalnie szybko. Niektóre programy przyglądają się OpenCL i będą przechodzić z prostego powodu - karty AMD jeśli będą takie jak je zapowiadają (najwyższe modele GCN) to będą się nadawać do GPGPU, więc wersja OpenCL powstanie (jednak nikt nie mówi o zamiast tylko o obok, bo CUDA daje większe możliwości optymalizacji). Ale żeby poważnie OpenCL weszło to AMD musi poprawić sterowniki.

 

Nie idzie o to, co jest teraz, tylko o to, co będzie później. Jeśli ktoś pisze kod pod badania akademickie, to jest mu obojętne, czy za rok się wykona, ale jeśli chce go rozwijać i sprzedawać przez dekadę, to myśli inaczej. To, że Cuda związana tylko z hardwarem nvidii była złym pomysłem, potwierdziła nawet Nvidia (wspierając x86), a otwiarcie Cudy - żeby mogła w ogóle konkurować z OpenCL w dłuższej perspektywie - tylko to potwierdza.

 

 

Taki Bullet czy Houdini? Z Houdini nie jestem na bieżąco, więc prosiłbym o podanie kiedy dostał akcelerację GPGPU i jaką.

 

Co do ma do rzeczy? Podaje te przykłady, żeby pokazać, że jest różnica, kiedy mówimy o prostym ray tracerze napisanym przez jednego człowieka w mniej niż rok, a programach pisanych latami przez duże zespoły.

 

Houdini 12, który pokaże się w publicznej becie pewnie na początku roku (luty?), ma wsparcie dla OpenCL'a w kilku micro-solverach levelset (Gas*), adwekcje, analizę pól (blur, curl, diffuse etc) i inne może robić w OpenCL (także na CPU). Obiecują także 'otwarty' solver, któremu możesz podać własny kernel. Na stronie SESI jest prezentacja 12tki. Testowałem już ten solver, rzeczywiście nawet na słabych Quadro (3500/3600fx) działa szybko, ale oczywiście bez pamięci wiele się nie zawalczy. 100 klatek symulacji w 100**3 to chyba max, co udało mi się osiągnąć (tylko dym, bez ognia, bo tam dochodzi kilka innych pól i nawet tyle bym nie uciągnął.

 

O ile pamiętam także Chaos Group pokazując swoje zabawy z Cuda zapowiadało, że czeka na OpenCL.

 

(...)przez co nie można podawać tego przykładu jako pokazówkę, że przechodzą na OpenCL (AMD ma tylko OpenCL więc nad OpenCL rozkazuje pracować)).

 

Racja, trudno to uważać za wolną wolę. Nie zmienia jednak faktu, że problemy OCL są przygodny (zła jakość kodu) a nie istotowa (zamknięta własność dostawcy sprzęty, któremu zależy na wyłączności). Otwarcie Cudy zmienia i komplikuje sprawę, pytanie tylko czy Intel i AMD podejmą pałeczkę czy zostają w swoich piaskownicach (bo sądząc po jakości OCL od Nvidii, ta się do 'obcego' produktu przekonała.

Edytowane 16 Grudzień 2011 przez SYmek

[Skoti]

Nie idzie o to, co jest teraz, tylko o to, co będzie później. Jeśli ktoś pisze kod pod badania akademickie, to jest mu obojętne, czy za rok się wykona, ale jeśli chce go rozwijać i sprzedawać przez dekadę, to myśli inaczej. To, że Cuda związana tylko z hardwarem nvidii była złym pomysłem, potwierdziła nawet Nvidia (wspierając x86), a otwiarcie Cudy - żeby mogła w ogóle konkurować z OpenCL w dłuższej perspektywie - tylko to potwierdza.

Jeśli ktoś robi programy dla klienta końcowego to nie może sobie pozwolić na problemy ze sterownikami - program ma wyjść i działać, a nie sprawiać problemy i zapychać support. Kiedy OpenCL będzie dobrze wspierany można wypuścić łatkę dodającą OpenCL (tym bardziej, że języki bardzo podobne, a nawet są konwentery kodu przepisujące CUDA do OpenCL) lub sprzedać jako nową wersję. Poprawne działanie na wspieranych konfiguracjach to podstawa w aplikacjach dla użytkowników końcowych (badania akademickie mogą się ograniczać do jednego sprzętu i jednej implementacji więc pisząc w OpenCL można olać, że program nie działa na innych implementacjach OpenCL - firma dla end user tego olać nie może). Nvidia nie wspierała x86 w CUDA - robiła to zupełnie inna firma (http://www.pgroup.com/resources/cuda-x86.htm), ale teraz po zmianie na LLVM x86 dostał kompilator za darmo (LLVM jest kompilatorem dla x86 już więc nie trzeba nic pisać).

 

 

Co do ma do rzeczy? Podaje te przykłady, żeby pokazać, że jest różnica, kiedy mówimy o prostym ray tracerze napisanym przez jednego człowieka w mniej niż rok, a programach pisanych latami przez duże zespoły.

Nad przykładowym Bullet pracuje też niewielka grupa osób i to tylko jeden z ich projektów - przykładowo autor Bullet czyli Erwin Coumans (teraz pracuje dla AMD, wcześniej pracował dla Sony czy nad silnikiem Havok) pisze Bullet cały czas podsyła łatki do Blendera, oraz robi własny silnik do prototypowania gier, później jest rponom (też z tego co pamiętam teraz pracuje dla AMD, ale robi 1/50 tego co Erwin) i trzeci jest [email protected] który od siebie dał jeszcze mniej - to wszystkie osoby które się udzielały przez kilka ostatnich lat. Ogólnie do stworzenia programów o wielkich możliwościach. OFC prosty pathtracer to zabawa nawet na kilka dni dla jednego programisty, jednak nie skala projektu decyduje o wykorzystanym API.

 

 

Houdini 12, który pokaże się w publicznej becie pewnie na początku roku (luty?), ma wsparcie dla OpenCL'a w kilku micro-solverach levelset (Gas*), adwekcje, analizę pól (blur, curl, diffuse etc) i inne może robić w OpenCL (także na CPU). Obiecują także 'otwarty' solver, któremu możesz podać własny kernel. Na stronie SESI jest prezentacja 12tki. Testowałem już ten solver, rzeczywiście nawet na słabych Quadro (3500/3600fx) działa szybko, ale oczywiście bez pamięci wiele się nie zawalczy. 100 klatek symulacji w 100**3 to chyba max, co udało mi się osiągnąć (tylko dym, bez ognia, bo tam dochodzi kilka innych pól i nawet tyle bym nie uciągnął.

To miło... mniej więcej wtedy (luty) ma się pojawić Blender z nodami kompozycji liczonymi w OpenCL (na CPU i GPU). Jednak tu OpenCL jest wyborem naturalnym podobnie jak w wypadku Hudiniego - program jest wieloplatformowy... też na Apple i ich komputery, które jako twórca OpenCL mają tylko implementację OpenCL i w obecnej generacji karty AMD (ze sprawną implementacją OpenCL bo od Apple, a nie od AMD). W tych konkretnych wypadkach do tej pory wybór CUDA był nie tylko ograniczeniem Nvidia only, ale też odejściem z MacOS X (teraz gdy mają programiści kompilator CUDA w LLVM (projekt wspierany przez Apple)).

 

 

Racja, trudno to uważać za wolną wolę. Nie zmienia jednak faktu, że problemy OCL są przygodny (zła jakość kodu) a nie istotowa (zamknięta własność dostawcy sprzęty, któremu zależy na wyłączności). Otwarcie Cudy zmienia i komplikuje sprawę, pytanie tylko czy Intel i AMD podejmą pałeczkę czy zostają w swoich piaskownicach (bo sądząc po jakości OCL od Nvidii, ta się do 'obcego' produktu przekonała.

CUDA teoretycznie była zawsze otwarta i tak mówiła o niej Nvidia (podobnie jak OpenCL - jest specyfikacja i trzeba sobie zrobić kompilatory na swoją arch) - Nvidia nawet zachęcała AMD do napisania CUDA dla kart AMD, żeby miały PhysX. Teraz Nvidia podała im kompilator na talerzu (kompilator LLVM kompiluje kod do pośredniego, z którego AMD już ma backend do kodu dla kart, bo korzysta z LLVM przy OpenCL), więc brak CUDA w sterownikach AMD mogą tłumaczyć tylko niechęcią.

Co do OpenCL od Nvidii to jak pisałem nie wiem czy można nazywać je "obcym" - Apple stworzyło go na podstawie CUDA, ze wsparciem Nvidii, przekazane zostało do Khronos gdzie rozwijane było pod okiem wiceprezesa Nvidii i przez niego wydane jako ostateczne 1.0. Nvidia jako pierwsza udostępniła kompilatory OpenCL i dała wsparcie w sterownikach... trudno tu mówić o czymś obcym. Bardziej obcym i zdecydowanie niekorzystnym dla obliczeń GPGPU jest C++AMP i IMO to jest powód wydania OpenACC i otartej implementacji CUDA gotowej do wykorzystania.