OpenGL 4.5 już gotowy: w pogoni za Direct3D, ale z poszanowaniem potrzeb profesjonalistów

Biblioteka graficzna Microsoftu zdobyła popularność wśródtwórców gier nie tylko ze względu na popularność Windows, naktórym ich obecność była gwarantowana przez producenta. Direct3Dstał się z czasem technicznie bardzo udanym, innowacyjnym API,pozwalającym programistom na wygodne korzystanie z różnorodnegomiddleware (oprogramowanie pośredniczące).

Jedną z takich ułatwiających życie funkcji Direct3D jestDirect State Access (DSA), pozwalający na ominięcieskomplikowanego, niewygodnego cyklu wywołań, niezbędnych byprogram mógł operować na obiektach. Bez DSA, by np. ustawićwłaściwości tekstury, konieczna jest aktywacja jednostkiteksturującej, a następnie przypisanie tekstury do jednostkiteksturującej. Dopiero wtedy można ustawiać jej własności. O ilemasochistyczny programista robi to wszystko ręcznie, to mamy doczynienia ze zwykłą niedogodnością. Gorzej, jeśli sięga pojakieś biblioteki warstwy pośredniej – wtedy nie wystarczyprzypisać powiązań i aktywacji, trzeba je jeszcze po całejoperacji usunąć, by nie doszło do konfliktu z ustawieniami, któremogła narzucić sama aplikacja za pomocą middleware.

Z DSA programista może ustawiać i odpytywać właściwościwszelkich obiektów graficznych bez przejmowania się aktywowaniemjednostek graficznych i ich powiązaniami. Upraszcza to tworzeniemiddleware – i to jest jeden z powodów, dla których producencigier chętniej spoglądali w stronę Microsoftu.

Co prawda DSA zadebiutowało w OpenGL już jakiś czas temu, wrazz wersją 2.1, było jednak tylko rozszerzeniem, a nie oficjalnączęścią standardu. Programiści nie mogli liczyć, że w danejimplementacji OpenGL rozszerzenie to zostanie wykorzystane. Terazsytuacja ta się zmieni, tworzenie middleware dla OpenGL będziełatwiejsze, a to może skłonić producentów, by sięgnęli pod towieloplatformowe API, zamiast zamykać się w świecie Windows, jużnie tak panującego na rynku, jak było to dziesięć lat temu.

Pozostałe istotne zmiany w nowym OpenGL to przede wszystkimwiększa kontrola nad przesyłaniem poleceń do procesora graficznegoi ich wykonywaniem. Ma to przede wszystkim pomóc przeglądarkom, wktórych oczekuje się (w imię bezpieczeństwa i stabilności)kompletnej izolacji programów 3D napisanych w WebGL – webowejodmianie OpenGL.

Grupa Khronos poinformowała również o wydaniu języka SPIR 2.0,będącego językiem pośredniczącym do obliczeń równoległych naprocesorach graficznych. W teorii przypomina to OpenCL, ale OpenCLjest językiem C-podobnym, podczas gdy wielu programistów nieprogramuje w C, ale np. C++ czy Pythonie. SPIR rozwiązuje tenproblem dzięki kompilatorom dla różnych innych języków,przekształcających z pomocą kompilatora LLVM napisany w nich kod wkod SPIR, który następnie uruchamiany jest na maszynie wirtualnejOpenCL uruchomionej na docelowym urządzeniu. Wersja 2.0 tego językaprzynosi pełną obsługę OpenCL 2.0.

Warto podkreślić, że Grupa Khronos widzi jednak w OpenGL nietylko interfejs grafiki do gier, ale też interfejs dlaprofesjonalistów, spełniający wymagania producentówprofesjonalnego oprogramowania graficznego – czyli w świecie, wktórym Microsoft czy ludzie od gier nie mają praktycznie nic dopowiedzenia. W dalszym rozwoju OpenGL nie powinniśmy się więcspodziewać jakichś radykalnych zmian, choćby ze względu na obawęna reakcję tychże producentów. Będzie on przebiegał w znaczniebardziej ewolucyjny sposób, niż np. w wypadku wspomnianego MantleAPI, w którym AMD zainteresowane jest jedynie wydajnością,wydajnością i jeszcze raz wydajnością.

Nie oznacza to, że Khronos zamierza odpuścić sobie rynek API dla graczy. Wręcz przeciwnie. Dzisiaj poinformowano także o rozpoczęciu prac nad budowanym od podstaw OpenGL Next Generation. To z założenia uniwersalne API grafiki nie będzie kompatybilne z klasycznym OpenGL-em, w zamian jednak ma zapewnić znacznie większą wydajność dzięki zbliżeniu do sprzętu i większej kontroli nad obciążeniami roboczymi zarówno GPU jak i CPU. Więcej o OpenGL NG napiszemy już niebawem (jak tylko przeczytamy szkic dokumentacji).