Firma AMD (NYSE: AMD) poinformowała o podjęciu współpracy ze znanym producentem oprogramowania do profesjonalnej obróbki multimediów: Adobe Systems Incorporated. Celem współpracy jest akceleracja sprzętowa podczas edycji wideo realizowana w otwartym standardzie OpenCL.
Wszystko wskazuje na to, że kolejna wersja popularnego wśród profesjonalistów programu Adobe Premiere Pro będzie w pełni wspierać akcelerację sprzętową z wykorzystaniem OpenCL, dzięki czemu użytkownicy komputerów wyposażonych zarówno w konsumenckie (Radeon) jak i profesjonalne (FirePro) karty graficzne oraz procesory APU firmy AMD odczują wzrost wydajności podczas obróbki materiału wideo za pomocą oprogramowania Adobe.
OpenCL jest już wspierany w oprogramowaniu Adobe Premiere Pro na platformę OS X, dzięki współpracy AMD i Adobe, z dodatkowych funkcji akceleracji sprzętowej będą mogli korzystać również posiadacze komputerów pracujących pod kontrolą systemu Windows.
Zgodnie z informacjami udostępnionymi przez firmę AMD, oprogramowanie Adobe akcelerowane przez OpenCL ma zapewnić nawet 4,3-raza szybszy eksport z formatu źródłowego z naniesionymi efektami do preferowanego formatu końcowego.
Więcej informacji na temat implementacji akceleracji sprzętowej wykorzystującej OpenCL w Adobe Premiere Pro na platformę Windows zostanie udostępnionych w trakcie konferecji NAB. Oprócz tego szczegółowe dane na temat nadchodzących nowych narzędzi audio i wideo firmy Adobe zostaną podane do publicznej wiadomości podczas konferencji Adobe MAX, The Creativity Conference, odbywającej się między 4 a 8 maja w Los Angeles w Kalifornii.
Obrabiam audio/video/foto od czasów Amiga 1200+Blizzard60 i nie zamierzam się mądrzyć , tylko czekam jak może kiedyś mniej będę/dziemy wydawać za sprzęt do roboty.
Też miałem taki sprzęt (TTK reklamy) teraz Sam440 śmiga aż miło
Obrabiam audio/video/foto od czasów Amiga 1200+Blizzard60 i nie zamierzam się mądrzyć , tylko czekam jak może kiedyś mniej będę/dziemy wydawać za sprzęt do roboty.
... ale nie mam tutaj nie wiadomo czego. Nie ma też możliwości porównania. Powiedziałbym, że na GF-ach i Quadro jest remis, zwłaszcza przy użyciu kernela AMD.
Nie mówię o Hyper-Q itp tylko o CUDA vs OpenCL nawet na kartach z serii 8k. Na takich kartach CUDA potrafi być szybsza od OpenCL (w zależności od kodu ofc) nawet 5-10x - nie za sprawą, Hyper-Q itp, a za sprawą tego, że kompilacja odbywa się offline - kompilator nie liczy się z czasem kompilacji przez co może dużo lepiej kod zoptymalizować niż kompilator działający w trakcie działania już u klienta na komputerze - to powoduje, że kod w CUDA jest dużo lepiej zoptymalizowany i bywa, że ten sam problem do rozwiązania, tyle samo instrukcji w kernelach 'C-like' po skompilowaniu w CUDA ma wielokrotnie mniej instrukcji do wykonania niż kompilacja OpenCL robiona na szybko, bo nie można sobie pozwolić na wiele minut kompilowania kernela jak to odbywa się kiedy kompilator jest offline - może w przyszłych OpenCL będzie uniwersalny bytecode i będzie można kompilować offline, ale w tej chwili niestety o porównywalnej wydajności zapomnij.
Nie chciałbym tego sukcesu mącić, ale z moich i innych w sieci testów wynika, że potrafi być 70x i więcej wolniejszy od OpenCL. Obecnie to obliczenia na CPU są szybsze niż C++AMP na GPU:
http://www.overclock.net/t/1329409/updated...ompute-v0-5-7-2
Przyjmijmy więc, że wszystko zależy od kodu i C++ AMP może być równie wydajne co OpenCL, albo CPU.
Poza tym koszt zakupu dodatkowego CPU to: mobo +1500zł cpu +2x2700zł... W tej cenie kupisz 7970. C++ AMP na 4x7970 z pewnością będzie wydajniejsze niż na CPU 2x Xeonach
Co do wydajności na papierze implementacji Intela to wszystko wygląda ok, ale na papierze - zobaczymy jak będzie w praktyce skoro na prostych testach jak szybka transformacja Fouriera traci już na oko ponad 20% na GPU... na bardziej skomplikowanych kernelach straci dużo więcej - szybszy być na dobrą sprawę nie ma prawa... bo to OpenCL, a słabszy jak najbardziej, bo kod wygenerowany z C++ może być dużo słabszy.
Ponieważ dyskusja dotyczy mojej osoby postanowiłem dołączyć
Zdawało mi się, że o to Ci chodziło w zacytowanym przez Virtusa fragmencie (przyznaję, nie pamiętam dyskusji dokładnie, a nie miałem czasu czytać całego wątku). Skojarzyłem tylko mniej więcej czas żałoby gamedev za Larrabee i tym co napisałeś... jeśli błędnie to przepraszam.
Nie, chodziło mi o kwestie typu: cache L1/L2 zamiast shared memory, stronicowanie pamięci GPU, obsługa przerwań po stronie GPU itp, wspólna przestrzeń adresowa pomiędzy CPU i GPU
A potrzebuje coś więcej poza samym C++ na GPU (zmienianym przez Intela na C-like OpenCL, ale jednak konwersja zapewne będzie kosztować (i co pokazuje Intel nawet na prostych testach kosztuje))?
Intel chciał niskim kosztem dołożyć obsługę C++ AMP dlatego wykorzystuję translacje do OpenCL. Można się domyśleć że bez translacji wydajność byłaby wyższa.
Zanim odpiszę na wcześniejsze posty i interpretacje moich słów polecam przyjrzeć się jak Intel implementuje C++ AMP u siebie: http://llvm.org/devmtg/2012-11/Sharlet-ShevlinPark.pdf Okazuje się, że dobrze zrobiona implementacja C++ AMP może być równie szybka jak OpenCL. Na końcu masz porównywanie wydajności C++ AMP Intela, OpenCLa i C++ AMPa od MS.
Wiem jak robi to Intel - Microsoft robi to teoretycznie lepiej (w praktyce optymalizacja musi leżeć) - kompiluje offline kod GPU do bytecodu.
W testach C++AMP udawało mi się osiągać wydajność OpenCL, ale to optymistyczne przypadki - przy większych kernelach (bipathtracer) już C++AMP tracił sporo.
Co do wydajności na papierze implementacji Intela to wszystko wygląda ok, ale na papierze - zobaczymy jak będzie w praktyce skoro na prostych testach jak szybka transformacja Fouriera traci już na oko ponad 20% na GPU... na bardziej skomplikowanych kernelach straci dużo więcej - szybszy być na dobrą sprawę nie ma prawa... bo to OpenCL, a słabszy jak najbardziej, bo kod wygenerowany z C++ może być dużo słabszy.
Ponieważ dyskusja dotyczy mojej osoby postanowiłem dołączyć
Zdawało mi się, że o to Ci chodziło w zacytowanym przez Virtusa fragmencie (przyznaję, nie pamiętam dyskusji dokładnie, a nie miałem czasu czytać całego wątku). Skojarzyłem tylko mniej więcej czas żałoby gamedev za Larrabee i tym co napisałeś... jeśli błędnie to przepraszam.
A potrzebuje coś więcej poza samym C++ na GPU (zmienianym przez Intela na C-like OpenCL, ale jednak konwersja zapewne będzie kosztować (i co pokazuje Intel nawet na prostych testach kosztuje))?
''Zanim skomentuje poszczególne wypowiedzi wspomnę, że ja patrze z punktu widzenia programistyczno - ekonomicznego. Tzn jeśli mam do wyboru dwa przypadki:
...'
To słowa autora tego bloga jeśli dobrze pamiętam? Ale wracając do tematu to co on by chciał, a to co jest to dwie różne rzeczy. Chciałby Intel Larrabee (MIMD), ale to już przeszłe idylliczne marzenia - teraz na lata w GPGPU dalej rządzić będą SIMD (a kod C++ nie wektoryzuje się łatwo)... w praktyce to co chciałby aby było osiągnie po prostu za pomocą programowania wielowątkowego na CPU (klasterki obliczeniowe ARM czyli wiele rdzeni MIMD wchodzą ostatnio na rynek - czyli coś takiego jak chciał z GPU - wiele małych rdzeni MIMD).
Ponieważ dyskusja dotyczy mojej osoby postanowiłem dołączyć
C++ AMP w porównaniu do OpenCL zakrywa przede wszystkim inicjalizację różnych zasobów na GPU (alokacje pamięci, transfery danych) natomiast sam kod kernela jest na podobnym poziomie abstrakcji. C++ AMP nie wprowadza tutaj elementów, które miałyby jakoś specjalnie wpływać negatywnie na wydajność tworzonego programu.
Nie chciałbym tego sukcesu mącić, ale z moich i innych w sieci testów wynika, że potrafi być 70x i więcej wolniejszy od OpenCL. Obecnie to obliczenia na CPU są szybsze niż C++AMP na GPU:
http://www.overclock.net/t/1329409/updated...ompute-v0-5-7-2
... ale nie mam tutaj nie wiadomo czego. Nie ma też możliwości porównania. Powiedziałbym, że na GF-ach i Quadro jest remis, zwłaszcza przy użyciu kernela AMD.
Nie mówię o Hyper-Q itp tylko o CUDA vs OpenCL nawet na kartach z serii 8k. Na takich kartach CUDA potrafi być szybsza od OpenCL (w zależności od kodu ofc) nawet 5-10x - nie za sprawą, Hyper-Q itp, a za sprawą tego, że kompilacja odbywa się offline - kompilator nie liczy się z czasem kompilacji przez co może dużo lepiej kod zoptymalizować niż kompilator działający w trakcie działania już u klienta na komputerze - to powoduje, że kod w CUDA jest dużo lepiej zoptymalizowany i bywa, że ten sam problem do rozwiązania, tyle samo instrukcji w kernelach 'C-like' po skompilowaniu w CUDA ma wielokrotnie mniej instrukcji do wykonania niż kompilacja OpenCL robiona na szybko, bo nie można sobie pozwolić na wiele minut kompilowania kernela jak to odbywa się kiedy kompilator jest offline - może w przyszłych OpenCL będzie uniwersalny bytecode i będzie można kompilować offline, ale w tej chwili niestety o porównywalnej wydajności zapomnij.
Nie chciałbym tego sukcesu mącić, ale z moich i innych w sieci testów wynika, że potrafi być 70x i więcej wolniejszy od OpenCL. Obecnie to obliczenia na CPU są szybsze niż C++AMP na GPU:
http://www.overclock.net/t/1329409/updated...ompute-v0-5-7-2
... ale nie mam tutaj nie wiadomo czego. Nie ma też możliwości porównania. Powiedziałbym, że na GF-ach i Quadro jest remis, zwłaszcza przy użyciu kernela AMD.
Czy C++ AMP jest znowu tak mało wydajny. Nie jest to drastyczna różnica. Nawet gdyby był 2x mniej wydajny wszystko sprowadza się do szybkości zaprezentowania gotowego rozwiązania. Jeżeli C++ AMP go skraca mimo, że spadek wydajność jest 1,5-2x to jest to 'parszywy', ale sukces. Dalej wydajność jest zadowalająca.