Otwarte czy zamknięte? Na to nie ma łatwej odpowiedzi

Kiedy mówimy o konflikcie open-source kontra closed-source, odruchowo przychodzą nam na myśl podstawowe produkty konsumenckie. Zamknięty Windows i otwarty Android. Zamknięty Internet Explorer i otwarty Firefox. Office kontra OpenOffice.org. Przykłady można mnożyć. Jednak polityka otwartości i zamkniętości nie ogranicza się tylko dla aplikacji dla użytkownika. To również architektury sprzętowe, sterowniki, bazy danych a nawet silniki do gier.

Rozwiązania „otwarte” intuicyjnie pojmujemy jako te bardziej korzystne. Dzięki nim inni mogą się uczyć od autorów nowoczesnych rozwiązań, implementować je u siebie a nawet ulepszać o swoje własne rozwiązania. Sęk w tym, że ciężko w tym przypadku chronić swoją własność intelektualną. Jeżeli opracujesz algorytm, który rewolucjonizuje przetwarzanie pewnego rodzaju danych, to najprawdopodobniej chcesz na tym jak najwięcej zarobić i nie zdradzać swoich tajemnic. Dlatego też wiele firm zazdrośnie zamyka swoje rozwiązania, zdając sobie sprawę, że mają w rękach, ich zdaniem, zbyt dobry produkt, by pozwolić konkurencji go wykorzystywać.

Ciekawy bój toczy się na rynku rozwiązań graficznych. Zapoczątkował go wiele lat temu konflikt pomiędzy dwoma uznanymi rozwiązaniami: DirectX i OpenGL. Batalię wygrało „zamknięte” rozwiązanie Microsoftu, ale to tylko jedna bitwa w wielkiej wojnie. Przyjrzyjmy się kilku przykładom nowoczesnych standardów graficznych. Właściwie w każdym segmencie toczy się batalia pomiędzy własnościowymi a otwartymi technologiami. Jedną z najciekawszych bitew, które nadal się toczą, jest…

OpenGL przegrał batalię o popularność wśród programistów. Jest nadal stosowany, ale przytłaczająca większość gier powstaje w oparciu o rozwiązanie Microsoftu. Niedawno jednak firma AMD zaprezentowała alternatywne, otwarte rozwiązanie o nazwie Mantle.

Mantle stanowi konkurencję dla Direct3D i to mocną konkurencję. Rewolucja polega na zapewnieniu deweloperom niskopoziomowego dostępu do sprzętu (a konkretniej, do karty graficznej). Owa niskopoziomowość powoduje, że komputer nie musi tak intensywnie tłumaczyć uniwersalnych poleceń na kod zrozumiały dla układu GPU a programista, jeśli będzie miał takie życzenie, może optymalizować swoją grę lub inną aplikację ściślej pod dane układy, dzięki czemu zyskuje dodatkową, tak pożądaną wydajność. To jeden z powodów, z których Mantle, mimo iż otwarty, póki co działa wyłącznie na wybranych modelach kart Radeon.

Mantle nie jest pozbawiony wad. Twórcy Battlefielda 4, którzy jako jedni z pierwszych zastosowali w komercyjnej grze owe API, narzekali na ograniczone względem DirectX funkcje, przez co jakość oprawy graficznej odbiega od tej renderowanej za pomocą rozwiązania Microsoftu. Pamiętajmy jednak, że Mantle pojawił się raptem kilka miesięcy temu i cały czas się rozwija. A to samo studio odpowiedzialne za Battlefielda chwali to API za zapewnienie znacznie większej wydajności na tym samym sprzęcie.

Microsoft szykuje się do kontrataku: DirectX 12 również ma zapewnić niskopoziomowy dostęp do układów graficznych. To jednak dopiero bliżej nieokreślona przyszłość, a Mantle jest już teraz na rynku.

Mantle nie jest do końca otwartym rozwiązaniem. Na chwilę obecną jest optymalizowany pod układy graficzne GCN i AMD nawet nie myśli o zmianach umożliwiających mu lepszą (lub jakąkolwiek) współpracę z układami Intela czy Nvidii. Nie oznacza to, że inni producenci nie mogą napisać zgodnego z nim sterownika do swojego układu. Wątpliwym jest jednak, przynajmniej na razie, by Intel czy Nvidia zdecydowały się na ten krok. Mantle jednak prędzej czy później dojrzeje i jest całkiem prawdopodobne, że zyska dużą popularność wśród deweloperów. Niewykluczone, że konkurenci, najzwyczajniej w świecie, nie będą mieli wyjścia. Na dodatek AMD nieraz podkreślał, że Mantle nigdy nie byłby tak dobry gdyby nie dzielenie się informacjami na jego temat i konsultacjami z deweloperami. DirectX powstaje jako „super-tajne” rozwiązanie i jest tworzony wspólnie z producentami kart graficznych. Mantle z kolei otwiera się na deweloperów. Czy takie podejście się opłaci? Mantle jest zbyt młody, by móc to ocenić. Zainteresowanie API od AMD jest jednak bardzo duże. Należy podkreślić: Mantle nie jest rozwiązaniem typu open-source, ale de facto „otwiera” karty Radeon i ich własnościowe technologie dla programistów.

Kolejnym ciekawym przykładem jest bitwa pomiędzy standardami CUDA i OpenCL. Oba służą do dokładnie tego samego: zaprzęgnięcia układu graficznego do przeliczeń niezwiązanych z renderowaniem obrazu. Procesory nowoczesnych kart graficznych idealnie nadają się do pewnych zastosowań przeliczeniowych, więc ktoś wpadł na pomysł, by ten marnujący się potencjał wykorzystać.

CUDA to własnościowe rozwiązanie Nvidii i jak ono działa, wie tylko sama zainteresowana a częściowo zdradza dokumentacja. OpenCL z kolei jest całkowicie otwarty. Standard ten został opracowany przez firmę Apple, ale obecnie opiekuje się nim grupa Khronos odpowiedzialna za promowanie otwartych standardów w multimediach.

CUDA jest dojrzalszym standardem i wysoko cenionym, ale OpenCL ma kilka przewag z uwagi na swoją otwartość i zdobywa coraz większe uznanie wśród programistów. Głównie z uwagi na jego bardzo dynamiczny rozwój dzięki możliwości tak zwanej kontrybucji, czyli ulepszania tego standardu przez właściwie każdego zainteresowanego.

Oba standardy działają na wszystkich mainstreamowych systemach operacyjnych, ale tylko OpenCL współpracuje z innymi układami, niż te od Nvidii. Co więcej, w razie problemów OpenCL potrafi wykorzystać… jednostkę centralną komputera do dalszego przetwarzania danych potrafiąc, w przeciwieństwie do takich rozwiązań jak PhysX, wykorzystać wszystkie wątki tegoż procesora.

Zamknięta CUDA jest technicznie bardziej zaawansowanym produktem. Ogranicza jednak do jednego rodzaju sprzętu i rozwija się na chwilę obecną znacznie wolniej od OpenCL.

To kolejny, bardzo ciekawy pojedynek otwartej i zamkniętej techniki generowania grafiki. Oba wymienione w podtytule rozwiązania służą do synchronizacji pionowej obrazu. Dzięki nim obraz na ekranie nie rozjeżdża się w żaden sposób (tzw. screen tearing) poprzez wyświetlanie informacji z dwóch klatek obrazu w jednym cyklu renderingu na wyświetlaczu.

FreeSync powstał jako alternatywa do G-Sync, uznanego standardu. Jego twórcy postanowili więc zdobyć zainteresowanie poprzez otwartość rozwiązania. I to podejście się opłaciło.

FreeSync, z uwagi na zgodność z VESA, stał się jej częścią. A że właściwie każdy producent sprzętu służącego do wyświetlania obrazu dąży do zgodności z VESA, FreeSync stanie się szybko najchętniej używanym rozwiązaniem tego typu. Z uwagi że jest darmowy i stawia na DisplayPort, owo złącze powinno wkrótce znacznie zyskać na znaczeniu wśród graczy. Nvidia zapewne pozostanie przy G-Sync…

W niektórych przypadkach własnościowe standardy są wręcz zbyt niepraktyczne. Coraz popularniejsze są środowiska, w których współpracuje kilka procesorów o zupełnie różnej konstrukcji, przeznaczeniu czy architekturze. Nazywamy takie środowiska heterogenicznymi.

Coraz częściej pojawiają się one nie tylko w wyspecjalizowanych jednostkach obliczeniowych, ale również w procesorach konsumenckich. HSA (Heterogeneous System Architecture) pojawia się w układach SoC łączących rdzenie x86 i ARM, a także CPU i GPU.

Dzięki heterogenicznej strukturze, układ SoC może czerpać wszystko co najlepsze z obu światów. Układy APU mogą wykorzystywać moduł GPU nie tylko do renderowania obrazu, ale również do przetwarzania skomplikowanych obliczeń matematycznych a moduł CPU do systemu operacyjnego i do zadań szeregowych.

By deweloperzy mogli w pełni wykorzystać zalety tych rozwiązań przy zachowaniu zgodności z tradycyjnymi rozwiązaniami, musi powstać odpowiednia platforma deweloperska. Tym zajmuje się HSA Foundation, która promuje otwarte standardy w HSA. Należą do niej, między innymi, ARM, AMD, Imagination Technologies, MediaTek, Texas Instruments, Samsung i Qualcomm.

W efekcie powstało otwarte rozwiązanie HSAIL (HSA Intermediate Language), który eliminuje zaniżoną efektywność wywołaną koniecznością współdzielenia danych między poszczególnymi modułami pozwalając zarazem na pisanie aplikacji, które również zadziałają w środowisku nieheterogenicznym. Innymi słowy: mogą oni wykorzystać potencjał nadal niszowego rozwiązania, jakim jest HSA, a zarazem zachować zgodność z innymi środowiskami. Nie można było tego dokonać za pomocą zamkniętych, własnościowych rozwiązań.

Otwartość nie gwarantuje rozwoju czy dostępności powszechnej. Nadal niektóre własnościowe technologie są lepiej rozwinięte, a te otwarte są, co najwyżej, „nadzieją na przyszłość”. Przy czym owa nadzieja może zostać brutalnie zgaszona przez nową wersję zamkniętych rozwiązań. Z całą pewnością jednak otwartość ułatwia współpracę między podmiotami, a niejednokrotnie jest wręcz niezbędna.

Oba podejścia mają sens i oba mają przyszłość. A otwartość należy cenić. Do tej pory open-source’owe rozwiązania tyczyły się głównie niszowych, profesjonalnych zastosowań. Teraz dzięki nim mamy ładniejsze gry i procesory w naszych gadżetach, które umieją jeszcze więcej. Alternatywa stymuluje rozwój. Obu stron. Zwłaszcza, że zamknięte standardy najczęściej prowadzą do uzależnienia się rynku od jednego dostawcy danego rozwiązania.