Mity i fakty dotyczące rywalizacji CPU i GPU
Komputery bez procesora?
Producenci układów graficznych twierdzą, że procesory graficzne (GPU) są poważnym zagrożeniem dla standardowych procesorów (CPU). Czy faktycznie już niebawem w PECETACH nie będzie potrzeby montowania CPU? Postanowiliśmy to sprawdzić.
ATI Radeon serii 4800 to pierwszy na świecie GPU o wydajności arytmetycznej ponad jednego teraflopa Wstyczniu tego roku rosyjska firma ElcomSoft zaniepokoiła wielu użytkowników sieci bezprzewodowych Wi-Fi informacją, że udało jej się drastycznie skrócić czas łamania zabezpieczeń standardów WPA/WPA2. Innowacyjny był jednak nie algorytm, lecz zastosowana jednostka obliczeniowa: karta graficzna. Proponowane rozwiązanie pozwala generować hasła za pomocą karty Nvidia GeForce GTX 280 ponad dziesięć razy szybciej niż z wykorzystaniem czterordzeniowego procesora Intel Core 2 Quad Q6600. Ten i wiele innych przykładów dowodzi, że procesory graficzne pod względem mocy obliczeniowej mają dużą przewagę nad głównymi procesorami. Sytuacja wygląda jeszcze bardziej dramatycznie, gdy spojrzymy na teoretyczną wydajność arytmetyczną GPU. Powszechnie stosowaną miarą jest liczba operacji zmiennoprzecinkowych, które dany układ może wykonać w ciągu sekundy (FLOPS). Najszybsze procesory Intela uzyskują wynik 96 GFLOPS, tymczasem osiągi ostatnich produktów AMD i Nvidii oscylują już wokół jednego teraflopa, czyli 1000 GFLOPS! Oczywiście porównanie to nie miałoby większego sensu, gdyby karty graficzne w dalszym ciągu nadawały się tylko do wyświetlania grafiki w grach. Tymczasem równocześnie z szybkim wzrostem wydajności procesorów graficznych poprawia się też elastyczność i programowalność GPU. Od kilku lat rozwijana jest technika GPGPU, czyli General Purpose computing on GPU. To metoda wykorzystania kart graficznych do zastosowań ogólnych – niezwiązanych z wyświetlaniem grafiki rastrowej. Pojawia się coraz więcej aplikacji potrafiących zrobić świetny użytek z pokładów mocy układów graficznych. Czy zatem wkrótce większość zadań nasze komputery będą wykonywały za pomocą kart graficznych, a CPU zostanie zepchnięte na margines? Historia: Jak powstał GPGPU?Do 2000 roku proces przetwarzania danych przez karty graficzne był z góry zdefiniowany w samym sprzęcie, a więc programista tworzący aplikacje nie miał większego wpływu na jego przebieg. Z czasem jednak producenci kart graficznych dostrzegli i zaczęli uwzględniać potrzebę zwiększenia swobody artystycznej twórców gier. Aby wyglądały one ciekawiej, a karty sprzedawały się lepiej, zdecydowano o wprowadzeniu programowalnych jednostek cieniujących. W 2001 roku wraz z rodziną GeForce 3 pojawiły się Vertex Shader 1.1 oraz Pixel Shader 1.1 (zbiorczo określane jako Shader Model 1.1 i zaimplementowane w DirectX 8.0). Cieniowanie wierzchołków (VS 1.1) pozwoliło na dowolne modyfikowanie właściwości wierzchołków obiektów trójwymiarowych (np. pozycji, koloru, oświetlenia, współrzędnych tekstur). Dzięki temu możliwe stało się na przykład modyfikowanie geometrii obiektów oraz wydajne dodawanie niektórych efektów (np. mgły). Z kolei cieniowanie pikseli (PS 1.1) pozwoliło na modyfikowanie poszczególnych pikseli otrzymanych w procesie rasteryzacji geometrii. Umożliwiło to implementację niedostępnych wcześniej rodzajów cieniowania, filtrów itp. Jednocześnie narodziła się koncepcja wykorzystania kart graficznych do obliczeń niezwiązanych z grafiką. Jednak możliwości programowania były w tamtym momencie jeszcze bardzo ograniczone. Kod wykonywany przez jednostki cieniujące mógł liczyć najwyżej kilkadziesiąt instrukcji, zaś zestaw dostępnych instrukcji ograniczał się do podstawowych funkcji matematycznych i operacji odczytu tekstur. W kolejnych generacjach kart graficznych dokonywał się niewielki postęp. Przełom nastąpił w 2004 roku – wraz z pojawieniem się rodziny GeForce 6 wprowadzającej obsługę Shader Model 3.0 (DirectX 9.0c). Wreszcie do dyspozycji było podstawowe narzędzie programisty: sterowanie przebiegiem programu (flow control), czyli pętle, skoki i instrukcje warunkowe. Jednocześnie limit długości kodu został zwiększony do 512 instrukcji. Dzięki temu wizja GPGPU stała się bardzo realna. Zaczęły powstawać prace naukowe eksplorujące wydajność GPU lub dowodzące jej w zadaniach, których dotąd nie wiązano z produktami Nvidii i ATI (obecnie AMD). GPGPU stało się ważnym tematem konferencji SIGGRAPH, poświęconej grafice komputerowej. Podjęto też próby wykorzystania GPGPU do celów komercyjnych. Wreszcie pod koniec 2006 roku pojawiła się seria układów GeForce 8 z obsługą Shader Model 4.0 zawartego na przykład w DirectX 10. Zniknął podział na jednostki cieniowania wierzchołków i pikseli, tym samym rozwiązano problem nierównego podziału pracy między nimi. Zastąpiły je jednostki zunifikowane (unified shaders wg ATI), zwane też procesorami strumieniowymi (stream processors wg Nvidii). Umożliwiono również swobodny zapis danych w pamięci karty graficznej (scatter), a limit długości kodu zwiększono do 65 tysięcy instrukcji. Nie sposób nie wspomnieć o technologii CUDA wprowadzonej przez Nvidię wkrótce potem (luty 2007 r.). Dopiero ona uwolniła programistów od „graficznego” sposobu operowania, czyli przemycania danych w teksturach, wywoływania kodu na pikselach, graficznych interfejsów API (DirectX, OpenGL) i graficznych języków (Cg, GLSL). Udostępniła natomiast wygodne środowisko programowania w powszechnie znanym języku C. Z podobną inicjatywą wyszła firma ATI. Najpierw pojawił się projekt Close-To-Metal (CTM), czyli niskopoziomowe API przeznaczone do GPGPU. Ponieważ jednak narzędzie to było trudne w użyciu, ATI zaadaptowało Brook+, czyli oparty na C język i kompilator stworzony |
Kup Najtaniej
Błędne jest tylko stwierdzenie, że z CUDA korzysta Photoshop. Rzeczywiście, nowe opcje w tym programie używają co najwyżej OpenGLa.
Tymczasem Premiere na przykład jak najbardziej może korzystać z GPGPU.
Ponadto, do Photoshopa można sobie pobrać filtry innych producentów, które korzystają z CUDA.
W kwestii programowania to niedawno zaczęło się robić ciekawie za sprawą OpenCL (ang. Open Computer Language), czyli unifikacja intefejsu programistycznego - piszesz jeden program , który wykonuje się na GPU lub CPU lub GPU i CPU. O rozdział zadań dba biblioteka. OpenCL jest zarządzane przez tą samą ogranizację co OpenGL, są już pierwsze biblioteki dla GPU Nvidia, AMD też już napisało odpowiednei biblioteki i stara się o certyfikat zgodności. Wiadomo, że ten nowy interfejs jest skompilikowany i dopiero za kilka lat zaczną pokazywać się masowo ciekawe produkty.
Miejmy nadzieję, że MS nie zechce pogrzebać projektu i na siłę promować swój własny niekompatybilny z niczym stadard. Szkoda, że większość obecnie gier jest projektowana dla konsol
podkrecony cell ma ok 100GFLOPS a zwykle CPU ~98GFLOPS a GPU 1000GLOPS
twoj cel moze skoczyc